Back in the Saddle: How to choose, implement, finish and release your first game, a guide for the uninitiated by the foolish

Back in the Saddle: How to choose, implement, finish and release your first game, a guide for the uninitiated by the foolish

Bienvenido/Bienvenue/Welcome

In this guide, I'm going to detail a series of steps that may be followed to complete your first game project.

This guide is meant for absolute beginners, although, a more advanced student could possibly benefit from it.

You've chosen to take a great step. Game development is an incredibly challenging field, but also a satisfying one.

The first thing I'd like you to do is write down 5 games that you love, not like, love. Games that were significant for you in one way or other. These games don't need to be GOOD[1], they need to be significant to you.

Why? Because games are art, and art is about making your audience feel.

Once you have the list, pick one of those games and write at least 2 things that game made you feel. It can be anything: delight, loss, intelligent, charmed, etc...

Whenever you're feeling down in your journey, I encourage you to come back to this list and pick another game or if you've run out of your inital five, add some more. Then repeat the exercise, write down at least 2 feelings this particular game made you feel.

But for now, one game will do.

Choose a project

Now your next step is to make a decision on what game you're going to make.

Since this is your very first game I can recommend choosing a game from this list.

This list was compiled by Al Sweigart, a prolific writer and author of the book Invent Your Own Computer Games with Python.

Another good source of clone candidates are games in the Atari 2600 library. These games tend to be quite simple to both understand and implement.

Why these games? Because they're basic, they have few gameplay elements. So you can focus on the actual process of making a game, rather than the game itself.

Apart from those lists there are two other genres worth considering:

  1. Visual Novel: A game that blends graphics, storytelling with choices, and impacting narrative outcomes. Some examples of the genre are: Phoenix Wright: Ace Attorney, Professor Layton, and 999: Nine Hours, Nine Persons, Nine Doors
  2. Interactive Fiction: Similar to VNs as in your choices determine narrative progression, just text-based. Some examples: Zork, A Mind Forever Voyaging, and 80 Days.

These two in particular are quite good for writers who don't neccesarily have any experience with either art or programming, but nonetheless would like to develop a game.

Choose your tool

Now that you've selected your game, either from the lists provided or one you found elsewhere, it's time to choose the tool to implement it.

There are many tools out there that play to different strengths, and some of them have more of a learning curve than others.

A good rule of thumb is that the harder a tool is to learn, the more complex games it can produce. Although, take this statement with a grain of salt, sometimes tools are just badly designed.

I'm going to split the tools into two categories, one for general games, and one for the two special genres I mentioned.

General Purpose

Godot 4.0

For our purposes Godot 4.0 is a solid option. It's free, open source, and has a very active community.

GameMaker

A very simple to use tool that has been used to make many games. It's not free, but it's not expensive either, and it has a very reasonable licensing scheme.

Special genres

Ren'Py for Visual Novels

Ren'Py is a free, open source tool that is specifically designed to make visual novels. It's very easy to use and has an incredibly active community.

Twine for Interactive Fiction

Twine is an open source tool that lets you create interactive fiction in the vein of Choose Your Own Adventure books.

What about Unreal, Unity, and other tools?

Tools like Unreal and Unity are great, but quite out of scope of what we're trying to do here. We're trying to get you to finish your first game so you get a taste of what it's like to make games, and then can make a far more informed decision on what to do next.

Also both Unreal and Unity are rather complex and can be quite daunting for a beginner.

Develop the prototype

The next step is to develop a prototype of your game. A prototype is a very simple version of your game that has the bare minimum to be playable. What is the bare minimum in this case? Well, you just need to clone(i.e. exactly copy) your source game, once you've copied all the basic gameplay elements, you're done.

Prototype example

Let's say you've chosen to clone the game Frogger. The first thing you need to do is play it. Which you can do here. You don't need to master it, five to ten minutes should be more than enough to understand the basic gameplay.

Once you've done that, you need to write down a breakdown of the game. What are the basic gameplay elements? What are the rules? What are the win and lose conditions? What are the controls? What is the art? What is the sound? What is the music? What is the UI?

None of these answers have to be long or detailed, just a couple bullet points for each one is fine, this is more to get you thinking than something you're going to present to anyone.

Now, let's say that analysis has been done, and you've identified the all the games basic building blocks.

You're now going to take each one of those blocks and come up with your own prototype version.

For example, to represent the frog, the cars, the logs, and the river. You can use a green square for the frog, a red rectangle for the cars, and a brown rectangle for the logs. The river can be a blue rectangle.

Once you have that, you need to make the frog move with the arrow keys, and the cars move from right to left, and the logs move from left to right. The river should be a death trap, so if the frog touches it, it dies. And when the frog reaches the top of the screen, you win.

After your prototype is finished you should add a simple menu screen that allows the player to start a game, quit, and mute the sound and music.

It should also have a pause menu, with a button to return to the game, and a button to return to the main menu.

Add a twist to it

What you currently have is what we usually call a proof of concept, it's a very simple version of your game that proves that it can be done.

The next step is to add a twist to it. A twist can be several things but it must be:

  1. Gameplay related - Making your frogger clone steampunk themed doesn't make it any less of a frogger clone.
  2. Achievable with your current skill level - Making an MMO frogger with 10,000 frogs all racing towards a goal sounds like a great idea, but if this is your first game, and have no idea what the difference between UDP and TCP even is... it's probably not a good idea.
  3. Fun - This is the most important one, if you don't think it's fun, it's not fun. Although fun is very subjective and we'll discuss how to address this in the next section.

