-
Notifications
You must be signed in to change notification settings - Fork 0
Home
The wiki for this project is meant to be a code- as well as project- and thought-process documentation, to help other devs wanting to start with SDL3 using C.
I wanted to create a game in pure C without having to rely on clunky, UI-heavy and slow game engines that are way too overkill for a small game to tip my toes into gamedev.
A space-shooter was the most charming idea to me.
I wanted to create a character that has two ways of moving: rotation by mouse and movement by pressing WASD. The character should be able to shoot projectiles that, if they hit an object, increase a score counter.
I did not want to juggle any textures or 3D objects, because OpenGL/Vulkan rendering is complicated and I wanted to create a simple 2D game first.
I wanted to have fun with C with focus on the game logic instead of rendering or anythign else.
I researched both SDL and Raylib and ultimately settled on SDL3, simply because SDL has been there forever and is also pure C. There was no other reason, I could have gone with Raylib but the already existing documentation for previous SDL versions and years of experience from other devs made this my preferred choice.
I used git for version control, WIN10 as my OS (don't give me shit), alacritty with powershell and neovim 0.11. to edit my code.
There are not many Youtube videos about SDL3 (because it is pretty new I guess) or SDL with C in general. However, to get an idea about how to go about stuff, I watched Mike Shah's "SDL3 tutorial playlist" and constref's "Making a game from scratch with C/C++, CMake, SDL3, SDL_Image, SDL_mixer".
I also had the SDL3 documentation open the whole time and every time. The functions are very clearly structured, so good that I never had to ask ChatGippedy to explain functions to me.
Before I wrote my first line of code, I mentally planned out what I wanted to do. I set small goals I wanted to achieve each step, to not work on everything at once but structure my approach, because working on small packages is easier than working on five things at once.
My first goal was to 1. create a player character and 2. make it turn using the mouse position.
The next goal was to make the player move using WASD, and so on and so forth.
I knew I had to split up my logic into different files (or "compilation units") -> main loop, player, projectiles and enemies. In the source code you will also discover more files, like my common.h or S_shapes.h which were helpers during development.
Managing those header files is an art in itself, there is no right or wrong, but there are bad and better approaches. I tried organizing them in categories, like player, shapes, projectiles and enemies, but made sure some functions are shared accross each other to enable communication between those systems.
For everything I added I first asked myself if I could add this to a system I already have to keep the code as slim as possible. For example: the scoring system I added as a member to the player struct because it made sense that each player has his own score. But the hex shape is too far away from any other part so it was neccessary to move it to its' own space.
After I completed each small goal I pushed the new version to GitHub to track and show what I had done.
Now you can continue reading the code or architecture documentation. :)

