Mike Pickton Meeting 3 - Game A Week Progress Update

In the meeting with Mike this week I let Mike know of what I've been up to in regards to my Game A Week work and what I plan on looking into next. So I got him to play through Cloud Bounce Cloud Bounce, which he wasn't very good at.

There wasn't too much of an agenda this week from myself as it was more a test to see if I am on the right track and if there is anything I could be missing from my critical analysis. We agreed that the game a week entries should be an attempt to experiment with different methods of working and as a process to figure out the best way to create the games we want to make, finding out the pros and cons of each different approach.
This can be evaluated through each projects post mortem post where I will write about each project and how each game fits into what I am trying to investigate. Currently for example on Cloud Bounce Cloud Bounce, I have attempted a shorter simpler project as a warm-up into becoming quicker with the prototyping process and as a focus on creating something extremely simple and easy to manage.

Mike suggested though that I add some areas to my conclusion adding more of a sense of progression through the different games:

• The longevity of the game concept - More how I would scale the concept and how I might go and release each game, this is useful in identifying whether any of these game concepts have the potential to go forward as an idea. If it was to be expanded as a full game, what time would be needed to finish it and would more people be needed? This might not apply to all games as most of these games might not stand on their own, and the same thinking behind them might be applied to the next game.
• Task breakdowns - For the benefit of seeing how I spend my time during each project and in what software, useful to see if I might have spent too much time doing something like asset creation when I should be prototyping gameplay. Also can be useful later on in evaluating where I should be spending time relative to what type of game I am making and what skills are needed.
• Reusable components - Finding out where I can reuse stuff can be massive time saver and can be more efficient if I am developing a similar kind of game. Also figuring out where I might need some reusable components for a larger game can help me decide where I should aim a few of my projects to try things out, very important in these early stages. This is even easier in Unity as the engine is built around using scripted components, this is something I will be possibly trying out in next week's project.

Mike also brought up that reusable components should possibly extend to the games frontend, which means the UI, basic interaction and general look of the games could also be made to be reusable through different projects. Having a fixed standard for the frontend that can be iterated on will greatly help how long it takes to get each game ready to release. 

Continuing forward now I will assess how I write about each project and whether everything is relevant. For now though I have just thought up a new idea for this weeks game while writing this post, which I could do feasibly within the next two days, so I'm going to go away and take some notes.

I'm thinking something text-based which could help the writing and narrative component a little bit more. :)

-James