Designing a Game Engine for Beginners
The desire to program games was what got me into programming in the first place. I have probably been programming for some 30 years at this point and having children on my own. Today this makes me reflect upon how to teach programming to the next generation.
The Challenge of Learning Programming Today
While we have more amazing tools, hardware and resources available than ever before, it does present new and unique challenges.
Computer hardware today is exceptionally complicated compared to Commodore 64, Amiga and PCs with DOS that I grew up with. When I got serious about programming my own games I was doing it using C in DOS with what what called VGA mode which offered 320x200 pixel resolution at 256 different colors.
You manipulated the graphics by modifying bytes directly in memory. The video buffer started at memory address 0xA000 (hexadecimal number). You could just set a pointer to that location and begin altering bytes to change pixels on screen.
// Location of 256 color VGA graphics with 320x200 pixels
char *video_buffer = 0xA000;
// draw pixel
video_buffer[y*320+x] = color
Each byte could hold a value from 0–255. These values got looked up in a table that held the color palette. Thus say the value 4, would mean to go into row four in the color palette and lookup a triplet for an RGB color.
From these simple foundations we could build up functions to draw lines, squares, sprites and other things. The beauty of this simplicity is that as beginner you where able to understand the fundamentals of computer graphics.
Today it is very hard to learn graphics in this manner. Computer graphics is far more abstract. You don’t modify memory areas directly. Instead you have layer upon layers of abstractions. Modern 3D graphics hardware is phenomenal but also very complex.
If you want to do low level C graphics coding today, then you have to learn about OpenGL, DirectX, Metal, Vulcan or something similar. You will be exposed to vertex shaders and fragment shaders. You have to understand matrices, coordinate transformations, viewports, scenes, virtual cameras, projections, matrix multiplication, vectors etc.
When I began with computer graphics, I did not have to know any of that, and I certainly did not have enough mathematics understanding to understand modern 3D graphics. Most young teenagers don’t have that kind of grasp of linear algebra. They most likely haven’t even heard of it.
Obviously this is not the natural place to start.
The Case for Pixel Art Games
This is why I believe in going back to basics and create retro looking pixel art games. I am talking about games that look like what you see below.
The benefit of this style is that it is something you can easily edit yourself. Especially for beginners and kids who want to learn about programming and graphics it is easy to get into. You can buy or download for free a wealth of pixel art assets which you can easily modify and tailor to your own needs.
Also because the resolution is low, you get a more direct feel for how computer graphics is made up of little squares called pixels. This a bit lost with higher resolution.
You also avoid the problem of dealing with vector graphics where you need to deal with logical coordinates, scene transformation etc which I think is too much to chew over for beginners.
Pixel Art Game Engine Options
There are lots of engines which are tailored towards this kind of game development. A solution I have explored with my kids is MakeCode Arcade. This is actually a pretty good system.
You can put your games on little handheld consoles. It offers visual coding and even has a simple level editor.
As an introduction to programming I quite like this. Although I actually think the system that Scratch uses is better designed for children. However Scratch is not a pixel art oriented system.
The problem with both Scratch and MakeCode while excellent beginner systems is that it is hard to move further.
Tiled Map Editor
The problem with Scratch and MakeCode is that they are not really part of the larger game making ecosystem which have a lot more tools available to make more exiting worlds.
Below is an example of a simple level I made with the Tiled Map Editor.
This is an amazing tool made by Thorbjørn Lindeijer, and it is free although the creator naturally would like you to donate. With some quick guidance my youngest son at 9 years old is able to use this tool. You don’t need to necessarily make a game. It is fun just as a sort of drawing tool. My son likes to just draw interesting worlds with it.
Thus you want to integrate with stuff like this. One option I have looked at is Godot Game Engine which is also an amazing piece of work.
Using Godot Game Engine
Godot is a very promising game engine, which I have spent time making a couple of very simple games with. Yet the jump from something like Scratch and MakeCode to Godot is too large.
It is not a tool I would really want to teach beginner game creation and coding. For somebody who has has gotten a solid handle on the basics of programming and game creation this is a great tool to continue with.
PyGame, LÖVE, PyGame Zero and Others
This brings us to solutions existing somewhere between MakeCode and Godot which are various small 2D game oriented libraries made for friendly programming languages such as Python and Lua. We got:
- Pygame — Which is a 20 years old now.
- LÖVE — A 2D game engine using Lua. Lua is a very popular programming language within game programming.
- Pygame Zero — A more modern and beginner friendly Python game engine.
All of these have their own appeal. If I was to pick solutions I find inspirational when thinking about how I would make a game engine then I think Scratch, Godot, GameMaker and Pygame Zero would be my key source of inspiration.
There are multiple things in miss in these solutions. One is that they are not very tool oriented. What I like about Godot, GameMaker and Scratch is that these are solutions built around tools. You have tools that allow you to drop in and manage assets.
Of course there is an appeal with working in low level way. However what I miss is the ability to do interactive coding, as well as teaching the fundamentals of how these engines actually work.
This is hard in game engines in general because they are built around events. The code has to continuously run and listen for events and interactions by the user. That means that the normal REPL (interactive command line) flow is broken. You cannot write some code, hit enter and see some result. Instead you write a bunch of code with various handlers and callbacks, launch it hand hope everything hangs together properly. If not shutdown and rinse and repeat.
What I think is a possible solution to this problem, is to have game engine which works in two different ways:
- A way to actually make regular games with events and callbacks.
- A non interactive game world simulator.
What I mean by the latter is to develop something similar to a game world where computer controller character move around. They can interact with each other, fire weapons, take damage etc. However there is no player in the world which you control. In this sense, it isn’t really a game but a simulator.
What is the benefit of that? It means you can create a system where you can advance one or multiple frames at a time in an interactive REPL environment. At any point as you develop a solution, you can inspect the full state of the system.
Getting the visuals out becomes much easier. You don’t actually have to have a real graphics system. You can simply manipulate memory buffer representing pixels. We are back to my initial example of pointing directly to VGA graphics memory in DOS.
These buffers can then be written to file as individual PNG files. You can combine multiple PNG files into what is called APGN files (Animated PNG) or alternatively GIF. The benefit of this is that all your software needs to be able to do, is to have the capability to write PNG or GIF files. Lots of tools will take multiple PNG files and turn them into APNG or animated GIF files.
Individual frames can typically be viewed easily in a lot of software.
Thus my idea for a game engine is built upon the idea of making it easy to create game simulators first. This is a great way of teaching the basics of graphics, because a beginner can make a change to one pixel and then immediately see the change done.
The challenge will then to be to advance from this type of development into making a regular game. But I will get into the details of how to do all this in my next story.