Let the group project commence! Lecture 3

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.

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…

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…)

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

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]

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

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”

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.

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.

Let the games begin!