The unexpected (kinda) unfair advantage of game frameworks!

An ode to code

You probably noticed it so far—I am a text/code first person. This explains why I write a newsletter and not record clips for a YouTube channel. It also explains why I progress with game frameworks instead of click-first game engines.

I spent my fair share of time convincing you that engines are the better more efficient simpler solution only to switch to a framework myself.

But, damn, do I like to write some code! While doing some Raylib tutorials, I noticed that most of the code can be reused later! Oh, joy! Not only do I learn new stuff, but create the foundation for my future games!

ReusableTemplates/RayLibBase: This is a basic C# template for RayLib projects

Making a project on Github isn't helpful in itself, because you either have to copy-paste the entire thing to your project or fork it and deal with name changes later. Hence an instruction on how to turn this solution into a template for Visual Studio!

Is it a complete template?

No, it’s not! At this point, it's only a refactored division of game phases. The Raylib tutorials are written in C, so first I had to rewrite them in C#, but on noticing some similarities between the phases I decided to turn this into an object-oriented solution¹. At some point, I'll learn it's not the most effective way of doing game development, but I'll let that worry me later!

Of course, putting all code into this project will be problematic, when updating especially (because of all the projects based on this template, and the need to update them). So I will put only the code that is prone to adjusting by the game developer. The rest will land in separate libraries.

To be honest, I heard how dull it is to make menus every time, or options. And I think it shouldn't be bad with a code-first approach. After all, in most cases, it is a matter of different background images, chosen font, and applying all of the options to the game itself (well, this one cannot be easily automated😉).

Either way, this should end up as a separate dependency.

That, and...

• credits generator

• logo generator (currently inside, soon to be extracted), etc.

This is what I like about a code-first approach. I can make it more and more readable and transparent to the end user². If it's a mess, I can clean it up. If it's hard to read I can make it more readable.

But more importantly, I can jumpstart faster!

The template I showed you today is not much. But at some point, it will become the basis of all my games.

And new templates.

Once I make a shmup I will turn it into a template, so that every shmupy idea can be started faster!

Visual novel? Template it!

Top-down zelder? Template it!

Fire Emblem? Template it!

Templates will have all the basics needed to build upon them.

Why build every time from scratch, when I can build upon it?

a startup owner building something from lego blocks in a coffee shop

Now, can you guess what will be my first game?

1. which I find funny, as the last years of my IT career I've become less and less enthusiastic about object-oriented programming (and moving my interest towards functional programming), only to rediscover it for game development.

2. my overwhelmed self one or two weeks from now