Quokka Blokka
Uni Capstone Project
The final stage in my uni degree was to work in a team to create a complete game. The game we came up with was a unique Tetris/endless runner hybrid called Quokka Blokka, which was made in Unity.
I took on the producer role for this assignment, ensuring that everyone kept on track, and handling aspects others shied away from like design documentation and pitch presentations. I also aided with some aspects of the design and took charge in scheduling and reporting on playtesting.
We had a bit of a rocky start but in the end we learned a lot and got a High Distinction for the course, which we couldn't be happier with. You can play Quokka Blokka by clicking the button below, or keep scrolling to read a bit more about the development process and see the documentation deliverables I worked on for the project.
Making Quokka Blokka
Behind the Scenes
Getting Started
The project started with everyone in the class pitching their ideas to the other students. Everyone would then give a vote to the idea they liked best, and the ideas with the most votes would be the projects that would be worked on with the pitcher as a team leader. My friends and I already knew we were going to work together so we thought we’d use this as an opportunity to see which of our ideas was most popular so we could work with it.
Unfortunately, our ideas were too good and the votes all went to us. Instead of going along with the rest of the process we formed our own team because we knew we could rely on each other, and went with the highest-voted idea amongst us. It was a game called Tetris Bridge, in which the player was presented with an incomplete platforming level of some kind. They would have to play a game of Tetris within the gap to build up a path that their character could move along. It was a sort of puzzle/platformer hybrid where you’d be playing Tetris on oddly-shaped playing spaces and trying to use the tetrominoes to make specific shapes rather than completely clearing the board. It was very unique and a developer from a notable Australian mobile game studio who was present said he loved it and we should definitely go with that idea.
A few weeks later we then had to pitch our ideas to a panel of Australian game developers. We split up parts of the presentation to work on and then I would be the one actually making the pitch. Part-way through the pitch when I was explaining our mechanics, I realised someone on the team had made changes to some of our design choices on the slides without telling me and it tripped me up. They apologised after, but it made things a bit awkward. Things would only get worse though. The feedback was the most brutal teardown I have ever experienced.
The first developer to speak up said something along the lines of “You have no functional game idea”. From then onwards it was a bit of a pile-on with each of them pointing out things they didn’t like and that our idea would not work, which is something we were not prepared for at all. And being the one giving the pitch I was standing out in front of everybody having this feedback directed at me personally.
Picking Up The Pieces
We were broken after that presentation and didn’t know how to react. Our unit convener actually sent us an e-mail afterwards apologising to us because he felt that they were all harsher than they needed to be. But as rough as it was, they did actually make some good points. One of the suggestions was to design one single level of our game and try out a paper prototype of it. This would be a test; if we could do it, the game would work. If not... [pulls collar of shirt]. Through doing this we quickly realised that, yes, our mechanics really didn’t make much sense.
We loved the idea of using Tetris mechanics in a platformer, but we had to figure out a way to make it work. I’d spoken to one of the developers on the panel afterwards because I’d written an essay on one of his games earlier in my degree and my leccturer had forwarded it to him, so I thought I could use that as an in to strike up a conversation and get some help. He said he’d actually run into an issue with a game he was currently working on where the team had realised that the game just didn’t make sense, so they took it back to the drawing board to “find the fun” in the original concept and then build upon that.
So that’s what we did. We went back to that mechanic of falling Tetris blocks in a platformer and tried to work out how to best capitalise on it. We realised that this puzzle/platformer approach we were thinking of just wouldn’t work in practice and even if it was salvageable we didn’t have enough puzzle design experience to construct levels from it. With that in mind, we realised that our mechanics would work in a minimalist playing space - if a character was constantly moving forwards, there would be a challenge in attempting to construct a path for them that wouldn’t destroy itself under Tetris rules. So we rebranded our game as a procedurally-generated endless runner that would allow our mechanics to shine.
We submitted a new pitch for our new game that our convener marked and said was a much more promising starting point. We were back! Interestingly, I noticed on re-reading pitch that while I called myself a producer I made a bigger deal of the technical contributions I’d be making to the game, as if I was afraid that management and documentation wouldn’t be seen as important.
The Development Process
Our project was split up into four sprints. We had to identify our goals for each sprint, and as the project progressed we had to log our progress in Trello. At the end of each sprint we had to show off our game in its current state and provide a status report on what we achieved, what we struggled with, and what we would be working on for next time. Everyone on the team had their own role, whether that was programming or graphical work. We already had a few people on the team who could code so I left the programming to them and decided I would do the ‘boring’ work nobody else wanted to do. A lot of people find documentation and presenting dull but I like it and have gotten good at that kind of work.
I contributed a few other things to the project as well, like some level design in the form of pre-made ‘chunks’ of blocks that would be inserted into the levels and testing those to ensure they worked properly and added to the experience. Our artist helped with this as well when they didn’t have any graphical work to do. I also handled the project’s playtesting, getting my friends and family to play the game and give feedback and also taking notes whenever our markers and peers played our game.
Our playtesting document has plenty of information on our playtesting process, but I’d like to speak a little bit about it here because playtesting is such an important aspect of development that’s so easily overlooked. And indeed, we were pretty much the only group who did actual playtesting beyond “we played our game ourselves and it works”. While our playtesting was extensive through all sprints of the project, there was still plenty of room for improvement. One of the main things we realised was that people can’t always express what they mean and their feedback will often contradict everybody else’s. We were hoping to use playtesting to work out how to balance the difficulty of our game, but some people were saying X was the reason it was so hard and others were saying Y was the reason and it wasn’t of much help.
What we realised at the end of the project, with guidance from our convener, was that our playtesting should have been more ‘targeted’. For example, to work out whether the game was too fast-paced we could have given players different builds of our game to try where the quokka moves at different speeds. We could see what effect the speed has on their playstyle and get more useful feedback from players as well because instead of just guessing “The game would be better if the quokka was slower” they could actually experience the changes first-hand and see if it actually does improve their experience.
Enhancing the Core
We had a habit of getting distracted with all sorts of cool and fun things we could add to the game, so something I always tried to bring us back to was enhancing the core of the game. There were a few ideas we scrapped along the way because they were going to take our focus away from more important aspects of the game and we agreed they weren’t important enough to justify the effort.
One key time I remember bringing up this concept was when we were determining the power-up block abilities. These were blocks that gave the quokka special powers when it made contact with them. We came up with plenty of great concepts, but some of them were weird and gimmicky and would probably detract from the experience rather than enhancing it. I pointed out that our power-ups should each be directing the focus on one of the Quokka's key behaviours and making it shine. We identified that these key behaviours were movement, climbing, and falling.
We created the Sprint power-up to emphasise the quokka’s movement and make him speed across the screen. We created the Elevator power-up to allow players to make use of verticality in the game without the usual drawbacks. And finally, we created the Slippery power-up to make falling more useful. Normally falling is a negative consequence of not building a good path quick enough, but with this power-up the player could let the quokka fall forwards while diverting their attention to building up a path further down the screen.
This final set of power-ups really enhanced our game and made the experience much better for the players than if we’d dumped in each and every idea we came up with.
That's A Wrap
At the end of our project we had to present our games to the class and also the panel of developers we initially pitched them to. We were anxious after what happened last time they were here, but given that we had a functional game that people had enjoyed playing we got over those nerves. And what do you know, they actually loved our game! They all said they were so impressed that we hadn’t given up after that rough pitch meeting, and were amazed that we’d managed to turn our initial concept into this final product instead of making something entirely different.
In addition to the game we had to turn in some final deliverables as well, like a final game design doc, all of which is accessible at the top of the page. Our project was a major success as we got a High Distinction mark for the course. We were so proud of all our hard work.
The Morals of the Story
Ideas that are good on paper aren't always good in practice
Ensure everybody's always on the same page
Playtest early because it increases your workload, and perform it with a purpose so you get more focused and useful feedback
Deadlines aren't scary when everyone does their part and sticks to the plan
Be flexible with your Sprint Goals if it means making the most of your team.
Introducing players to mechanics can be a challenge.
Making games is fun and fulfilling :)