In the Game Project course students design and develop a game from a scratch to (at least) beta level. It is obvious that current version of the game project course has some flaws. Currently the structure suffers issues of the big-design-first model. The course milestones set does not require prototyping and iteration. This has worked somewhat, and it seems that groups are creating interesting games. However, the last deadline is looming and they have a lot of to do to get their games ready.
To improve the course in the future, I searched alternative approaches to game development process for the Game Project course and found Clinton Keith’s (2010) book Agile Game Development with Scrum.
The overall structure of project in Scrum is show the figure below.
Roughly, a Scrum project consist of sprints that last two to four weeks and have a clear target. Each sprint starts with planning meeting in which the target of the sprint is set. The target is a feature list that should be developed by the end of the sprint. The initial list of the features are features (and each feature have a priority) are set in the concept sprint. Each sprint contains design, asset creation, coding, and testing. After each sprint, the team should have a working game build. (Keith 2010.)
I am yet not exactly sure how to adapt Scrum for the course, as there are some roles (such as Scrum master) that might need rethinking for the course context.
However, I like the idea of sprints. Students would set targets for each sprint with the teacher. Two to four weeks sprint in the course lasting almost the whole academic year means 7 to 14 sprints. That would split the goals to more manageable smaller sub-goals, as each sprint has its own feature list that should be ready at the end of the sprint. The Scrum process has natural checkpoints (at the end of each sprint) where we can check how the project progress.
Keith. C. 2010. Agile Game Development with Scrum. Addison Wesley.
7 thoughts on “Some Refelections on the Game Project Course”
Sounds good. We have had a weekly status check and task assignment meeting, but we haven’t specified our “goals” very specifically (like in scrum sprint targets). Also, I think a week is a bit too long time between these kinds of meeting, but unfortunately it seems that people’s schedules are quite diverse and figuring out a time that works out for anyone can be quite difficult.
The most important thing that should be thought of (considering the next game project), at least in my opinion, is defining a design process that explicitly specifies how to use the needed/available tools efficiently. By this I mean how to use Unity when many people are working on the same project, version control, asset management etc.
I agree that the asset pipeline and sharing a project should work without issues next time.
I thought that the process how share the project was already defined and working, as we have a working process for that earlier. Unfortunately, Unity 3 surprised me when it refused to use networked drives as it did earlier and I was not clever enough to check with Unity 3 performs with networked drives. Now, it seems that the only easy to use, working alternatives are asset server or external version control feature of Unity pro.
I think this would be an improvement over the current structure. I just want to add that in my opinion the games that are developed on this course should focus more around fun mechanics and refined gameplay rather than story, which is what the current murder mystery requirement implies. The previous Game Design and Analysis courses were also mostly about mechanics so it would be a logical continuation from those.
Also, I second what Jussi said about defining the development process.
While the game courses did not cover story-writing, both groups have people doing our interactive storytelling courses. I thought that there is a possibility to introduce storytelling element here. However, you have a good point: the game courses have not covered some relevant topics (such as how game system and game mechanics can works storytelling device, which might not be covered in the storytelling courses). Using storytelling dimension in assignment is definitely something I need to rethink.
Hey, yes I think the SCRUM idea is great. At least this is how some professional companies work, so its good if we can follow a similar workflow.
There is difficulty working as a group meeting only once a week. Maybe along with sprints, there should be workshops where the students are designing together during a weeks time, and then one or 2 weeks of break or solo work. There also should be someone prioritising all the assets, which has been hard with everyone on doubleduty for all kinds of design and programming and art needed in the game, so maybe the teacher could facilitate this or some other individual.
The aim of the project was hard to get, in that express the words ‘hot, beautiful, paranoid’ is quite an abstract concept, so maybe concretely, it can be described what is important to convey, the feeling, theme, or to make mechanics that support these themes/feelings, or all of the above – but something must be more important than the other. From a learning point of view, all these requirements listed are challenging and rewarding to learn, its just that within such a small time frame, making an excellent game is very challenging if we need to meet all these requirements. For example, with paranoia, it could have been thematic, or we could use gameplay that induces paranoia, but it would be hard for the team to decide together what is better unless we understand the context of the whole learning objective. It might be too open letting us choose. I would probably choose gameplay.
I think the game development would be easier if everyone stuck to a role, because coming to agreement with everything in the game has been very hard with the opinions of six different people. And if some people did agree on something, another element might suffer. Because obviously someone programming the game has a different point of view from the artist, who has a different point of view from the storywriter, we are each caring more about some different aesthetic.
I would have liked to approach the game design in steps, where we answer the fundamental questions first. Like what are we trying to achieve? What kind of game are we trying to make? Who is the audience? And with these questions answered, then making the game mechanics to support that. I felt like we started to choose mechanics for the project without the framework of these questions.
Designing good interfaces for UI isn’t covered much by media lab, apart from maybe the one prototyping workshop Markku had, but it seems like we need in part to at least have one lecture on designing interfaces, because its important for the user experience. And that’s really what gaming is about.
It might be interesting to structure the lectures so they coincide with the stages we are at in the game design phase, so that it gives some thought provoking content while we are designing.
Gameplay progression should be designed alongside a story, if we have this kind of game which requires there is a history to what happened (someone was murdered, how where why etc). In platformers or puzzle games it might not be relevant, or have low relevance how well the story is designed, but in our case of a murder mystery, it is almost a given. Even without dialogue, you would need to design a story with the game elements and game progression, so basically you would need to write a script. I felt like we approached the game design document with elements separated and not exactly in the order that would aid design. My preferred order would be to design a story and game progression to fit the aims of the project (whether its a psychological feeling of paranoia, or the theme of paranoia) and then design the mechanics to suit this, and a UI to communicate this. I felt like too many of these decisions were taken within isolation, and this probably comes from the fact that everyone had a different vision for the game, but if there was a single, most important aim for this game given, then maybe it would have been easier to unite the visions and approach in a clearer design progression.
– The goal of creating an excellent game is really ambitious. The requirement for the course is playable game at least beta level completion (no gold master level polish is required).
– One main thing you should learn is to group work and negotiating between different requirements coming from customer (teacher), game design, asset creation, coding, etc. and getting the game ready. As you noticed, communicating ideas is hard as well as making decisions and following what has been decided.
– Scrum type process is intended to involve all team members to design sprint (features) and collaborate in development within sprints.
– If the process follows Scrum, there should be no solo work.
– I am not keen on teacher stepping in to facilitate assets creation (except as in this year: there is a small budget to buy asset and you can animators/musicians/etc. to help with those parts and they can get credits), because prioritizing asset creation requires practice.
– Well as an artist, i guess I hope just to create something that gives a deeper emotion than just any game.
– About the scrum process, at least yeah I know that the team works on sprints. For solo, I meant that asset creation like code and graphics etc, need a time to be done also, and that they can do in their own time. The point about the one week break was mostly because people cannot be at our class every week unless they are studying only game design.
– yeah we should practice this, though the team is pretty much so that everyone is busy, and from my experience, we have been communicating just verbally when meeting what needs to be done, what has been done, but the online pipeline hasnt been working that well because maybe everyones priority has been content creation and there has been not much management so to speak.