Game Development – Introduction: Week 1

New course, new project!

Our big assignment in this 10 weeks long course is to turn one of the concepts that were made by all students during the previous course into a playable game while using the Scrum-framework for project management.

Our milestones for this project are:
———————————————————————————————–

Week 1 (19th January – 25th January):
– No hand-ins

Week 2 (26th January – 1st February):
– Write down feature definitions for our intended game and breaking these down into concrete tasks for code, art, audio and design.
– Write these taks down into our Scrum-template and create a product backlog by sorting these by risk and priority.
– Hand in the product backlog by Friday 30th.

Week 3 (2nd February – 8th February):
– No hand-ins

Week 4 (9th February – 15th February):
– Fill out the Game Design Document template and hand it in by Friday 13th. *(O_o)*

Week 5 (16th February – 22nd February):
– ALPHA VERSION HANDIN by Friday 20th.

Week 6 (23rd February – 1st March):
– No hand-ins

Week 7 (2nd March – 8th March):
– No hand-ins

Week 8 (9th March – 15th March):
– BETA VERSION HANDIN by Friday 13th. (Again! I wonder if it’s a kind of foreshadowing?)

Week 9 (16th March – 22nd March):
– No hand-ins

Week 10 (23rd March – 29th March):
– FINAL HANDIN, Friday 27th.

————————————————————————————————

We chose “Green Warden” as our concept. This is their one page document that they provided to us:

By now we are about two weeks into the project and we have done our feature definitions and handed in our SCRUM backlog. With three weeks to go to alpha we are starting to feel the heat. So what has been going on so far?

Week 1:

During our first week we did not really produce any assets for the game. Instead we spent the first week:

• Acquainting ourselves with our chosen concept.
• Coming up with ideas for suitable changes and discussing them.
• Documenting our changes to the games aesthetic and mechanics.
• Coming up with an overarching storyline for the gameplay.
• Creating a flowchart for the necessary game states and their transitions.
• Starting to work on our feature definitions and product backlog.
• Creating a paper prototype and playtesting it a couple of times to get a feel for the basic gameplay. We could have used the paper prototype created by the previous group but since we changed some of the mechanics we felt more comfortable designing our own, which was more of a strategy-board kind of game instead of a cardgame like the original prototype.

Results:

Concept document changes: 

After reading the one page design document and concept document we had a couple of thoughts on it:

1. We want to remove some of the randomized elements from the concept to give the player more agency and strategic freedom.
2. We want to lower the pace of the game and give the player a win-condition to strive for instead of surviving for as long as possible.
3. We want to make the seed-system more transparent to allow the player to focus more on their strategy and the placement of their units.
4. We want to make enemy behaviour less predictable by not making it obvious to the player when they attack (ergo, no more attacking in timed waves).
5. However to keep balance in the game, stick with the “defender”-aspect of the player avatar and encourage the player to make the most of the seed system we want to limit the avatar’s abilities to defensive ones and only grant offensive abilities by powerups which should make them more special and amp up the pace for the player during those occasions.

With this we wanted to redirect the game from survival to strategy and empower the player which supports the original aesthetic goal:  “A dryad defending their forest creates a fantasy setting that is not part of our everyday lives, giving our players a chance to experience something they would not normally experience, making them the warden of the forest.”

Game ideas:

As opposed to our concept assignment this time around we had no problem coming up with ideas for what we wanted to do and we quickly came up with general gameplay, progression, storyline, possible units, what the player should be able to do and how the world should respond to those actions. Most of these ideas we ended up discarding for the scope of this project because:

1. We had to face that the gameplay mechanics for our chosen concept were fairly advanced compared to a speedrun-type of game.
2. We have one programmer less than the other groups.
3. We are inexperienced.

So realistically we would probably only be able to create one, decently playable level by final hand-in.
Some ideas however went into the product backlog like ground tiles and static objects responding to the enemies presence by turning bland and grey and growing more colorful and saturated when the player retakes the area. Other things like creating a card-collecting system to let the player create a “deck” of units they want to use before each session went into a “maybe later if we magically end up finishing all the basic stuff on time”-pile.

Paper prototype playtesting results:

What we tested in our paper prototype were the basic mechanics for player movement, ordering plant units, enemy movement etc. For this we used the abilities and types of enemies suggested in the concept document but we tok away the avatar’s offensive abilities. We played this as a 2-player game with each player having a set amount of action points per unit.

After round 1 we could quickly tell several things:

1.  The player was seriously disadvantaged by having immovable units compared to the enemy’s mobile ones.
2. The player’s units needed more firepower.
3. The Juggernaut was seriously overpowered.

What we did then is that we changed the Action Point system so that the player would start out with a set amount of action points to spend and it would then increment by 1 each round, making both players more capable over time and allowing them to utilize all their units, to simulate how this system could behave in real-time.

We added a resource-system for the goblins, making it so that they would start out with a certain amount of resources to spend that would regenerate a little each round. The rate of regeneration could be increased by building factories and multiple enemies could be spawned during the same round by building barracks. We thought about letting the enemy units “mine” resources from the trees but it was deemed like more work than it was worth so we decided to imply the impact the enemies had on the landscape by turning all ground and trees within their territory, that were not the player’s special units, grey and dead.

The players resources instead would be the time it took for the Life Tree to spawn a seed and for the seed to fully grow after it’s been planted.

After round 2 we could tell that:

1. The player could now hold her/his own better.
2. However she/he still needed more offensive capabilities. The player easily became dug down in their territory and had a hard time progressing toward enemy camp. Since the dynamic where the player was mostly busy fetching seeds, planting them and protecting units felt more “in character” the solution would be to increase the power and abilities of the player’s plant units.
3. We needed a movement system to manage the movement speed of all units.
4. The Bombardier enemy that made  damage over a larger area should stay, it forced the player to spread out their units more instead of creating one impenetrable wall of plants.
5. Since we felt that one plant unit shouldn’t have too many different abilities at once we needed more units for the player to choose from which made us change our priorities in the product backlog and push the seed combination system higher up on our to do-list.
6. Some of these “combined player units” should be trap units or teleportation units to slow down the enemies and let the player move their character quickly over the field.

————————————————————————————————————-

The group: 

Since we are working in the same groups this project as in the previous project we pretty much fell back on the same responsibilites as the last time around, only switching around some.

This week I was multitasking a little here and there, making the state flow chart, playtesting the paper prototype and reviewing game ideas. However I primarily took responsibility for our deliverables and worked on feature definitions and our product backlog. Aside from that it was managing and documenting meetings and making sure we got started with deciding on a visual style and how we were going to communicate everything to the player.

Next up: Week 2, aesthetics, visual style and Scrum!

About Eva Sokolova

2014  Graphics

View all posts by Eva Sokolova →