Week 6 - Dungeon Generator & new challenges

So I was going to hold off on a blog update for a week in the interest of having something new to show visually, but I figured I have a lot to write about for now regarding the dungeon generator. So have a visual of one of the older mockups before I decided to zoom the camera out:

A great deal of progress has been made on the fundamental generator of Infernum. Through a few evenings of idle coding there is now a dungeon-generator that supports the ability to draw rooms of varying rectangular sizes, give them floors, and then put walls around the room.

At the moment I don't generate a complicated grid or anything. At the moment I've been testing to ensure the making of rooms works in general, but I'm going to work on the ability for the player to have vision and move, which means moving on to work on the GameManager.


Through this next week or so I'm going onto a new challenge before returning to generating actual rooms and corridors all connected. In this case, that is player-vision.

There are a ton of ways to implement player vision, generally it seems to be direction-based. Through research it seems the original Rogue itself did a very non-intensive vision system: It lit the room up if you were in it, and in corridors it just strictly lit up the tile in front of you.

In this case I don't want to do direction-based, I'd like to push for a more uncommon approach via a full surrounding vision via light and lack thereof.

To this end, vision will be circular. This presents a new problem: Circles in square tiles.

Overall my focus for the next week will be to create a system to allow the player to see a circular area around them. At first there will be a minimum view of a simple 3x3 area around the player. From there, I want to experiment with going up to 5x5 as suddenly I have to deal with the idea that something might obstruct vision (Aka one of the tiles of vision are past a wall).

My current theory on this is that I can draw a circle after 3x3-size and then try to do pathfinding from the center to see if I can reach every tile in the circle. Also the size of the light source will now be based on the circular radius, not a square grid (So a size 3 would mean a radius of 3, meaning we can see 3 tiles away directly in each of the four primary directions, then I see if it's possible to create the circle roughly by trying to go to between them.


Hopefully next week, assuming this goes well, I will be able to show a basic running demo of the player moving around and having a light-based vision system with the lit and unlit tiles. After that I can return to try and expand on generating a proper dungeon.

Week 4 - Additional Research and Progress

This blogpost is a mid-week update on the progress split between a minor update on the dungeon-generator and more research-related talk that is more relevant to the module itself.


To start with, the generator has most of its systems in place now, with the proper infrastructure set up to ensure that tiles are usable objects with the most basic set of properties we need to use them efficiently, but most importantly is I managed to spend a couple of days writing and then rewriting asset loading functionality.

The generator now has the ability to instantiate a special AssetLoader script that is designed to handle my template for tilesets, and can also handle more custom tilesets like the door and ladders for now. With this support it has become very convenient to switch between lit and unlit tiles without having to write new code to poll the logic of when we should do that and what specific graphics etc, now tilesets can inherently flip their tiles from lit to unlit as needed through one method.


From a research perspective, building on the latest class presentations that ask us to think about the game in a more broken down perspective and analyze the particulars within each mechanic, I've been thinking about how to break down what can be considered a modest interpretation of the core roguelike experience:

The player approaches a small room with a ladder going down to the next floor. In front of it stands a goblin with a club and shield. The music has changed into a more combat-esque setting. Unsure of whether or not he'd win in a melee fight right now, the player backs away and goes to take out a bow instead of his sword.


 1) Input

The player typically uses the keyboard for input on a roguelike, not often the mouse. As such, we see input from the arrowkeys or WASD or other keyboard-format equivalents being used for directional controls. Every in-game 'turn', a new instant-effect / short-term command is given to the player's character.

2) UI

The player needs to have fluent and easily identifiable access to the user interface and all that it provides. To this end, buttons like Inventory, Options, and more rogue-like-specific options like examining need to be clearly allocated to a convenient location. It's likely that in a more modern setting like this prototype that they would be accessible via mouse, rather than overcomplicating a modern gaming scene with mandating keyboard controls for *everything*.
(Obviously some people like this, but a large argument of this prototype is the experiment of finding a balance between the good old and the bad old)

3) The Environment

