My original intent for the project was to create a version for mobile. 2yrs later I finally did it. I also redesigned the game mechanic to be friendlier, created a tutorial to learn how to play & gave the whole game new art, and feel. I'm going for a more minimalist relaxing feel to the game. I did the art design myself which I'm pretty proud of how it turned out.
I ended up re-coding the game in Unity. Moving the C code into C# code. The primary reason for this was to get it on Android & iOS without a lot of learning on my behalf.
Would love it if you checked it out. I think it's a pretty solid casual puzzle game. You can download it here for Android. You can also play it on the web here. The experience is a lot better on the app & it also saves your progress.
Thanks for reading, & if you've got any thoughts please leave a comment.
I ended up re-coding the game in Unity. Moving the C code into C# code. The primary reason for this was to get it on Android & iOS without a lot of learning on my behalf.
Would love it if you checked it out. I think it's a pretty solid casual puzzle game. You can download it here for Android. You can also play it on the web here. The experience is a lot better on the app & it also saves your progress.
Thanks for reading, & if you've got any thoughts please leave a comment.
I’m releasing my first game ‘Feoh the Fitter’. It is a puzzle grid game designed to test your spatial awareness and allow you to explore the rules of the game. If you like thinky puzzle games like sokobond or a good snowman is hard to build you may enjoy this game.
To download the game i’ve created an itch io page here (itch io page). It is pay what you want.
If you have any bugs that come up, any questions or just want to say hello, the best email is [email protected]
I made the game with the idea of building a system and exploring interesting consequences that arise. I have learnt a lot from this project. How to make a professional product (hopefully!), how you go about designing a game and most of all, actually finishing the product. All three of these were a big learning curve for me, but I’m happy to say I made it out alive.
It has given me confidence to take on bigger challenges, and the confidence of finishing a product once I start.
Thank you everyone on the Handmade Network for answering questions and giving me support (just by existing) to make this game. I would not have done this without the network, and definitely not without Casey’s Handmade Hero, which gave me the confidence that I could even make a game. I am very grateful Casey made the series and everything that has come about from it.
I would be great if you could test the game on your computer and see if it works, and give me any feedback.
Some details about the game:
Developed primarily on a Mac computer
Used plain c (no function or operator overloading and writing typedef struct a lot)
Compiled using clang on mac and visual studio compiler on windows
Libraries used:
SDL2 for both Windows and Mac
Sean Barret’s stb_image, stb_image_write, stb_truetype
gl3w to load OpenGL functions
Only supports rendering through an OpenGL context. And needs at least version 3.1 to run.
Time Length:
I started making the game at the start of September and finished around end of January. Didn’t do anything in December. Working part-time (2-3hrs 5 days a week approx.). I used engine code from previous projects, so didn’t write it from scratch.
To download the game i’ve created an itch io page here (itch io page). It is pay what you want.
If you have any bugs that come up, any questions or just want to say hello, the best email is [email protected]
I made the game with the idea of building a system and exploring interesting consequences that arise. I have learnt a lot from this project. How to make a professional product (hopefully!), how you go about designing a game and most of all, actually finishing the product. All three of these were a big learning curve for me, but I’m happy to say I made it out alive.
It has given me confidence to take on bigger challenges, and the confidence of finishing a product once I start.
Thank you everyone on the Handmade Network for answering questions and giving me support (just by existing) to make this game. I would not have done this without the network, and definitely not without Casey’s Handmade Hero, which gave me the confidence that I could even make a game. I am very grateful Casey made the series and everything that has come about from it.
I would be great if you could test the game on your computer and see if it works, and give me any feedback.
Some details about the game:
Developed primarily on a Mac computer
Used plain c (no function or operator overloading and writing typedef struct a lot)
1 2 | 11855 loc total not including libraries or external code. 3390 loc for the main gameplay code, included in the above |
Compiled using clang on mac and visual studio compiler on windows
Libraries used:
SDL2 for both Windows and Mac
Sean Barret’s stb_image, stb_image_write, stb_truetype
gl3w to load OpenGL functions
Only supports rendering through an OpenGL context. And needs at least version 3.1 to run.
Time Length:
I started making the game at the start of September and finished around end of January. Didn’t do anything in December. Working part-time (2-3hrs 5 days a week approx.). I used engine code from previous projects, so didn’t write it from scratch.
If you want to make your program look a bit more professional, one way is to set a icon on the exe, instead of the default icon.
Windows version:
Thats it! Now the exe should have a unique icon to make it look more professional.
Note: I believe the ico file is compiled in with the exe, so you don’t have to keep the .ico file around when you go to ship your program.
On mac it is also pretty simple. Mac differs in that you don’t actually change the icon of the executable, instead you set the icon for your .app bundle.
For more info about the bundle structure on MacOS see
I found looking in the .app folder was the easiest way to work out how it works.
Windows version:
- Convert your logo image to .ico format. There are free online convertors that do the job.
- Create a .rc file in your project. This is a script file windows will use to find out you want to set the icon.
- In this file write: uniqueId ICON “./path/to/file.ico”
Where the uniqueid is a name of your choosing. - You then compile this file using windows resource compiler, which takes .rc files and converts them to .res files. On the command line write: RC filename.rc where filename is the name of your .rc file you created.
- Now that you have a .res file, you can pass this to the compiler when you compile your .exe. You just have to pass the path/to/file.res
Thats it! Now the exe should have a unique icon to make it look more professional.
Note: I believe the ico file is compiled in with the exe, so you don’t have to keep the .ico file around when you go to ship your program.
On mac it is also pretty simple. Mac differs in that you don’t actually change the icon of the executable, instead you set the icon for your .app bundle.
- Convert your png image to .icns instead of .ico. I found the program Image2icon pretty good. And you just need the free version.
- Put this file in the Resources folder of your bundle
- A .app bundle has a file called Info.plist which is an XML file with meta data about your app. In this file there is an identifier that looks like this:
<key>CFBundleIconFile</key>
<string>iconfilename.icns</string>
For more info about the bundle structure on MacOS see
I found looking in the .app folder was the easiest way to work out how it works.
When we ask the GPU to render a sprite or mesh to the screen, the biggest bottleneck isn’t the actual rendering of the pixels, but sending the data from the CPU to the GPU. And what this comes down to is how many draw calls we issue in each frame. (A draw call being in OpenGl glDrawElements). So instancing is an optimisation technique in which we bundle as many render objects (render object being a sprite or mesh in our game world) into the same draw call.
In a perfect world we would have a draw call for each render object and we would set uniforms unique to that render object i.e. the color, the MVP matrix, the objects material etc. However if we had a even handful of render objects in our scene, our program would come to a slow unplayable halt. So we want to share as many things as possible across render objects. The only hard limit that we can’t share is the vertices & indices array we are drawing, and the shader we are drawing with. The rest is up for grabs. Even with these two hard parameters, there are still work arounds like having a uber mesh or under shader. The good news is with 2D games, we only use one vertex buffer in the game, a quad, and in this game one shader for sprites. Given this, there is no reason why we can’t render our whole scene with one draw call. And this is what we’re going to do!
To make our game code as simple as possible, the game code knows nothing about instancing. We can call ‘pushSprite’ or ‘pushMesh’ anywhere in the code, which gets added to a render buffer. Then when we are ready to issue the draw commands to the GPU we call ‘executeRenderGroup’ which does all the heavy lifting.
Since the render objects are unsorted in what sprite or shader they use, we first have to sort them. This is the first part of our instancing algorithm. Our sort function is a quick sort that groups the objects based on a criteria. This criteria depends on how your game engine is set up, but for my game is looking for:
1. Same vertex handle (our quad)
2. Same shader program handle
3. Same texture handle (where a texture atlas comes into play)
It groups render objects with this criteria, together. After this we can then loop through them and collect unique information about the render object like it’s position and color. This is part two of our instancing algorithm. This loop looks like this:
So here we are looping through and collecting all the unique information and putting in into a stretchy array. In our engine the three things we need to send to the shader are:
1. PVM matrix to position the object on screen
2. Color tint
3. The texture UV coords since we are using a texture atlas
The final part of our instancing algorithm is then converting this array into a form that the GPU can access. Since arrays can’t be very big in glsl, I’ve gone for storing this info in a texture buffer. What this looks like is:
So it creates a GL_TEXTURE_BUFFER object, which we then copy the array data into. We create a buffer for each unique info (one for PVM, one for color & one for UV coords), then set the buffer handle via a uniform. We then delete this buffer the next frame, to make sure we aren’t deleting anything in the middle of rendering.
There is one more piece to the puzzle here. In order to do things as I’ve done i use a modified version of glDrawElements, which is glDrawElementsInstanced. This is specifically made for instancing in which pass the usual arguments as drawelements, but with one more argument specifying how many times we want to draw this vertex array. Then in our shader we have a handy predefined variable call gl_InstanceID. This gives us the index of the instance being drawn, which we use to access the info our of our arrays.
For accessing our PVM matrix we use the following code:
This wraps up how I’m doing instancing for the game. There are many ways to make use of instancing, and comes down to how your engine is set up, and what can you share amongst render objects. Can you use a texture atlas instead of seperate textures, can your use a uber shader instead of seperate shaders? and for unique data, what’s the best way to retrieve this on the GPU?
Some more info on topic:
Opengl Instancing tutorial
Randy Gaul lecture at Digipen
NOTE:
I tried using a standard glTexImage2D(GL_TEXTURE_2D… to store the unique data instead of a GL_TEXTURE_BUFFER, but I couldn’t get it to work. I think because of the implicit remapping of the values behind the scenes. Whereas GL_TEXTURE_BUFFER doesn’t do this.
NOTE: To my dismay GL_TEXTURE_BUFFER isn’t supported on iOS. However isn’t applicable now since they’ve moved to Metal (even more dismay :().
In a perfect world we would have a draw call for each render object and we would set uniforms unique to that render object i.e. the color, the MVP matrix, the objects material etc. However if we had a even handful of render objects in our scene, our program would come to a slow unplayable halt. So we want to share as many things as possible across render objects. The only hard limit that we can’t share is the vertices & indices array we are drawing, and the shader we are drawing with. The rest is up for grabs. Even with these two hard parameters, there are still work arounds like having a uber mesh or under shader. The good news is with 2D games, we only use one vertex buffer in the game, a quad, and in this game one shader for sprites. Given this, there is no reason why we can’t render our whole scene with one draw call. And this is what we’re going to do!
To make our game code as simple as possible, the game code knows nothing about instancing. We can call ‘pushSprite’ or ‘pushMesh’ anywhere in the code, which gets added to a render buffer. Then when we are ready to issue the draw commands to the GPU we call ‘executeRenderGroup’ which does all the heavy lifting.
Since the render objects are unsorted in what sprite or shader they use, we first have to sort them. This is the first part of our instancing algorithm. Our sort function is a quick sort that groups the objects based on a criteria. This criteria depends on how your game engine is set up, but for my game is looking for:
1. Same vertex handle (our quad)
2. Same shader program handle
3. Same texture handle (where a texture atlas comes into play)
It groups render objects with this criteria, together. After this we can then loop through them and collect unique information about the render object like it’s position and color. This is part two of our instancing algorithm. This loop looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | for(int i = 0; i < renderGroup->items.count; ++i) {
bool collecting = true;
while(collecting) {
RenderItem *nextItem = getRenderItem(group, i + 1);
if(nextItem) {
if(info->bufferHandles == nextItem->bufferHandles && info->textureHandle == nextItem->textureHandle && info->program == nextItem->program) {
//collect data
addElementInifinteAllocWithCount_(&pvms, nextItem->PVM.val, 16);
addElementInifinteAllocWithCount_(&colors, nextItem->color.E, 4);
if(nextItem->textureHandle) {
addElementInifinteAllocWithCount_(&uvs, nextItem->textureUVs.E, 4);
} else {
assert(uvs.count == 0);
}
i++;
} else {
collecting = false;
}
} else {
collecting = false;
}
}
|
So here we are looping through and collecting all the unique information and putting in into a stretchy array. In our engine the three things we need to send to the shader are:
1. PVM matrix to position the object on screen
2. Color tint
3. The texture UV coords since we are using a texture atlas
The final part of our instancing algorithm is then converting this array into a form that the GPU can access. Since arrays can’t be very big in glsl, I’ve gone for storing this info in a texture buffer. What this looks like is:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | typedef struct {
GLuint tbo; // this is attached to the buffer
GLuint buffer;
} BufferStorage;
BufferStorage createBufferStorage(InfiniteAlloc *array) {
BufferStorage result = {};
glGenBuffers(1, &result.tbo);
glBindBuffer(GL_TEXTURE_BUFFER, result.tbo);
glBufferData(GL_TEXTURE_BUFFER, array->sizeOfMember*array->count, array->memory, GL_DYNAMIC_DRAW);
glGenTextures(1, &result.buffer);
glBindTexture(GL_TEXTURE_BUFFER, result.buffer);
glTexBuffer(GL_TEXTURE_BUFFER, GL_RGBA32F, result.tbo);
return result;
}
|
So it creates a GL_TEXTURE_BUFFER object, which we then copy the array data into. We create a buffer for each unique info (one for PVM, one for color & one for UV coords), then set the buffer handle via a uniform. We then delete this buffer the next frame, to make sure we aren’t deleting anything in the middle of rendering.
There is one more piece to the puzzle here. In order to do things as I’ve done i use a modified version of glDrawElements, which is glDrawElementsInstanced. This is specifically made for instancing in which pass the usual arguments as drawelements, but with one more argument specifying how many times we want to draw this vertex array. Then in our shader we have a handy predefined variable call gl_InstanceID. This gives us the index of the instance being drawn, which we use to access the info our of our arrays.
For accessing our PVM matrix we use the following code:
1 2 3 4 5 6 7 | int offset = 4 * int(gl_InstanceID); vec4 a = texelFetch(PVMArray, offset + 0); vec4 b = texelFetch(PVMArray, offset + 1); vec4 c = texelFetch(PVMArray, offset + 2); vec4 d = texelFetch(PVMArray, offset + 3); mat4 PVM = mat4(a, b, c, d); |
This wraps up how I’m doing instancing for the game. There are many ways to make use of instancing, and comes down to how your engine is set up, and what can you share amongst render objects. Can you use a texture atlas instead of seperate textures, can your use a uber shader instead of seperate shaders? and for unique data, what’s the best way to retrieve this on the GPU?
Some more info on topic:
Opengl Instancing tutorial
Randy Gaul lecture at Digipen
NOTE:
I tried using a standard glTexImage2D(GL_TEXTURE_2D… to store the unique data instead of a GL_TEXTURE_BUFFER, but I couldn’t get it to work. I think because of the implicit remapping of the values behind the scenes. Whereas GL_TEXTURE_BUFFER doesn’t do this.
NOTE: To my dismay GL_TEXTURE_BUFFER isn’t supported on iOS. However isn’t applicable now since they’ve moved to Metal (even more dismay :().
Since starting this project for Handmade Network I think I've changed project five times, with different game ideas and a drawing app. None were being finished, so when One thing a Month challenge came up, I jumped on it eagerly. I made a tetris clone with a twist. From this I built it into a puzzle game, over the last couple of months.
I've made this project as simple as possible, with goal of finishing a complete game and releasing it.
Through the project so far, I realised a game doesn't have to take forever to finish. Just being in the space of creating things feels really good. I plan on releasing it in the next couple on months, hopefully on steam, itch.io, and apple & google play store. I'm using SDL for the platform layer so I hope it isn't to big a job to get it running on touch devices.
After making this game I realised I learnt to program more for designing interesting games, than engine development. I really like the whole process of building a game in the Handmade way but I find it discouraging wrestling with graphics APIs, multi-platform support and complier switches. So I'm not sure where the next project will be made. Maybe Jai will make it easier or I might learn to use Unity. Who knows!
This is the trailer I've made for it here
I'll keep this blog posted for more info about the game and releasing it.
I've made this project as simple as possible, with goal of finishing a complete game and releasing it.
Through the project so far, I realised a game doesn't have to take forever to finish. Just being in the space of creating things feels really good. I plan on releasing it in the next couple on months, hopefully on steam, itch.io, and apple & google play store. I'm using SDL for the platform layer so I hope it isn't to big a job to get it running on touch devices.
After making this game I realised I learnt to program more for designing interesting games, than engine development. I really like the whole process of building a game in the Handmade way but I find it discouraging wrestling with graphics APIs, multi-platform support and complier switches. So I'm not sure where the next project will be made. Maybe Jai will make it easier or I might learn to use Unity. Who knows!
This is the trailer I've made for it here
I'll keep this blog posted for more info about the game and releasing it.