1. Let the group project commence!
Lecture 3

2. So where do we start? Start coding, right?
**NO!**
A little time spent planning is well worth your time.
You should address several issues before coding.

3. Question #1: What are we making?
Make sure everyone in the group is sharing a common vision.
Some ideas:
A design document
In Jason’s opinion, a massive tome (aka “design bible”) is wasted effort*
A one-page vision statement (bonus points for pictures) is better
Sketches
Sample Levels (again, sketches)
…in other words, a pitch. But a refined pitch document.
Take this to the bank: “If no one reads it, a document has no value.”
*If we were working under the supervision of a seasoned lead programmer, this might make sense. But we’re not that lucky…

4. Question #2: How will we communicate?
In class, F2F (face-2-face) is ideal.
Issues we need to coordinate:
What are our short-term and long-term deliverables?
We also need to consider long-term milestones.
Who is working on what?
Is it getting us closer to a deliverable?
How do the different jobs connect to each other?
E.g. which methods does classA call of classB, and when?
Often called an API (Application Programming Interface)
Bugs that need fixed.
In addition to F2F, here are some tools to consider:
A daily / weekly standup (scrum)
A google document (again, no value if no one reads it)
Scrumy.com [Show it]
Other alternatives: Trello, Slack (The school may not have the $$ for these…)

5. Question #3: How will we share files?
Some initial thoughts (and problems):
Flash-drives
Very fragile
What if two people edited the same file? Manual merge.
Dropbox or similar
Someone could accidentally delete / modify something they shouldn’t have
Still have to do manual merges

6. Q3, continued. Enter Version Control Advantages over other methods:
Many protocols: CVS, SVN, Git, Perforce, …
Hosting: on atlas (Perforce, SVN), bitbucket, github, …
Advantages over other methods:
Logging (who did what, when)
Ability to “check out” a particular revision
Branching (e.g. a trunk for most development, branches for experimental stuff)
Semi-automated merging (sometimes the diff tool needs help)
Reports (e.g. ranking by commits, what changes have been made to file x, …)
[Insert SVN demo here]

7. Question #4: code style Design Philosophy, two extremes:
Loosey-goosey (normal python, little error checking)
Very structured (more like Java, lots of error checking)
In a large project, it needs to be maintainable
How this is met depends on the team dynamic, the language, etc.
Code Structure (often in a Technical Document*)
Classes? Modules?
Don’t try to plan everything…
xkcd
*again, I’m not sure this has a lot of value for us (like the Design Bible) – just talk it out

8. Question #5: People-skills
Working in a group is hard.
Everyone is passionate about this, but we have very different opinions
Some behaviors to avoid:
“The Hero”: Tries to do everything
Be willing to let others work on something even if it’d take longer than you
“The Hermit”: Afraid of wrecking something
Version control should remove some pressure
“The Perfectionist”: Won’t commit anything until it’s 100% perfect
Integrating early is much easier than later.
“The Procrastinator”

9. Question #6: Conflict Resolution
It will come up.
We’re all individuals that love gaming but have different opinions
We’re all at different skill levels
It’s actually a healthy thing
Advice that (maybe) makes it better:
Be professional and courteous
Make sure criticism is constructive
E.g. “What if tried ___” rather than “____ is a bad idea”
E.g. “Could you explain ____” rather than “____ broke my code.”
Don’t shut anyone out or make anyone feel useless
Even if you are the greatest Rockstar programmer in the world (hint: you’re not)
Attempt to resolve conflicts yourself. Talk to Jason in private if you see a problem arising.

10. Question #7: Where to start
Shoot for a MVP (Minimal Viable Product) asap.
Try to plan and code all essential features.
See if it’s fun.
Sometimes called a Whitebox Level
Since often the final art isn’t ready
Players, tiles, etc. are just boxes (some of them white)
If the games fun now, it’ll be that much more fun with music, actual art, etc.

11. Let the games begin!