The player cannot see the whole environment at any one time. They see only some area around them, which might depend on whether or not they have a light source. The player spots a critical threat to their current run of the game by being able to see it in time to formulate an appropriate reaction.

4) The Enemy

The enemy is as complex as the player in a roguelike game. They are bound by the same rough principles of logic within the gameworld. If something sets the player on fire, it generally sets the monsters on fire too (Unless they are specifically immune to it). The enemy will not spot the player any faster than the player can spot them unless it had to be intentionally given such an ability (night-vision, a great field of vision in the first place, etc)



For a final piece relating to recent module lectures, we have the idea of game progression, something that is very unique in a Roguelike game.

The progression of a rogue-like can both be the sole target and yet can be the utmost trivial accomplishment ever. Rogue-likes are traditionally very difficult, forcing you to move ever-onward in the hunt for resources and equipment. To die is to be expected, and to not die is rare. Perhaps then the true progress of the game is your overall accomplishments, not your ability (or lack thereof) to beat the final task the game hands to you.



That's all for this blog update, once there's a working prototype of the dungeon-generator, I'll be back.

Initial weeks of research

In the first 2 to 4 weeks, I've been doing research on Roguelikes.
One of the greatest resources during this time for me was Roguebasin, a website dedicated to information on playing and developing Roguelikes.

Firstly, a quick pixel-art mockup of the style I'm aiming for:

There is a rough definition to Roguelikes called the Berlin Interpretation.
The Berlin Interpretation was a large convention for Roguelike fans to determine what could officially constitute a Roguelike game. Some of the most important points are as follows:

• Random Generation of the Environment
• Permanent Death of characters
• Turn-Based gameplay
• Grid-based gameplay
• All gameplay must be in 1-mode (Trading, combat, general interactions, everything is on one-screen. No splitting it up)
• Complexity
• Resource Management (Health, Hunger, Thirst, Mana), and ensuring they are critical elements and not simply passive.
• Hack-n-Slash focus (Ensure killing monsters en-masse is a large focus no matter what)
• Exploration and Discovery.

One of the less-important but worth-mentioning elements is ASCII-graphics, though I intend to forego this particular element in favour of 16x16 pixel art tiles for everything.


I've begun looking into dungeon-generation algorithms also. Generally speaking the two popular approaches is either spawn-corridors and merge them into rooms, or spawn rooms and forcibly connect them as you go along with corridors. Some other options exist like just spawning a lot of rooms and then using a flood-fill algorithm to check if they are all accessible.
Personally, I believe I'm in favour of the approach of spawning rooms and then branching out with new corridors to form more of them. Though it may not be the most unique approach without severe customization, it sounds as if it will be the safest route in ensuring a playable demo at the end for now.

A feature I am keen to implement is the ability for tiles to be lit or unlit. Basically if they are close enough to the player (To imitate a lightsource and/or vision). Though I don't intend to do any complex logic for working out lighting around corners etc, the basic version of lit and unlit sprites is something I am keen to do. When experimenting with this, I realized I would have to manually load-in all the sprites I want to change between, to prevent stuttering that even a turn-based game could have problems with (As a result of constantly loading on-demand).


This led to a new issue, what is the best way to store these tilesets?

For now, my approach is to standardize my tilesets. There will be miscellaneous tilesets for unique sprites such as follows:

And then there will be standardized tilesets for any theme, like such:

The idea here is to have the lit and unlit variants of walls and floors combined. If I ensure every tileset for walls and floors are the same layout, I can standardize a loop to load these assets in, which means no massive mess of code for slowly loading it all in one-by-one.

From there, each tileset will get its own Class to tidy up where I can request the tiles.
The rough idea is as follows:

-Player Moves
-Game recalculates what tiles are lit and unlit
-It knows some tiles should be lit now, and some should be unlit now.
-It simply checks what tileset this tile used.

-Calls a method from that tileset class to flip between lit and unlit.

-Done!

Now that I've got a process down for how to implement graphics, I need to get the actual process put into a project and then I can begin experimenting with generation of primitive rooms and corridors!