Every once in a while I come across something new (to me) and interesting, and it makes me wonder... could I build a game engine on this? (spoiler alert: the answer is always yes). Recently I came across MiniScript, an embeddable scripting language that has apparently been around for years, but somehow escaped my attention until now. There are at least 3 implementations of the MiniScript interpreter, in C++, C# and TypeScript, which allows a lot of flexibility in what tools and frameworks to embed with. For my experiment, I've chosen TypeScript, as it is a language I use often in my day to day work, and allows for fast prototyping with excellent tooling.

So what do I call it?

Oh, naming things - certainly one of the hardest parts of the entire project. I will base a lot of this project on concepts I used to build the A2D engine (over 12 years ago now!), but calling it A2D2 just sounds like a drone I'm not looking for. I've asked a chatbot to help me come up with a name and the best it could do was "MiniJamLab", which I guess isn't the worst. Suggestions welcome, though.

Project Goals

First I want to say I'm not looking to build the next big thing, competing with the likes of Godot (I love Godot).

So, goals:

Avoid callbacks

12 years ago I built A2D around event listeners - which meant, as was customary for the time in JavaScript, callback hell. This time around, I want to avoid callbacks as much as possible, and instead keep things synchronous where possible, and use async/await where not.

Separate behavior scripts (using MiniScript!)

There should be no need for boilerplate code in the bahavior scripts. No creating drawing contexts, manipulating pixels, etc. Let the Engine handle the stuff, and write the code that actually makes things happen.

Testable code

This one gets me every time. I get excited and have half of the thing built and running a game of sorts before I realize I haven't added any unit tests! This time will be different. TDD is the name of the game, and it forces me to think about architecture differently, producing more testable code.

Leverage existing tools and formats

Why build a map editor if a perfectly good one exists already? Why invent a configuration file format if JSON and YAML are perfectly fine for the job? Let's not create headaches for solved problems (I know, the entire "Game Engine" problem has been solved, but let me have a little fun with this, ok?)

Lessons Learned

And finally, I'm re-reading a lot of my own old code, particularly in the old A2D engine code, to see how I solved the common problems at the time, and what I can learn from my mistakes.

More updates to come...