For King Trivia! – Adventures in novice game development, Week 3

Originally posted on 26th January 2017 Written by: Mark

There have been a few... distractions here at Mostly Kobolds HQ. Between podcasting, writing articles and repeatedly strapping a hunk of plastic to my face and declaring myself to have transcended meatspace, I haven't been able to allocate as much of my time to developing my game as I'd have liked. Happily I did find a few hours to fiddle about under the still-to-be-constructed hood and, thanks to having put a ridiculous thought into how things could work beforehand I managed to get some progress done in the times I wasn't being distracted by shiny colours and pretty lights.

Putting together very basic dungeon generation went off surprisingly smoothly. The way I've designed it is that the game lays down a series of pre-designed rooms, each up to 5x5 in size. The specific choice and direction of the room is decided by a dice roll, which then corresponds to an event which feeds the required data into memory. Each room is made up of a series of variables, which when fed through the dungeon generation process are laid out as tiles in front of an object that handles the positioning of each room. After the room is finished, the object is placed on the room's exit, and the process is repeated as required until a series of rooms has been placed.

At this point I can't even remember what those counters in the corners do. I should probably hide them.

The result so far is a program that creates extremely boring linear dungeons. I decided that there was no point in creating more complex rooms until factors like monster and item placement were built into the system. Instead I moved onto working on allowing the player to move around the dungeon. This also went ludicrously smoothly. In this case, because my walls and floors are contained on the same tile, I had to set the directions the player could move on each tile.

For the sake of adding future features, it also disables movement when a direction is pressed, and then activates a group of events that currently merely tells it to enable movement. It's in this frame I will be adding in other important stuff, such as combat detection and enemy movement (if enemies move. Some enemies move I guess? The others will most likely be standing in front of doors trying to look intimidating.). I could definitely have programmed it in a way that used up less events (by, for example, adding lots and lots of OR statements to each direction), but I opted for a method that I could more easily go back and fix later should I mess up the tilesets.

FKT's movement script is long and boring. But hey, at least it's easy to debug.

So that's where I'm at; a 'game' in which a default diamond shape jankily moves around an incomplete dungeon. But it's the barebones of two systems solidly in place, and a point from which I can advance. Next step will probably be to add side rooms and dead ends to the dungeon, which should somewhat alleviate the severe boringness of the structure of dungeons. I suppose I will also have to work out how the dungeon itself is going to be revealed to the player sometime, as I suspect that one is going to be a major pain in the proverbial neck.

Speaking of which; I think there's time for a bit more VR before bed.

Summary: Weeks 2 & 3