In this entry about project management, I will be describing the process in which our team defined the scope of the game we would be making and the role I took within this activity. With my current knowledge of the project state and the experience gained from doing this, I will try to reflect on what went right, what went wrong, how we resolved issues and what we should have done differently. As this topic of defining scope will become even more relevant going forward to Module 2 (since we will need to finalise our game design in terms of features and interactions), I think it would be useful to identify what we can do differently when re-scoping and what we should really make use of again in the game design process.
Initial efforts to define scope/make design decisions
We started off, quite understandably, not knowing where to start. Our initial brainstorming sessions gave us a bunch of ideas written down in terms of theme, mechanics and characters. The purpose of the exercise as stated by Oliver, was to gather as many ideas as we can, start trying to combine them and see if any of them stick. While we were able to narrow down some favourites, it was still difficult to be decisive about this: all members have an equal say in the team and everyone has something or another that they like best, hence it gets tough to narrow down the choices. I find that completely to be completely reasonable, since as long as we have creative freedom in the project, it would be best if we can all work on something that we like, rather than being stuck with someone else’s idea which you don’t fully agree on.
While we could agree on our basic core mechanic, which was selected to be “Dash”, and we could identify the types of gameplay we want to have (by dissecting the Minimal Viable Product this gave us the platform types, event-driven interactions, basic controls), we were torn between several other issues:
– The theme of the game. This split the team in half between Ancient Greece and Apocalyptic. There was a crucial mistake we were making which was pointed out by Oliver, in that we were all arguing about something that is actually an art question. After this was pointed out, I realized and suggested that the artists make this decision, as it is most significant towards their work. They ended up picking Ancient Greece based on the fact that there’s a more common vision for this theme, as well as abundant references. While I preferred the Apocalypse theme, I stepped down and withdrew from the discussion: if the artists choose what they are most comfortable with, this should lead to better art and team performance between the artists. Looking back at it, I am glad I did so, as the concepts being produced are really well done and the artists do seem to have a common view on how they imagine the theme.
– Face controls vs. Gestures and the Dash button. We started arguing about this one quite a lot. This discussion was based purely on our personal insights and views, such as “performing a dash in mid-air is too difficult, lets not have that” and “the dash and jump should be the same button that alternates depending on whether you’re jumping or not.” This whole discussion sounds absurd when I think about it – no one had any reasonable ground to justify what they were saying, but more on that later.
– Puzzle focuses vs. Action focused. This started up a heated discussion as well, as some people felt they really want a puzzle game, while others argued that it’s easier to do an action-y platformer, and then the first group saying “You can’t be precise on a tablet so that won’t work” and so on and so forth. This was the second mistake we made – we should not have been arguing about this at all at this stage.
To try and solve some of these issues, I suggested asking Oliver and Zuby for input in hopes that we could use their experience to identify what we’re doing wrong and maybe narrow our ideas down further. Zuby then immediately shot all of our arguments down by asking a crucial question (which went something along the lines of) “Did you research any of this?” The answer was “no”, we were arguing with nothing to support our views apart from our personal preference. While everyone seemed to have realized this, soon after we were having the same arguments again.
The lengthy list of questions and the research
To help somehow remedy this, I took a look at the game brief while the others continued to discuss these key issues. I then proceeded to write down a set of questions from the game brief, as we needed something to base our research on. What I ended up with was this (rather lengthy) list of questions:
Who is today’s gamer?
What do we want in terms of themed level structure? How many themes can we manage? (This is about the changing settings every few levels )
In what ways are 3star ratings used in other games? What determines the star rating awarded to the player? (Time, pick ups, enemies defeated, specific objectives, etc.)
How much gameplay/mechanics can be put in to a single-screen level?
What level starts/exit conditions are used in other games? Do they end a level after the player picks something up? Goes through a door? Other conditions? How does the player “unlock the exit”?
What kind of platform puzzles exist in other games?
What kind of event-driven mechanics do other games use? (Switches/buttons/etc.)
What kind of different platform behaviours exist in other games? (Travelators, crumbling platforms, etc.)
What are the enemy behaviours encountered in other platformer games? What kind of patterns do they follow?
What are the ways to avoid/destroy enemies in other platform games?
What are the common control schemes for other phone/tablet platformers?
What kind of projectiles (if any) do enemies use in platformer games?
What are the tablet game UI norms in terms of in-game menus etc.?
How are the start screens organised for games? What options are presented?
What are the possible game over states used in tablet platformers?
How is character movement defined in other tablet platformers? Is the character fast/slow? Do controls require precision?
How do tablet platformers establish a difficulty curve? In what way do the levels get progressively more difficult?
How can a tablet platformer be made accessible to both novices and experienced players?
Specifically for dash mechanics:
How do touch based games implements dash mechanics?
Other mechanics to consider/research in platformers:
Switches, pushable blocks, pick ups, buttons. How are these implemented? (Listed in the brief as event-driven mechanics which we should have in the game)
I proposed that we all look at other (similar genre/platform) games in the evening (preferably different ones) and try to answer these. After all, we all like playing games, and we would be doing research while we’re at it. We decided that we’d finish the discussion the following day, hopefully having some ground to support our claims.
I personally researched Sword of Xolan (2015), Blym (2013), League of Evil (2011), Commander Pixman (2011) and Moy’s World (2013). Having this research turned out to indeed be a great idea, as it gave me a clear understanding at the time (and also later) as to how good character controls feel. Furthermore, League of Evil (2011) had a dash mechanic in it, and this allowed me to evaluate how it’s done and whether it works well in that game. This gave me evidence enough to solve our question of control scheme – we managed to find one that works well!
During the research process, Blym was a single-screen puzzle platformer (perfect match for our genre?) which was clearly focused on puzzles and not on action. This was the only pure puzzler I could find (apart from Headless Zombie (2013)) and it was done really well. So now we had both Action based games and Puzzle based games to compare when discussing the Action vs. Puzzle question.
Doing this research really helped when deciding the control scheme, but not so much when discussing the genre question. In general, I (and I think the whole team) found researching gameplay to be incredibly useful when unsure about game design – we kept referring to these games researched throughout Module 1 when discussing what works and what doesn’t. This is something we should do even more during the Production phase, I think.
In terms of what potentially didn’t work so well – playing different games. This raised two problems: everyone saw different great games, so everyone’s opinion as to what makes a good mobile platformer diverged even further (making communication and shared views more difficult) and discussing something one game did really well was difficult, as some team members have not played it and don’t know what I’m (or someone else) talking about. Going forward, I feel that we should all research the same games instead, as that makes for better discussion, as well as gives second opinions on whether “that game did this thing really well” indeed.
Why are we talking about this?
This was a phrase spoken by my colleague Radu about the face button positioning or something similar that has stuck with me. I thought the exact same thing – Why are we arguing whether our game should be action focused or puzzle focused? Deciding at the beginning of the project would put us in a very waterfall-like design, where we become inflexible.
The good thing about that would be having more focus and direction towards what the game we are developing should be.The bad thing about it, is that waterfall-ish decisions are, well, inflexible. And inflexible projects don’t like risk – they can’t adapt to it well. Therefore, before making this decision, one should think – is it a low-risk decision? I can’t help but say that answering “yes” to this question is incredibly naive in all but the most trivial decisions. We can’t read the future, and we can’t predict it too well – predicting requires a great amount of experience (which we, uh, lack).
And there was a major risk with this action vs. puzzle decision that gave me red flags instantly: we are not expert designers; designing puzzles is difficult; can anyone confidently say that they can make interesting puzzles? No-one in our team could make such a bold claim, making the risk really evident. So while the team was leaning towards puzzles, we could not commit to it. I proposed to let the genre of our game evolve as we go along and make that decision further down the line, when we have our mechanics and see if they can facilitate interesting puzzles. So I proposed what I thought would be the best way to mitigate this risk: instead of creating a focused genre game, lets create a toolbox of mechanics to play with and see which direction it takes us – action or puzzler? This is what we stuck with and this is what we have developed.
Emerging puzzles and gameplay
Letting the genre and the gameplay develop based on building fun gameplay tools really paid off (I think). A good example of this is how we developed the different enemy types in the game through team design meetings. We have four of those currently:
– Cyclops which is your standard patrolling enemy.
– Harpy (I think that’s the name), which is our standard patrolling air enemy.
– Minotaur, which can charge at the player and needs to be stunned first to be killed.
– Medusa (or Gorgon), which has a deadly gaze and can be turned to stone and act as a pushable platform for a period of time. It is un-killable, only temporarily turnable to stone.
These are quite standard and not special at all until you consider them interacting with each other and their environment. Lets look at the Minotaur. When it charges at the player, the player can dodge it by jumping over it. What happens then? The Minotaur might hit an enemy and kill it. It may hit a pushable block and slam it up with its horns (therefore moving it somewhere that the player couldn’t move it before). It may hit a Medusa and kill her (so you can’t use the Medusa as a platform anymore). It may hit a breakable wall which the player couldn’t have broken themselves. What happens if a Medusa applies its death beam to another enemy? They might turn to stone and you would get an extra movable platform.
The enemies are only a few of the features that can provide different puzzling possibilities by interacting with each other. As far as puzzle design goes, giving the player enough choices to interact with the level would make the puzzle harder and more interesting. The fact that you could now build levels where there is a huge amount of distinct possibilities and interactions is definitely a positive thing, as the player would need to think how to best use these interactions to beat the level.
I don’t think we would have been able to come up with such gameplay from the start, and the fact that this emerged from simply implementing enemies is good enough evidence that we were right to not make the decision from the start. Furthermore, since we would have not considered such interactions from the start, making early commitments would only be a barrier towards using these emergent elements in our game. We would be less prone to adapt. However by deferring the choice, we are free to review what we have in our game and decide how we want to move forward. I think this is something we should keep doing – re-scope our project as appropriate as we move along.
The woes of re-scoping
The one big problem with re-scoping as we go, is the question “when do we stop?” If we keep adding new features, we might end up adding way more than we can do and the game will be at risk of not being finished. So we need to remain aware of this and plan accordingly to be able to draw a line and start working with what we have to construct the game out of it. Being agile does not draw this line for us, and it’s up to the team to be sensible about time constraints and feasibility to ensure that the project gets finished (and finished well). As long as we try and remain realistic about our ability, we should be able to decide this halting point (then make it even earlier to compensate for our naiveness) and finish the game as planned.
Godsend Project Management #1: Defining Scope
In this entry about project management, I will be describing the process in which our team defined the scope of the game we would be making and the role I took within this activity. With my current knowledge of the project state and the experience gained from doing this, I will try to reflect on what went right, what went wrong, how we resolved issues and what we should have done differently. As this topic of defining scope will become even more relevant going forward to Module 2 (since we will need to finalise our game design in terms of features and interactions), I think it would be useful to identify what we can do differently when re-scoping and what we should really make use of again in the game design process.
Initial efforts to define scope/make design decisions
We started off, quite understandably, not knowing where to start. Our initial brainstorming sessions gave us a bunch of ideas written down in terms of theme, mechanics and characters. The purpose of the exercise as stated by Oliver, was to gather as many ideas as we can, start trying to combine them and see if any of them stick. While we were able to narrow down some favourites, it was still difficult to be decisive about this: all members have an equal say in the team and everyone has something or another that they like best, hence it gets tough to narrow down the choices. I find that completely to be completely reasonable, since as long as we have creative freedom in the project, it would be best if we can all work on something that we like, rather than being stuck with someone else’s idea which you don’t fully agree on.
While we could agree on our basic core mechanic, which was selected to be “Dash”, and we could identify the types of gameplay we want to have (by dissecting the Minimal Viable Product this gave us the platform types, event-driven interactions, basic controls), we were torn between several other issues:
– The theme of the game. This split the team in half between Ancient Greece and Apocalyptic. There was a crucial mistake we were making which was pointed out by Oliver, in that we were all arguing about something that is actually an art question. After this was pointed out, I realized and suggested that the artists make this decision, as it is most significant towards their work. They ended up picking Ancient Greece based on the fact that there’s a more common vision for this theme, as well as abundant references. While I preferred the Apocalypse theme, I stepped down and withdrew from the discussion: if the artists choose what they are most comfortable with, this should lead to better art and team performance between the artists. Looking back at it, I am glad I did so, as the concepts being produced are really well done and the artists do seem to have a common view on how they imagine the theme.
– Face controls vs. Gestures and the Dash button. We started arguing about this one quite a lot. This discussion was based purely on our personal insights and views, such as “performing a dash in mid-air is too difficult, lets not have that” and “the dash and jump should be the same button that alternates depending on whether you’re jumping or not.” This whole discussion sounds absurd when I think about it – no one had any reasonable ground to justify what they were saying, but more on that later.
– Puzzle focuses vs. Action focused. This started up a heated discussion as well, as some people felt they really want a puzzle game, while others argued that it’s easier to do an action-y platformer, and then the first group saying “You can’t be precise on a tablet so that won’t work” and so on and so forth. This was the second mistake we made – we should not have been arguing about this at all at this stage.
To try and solve some of these issues, I suggested asking Oliver and Zuby for input in hopes that we could use their experience to identify what we’re doing wrong and maybe narrow our ideas down further. Zuby then immediately shot all of our arguments down by asking a crucial question (which went something along the lines of) “Did you research any of this?” The answer was “no”, we were arguing with nothing to support our views apart from our personal preference. While everyone seemed to have realized this, soon after we were having the same arguments again.
The lengthy list of questions and the research
To help somehow remedy this, I took a look at the game brief while the others continued to discuss these key issues. I then proceeded to write down a set of questions from the game brief, as we needed something to base our research on. What I ended up with was this (rather lengthy) list of questions:
Specifically for dash mechanics:
Other mechanics to consider/research in platformers:
I proposed that we all look at other (similar genre/platform) games in the evening (preferably different ones) and try to answer these. After all, we all like playing games, and we would be doing research while we’re at it. We decided that we’d finish the discussion the following day, hopefully having some ground to support our claims.
I personally researched Sword of Xolan (2015), Blym (2013), League of Evil (2011), Commander Pixman (2011) and Moy’s World (2013). Having this research turned out to indeed be a great idea, as it gave me a clear understanding at the time (and also later) as to how good character controls feel. Furthermore, League of Evil (2011) had a dash mechanic in it, and this allowed me to evaluate how it’s done and whether it works well in that game. This gave me evidence enough to solve our question of control scheme – we managed to find one that works well!
During the research process, Blym was a single-screen puzzle platformer (perfect match for our genre?) which was clearly focused on puzzles and not on action. This was the only pure puzzler I could find (apart from Headless Zombie (2013)) and it was done really well. So now we had both Action based games and Puzzle based games to compare when discussing the Action vs. Puzzle question.
Doing this research really helped when deciding the control scheme, but not so much when discussing the genre question. In general, I (and I think the whole team) found researching gameplay to be incredibly useful when unsure about game design – we kept referring to these games researched throughout Module 1 when discussing what works and what doesn’t. This is something we should do even more during the Production phase, I think.
In terms of what potentially didn’t work so well – playing different games. This raised two problems: everyone saw different great games, so everyone’s opinion as to what makes a good mobile platformer diverged even further (making communication and shared views more difficult) and discussing something one game did really well was difficult, as some team members have not played it and don’t know what I’m (or someone else) talking about. Going forward, I feel that we should all research the same games instead, as that makes for better discussion, as well as gives second opinions on whether “that game did this thing really well” indeed.
Why are we talking about this?
This was a phrase spoken by my colleague Radu about the face button positioning or something similar that has stuck with me. I thought the exact same thing – Why are we arguing whether our game should be action focused or puzzle focused? Deciding at the beginning of the project would put us in a very waterfall-like design, where we become inflexible.
The good thing about that would be having more focus and direction towards what the game we are developing should be.The bad thing about it, is that waterfall-ish decisions are, well, inflexible. And inflexible projects don’t like risk – they can’t adapt to it well. Therefore, before making this decision, one should think – is it a low-risk decision? I can’t help but say that answering “yes” to this question is incredibly naive in all but the most trivial decisions. We can’t read the future, and we can’t predict it too well – predicting requires a great amount of experience (which we, uh, lack).
And there was a major risk with this action vs. puzzle decision that gave me red flags instantly: we are not expert designers; designing puzzles is difficult; can anyone confidently say that they can make interesting puzzles? No-one in our team could make such a bold claim, making the risk really evident. So while the team was leaning towards puzzles, we could not commit to it. I proposed to let the genre of our game evolve as we go along and make that decision further down the line, when we have our mechanics and see if they can facilitate interesting puzzles. So I proposed what I thought would be the best way to mitigate this risk: instead of creating a focused genre game, lets create a toolbox of mechanics to play with and see which direction it takes us – action or puzzler? This is what we stuck with and this is what we have developed.
Emerging puzzles and gameplay
Letting the genre and the gameplay develop based on building fun gameplay tools really paid off (I think). A good example of this is how we developed the different enemy types in the game through team design meetings. We have four of those currently:
– Cyclops which is your standard patrolling enemy.
– Harpy (I think that’s the name), which is our standard patrolling air enemy.
– Minotaur, which can charge at the player and needs to be stunned first to be killed.
– Medusa (or Gorgon), which has a deadly gaze and can be turned to stone and act as a pushable platform for a period of time. It is un-killable, only temporarily turnable to stone.
These are quite standard and not special at all until you consider them interacting with each other and their environment. Lets look at the Minotaur. When it charges at the player, the player can dodge it by jumping over it. What happens then? The Minotaur might hit an enemy and kill it. It may hit a pushable block and slam it up with its horns (therefore moving it somewhere that the player couldn’t move it before). It may hit a Medusa and kill her (so you can’t use the Medusa as a platform anymore). It may hit a breakable wall which the player couldn’t have broken themselves. What happens if a Medusa applies its death beam to another enemy? They might turn to stone and you would get an extra movable platform.
The enemies are only a few of the features that can provide different puzzling possibilities by interacting with each other. As far as puzzle design goes, giving the player enough choices to interact with the level would make the puzzle harder and more interesting. The fact that you could now build levels where there is a huge amount of distinct possibilities and interactions is definitely a positive thing, as the player would need to think how to best use these interactions to beat the level.
I don’t think we would have been able to come up with such gameplay from the start, and the fact that this emerged from simply implementing enemies is good enough evidence that we were right to not make the decision from the start. Furthermore, since we would have not considered such interactions from the start, making early commitments would only be a barrier towards using these emergent elements in our game. We would be less prone to adapt. However by deferring the choice, we are free to review what we have in our game and decide how we want to move forward. I think this is something we should keep doing – re-scope our project as appropriate as we move along.
The woes of re-scoping
The one big problem with re-scoping as we go, is the question “when do we stop?” If we keep adding new features, we might end up adding way more than we can do and the game will be at risk of not being finished. So we need to remain aware of this and plan accordingly to be able to draw a line and start working with what we have to construct the game out of it. Being agile does not draw this line for us, and it’s up to the team to be sensible about time constraints and feasibility to ensure that the project gets finished (and finished well). As long as we try and remain realistic about our ability, we should be able to decide this halting point (then make it even earlier to compensate for our naiveness) and finish the game as planned.