You will find that nearly all the professional developers out there will set aside some time to plan out how their code is going to fit into the wider project on which they’re working. Regardless of whether they’re working as part of a team on the latest game, developing a workflow user interface for the company, or creating a set of automated tasks that can be used across a number of different platforms, each developer will set out their code in a plan.
The planning stages can be unique to the developer, unique to the company for which they’re working, or the project on which they’re working. Planning meetings will often involve sketching out a rough plan of how the end product will function, with each developer team then working on their element within the project. Lone developers will sometimes go back to basics, grab paper and a pencil and start getting their ideas down. The end result is always the same, though, a plan of action that enables the developer to plan without worrying about the actual code at this early stage.
One of the more popular methods of planning to code is using pseudocode. It’s a term used in programming circles that allows the developer to represent the implementation of code, and the sequence of the actions, using plain English and a mixture of code examples together with a flowchart or two to help ‘picture’ loops within the coding project.
For example, a developer who is planning to write a program that will check user input for odd or even numbers will probably begin with a basic statement of pseudocode:
A program to allow a user to check if the number is odd or even
Then the basic statement can be expanded:
“I am result 1”
“I am result 2”
It’s very simplistic, but from there the developer can continue to plan the remainder of the code needed without taking up too much valuable time – but while also having a readable plan of action for how the code is going to be formed.
The actual writing of the code, therefore, takes place later on in the project. Once there’s a plan of action in place, the developer can share the plan with their colleagues, lead developers, managers, and so on. Then the plan can be further tweaked to include other aspects that the original developer may have missed or may have been removed due to being classed as unnecessary.
This process will not only trim the fat off the code before it’s even written but will also help plug any gaps in the project before the hard work of entering the code begins.
If you’re planning to include graphics in your project, such as a platform game, then one of the best resources you can use – and one that has been used since the early days of coding games – is graph paper.
Super Mario Bros., launched for the Nintendo Entertainment System in 1985, was nearly exclusively drawn out – both characters and levels – on graph paper before being applied to code. Entire game maps were often created this way, especially on the older 8-bit machines such as the Commodore 64 and Sinclair ZX Spectrum home computers. 8-Bit graphics were ideal for graph paper since the sprites used then were made up of eight or sixteen blocks; the developer could then visualise the layout of the sprite using the drawing on the graph paper and apply that to the code. The end result, of course, is the character appearing on the screen.
Once the graphical planning stage is complete, it’s then down to you as the developer to fill in the blanks, as it were. This means creating the code that will place and animate your characters within the game, as well as developing interactions, collision detection, number of lives, and so on. With the help of some pseudocode, you could easily plan out what modules you’d use or create, the number of variables needed, and the various endgame states that will arise when someone plays your game.
The whole point of planning is to create something easy to follow that will help you write the code for your project. Planning isn’t supposed to be a chore; it’s there to aid you when you get stuck trying to work out which variables you’ve used, where you are in the game, with what you’re left and how the game will eventually pan out and end.
When planning, begin with small steps. Coding a Hangman game, for example, begins with the plan to get the player’s name, then includes: the word bank, drawing out the stages of the Hangman, asking the right questions, and finishing the game in one of two states – a win or a lose – before asking if the player wants another go.
Once you’re used to planning it’ll come naturally, and you’ll find yourself thankful for all those post-it notes stuck to a sheet of A3 paper, as well as the reams of graph paper that detail your characters and level designs.