While running the game today, I noticed that I occasionally got a room or two that were rotated incorrectly. These were always rooms with 3 and sometimes 2 connections. Meanwhile, all the other rooms were always fine.

I started tracking down the reason, but it was hard to reproduce reliably, since the entire dungeon is random. Skip a few hours later and I realized this was an error in determining how much to rotate a room template based off the comparison between desired and actual room directions. Okay so, the actual bug was that directions Up, Right, Left were sorted in that order, when in actuality I needed Left, Up, Right, because I am not just looking for the 3 consecutive directions, but also that they have the same “gap”. Same bug with Up, Left. In the end, I wrote a bunch of unit tests for my newly-made direction and rotation utility library.

Yay, unit tests.

Anyway, my focus was going to be on player equipping and using items. I’m going to talk about the actual combat at a later date when I’ve ironed out the details. It’s likely going to be gun-based, so I’m making the test items be guns for now (although it makes little difference for the framework, might as well be swords and bows). Anyway, first order of business it to make an item framework for the game. Tremble before my might inventory:

Items now have entities, definitions, world objects, sprites, links between all that and their collections in the world. I glossed over these details with other things – mobs and tiles, but they have the same data-definition-view logic. It’s all very independent, encapsulated and structured.

Making the player equip an item is actually the most straightforward part. I made a simple inventory with a weapon slot and I can place any item definition in it, whose sprite is then used on the player’s world object (using debug key to equip here):

In fact, I can extend this further to swap the currently equipped item and drop it on the floor. In fact, this is also quite easy given my item framework is basically a copy of mob/tile framework and those already know how to “appear” in-game:

Now I can also add a couple buttons to drop the current item and another to grab and equip the closest item:

Consequently, the player can swap the item with another by picking it. In fact, let’s polish it a little and drop the old item where the new one is:

Impressive! In all seriousness, I will need to have a much more time-consuming polish pass to actually drop and pick up items smoothly with animation and all sorts of flair.

Now I need to add another information layer to the room definitions. At the simplest, it is currently a list of location within the room that have a certain designation, such as “spawn a mob” or “spawn some loot”. This can be set in the room editor:

This is fairly easy to convert into an action when placing the room (most of the work was done with tiles). So the player gets a gun at the start now:

In fact, pretty much the same works for mobs:

I also created props — in-game objects that are not pickable items and would have collisions and interactions. They have the same exact framework logic as items (and mobs and tiles), so there’s not much to add. Here’s a loot chest prop spawned instead of an item directly:

Now we can get fancy and have the chest spit out an item when the player gets close (for the first time):

Of course, we need visual feedback for actions like opening chests. In fact, I will define my original chest as something I can interact with (chest) and specify that it should transform into an open chest, which is a different prop:

This now means approaching a chest spawn a new open chest and drops an item (but approaching an open chest does nothing):

The transitions happens seamlessly between the two props, so I don’t need to complicate prop logic (yet) with being able to transform them and such. If I ever need to transfer stuff like health between props (or any other property between mobs or items or whatever), I can do so manually while keeping the main logic cleaner.

Later, I will work on the random loot and mob generation and placement in rooms. But I need to get actual combat going followed by actual enemy AI followed by MMO RTS elements. In other words, I need to start playing the game before I build more systems for it. I don’t really have the luxury to rewrite and redesign large parts of the game, so I need to test and get them right asap and not accidentally proceed into a dead end.

MicroRogue DevDiary #7 – Items
Tagged on:     

Leave a Reply

Your email address will not be published. Required fields are marked *