Post mortem: CountOut
https://walkies3.itch.io/count-out-

CountOut is a game based on requirements of a game jam, we were each given Atari’s “Breakout” as a base and then assigned an individual artist, my artist was Sally Sheinman an American installation artist. However, we did have creative limitations, these included;

·         Must closely resemble the layout of the original game.

·         Must closely resemble the mechanics present in the original game.

·         Must closely emulate the behaviour of player and nonplayer characters/entities.

·         Must resemble and embody the style and tone of the assigned artist.

This project was a solo endeavor by me, I am a student of SAE Quantm based in Brisbane, Australia. With experience in game development and majoring in programming

I wanted to create a game that would both showcase the installation style and also provide the same sense of easy fun that Sally intended with her art work. Most of all I wanted the game to stop becoming a game at some point and more a kinetic piece of art.

What went right

1.     Planning and scheduling

As this was a solo effort, planning and scheduling was achieved easily. I knew how much time I had and when I was available, not having to be concerned about whether work would be completed by others on time. Each week I used a scrum method, making a list of priorities that needed completing through HacknPlan and attacking one at a time in order. Through this method I was able to keep a track of the work that was done and what needed doing and thus how much time I would need to allocate to it. 

2.     Design & Style

From the beginning I had a very clear idea of the style and theme of CountOut should be, whether it was intended or not Sally’s work often imitates playable spaces. This made it very easy for me to envision a playable environment from one of Sally’s work in particular “Artkacina”. Looking very similar to a layout for a table top game with blocks to hit in the center. Her creations of many shapes and textures was easily reproducible in a game sense too

3.     Feature finding

As the game developed, issues arose with the core design and while this isn’t a positive thing the ingenuity in fixing these problems within a time period were. It also shed light on to new and interesting game mechanics that would eventually be reworked from bugs into features. Alternative solutions to these bugs were theorized and tested to make sure the new feature functionality was correct, overall these were still achieved in a reasonable time frame and didn’t affect the scheduling.

The way I worked

This was an interesting task, being a university student, time was restricted on the project. However due to effective planning and scheduling through HacknPlan, time was efficiently used as mentioned previously a scrum method was applied, by keeping track of tasks that needed to be completed within that week and updated frequently. There was never a point where I wasn’t sure what to do next. Also, any problems that arose were swiftly sorted and if the problem was outside of my expertise I looked externally for answers. 

What went wrong

1.     Not planning ahead

While I had an idea of what I wanted and needed in the game through the given individual specifications, the first couple of weeks of development my ideas changed, which in turn means there was less time planning the overall design of the game. Which lead to problems later in the project which included; core mechanics being changed, interactions being changed and more.

Ultimately these were worked around or solved but if a clearer design was decided earlier than much time and frustration could have been avoided.

2.     Self-Management
This is something I feel is often overlooked, especially in our industry. Even though my schedule and time management were well planned, my well being was put second. Often working many extra hours to achieve goals. Even though I enjoy this development process at the end of the day its still work. Making sure that you have sufficient breaks and time to clear your mind is just as important to the projects health as yours.   

What to do in the future

1.     Not planning ahead

This is something that I’m normally guilty of, starting development before final decisions are made. While it could be avoided by changing my work method from a scrum to a waterfall. The most obvious solution is improved documentation, by effectively sorting these out before the project is started, issues are addressed and understood in the pre-production process.

2.     Self-Management
Now these are going to sound a bit ridiculous, but you would be surprised how often this is overlooked;

·        Take a half hour break every three hours, have a stretch, get a snack

·        Make time in your day for “play”

·        Stay hydrated

·        Get at least thirty minutes of exercise a day, even if it’s just a walk

Looking after yourself is not only crucial to you and those around you but the life of the project as well. Time to reflect and recoup can help bring clarity to project which ultimately can save time and stress.

Conclusion
Overall, I’m really happy with how CountOut turned out, I learnt new programs and achieved things that were previously unobtainable. However, there is always lessons to learn and take away from experiences, this project being no different. In future projects I will keep in mind to create more detailed documentation and not to start a project before final considerations. Finally, to not take for granted health and self-management as the management of these affects the productive output of both the person and project. 

Find the game at:
https://walkies3.itch.io/count-out-

Development stats

·        Developer: Ben Walker

·        Length of development: 4 weeks

·        Number of developers: 1

·        Development tools: Unity, Blender, Audacity, Photoshop, Visual studio

·        Sleepless nights: 2