“Project G” Development Log : Part 2
So where should I start?
You’ve pulled up your sleeves and managed to get your awesome game idea down on paper. Maybe you’ve even passed it around, got some good feedback and even some people interested in helping you. But now you have to start actually making it. Staring at the blank project file you wish you could glimpse into the future and see how it turns out, head off any dead ends and know that you’ve picked the best starting point to ensure your end goals.
When starting Project G we had a similar moment, but the more games you make, the shorter this moment becomes because you start following your own rules. So where did we start?
Many of you will have heard of alpha and beta game releases? Well this is evidence of release planning. Instead of getting bogged down worrying about how you are going to go from 0 to a completed game, split it up. Instead concentrate on getting the first 20% done, decided what that first 20% looks like and work towards it. Then when you are happy move onto the next 20%, (your second release) and repeat until you have your finished game! Just to be clear release planning is part of the Agile Development Process, but the concept is very simple and will help you to keep motivated and on track the whole way through your project. At the moment we are using Trello to plan our releases as it’s a very flexible organization tool which is great for getting a team started on the concept of release planning, also its Free!
To give you an idea of what releases can look like here’s a basic game breakdown in 3 releases :
- POC (Proof of Concept)
The core mechanics of the game, no final graphics, a blocked out interactable demo.
Some Graphics, more polished mechanics, basic game loop in place, rough playable game.
Final graphics, good amount of polish, fun to play, pretty to look at, May still be bugs left to find but nearly ready.
Now I like to jump into coding as much as the next girl but before we do that let me bestow upon you the benefits of using source control and what its actually means! Have you ever been working on a project, everything is going great, your being super productive and then something breaks… and you have no idea why. Even worse, you can’t figure out why, you’re trawling through hours of code , commenting out chunks trying to find what broke everything and trying to get back to where it all worked and life was fair and decent. This is where source control can save you.
Source control lets you manage your project and save your work in stages. If something goes wrong, you can quickly see all the parts of code you’ve changed since your previous working version and pin point your issue. If it’s really bad you can simply roll back to a previous version and start working from there again. Although you can do this locally on your computer, it’s advised that you setup your source control with an online storage system, called a repository. Sites like Bitbucket and GitHub offer a fair amount of storage for free so set up an account with them. Then you can download a source control client, basically a program that will help you manage saving your project and updating your repository. I’m currently using bitbucket to store my code and the SourceTree client to manage it. I find SourceTree very good especially if you’re new to all this as the interface is quite friendly, but there are a many out there to choose from.
Another benefit of using source control is that you can easily share your code with others. When looking for a job in games as a programmer many companies will ask if you have experience with source control and will request to see your repo to check out your mad skills!
Tune in next week to see how we actually started coding Project G and how to begin creating art for your game!