What is Game In A Month?
There are many talented developers in the world who wish to create games.
Often the game is never completed because:
The vision is not clear
The idea is too large and the developer becomes overwhelmed by the scale of the project
The developer burns out or loses motivation.
The game turns out after many weeks to simply not be fun.
The idea is sound but the developer does not have enough experience in either the tools or the genre.
In either case, the game dies and any potential for joy dies with it.
Game In A Month looks to address all of these points by creating a structure which the developer can stick to and avoid the pitfalls and traps strewn at their feet.
By following these very strict rules governing the activity and time spent on each stage of game creation, a developer will create a game. It may take several restarts to fine tune their design, but they WILL create a game in the end and it’ll probably be good.
Once the game is created, developers should feel confident and be able to repeat this process and create larger and better games each time whilst learning more about the process and more importantly – about themselves.
Game In A Month is not easy though, think of it as a Tough Mudder challenge for developers.
You get nothing out of something unless you’re prepared to put into it.
You must also be honest with yourself about your level of ability and the scale of the project you can reasonably handle.
Above all, Game In A Month should be fun. After-all, you’re trying to make a game and games should bring fun; Both through playing them and by the process of creating them – and it’s a shame that so many games go unfinished due to various reasons, most of which could be avoided.
So lets bring more joy by creating more games and make a Game in a Month.
Just think, you could potentially create 12 games in a year.
Have an idea.
The idea can be anything your mind can conceive. It should be something fun, something you’d love to play yourself. It should be something you think you can build with the resources you have available to you in a very short amount of time.
If you’re stuck for an idea, think about the most fun you’ve ever had as a child.
Think about genres of games you enjoy playing – Genres that don’t involve an entire studio of resources.
Fully document your idea.
In this phase you have 7 days to design your game.
This is the entirety of your game.
There should be nothing in your game that is not covered in some way in your design document.
You must produce a physical design document that provides:
- the concept,
- the game rules,
- the game pieces,
- the win conditions.
- It should answer all questions
- it is the blueprint for your game.
You only have 7 days to write the game so make sure that the game you design can be built in 7 days using the tools you have.
Do not start writing code for your game during this week, you do not have time for code – this is the most crucial week and should be spent designing.
Do not name your game. Spending time naming your game eats into design time.
Do not solicit feedback during this stage – outside influences will only pollute the idea.
If your design takes longer than 7 days, You must restart the entire process with a different idea and design.
Remember, this is an exercise in thinking about your game in it’s purest form. If it takes longer than the allocated week, your game idea was too complicated and continuing to construction and review will be a waste of everyone’s time.
In this phase you have 7 days to write your game based on your physical design document.
This should be a fairly simple technical exercise using tools that you have an understanding of as all of the logic has been defined in the design document.
Make sure you’re using tools you understand as the more time you spend learning tools, the less time you have to write your game.
At the end of the week you should have a playable game which you can pass to someone to play, test and review.
You cannot modify your design during construction. If your design did not cover a feature you want to include, ignore the feature – this is scope creep trying to kill your project.
If the game is not ready for play test and review at the end of the week, you must restart the entire process from the Design stage. The design was obviously at fault otherwise the development would not have taken so long. Start again.
Do not solicit feedback during this section. In fact do not let anyone see your game during this time. This is your time to build your game in it’s purest form without outside influence. The time for feedback will come, but for now – code.
In this stage, you take a week off while people play your game.
Sounds easy? It’s very difficult to leave reviewers alone, this is an exercise in restraint and contemplation.
You can include as many people as you want in this part however you are prohibited from receiving feedback early or working on your game while it is being reviewed.
Do not engage with these people in conversation about your game and do not allow them to talk to you about it. If you do receive feedback early – ignore it – Do not act on it – Do not alter your game during this week.
This is a time to step away from your game and reflect and reviewers cannot give accurate feedback unless they are allowed to do so without interference or bias.
You will need the time off as the last two weeks should have been grueling and you need to prepare mentally for next week which will make the last two weeks seem like a picnic.
At the end of the week, your reviewers must give you documented feedback which you must not look at until after midnight on the last day of week 3.. effectively the 1st day of week 4.
Any feedback received after the 7 days must be discarded. Seriously – throw it away.
If no feedback is received within the week, you must start the process from the beginning.
If the people reviewing your game could not spend the time during the week to review the game, it was not engaging enough or was not playable enough therefore you must start from scratch.
You may have lost 3 weeks of work, however the lesson will be worth it.
You will have written feedback from your reviewers.
This can be in the form of suggestions, bug reports or vicious attacks on the game or utter praise.
This feedback must be taken objectively, you must remove all emotion from the process – even if your reviewers use emotionally charged terminology – take it for what it is, someone else’s opinion.
Do do not have to implement all feedback received, in fact you can disregard any feedback you don’t agree with.
Do not implement new features suggested via feedback, make a note of these for a future version of the game.
Do not modify core documented features of the game, in fact, do not deviate from the original document in terms of gameplay.
This is the final push. You have 7 days to polish your game before you release it unto the world. During this time, you may name your game as you now have a better idea what it actually is.
Fix any bugs you can and get the game ready for the world to see and enjoy.
This is the last part of the process and can only be done if all stages were completed on time.
You should release your game on whatever platform you’ve been developing for.
You can take as much time doing this as you need as several marketplaces require time for assessment however do not port during this time.
If feedback is returned from the marketplace curators, you may implement it in your game. You’ve completed the challenge at this point, you have made your game and proven your design. Everything else is just gravy.
The only point I will make here is that you really Should release your game. If you can’t release it for money or you feel that it won’t sell, release it for free. Allow players to experience the game you’ve crafted. tell your friends, tell everyone – you’ve made something from the fabric of your mind and it survived Game In A Month.
Should the game become popular, you know what to do for your next Game In A Month.