46

From a pragmatic standpoint.. If someone isn't going to be playing your game over and over again, but instead is going to play through once from start to end using checkpoints or free saves (like in most non-roguelikes), then why would you spend your time on implementing procedural generation for your world, instead of just making a single, static, well-...


15

Permadeath gives character building and world exploring decisions weight. Permadeath makes it harder to abuse the random number generator (grinding). These things help stop a roguelike feeling flat. Procedural content is rarely aesthetically pleasing, so roguelikes rely on creating interesting mechanical space; typically through risk/reward dynamics. The ...


9

Based on the discussion in comments, I would say that the question you're asking is several steps removed from the question you should be asking at this stage of your project. The first and foremost question is, "What do I want my player experience of the dungeon to be like?" Do you want the player in near-constant combat, with a sense that they are never ...


8

The obvious solution is to send every player command to the server as it's made and have the server log them; that way, if the game is aborted for any reason, the logged commands can be replayed to restore the game to the point where it left off. Of course, when a proper save is made, the old command log can be thrown away (although you could also save it ...


8

It seems you include a square when you can see any point in it while the eye is at the single fixed point. However, you should only include a square when you can see the middle of it (assuming the "eye" is also in the middle). Or you can draw rays from each corner of the starting square to the corners of the tested square, if you can see any from any then ...


7

Perlin noise and friends are a good starting point but you probably want to take it a step further. Most of the popular noise-based generators will give you a fairly uninteresting results. In order to make terrain realistic, you want to take a look at the algorithms emulating erosion effects. One of the most advanced game-ish world simulators out there - ...


7

One of the major game-mechanical aspects of classic roguelikes such as Nethack is that you don't know what the potions, scrolls, and wands that you collect do until you try them (and sometimes not even then). There's therefore a big element of risk - is this potion poison or healing? Is this scroll Enchant Armor or Destroy Armor? Any "undo" or save-restore ...


7

As long as your movement space isn't Euclidean and things can block an entire grid space, you'll have this problem. If you want people to not "play the grid" you're probably going to have to not use a grid.


6

(I don't have enough reputation to comment) The answer here is that the distances are wrong. A is closer than B. To convince yourself, compare A and the reflection of B w.r.t. the player, so I don't think there is an issue here. Hex grids are tricky in a lot of ways.


6

Alright. There is a rather computationally inexpensive solution for this issue. First use Union Find to keep track of rooms that are not connected yet. Each square will now belong to some set with a unique index. When you create a circular room, merge all squares inside of it to the same set. When you create a room that overlaps with another room, unify ...


6

You have 3 major options: 1: Implement some kind of sorting or data structure. For example: Keep monsters in a list/array (Something you are probably already doing) and sort them by x and y. This would enable you to perform a binary search (Which has O(log n) performance) for locating a monster at a given tile. However, this introduces the need to sort ...


5

I like to think of "permadeath" as just part of the genre. For instance, could you make a first-person shooter with no guns? Sure! You could replace them with swords, etc. But would people see it as a FPS? Probably not. Roguelikes, by tradition (and arguably, by definition), include permadeath because that's the way the genre was defined.


5

But why do the first two elements imply a permadeath approach? They don't. You can have perfectly functional gameplay without permadeath, while still allowing ability-based character progression and procedurally-generated worlds. Terraria's a good example of this. What you've done is broken down the Roguealike "genre" too far. You've stripped out ...


5

I wouldn't do the turn-based gameplay in a separate loop. Instead, just have the one main game loop like any other game, and that loop checks if it's time to advance a turn yet.


5

Imagine dots are doors and lines are corridors. This is how you can have three doors connected: There is no reason why you can't link a door to more than one other door. You can have corridors merge at some point. But oldskool roguelikes didn't even do this; they simply connected random pairs of rooms with corridors, and if they happen to cross into a room,...


5

Traditional roguelikes solve the save-scumming problem by making the saving system completely automatic. The game auto-saves the player's progress whenever feasible. Especially after something went wrong (including a game over, which deletes the savegame). But the player can not create manual savegames. That means the player can quit the game whenever they ...


4

The way that Dwarf Fortress and many other similar 3D roguelikes handle huge world maps is to break the map into chunks. Typically these are vertical slices of world map that are easy to stream in-out on the fly. Which is how Minecraft and Dwarf Fortress in Adventure Mode work. In Fortress Mode, Dwarf Fortress allows you to select a block of chunks to play ...


4

The first roguelike game, the Rogue have such algoritm to connect the rooms: 1.Pick direction of corridor: vertical or horizontal based on room's relative position: x1, y1 - coords of first room w1, h1 - size of first room, etc. if(x1 + w1 < x2 || x2 + w2 < x1) then vertical if(y1 + h1 < y2 || y2 + h2 < y1) then horizontal if(both) then random ...


4

The idea is to have spell objects hold some reference to the in-code action you want that spell to do. Python's first-class functions make this quite nice (I'll assume Python 2.7.x): class Spell: def __init__(self, name, description, activationFunction): self.name = name self.description = description self.activationFunction = ...


4

Note: I'm playing fast and loose with the pseudocode here, so let me know if anything is unclear. Ideally, the player shouldn't be special - just another set of components. The main function of entities is to group components. You might think of it this way: components get updates, not entities. From the good old Evolve Your Hierarchy article: Updates ...


4

You can create a room that is in the shape of a regular convex polygon with arbitrary sides, size and rotation. Steps: Draw walls by picking pairs of points around a circle and linearly interpolating between them. The number of pairs should equal the number of sides of the shape. You will need to use trig for this. Create a floor by filling the shape using ...


4

The naive approach of just checking all adjacent squares for one of lower elevation, then moving there gets stuck very easily in small holes/valleys. That happens all the time in real life; they're called endorheic basins of which the Great Basin is an example. What you could do is simply form lakes when this happens, or ignore the rivers that don't end up ...


4

I would say that your own answer might be a good start. Still, I would do it a bit differently. So, here are a few suggestions/additions. 1) You could first determine the possible positions of doors in each room, then use those as joint points. You connect Room A to Room B by a given door of A to a given door of B and then test if the result meets your ...


4

I would make it little different, i would make a procedural path builder and then spawn floor tiles randomly all over the map, so the rooms will be more "natural created" and them will be linked at least for 1 tile, i can't code in java but i'll code the example in javascript, i think it's clear enough. var c = document.getElementsByTagName("canvas")[0];...


4

I'm going to drop this alternative into the mix. Its one that I really liked and used myself, with some changes. https://www.reddit.com/r/gamedev/comments/1dlwc4/procedural_dungeon_generation_algorithm_explained/ Roughly speaking the steps are: Generate a bunch of squares of various sizes, save them to an array (you probably want a class for these objects: ...


4

The trick behind these roguelike mechanics is that typically you don't store much at all. The shape/contents of each room are determined by an algorithm that's generally seeded with the position of the room, and possibly a unique key for each "new game" session. This algorithm, which can take many forms, is effectively a deterministic machine: put the same ...


3

If I understand your question correctly, your main concern is storing / accessing the generated tiles. Good news: you don't have to reserve the empty space for all the tiles that are not generated yet. There are many ways of storing 'irregularly shaped' data structures. For example, a possible solution is to build a list of pointers to the tiles you've ...


3

I think you have a few options: Use a path finding algorithm like A* to find the shortest paths between rooms. This would give you a quick algorithm, but the paths would all be optimal, so it might be boring. There are some tweaks you can do to add some randomness to the path finding and make the hallways a little less optimal and maybe more interesting. ...


Only top voted, non community-wiki answers of a minimum length are eligible