In this lesson, we’ll go over the process of going from game ideas to code tasks.
While our focus in this course is on code, our code directly relates to the design of the games we create.
While professional game developers don’t necessarily need to excel at game design, they need to know how to turn game design ideas into code.
There’s a general process that we follow to create games.
It consists of five broad steps over which we iterate:
It may be a bit vague at this point, but we’re now going to look at a concrete example using our final project.
Note that making a game is an organic and iterative process. It’s not like you can make a detailed plan from the start and follow it strictly from start to finish. You will get new ideas, some mechanics won’t work, and you will have to change the plan as you go.
Still, this process helps you to work productively. If you don’t break down your game projects into small tasks, you will feel overwhelmed and lost in the sea of things to create.
This is not a game design course, so we won’t dwell on the different ways to approach finding game ideas, but at GDQuest, we try to think about what the player will do the most first. That’s what we call the core gameplay.
In this project’s case, it’s moving, shooting, and dodging.
We choose our projects’ core gameplay differently from most teams because we pick games with educational goals in mind.
We created an action game for this course because we could easily split the code into small independent modules, which is ideal for you to learn. Also, this modular code makes it easy for you to add your own mechanics and tweak the game, as you’ll see in this series.
That’s why, after prototyping several types of games, we went with a twin-stick shooter.
After figuring out the player’s main actions, we think of a broader loop and a goal. The goal is what the player has to do two move forward in the game.
In this case, it was straightforward: you have to reach the end of the level without depleting your health.
From there, we come up with a synthetic description of how the game plays.
Something like this:
This list already gives us helpful information to think about how we will code the game.
Although from there, you still need to make more decisions.
What should the weapons be? Where should the game take place?
Those decisions can take time to figure out, and you often make them as you prototype the game. The game creation process is iterative in that way.
We started this project with a prototype that had all the above with the most basic graphics. Then, we decided on a fantasy theme with spells.
Professional game developers generally start with prototypes like these.
This kind of ugly demo is excellent to test that your ideas work and that your game will be fun to play. If people enjoy it without graphics, they will enjoy it more with great visuals and sound.
It’s also much faster to make than a complete game with polished graphics, so you can test your ideas faster.
After prototyping the project, we went with spells for the player’s weapons. That’s because magic gives you much more freedom regarding what projectiles you can fire and what they do compared to more realistic firearms.
The next step is to turn every point above into code problems.
You always want to start with the actions the player will do most because you need to test the game to validate the general direction it’s going.
In this case, you’d want to start with the main character, the ability to move and to shoot.
The second part should probably be the enemies because you want some challenge.
In this series, we will approach things differently because the enemies are one of the most challenging parts of the code at your learning stage. So we will tackle them after warming up with mechanics like collectibles.
For now, let’s see how we would turn our character into a series of programming tasks.
We want the character to move smoothly, aim with the mouse, and shoot. We also want to change the character’s sprite depending on the player’s input direction.
For the character’s movement, we know that we can use steering behaviors to make the motion smooth with a bit of inertia. You’ve already done that in the first project, To Space and Beyond! You can reuse the same calculations here.
We can use the dictionary lookup technique from the top-down character series to change the displayed character sprites. We convert the player’s direction vector into precise values that we map to precise animation frames.
To aim with the mouse, we can do the same thing we did with the bat’s
raycast in the side-scroller series. We can have a node separate from
the player’s kinematic body that turns to look at the mouse using the
look_at() function.
For the spells, it’s exactly like what you did with the turrets in the tower defense chapter.
You want to create a node that serves as a point from which projectiles spawn. Then, another node should represent the projectiles because they need to move independently.
The node that spawns the projectiles will be attached to the player and turn with the character’s hands while the bullets need to fly through the game level.
This is roughly how you go from a gameplay idea to a code problem.
In practice, you don’t need to write it down in detailed sentences unless you need to discuss the implementation of each part with teammates. You may just scribble a few notes on a piece of paper, like so:
This is exactly the structure we used for the player’s character in the final project.
It allows us to keep the code compartmentalized, which is what we mean by turning the code into small problems that we can tackle one at a time.
We can code each of these components sequentially, then assemble them into a scene.
Breaking down ideas into standalone code takes experience, so don’t worry if you struggle to do this on your own at first.
It is often a process: you may write a lot of code in a single script before realizing that it would work better if you split it into two parts.
You will get better at this as you create games.
In the next part, we’ll dive into the final game’s file structure.