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!