DEV Community: Armen

MiniJamLab: Building Scenes

Armen — Wed, 31 Jul 2024 03:08:56 +0000

It's been a little while since I wrote an update on what's going on with MiniJamLab, so here are a few things I want to share.

Where's the editor?

Conceptually, the way the engine works is similar to engines like Godot and Unity. We compose a scene from components/nodes and attach scripts to them to define behaviors. But where, then, is the editor? How do we go about "composing" anything, if we lack a "composer" tool? Well, that's a great question! Currently, I'm afraid you're stuck writing JSON files to define a scene. Luckily, the JSON file isn't overly complex - For example, this is the TypeScript interface that defines a base node component:

interface NodeData {
  is: string;
  name: string;
  script?: string;
  angle?: number;
  group?: string;
  position?: {
    x: number;
    y: number;
  },
  scale?: {
    x: number;
    y: number;
  },
  size?: {
    width: number;
    height: number;
  },
  opacity?: number;
  fill?: string;
  children?: NodeData[]
}

If you have no intention of displaying anything, this is all you need. Create a component, then add child-components, and so on.

A quick high level overview of the allowed properties:

is

"is" defines what kind of node we are serializing. The base component is just "Node", but we also have others like "Sprite", "TileMap", and some UI nodes like "Text" and "Button", as well as non-display nodes like "Audio" and "SimpleCollider".

name

For many nodes, you'll want to be able to look them up and manipulate them from a script. In order to find them, we must name them - Note that the engine does not guarantee unique names, so keep that in mind!

script (optional)

Well we can't just sit there and do nothing - the "script" property allows us to attach a script file, for which we use the excellent MiniScript language

angle (optional)

For nodes that can be displayed (Sprite, TileMap), this allows us to rotate the node. This property may be moved out of the base node in the future.

group (optional)

Like name, this helps us identify what node we're dealing with - this is particularly useful when dealing with collisions. If we collide with a node in the "enemies" group, we may want to take damage now. If we are are colliding with a node in the "ladders" group, we could enable vertical movement controls. These group names are user-defined, so don't be afraid to get creative!

position, scale, size (optional)

Most nodes, even some that can't be displayed like the base node, will benefit from having at least a position set. That's because its children will be positioned relative to this, which allows things like easy attachments (weapons, tools), or relative movement (like parallax and particle effects)
Scale is useful for example to scale up pixel art, and size will help define a bounding box for collision. Note that for Sprite nodes, the size can be derived from the image, but if it is given, and smaller than the image, it allows us to treat the image as a spritesheet. Defining animations on a Sprite node is a topic for another day, however.

opacity (optional, default=1.0)

Again for nodes that can be displayed, this will allow us to add some transparency - note that here too, the value applies to this node's children as well.

fill (optional)

The "fill" property may mean slightly different things depending on what kind of node we set it on. On a base node with position and size, we are telling the engine to draw a rectangle with the given color. On a Text node, we are setting the fill color for the text.

children (optional)

This one is a bit magical, as hinted at before: nodes defined as children will be drawn after their parent, relative to their parent's position, and inherit the parent's opacity. Hiding the parent will also hide all of its children.

Seriously though... an editor?

While I hope the above sparks the imagination, I bet it also looks a little daunting if you're thinking about even mildly complex scenes. There is no editor. Will there be one? Well, maybe. I can't see any merit in trying to build an editor like Godot, instead, as much as possible, I want to leverage available tools. For example, the TileMap node imports maps from the excellent TileD map editor - and includes support for collision data and item spawns, and indeed should in the future support embedded animated tiles, and parallax layers. In a way, that's most of your Editor needs taken care of. I also don't see a need to provide a code editor for the engine - there are so many options better than anything I could give you: vscode/codium, VIM, or even EMACS for the masochists among us. Use what makes you happy.

Unfortunately that does leave a few gaps:

Composing individual components
Creating UI layouts

Open source tools are notoriously bad at marketing themselves, so perhaps solutions for these exist that I simply haven't come across yet. Perhaps in the end, I'll create a small editor to compose Sprite components and UI layouts. First, however, I'd like to actually have a functioning demo game running on this Mini Jam Lab of mine.

Final thoughts

JSON is a practical format because it is widely supported, many tools exist to create and manipulate these files. However, it's not great for humans to read and write. Other options exist, but sacrifice heavily on tooling. Perhaps another, better way exists to serialize a scene - if anyone has a suggestion I'd love to hear it!

Plotting a course: MiniJamLab

Armen — Thu, 27 Jun 2024 13:15:16 +0000

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.

The new and shiny

Armen — Sun, 23 Jun 2024 17:39:08 +0000

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...