Having published my concept prototype for the first game jam of the course, it’s time to reflect back over the last thirteen days to review what happened, what worked and where improvements may be made for the next round.
I’ve already covered the early phases in my previous posts, Game Jam 1 – The Reveal and ICEDIP Clarity — Game Jam 1, so I plan to focus more on the subsequent activities leading up to this evening. Warning — this may be a long post!
Outcome…
What was my goal for this game jam? Did I achieve it?
My primary goal, remember this was my first ever game jam, was to deliver a working prototype of a game and have fun doing it. I felt I needed a strong success to build on for the future to attack future jams with the right mindset going in. The beta version I published is nowhere near production hardened nor quality but I achieved what I set out to within the time available so I deem that a success.
I also wanted to move myself outside my comfort zone and areas of expertise. This dropped out of the ideation session as I ended up creating an educational game, not a genre I’m familiar with and in fact I really wanted to go down the RPG/RTS route. The rapid ideation was saying ‘educational’ so I got behind the concept, owned it, and made it work. I really enjoyed it too.
Finally, I wanted to create a ‘working’ game. I’ve experimented and played around with things in the past but never really created anything of note. From the outset I determined I would publish something on itch.io, to put something ‘out there’ for the world to see.
What were the issues I encountered? How did I overcome them?
Lack of expertise with graphics and modelling software was one of the biggest issues. I originally wanted to create every asset I used: to model a winged boat, the buildings, scenery and draw the background.
Having wasted the first Saturday playing around in Blender and Inkscape, I woke up, got with the programme and admitted defeat. This was never going to happen within the timeframe. A quick reset and reframe was needed and I chose instead to use free, stock assets, each of which are listed in the end credits on the ‘game over’ scene.
Using stock assets has given the game a completely different style to the one I wanted. It’s much darker than I visualised and I feel it needs a lighter, cartoony feel to appeal to the target audience of 6 to 10 year olds. As a concept I feel it works but if/when I take this to market I’d like to rip out the graphics and do a whole makeover in the styling.
The scripting behind the game also needs some serious attention. Unusually for me, I paid no heed to architecture or design and this felt really uncomfortable. The scripts grew organically rather than deliberately and are in desperate need of refactoring. They work, and that’s what counts, but their maintainability is simply dreadful. Adding more structure would definitely improve this.
The only other issues I encountered were a lack of knowledge with the Unity environment and API. There were relatively simple to overcome as the on-line API documentation is very good.
One very amusing little bug I found yesterday only showed up when I placed the two domed buildings in the scene. The boat kept getting stuck on them and not triggering the collider. It ultimately came down to the collider in the boat being badly positioned: rather than being aligned with the centre line, it was offset. When the boat hit the rounded roof the rigid body pushed the boat back and never triggered a collision event.
Lesson learned: always check in 3D space!
The other big issue was time management. I let my ego get the better of me and entered the Unity game jam last weekend. It was a big over-commitment, I made no progress on it and in the end I chose to withdraw (Unity Game Jam — What went wrong?) I felt my time would be more effective spent in this project: I could either do a good job on one or a bad job on two,
What did I learn?
Game jams are fun! They really focus the mind and with a little discipline around features and content it’s possible to create something that I’m proud of.
The rapid ideation techniques are fantastic. I’ve always struggled to come up with ideas and concepts which is why I’ve never created a working game until now. I’ve just hacked around in the code, got bored with it, fallen out of love with it and abandoned it. This time was very different. I took a random theme based on two completely unrelated stimuli and developed a working prototype.
That, dear reader, has completely blown my mind! I would never have thought that possible.
The other really big learning point was to remember to step back and look at the big picture. It’s easy to lose sight of the goal or go off on a tangent whilst working at the detail level. This can be disastrous and on a micro project such as this there simply isn’t the time to recover.
My last learning point is the importance of making quick decisions. Knowing when to change your approach is key to success. Problems and issues are a massive time- suck. If something isn’t working I feel it’s super important to know how long to persevere with it and when to change to a different solution.
Concept Elaboration…
Everything in the early analysis was pointing towards an educational, maths based game, as the best fit for the theme. When comparing my prototype to the offerings of my peers I do wonder if I’ve taken the theme too literally? Furthermore, has this had a detrimental impact on the type of game I built by constraining my thinking too much? (I believe I’m the only one who actually included the deck of cards in the game as well.)
I cannot answer these questions but for future game jams it would be prudent to explore other avenues that may open up if I only consider elements of the theme rather than the entire set.
The output of the brainstorm session suggested a game where the player is presented with a maths question and has to give an answer within a certain time limit. On a correct answer, the avatar moves up, if incorrect it moves down. Fail to give an answer within the time limit and the avatar moves down twice as far. The objective is to keep the avatar in the air — hit an obstacle (building?) or crash into the ground and the player will lose a life.
Workload Management
The game I’d chosen to make was very straightforward and simple. To ensure delivery of a successful prototype I felt it vitally important to strictly control the project scope. Jira by Atlassian was the logical choice for this, partly because I already had it set up, partly because the reporting tools highlight feature creep and partly because I’m very familiar with it for Agile project management. This, perhaps, gave me a slight advantage over some of my peers: I’m very used to creating, sizing and breaking down stories as part of my sprint planning.
My planning took around 20 minutes and I did it during my son’s swimming lesson at our local leisure centre. The output was a set of bite-sized stories I could work on over the next two weeks and track within the tool itself. Looking at the chart below, the red trace along the bottom and the light grey shaded area indicate feature creep. As you can see, there was a small amount of scope change in the first week and then again this evening as I added a couple of extra features just prior to creating the prototype build.
That 20 minutes investment in planning at the beginning paid dividends throughout the execution phase. I always knew what to do next and the trend line let me know if I was ahead or behind schedule. Armed with that level of information I knew when I needed to push and how hard in order to achieve the deadline. It also kept the number of very late nights to a minimum, there being only one from memory and that was because I wanted to take part in the Unity game jam last weekend.
For a shorter game jam, for example one that runs over a weekend, I’m not certain planning my work in this way would be very useful. Jira doesn’t offer the that level of fine granularity and given the additional time pressure a simple To Do list might be just as effective.
User Interface (UI) Design
For the UI, I wanted something very simple. Using Adobe XD I came up with the above design. It was quite straightforward as the split screen approach had dropped out of the brainstorm, as had the deck of cards to ‘deal’ a random question.
The biggest challenge was player input. As the target audience is between about 6 to 10 years of age and the game may very well be played on a mobile or tablet device, typing three digits and ‘enter’ was clearly a non-starter. This left a multi-choice style question as the only reasonable option that would work across a range of platforms.
In hindsight I believe this was the correct decision. It opened up an additional feature towards the latter stages of development where the difficulty is increased following a streak of 5 correct answers. Clicking or tapping an answer button is much easier and faster for the player than typing a number in. Two other advantages of the multi-choice approach are the prompt, thereby invoking the recognition aspect of the player’s memory rather than recollection, and the ability to indicate the correct answer to help the player learn the correct answer.
Implementation and Execution
The implementation in Unity was very straightforwards. Unity is a very simple engine and IDE to use but it’s very clear I have a long way to go to get the most out of the tool. Nevertheless, we have to start somewhere.
From the outset I put my files into GitHub and followed a Master Code-line branching strategy. It’s probably overkill for a team of one but when used correctly always guarantees the integrity of the source files in the main line.
Running the project was simply a case of taking the next story from Jira, working on it and moving it into the ‘done’ column on my scrum board. I’ve indicated all the states in my process below.
Conclusion and Learning Points…
I really enjoyed the game jam. It was fun to work through the whole process and not knowing what I would be producing until the theme was revealed added an interesting dynamic. I surprised myself too by coming up with a game that I may take through to production. It’s far from product hardened and needs restyling but the basic concept is there. I’ve also received some very favourable feedback and suggestions from my peers to whom I’d like to say a big, Big, BIG thank you.
Oddly enough, I elected to put my head on the block at the mid-point webinar because I didn’t believe I had enough of a concept and wanted to gauge reactions. I was fully expecting to have to abandon my idea and have a big rethink. This was a classic example of False Expectations Appearing Real (FEAR) as the reaction I received was very supportive, complimentary and encouraging. The positive input from my course-mates served to really inspire me onwards to produce my 0.1.0-beta version.
What have I learned from this game jam?
Make a decision and go — procrastination is very much the enemy of the game jam. With the limited time frame and the resulting pressure that creates, every second must count. It’s important to make decisions quickly and act upon them immediately. If it doesn’t work, that’s fine, it’s just part of the ‘fail early, fail often, but always fail forwards‘ mantra .
Work with pebbles, not boulders — It’s far easier to pick up a pebble and run with it than a boulder. The same is true with Agile stories. Keeping the story size down greatly helped me to develop the prototype and deliver something that works
Keep an eye on the bigger picture — It’s easy to lose sight of the project when working at the detail level. Taking a step back to look at the bigger picture helps to maintain purpose and ensure the development is heading in the right direction.
List of Images
Figure 1. THORN, 2020 Brainstorm — First Game Jam
Figure 2. THORN, 2020 Project Burn-up Chart in Jira
Figure 3. THORN, 2020 Initial UI Design
Figure 4. THORN, 2020 Story Workflow in Jira
References
Photo by Faye Cornish on Unsplash