Twist example

So, for our Frogger clone, I've decided that I'm going to give my frog a stamina bar, I'll make the stage longer, and I'll add a timer. The player has to reach the end of the stage before the timer runs out, and has to manage its stamina to do so.

Now, because I'm a fairly experienced engineer, I've decided I'm going to make the stages procedurally generated. This means that the game will generate the stage as the player is playing it. This is a fairly complex feature, but I wrote a similar feature for Disney Mirrorverse, so I have confidence that it's achievable.

To further distance myself from the original game, I'm going to make it about a McGill student moving from party to party through a wild night, all the time aided by a martlet, which is an heraldic bird that is part of McGill's coat of arms.

Get feedback

Once you've implemented your clone with a twist. It's incredibly important to get feedback on it. Feedback is one of the easiest ways to improve your game, because you're basically asking others to do the thinking for you, and the best bit is that they'll do it for free, and all you have to say to everything is: "Thank you for your feedback, and I'll take into consideration."

And you will, because player's opinions are important. Now, you don't have to implement every single suggestion, but you should at least consider them.

You also need to be very conscious of where an opinion comes from. My dear abuelita was a brilliant woman, but I feel she would have a hard time understanding why cannabis and timbits could be possible power-ups in the game, while a fellow McGill student won't need much explanation.

Polish

Once you've implemented the feedback and probably because your project is in a bit of state after all the changes. You should spend some time polishing it. This means fixing bugs, not adding features, and making sure that the game is as good as it can be.

Round 2 of feedback

After polishing, you should go back to your original group of playtesters and ask them to play it again. This time you're looking for bugs, and for any other feedback they might have. You should also ask them to play it for a bit longer, and to try to be mean, do unexpected things like quit a stage midway, and start again. Quit the game over and over again. Click in areas that they usually wouldn't click. Minimize the game and then maximize it. So, try to break it in general.

Round 2 of polish

This is just like the previous round of polish, but this time you're fixing bugs, and making sure that the game is as good as it can be.

Release

Finally, you should release your game to the world. This is not so you get feedback, online feedback is incredibly dubious in its quality, and should be taken with a gigantic grain of salt.

You should release your game because it's a great feeling to see your game out there in the wild. It also gives you something to points to when asked if you've ever released something.

You can release it for free, but I encourage you to charge at least a nominal fee for it. Game development is very much treated as a non-professional occupation due to the amount of free work that is done. This is a problem that is slowly being addressed, but it's still a problem.

I would recommend to release it on itch.io, it's a great platform for indie games, and it's very easy to use. Its community also tends to be friendlier towards beginner developers.

Next steps

Now that you've finished your first game, you have a couple of options:

  • Keep going and make another game, in which case I would recommend to pick a specialization from the next section and start learning about it.
  • Stop and reflect on what you've learned, and decide if you want to keep going or not.
    • It's perfectly ok to also just have enjoyed the experience and decide to come back to it later, which could mean 10 years or never.

If you choose the first option however, there are a couple of things to consider.

Pick your class

Game development is a multidisciplinary field, there are many jobs out there. As an example, a software engineer can specialize in half a dozen fields from Graphics to AI to Networking to Tools, but that's quite out of scope for what we're doing here.

For now, we're going to simplify it to 3 jobs:

  • Programmer
  • Artist
  • Game Designer

Let's take a quick look at each one to see what they do.

Programmer

A programmer takes art from the artist and game mechanics from the designer, and using a set of tools combine them to make the actual game.

These tools are usually combined into a single program called a game engine. You just used a game engine(Godot or GameMaker) to make your first game.

Programmers tend to have a background in computer science, mathematics, physics, or even general sciences. It should be noted that many programmers are self-taught, and programming is just one of the skills those degrees teach. It's perfectly possible for anyone to learn programming and apply it to their everyday life to solve issues without being computer scientists.

Artist

An artist creates every single visual and musical asset in a game. There are artists for everything from the actual 3D models with their animations, to the cursor, fonts, and the myriad of UI elements.

Professional artists have many tools to help them work, but most of them still focus on the basics. A good artist will have an understanding of sketching, composition, perspective, shadow, and colour.

Since game art is a generally new field, most game artists study either traditional art or animation and then learn the nuances of developing for games.

Game music artists are a bit of a special case, since they tend to be musicians first and foremost, and then learn how to compose for games.

Game Designer

The job most people want to do once they find out about it. Game designers write the rules that govern the game world. They decide how far can the player jump, how fast they can run, what weapons they carry, the enemies they face, the conditions for victory and defeat.

Game Designers tend to not have formal training in game design save for a short course or even a post-graduate. There are now plenty of game design schools, but many are of suspect quality, so I'd advise caution when considering one.

If you're considering games as a profession, it's far easier to become a professional artist or programmer and then learn game design on your own. That way you can guarantee two things:

  1. In case you dislike the games industry, which is a possibility, you will still have your more generic profession, which will allow you find other sources of employment.
  2. It's easier to finish a game when you're a programmer/designer or an artist/designer than just a designer. With the former you can fulfill two out of three "neccessary" roles to make a game. The last role can be either made easier through tools or supplemented with existing resources.

Parting thoughts

I hope this guide has proven useful to you. The games industry can be a rather insular and unfriendly place, but it's also a place where you can make a living doing what you love, and getting paid a fair salary for it. But it won't be easy, and you will have to fight for it.

[1] Good is subjective, because games are art, for more on this please refer to John Berger's Ways of Seeing.