ArmenAs the toy game engine is starting to take shape, it's time to put some thought into what I really want from it. First, perhaps a (very) short list of what I don't want:
- This won't be a general purpose game engine
- This will not even attempt to compete with the wonderful solutions already out there
Now before we get into what we do want out of this, let's give it a name:
MiniJamLab
- Mini: Miniscript is the primary behavior scripting language
- Jam: Intended rapid development cycles like Game Jams
- Lab: Experimental, handle with care!
Things that set MiniJamLab apart from general purpose game engines
One of the goals, as the name implies, is to increase the development velocity of small games, an as you might have guessed, this can't be done without making some sacrifices. In order to reduce the amount of boilerplate code required to get something running, we need a higher level of abstraction. Our game script shouldn't have to worry about opening a window, getting a drawing context, loading image data, decoding the image and writing pixels. But how high do we go? Do we attach behaviors to a Sprite, a Button, a TileMap?
This is where the sacrifice comes in: to rather than defining a 100 kinds of nodes you might add to your scene, get the intersection of the ones you need. A Sprite, Button and TileMap all have a few things in common: They are displayed, and may interact with user input. You might say that each of them is an Actor in the scene, and a behavior attached may determine if and where it is displayed, and what to do with incoming user input. We could take this further! If we further sacrifice our ability to be "general purpose" and, for example, only allow Tower Defense games, then all we need is a way to configure a Map, a number of Towers and a number of Enemies, which all have enough intersection to be scripted the same way.
In short, in order to determine the "ideal" level of abstraction for behavior scripts, we need to think long and hard about what kind of games we want to build with this.
So let's set some goals, MiniJamLab should be able to power at least:
- A platformer. Classic.
- An RPG or Rogue-Like
- A Real-Time or Turn-Based Strategy game
The platformer is the odd duck here - it is the only one that won't work on a tile-based coordinate system, but other than that, there is enough intersection between these games to provide a single Actor type node to the scripting environment. The first demo/sample will also be a platformer, so I can focus on the required features for this first.
Well, that's enough for now - next update I'll go a bit deeper into what Miniscript is, why it's great, and how MiniJamLab will use it.
