Writing Video Games¶
I am, by absolutely no means, a game developer.
However, I wish I could be.
Here’s my advice for people who want to become independent game developers.
Choose a Good Platform¶
I have looked at Unity and Godot. While Godot is great, I think Unity has a lot more features and seems to be the ideal place to go.
I don’t like C#, but it honestly isn’t that bad, and a lot of what you can do in Unity can eliminate the annoying aspects of C# from what I can tell.
Godot has GDScript, a cheap and weak knock-off of Python that really doesn’t resemble the Python I know at all. Godot has a lot of features, but it does show a significant chunk of features and it may be the ideal way to make a game. I don’t know.
Panda3D is also interesting, and seems to provide a lot of framework features. I haven’t used it much so I can’t really say how good it is.
Of course there is Unreal Engine, but I know next to nothing about it.
In the Python universe, you have basically these options for making a game:
Using something like Qt to develop a typical app. If you game is at all heavy on UI elements, I’d recommend Qt.
Using pyglet for a lightweight framework. Pyglet really doesn’t use much and doesn’t have a huge community to get support from. you’ll be left re-implementing a ton of the features that something like Godot would give you, let alone what you can find in Unity.
Using Pygame for decent framework. It’s easy to make games in Pygame, it’s a lot harder to make fast games. Part of this is due to Python, the other part is due to the SDL library Pygame is built on.
Rolling your own engine from scratch.
Elements of Your Game¶
As an experienced programmer, I can tell you what your game will end up looking like after sufficient development. Eventually, your code will be divided up into these areas:
Code for handling the main event loop. This will typically process user input, then network events, then update the game state, and then draw the new game state on the screen. Handling user and network events is basically translating incoming events into updates to the game state.
Code for managing the game state. This will be some sort of database, probably organized hierarchically due to the nature of games.
Code for updating the game state. This will apply the physics engine and the game rules. If you do have a physics engine, prepare for super-complicated code that is very sensitive to the smallest changes.
Code for drawing the scene. This will include code to draw UI elements that users can interact with, present information, as well as to render the scene.
These bits of code will largely be independent of one another.
Of note, the code that holds on to the game state will have to have routines to store and restore the game state. I would even consider something like SQLite or some such due to the nature of data. You don’t have to have all the data in memory all the time.
The code to update the game state is the rules of the game. There will be a lot of optimizations here to ensure that the bare minimum work is done. IE, don’t even try to detect collisions between objects that aren’t in the same region as one another. This will also include algorithms such as pathfinding, random number generation, and such.
Incremental Development¶
If you start off trying to code everything at once, you are going to be met with failure. It’s very important you start very, very small and make steady incremental changes. It’s also important you spend a lot of time actually playing your game and working only on those features which will actually make the game better.
