As 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.
Top comments (3)
Good stuff! But why do you say that a platformer won't work on a tile-based coordinate system?
Kip and the Caves of Lava uses a tile map for the whole environment. Sprites in Mini Micro use pixels, but you could instead have sprites use tile coordinates too, as long as they can be fractional, e.g., my hero is at x = 4.25, 1/4th of the way between tile 4 and tile 5.
This is what I mean by a higher level of abstraction - if we can configure our game world to exist on a tile map of 10x10 tiles, then our behavior script only needs to know it can move things around on that small grid. The "in between" animations, moving and sliding, are up to the host engine to take care of, which means our actors can only finish on a whole tile. A platformer will have a different kind of setup, where we deal with collisions, involving moving objects. Forcing all actors to always land on a whole tile in that scenario will not work well, unless the tile size is very small
Ah, I see. Thanks for the explanation!