DEVELOPMENT PROCESS

Initially, we came up with sketches. We then proceeded to create paper models of the level, to see how exactly we would have liked the levels to look, before beginning to move on to the final iteration. I think it’s important to recognize in the development process, you should never get too attached to anything, nor should you put too much effort into it’s simply going to be a placeholder. By doing so, you’re investing into something that might not make the final cut.

It’s difficult to hold off from polishing, especially when an idea seems so promising- but by holding off, we were able to successfully test our mechanics out and put our effort into making the final copy.

SUCCESSES

Myself and my group mate find that we’ve created a game that is aesthetically cohesive, and has a good difficulty curve. Often, that’s the most difficult part of game creation- making something challenging, but not to the point where you would want to give up and throw the whole thing in the garbage. But, making a game too easy, makes it boring. We managed to fiddle with the maps and mechanics just enough, to get a game that feels just difficult enough.

SETBACKS + WHAT WE LEARNED

As always, the main setback happened to be issues with Github. While myself and my partner are now more well versed in the mysterious workings of Github, we still ended up running into a rather significant error near the tailend of our project.

Additionally, we also had some lapses in our expectations. We had initially wanted to include some more mechanics, but ended up sticking to the most basic ones- though, this could be seen as a double edged sword. Often, the desire to add more can suffocate the piece instead of bringing out its best qualities- one shouldn’t pet their painting too much, otherwise, it loses its charm.

So, in conclusion, we learned that we always need to back up- no matter what. Wind, rain, shine, terrible earthquake? Always create a backup, no matter what circumstances. In the end, it was a back up that saved us from a rather disastrous Git merge conflict, that destroyed over half our level. We also learned to appreciate simplicity. As the saying goes, less is sometimes more.

FUTURE DEVELOPMENT

In the future, we would like to focus further on how we could possibly incorporate more mechanics- we were looking forward to further developing the puzzles, but given the time restrictions, we had to focus on polishing our main mechanics as much as we could. Additionally, there are still some rough edges, especially concerning the gaps between platforms, and some sticking problems that could do with some adjustment.

GROUP ROLES AND RESPONSIBILITIES We both split the work fairly evenly in the beginning, when it came to whiteboxing and creating code examples- however, our roles began to diverge once we reached the end stages of the game. Which is not a bad thing- it’s better to play to one’s strengths than to struggle needlessly. I handled most of the asset creation, which encompasses sprites, and music- though, I did occasionally throw my hat into the coding ring, it was mostly for minor things, such as scene changes, switching an asset on and off, etc. My partner handled the more technical side of things, creating the code for most of our main mechanics and the game. He also handled scene transitions and the design of levels 3 & 5, while I focused on 2 & 4, with level 1 being a collaborative effort.