Digital Game Production - Writeup
This assignment is due on Friday 6/8.
We are entering the Production phase of the project. This is Step 6 of the Playcentric Design Process. You will complete three week-long sprints during the Production phase, including two Playtesting sessions.
Deliverables
With such a large project there are multiple deliverables:
- At the end of each sprint we will have an in-person check-in to discuss progress in your game.
- During the production process we will have two playtesting sessions that will require a short worksheet that can be completed in class.
- I will also ask about specific playtesting results used in your development.
- You will use project management software to track to-do items, and I will require that to-do items be assigned to each team member and completed at the end of each sprint.
- Throughout the production process you should also be working on your Design Document.
Sprint Check-ins
The structure for each consecutive sprint will be mostly the same:
1. Project Management
I want you to use a project management system to assign and track work on your project. The issue trackers built in to Github and Gitlab are both excellent choices for this. You can also use Trello if you prefer. Any other reasonable issue tracking software is allowable assuming that I am able to access and use it. Please let me know if you plan to use software other than the three above recommendations.
These sorts of software are set up to be used as an issue tracking solution - that is, for keeping track of and resolving bugs in a software project in some form of a release stage. However, it is reasonable (and common) to use them simply to track to-do items. The difference between an issue and a to-do item is that an issue usually refers to something that is broken, e.g. “using this feature causes the app to crash” while a to-do item can be more nebulous, such as “look into a way that we can add this to our game”. In many Agile paradigms this set of to-do items is referred to as the Product Backlog.
Expectations
Near the beginning of each sprint I will review the items in your product backlog to get an idea of what you aim to complete by the end of the sprint. Ideally I would like to see at least one item in the issue tracker assigned to each team member. Remember that this is a tool to aid you in your development process. Feel free to add any and all relevant thoughts, comments, and discussion to the issues in your issue tracker.
It’s also absolutely fine if you end up planning too little or too much for your sprint. That’s one of the goals of an iterative development framework - you can use your progress on previous sprints to help inform your planning for future sprints.
2. Demo
On sprint deadline days I want to meet with each team individually to discuss current progress, the completed and incomplete tasks for that sprint, and the goals going forward. Mostly I would like to see playable demos!
I want to allow up to 10 minutes with each team, so check-ins will occur in both lecture and lab period. If we have about ten teams, two 50 minute class periods, it should all work out.
At the start of class I will set out a sign-up sheet for teams to reserve a 10-minute slot. I’m hoping to keep every check-in under 10 minutes so that it is easy to stick to the schedule.
Sprint Deadlines
See the course schedule for sprint deadlines.
The Grading Rubric for this assignment can be found here.
Playtesting
Session 1
It’s not important that you have anything particularly playable or complete for this playtesting session. This is just a chance for you to get some early feedback from your classmates. I suspect that a lot of feedback will be about adding things that you are planning to add, but you may learn something about an existing mechanic that you hadn’t thought about. And it can help you prioritize what aspects of your game to work on next.
Your fellow classmates are somewhat difficult to classify as playtesters. They are not members of your design team, nor are they necessarily confidants since you may not know them well. However, they are all familiar with the playcentric design process, the principles of playtesting, and other game design topics. They are likely aware of at least what kind of game you are making. As such it is reasonable to playtest your classmates’ games, even if those games are still in the Foundations or Structure stages of development.
I won’t ask that you write up a script for this playtesting session, since I’d like to keep it somewhat informal. Also, you don’t really need to explain the playtesting process since you are all familiar with it. However, you should think about how you can get the most valuable information out of this playtesting session. Consider setting up test control situations, or modifying your test levels to allow further exploration of your foundational mechanics.
And don’t forget that this is just the first playtesting session, and is to some degree an experiment in early playtesting. The author of our textbook says that you should playtest often and early, so we are going to try it out! You will have further opportunity to playtest a more final version of your game when we do the second playtesting session, and when we have final project displays during the final exam period.
There will be a small worksheet/survey for you to fill out during the playtesting session, reporting some brief notes on what you learned from the session and how useful it was to playtest this early. You should all make more detailed notes about the playtesting for your own use. You can playtest in either the lecture or lab hour.
Session 2
Playtesting Session 2 will be much like Playtesting Session 1 except your games should be more complete by now. This will likely mean some more relevant feedback and observations, but the information might be less actionable since we are so far into the development process.
Remember that playtesting is just as much (and maybe moreso) about making observations about people playing your game as it is about mining them for feedback and suggestions after they’re done!
This is definitely the time to set up Test Control Situations if it’s relevant for your game. There will be a small worksheet/survey for you to fill out during the playtesting session, reporting some brief notes on what you learned from the session and how useful this second playtesting session was. You should all make more detailed notes about the playtesting for your own use. You can playtest in either the lecture or lab hour.
Rubric
| Points | Content |
|---|---|
| 30 |
Project Management
|
| 70 |
Game production
|
| 30 |
Playtesting
|