Essay - Published: 2026.01.19 | 4 min read (1,133 words)
build | create | csharp | raylib | video-game
DISCLOSURE: If you buy through affiliate links, I may earn a small commission. (disclosures)
I went into my batch at Recurse Center wanting to learn how to build video games. So it's probably not a big surprise that my first big project is... a video game.
I built a simple clicker game in C# using Raylib and in the rest of this post will walk through what it is and how it's built.
Simple Clicker Game is a simple clicker game. My goal was to learn the basics of game loops, rendering, and publishing a game. So its feature set is intentionally minimal so I could focus on the core systems without getting caught up in feature complexity / polish.
Features:
You can see a demo of the game in the video embedded above or play it yourself / look at the code at the GitHub repo. (There will be links to various code implementations scattered in the following sections).
I've had a few false starts into game development before - typically choosing something heavyweight like Unity, Godot, and Unreal. Those all led me to rabbitholing on 3D and their specific flavor of doing things - models, lighting, collisions, automation, etc.
During my time at Recurse Center I'm trying to learn rapidly across several interests so figured a bunch of small projects would suit me better than one big project which may never see the light of day. This also aligns with my principles around atomic bets / batches so feels better for me.
I ended up narrowing my engine selection to those that were lightweight, well supported, and in a language I was excited to use - mostly C# and TS. This led me to a few good options - Raylib, Phaser, and Monogame.
I ended up choosing Raylib as it was very lightweight and seemed like it would do what I wanted while getting out of the way. Plus there are bindings for it in a number of languages so felt like these skills / context would be transferable if I wanted to try another language.
The main game loop is simple (and I'm told you should strive to keep it simple even for large games):
We do clicking by reading mouse / key presses each frame, update the calculations based on those presses (and passive income), then draw all elements to the screen (I believe this is called immediate mode rendering).
I added upgrades to spice things up a bit - I figured clicking a button forever and just seeing the number go up would be boring. Past clicker games I've played all have upgrades and that's really the driving force behind it - a vast tree of possible upgrades to unlock.
Adding these was a bit harder - mostly because we have to deal with timing (passive income is added each second) and we have to build menu items.
We store the full game state on a global object and keep track of the upgrades the player has. Then we grab the inputs, calculate the amount the upgrades provide, and use that to update the game state.
Save games seem pretty advanced in game dev but an endless clicker like this would be frustrating if you lost all your progress so I added auto save functionality.
Saves happen:
We dump the current game state to a JSON file in the same folder as the executable. On startup, we look for such a file and try to load it.
I wanted the game to work cross platform - mostly because I'm building this on Fedora and basically no one uses Fedora that I'd share this with so if it wasn't cross platform no one would be able to play it.
I thought this would be tough to do but it seems Raylib and dotnet have good cross platform support so it was pretty easy to enable cross platform, single-file executables. I then setup automated builds so that whenever I push a new version of the game, those executables will be available for people to download.
You can find these releases on the release page.
Another area I'm exploring while at Recurse is applied AI - using the new models to streamline my workflows and systems.
Even though I'd never used Raylib before, I was able to build this in a few hours over the course of a couple days by vibe engineering. I had a general sense of what I wanted to do and how it should go together but had never tried to build specifics like menu items or particle effects in Raylib - which themselves likely would've taken a few hours to get the hang of.
I found spec-driven development to be extremely helpful here in aligning on the goals for the project before moving to implementation. I especially found a new step useful where the AI interviews me about any and all clarifications to the spec. Through this interview (40 questions!) we got clear on a lot of items I had in my head but had left out of its prompt context - like how the UI should be formatted, how should we display upgrade information, what coding styles we should use, etc.
AIs do better when you provide them a lot of relevant context but I'm realizing that even when I do large context dumps, I'm still leaving some relevant things out that I have in my head.
This game is playable but not really "complete" but in the spirit of learning generously I'm sharing how it's built early so people can take a look under the hood.
Please take a look at the game and lmk if you have any feedback! Also if you have any resources you like about game dev please send them my way - I'm new to this and would love to learn more ab it!
If you liked this post you might also like:
The best way to support my work is to like / comment / share for the algorithm and subscribe for future updates.