Exercising the entity system

I’ve written a pretty robust entity system for an unrelated earlier prototype game (a 3D platformer like). It was actually pretty nice, but the game never got too far. So, while building prototype 1 of this game, I’ve decided to just take over and adjust the entity system to have at least something in place.

This turned out to be a good idea. The system is flexible enough to allow most things but organized enough to keep things manageable. It revolves mainly about entities switching states. A state is defined by a state spec which is a collection of parameters, like the displayed model/animation or acceleration, and event callbacks. Each entity is in exactly one state at all times. Additionally, there are 2 states each entity spec always implements: The initial state and the inactive (typically the last before destruction) state.

States also manage resources, loading and unloading them at appropriate times. State specs are built to be mostly descriptive. This way, I don’t have to implement the same basic steps (like loading and unloading resources) over and over again, reducing code size and potential for errors.

The first boss

I’ve decided to flesh out game play a bit more. So I’ve implemented the first boss (aptly named boss1). It exercises the entity system much more than previous enemies, cycling between a set of attack patterns. It actually consists of three entities: The main body and it’s two claws. The body is what controls everything, and the claws are separate targets for the player to shoot down. Each claw has a dedicated attack it performs. The enemy is designed to be defeated in segments: First it’s claws (in any order) and last it’s body. The last part doesn’t work yet, however.

Dropping stuff and mixins

Some features of the entity system resemble OOP concepts, like entity specs and state specs being very akin to classes. There is one more of those concepts: Mixins.

The entity system has to handle all types of entities. This includes enemies, but also more passive ones like asteroids or the tutorial target. Even the mouse cursor is actually an entity!

Many entities will share a lot of code, though. For some stuff, like accelerating, I’m best off implementing this in the entity base class. Some other stuff, like shooting bullets, is very specific, though. So they’re implemented in mixins, which can be pulled in by entities that use them.

Shooting bullets is one example, but there’s another one: Dropping things after an entity is defeated. Indeed, there are now functioning health drops, and dropping then is handled through another mixin.

Technical stuff

Builds that include mouse controls (all of them except PSX, at this point) can now be optionally controlled via keyboard. This was previously only possible by removing the mouse from your system / unloading it’s driver. Now mouse controls deactivate upon first use of keyboard controls.

There is now an early loading screen (actually implemented in NRSL). This will get prettier in the future, but works for now.

Behind the scenes, there were actually quite a bit of improvements to get the boss enemy working. Most important of all is the ability to track individual objects (as in the Wavefront OBJ sense). This allows us to adjust stuff to vertex positions - even in animations. The boss uses to position it’s claw sub-entities.

The camera also got an overhaul, now being able to be focused on chosen entities (instead of always the player) and, optionally be manually controlled.

Some work also went into getting hitboxes right and making them scale properly.

This development cycle

The game is starting to get into shape. You can get a glimpse at what game play will be like. This cycle featured a lot more work on that rather than technical stuff. I feel like I have to keep going that while for a few more cycles to really lay a solid foundation.