Every programming paradigm has a peak point, the point of no return that I call the “A-ha!” moment. It’s the moment where you get “it” and “it” is no longer confusing. You may not understand all the facets of the paradigm but you know enough to exponentially move forward, using professional tutorials and literature as well as personal tinkering with the technology.
Understanding the “lifecycle”
A lifecycle of an application is a way of describing how an application works and what gets run when. Web development, for example, may seem straight forward:
request->code->response, but can be very complicated in an MVC application where the lifecycle is more like:
It took me a while to grasp the client-side part of web development since it’s not linear (you don’t simply go from one part of the code to another until you send out a response), but it’s event-based, meaning that code gets fired only after an event happens. Here’s a quick diagram of that:
Some JS frameworks will alter that lifecycle (such as MV* frameworks) but this is the basics of it. Now, let’s look at game development’s lifecycle and how it works.
The While Loop (Game Loop)
The while loop (formally called the
game loop) is the portion of the game that gets run continuously while the game runs. Ever heard of “FPS”? FPS stands for Frames Per Second. For most purposes, that basically means “how many times the update/while loop gets run a second”.
There are things that have to be continuously monitored in a game for it to run. You have to draw the next “frame” (image representation of what you’re doing), calculate if objects collided, figure out what the AI will do in the next second, check if the user is pressing a button and trigger an appropriate action. All of that happens anywhere from 30 to 60 times a second (30fps/60fps). Just as a sidenote, consoles usually run at 30fps (or slightly lower) while PCs run 60fps on an optimal setting.
To put it in different terms, imagine you’re building an MVC application. Whenever you fire off a request, the request goes through the router which sends it to the controller, that fetches all the correct “models” (information), and finally sends it to the “view”. Game programming is a lot like that except this happens in the “update” calculation and keeps happening as you play the game.
Just as a sidenote, and to provide some distinctions. I’ve talked about two distinct concepts that merge together. There’s the Game Loop which runs the game (shading, rendering, etc.) which fires off Update methods which update objects. This is great because each object and part of the game world can have its own way of updating itself, and then the game loop run that code. The Game Loop thus also takes care of using the game updates in order to draw the next frame correctly.
Anyways, I hope that makes sense. It took me some time to understand what this actually meant and helped me a lot when I figured it out.
The “create” method (or init())
So, a while loop gets continuously run. The problem is that you don’t want classes and other stuff continuously initiated. For instance, you shouldn’t have to load up all your images, create all your characters, 30 times a second. You want to do it once.
This is the “create” portion of the game. Basically, when your game loads up. You can instantiate your classes and objects etc.
This create part of the lifecycle will also start the game loop and provide it with all the necessary (preloaded) assets.
The game “states”
After going through a few tutorials, I feel like “game states” should get a mention. Now, not every game follows this paradigm but it is most apparent in Phaser.io which kind of works on this way.
For example, in the Flappy Bird Phaser tutorial, the game gets broken down to 5 different states.
Each “state” is a representation of the game at different parts of its being and each state has several methods like the
So what can these states be? Well, there is the “preload” state. This is when your game is loading up. During this state, you obviously don’t need to have any calculations regarding bullets done. Hell, you probably don’t even have the right files loaded up for those things!
In the preload state, you basically load up all the files you’ll need. From textures to code, to everything else, music etc.
Then there’s the “menu” state. It’s obviously MUCH different from the actual game itself. So this state will get its “create” and “update”.
Then there’s the “play” state which is exactly what it sounds like.
The cool thing about all these states is that your preload state will be able to load up all the assets you may need for the “play” state which the
play state will take advantage of in its “create” cycle.
Understanding the flow of programming makes it much simpler to get started, that’s for sure.
Wtf is collision?
“Colliding” objects is basically the act of checking if any of your objects are touching each other. If they are, you’d write the logic for what to do next.
For instance, if two balls collide, you may want both of those to invert the direction they’re going (so that they head opposite ways) and diminish their velocity.
The wheel is thoroughly vetted
Don’t reinvent the wheel, it’s been done over and over and now we have tons of great wheels that you can use. Simply said.
For example, collisions? Most engines do those out of the box. Texture loading? Same. You just have to access the API of the library and write the code for your specific use-case.
However, plenty of people will let you know that learning by reinventing the wheel is the best way to do it, and I agree.
Only 1 user will use this and it’s on THEIR machine
When it comes to web development, one of the main tenets of building an application is considering how the server will perform, how many people can access the site at once and so on. Game development is nothing like that.
Whatever minimum specs your game requires, it’s on 1 machine getting accessed by 1 user. Not a single machine of yours that gets thousands of hits a day. Performance is a big deal, sure; however, performance is calculated much differently. Keep this in mind.
Programming Language Selection
A topic I often hear on forums and subreddits is “What programming language should I learn first?” to which I often hear, “Learn game development with whatever you already know.”
The problem is that if you’re like me, you may know PHP or Ruby but those are quite useless for game development. However, your programming knowledge is not.
Depending on the types of games you’d like to learn to build, I’d recommend different technologies. There is a ton to be honest and you can’t just jump into UnrealEngine and make the next best FPS. The top languages I’d say are Java, C# (especially because of Unity), and the holy grail C++. Java and C++ sound out of date but they’re very current when it comes to game development, and C++ is definitely the top language.
The problem? C++ is not an easy language to use and develop in when you’re a beginner. So I’d say: stay with Java, C#, or even Python. You’ll be able to make 90% of the games you want to. Want to make game development your career and want to work on AAA games? Go for C++ at that point, and the transition will be easier.
If you still can’t decide (even though it doesn’t really matter what you pick), check out a listing of top game engines of the year or this generation. You might also want to just search for top engines for whatever language you like.
As a note, I’d like to let you know about Cherno’s Tutorials which are great for starting in Java and learning about how to build a game engine. He goes over all of the “A-ha!” concepts throughout the tutorial series.