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-...
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 ...
In my roguelike game Tyrant I used a system of action points and speed ratings.
Most actions had a AP cost of 100
Most creatures have a speed of 100
Then the game loop would go as follows.
Hero takes an action.
Elapsed time is calculated as hero action AP cost * 100 / hero speed
All creatures get given APs equal to creature speed * elapsed ...
There's nothing wrong with objects knowing about other objects. That doesn't defy encapsulation.
However, I don't think anything is gained by having CreatureInstance actually store a reference to it's LayerCell. That's a needless coupling of data. It should have a "location" type, and Atlas should have a FindCell function that takes this location type.
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 ...
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 ...
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 ...
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 ...
I suppose the answer depends on just what you think of as a "berserker".
The historical Berserkers were shock troops who focused their attention on engaging and slaying their opponents with little regard to anything else, including their own safety or that of others on their side. Different sources disagree on just how indiscriminate they were in their ...
He is pissed/aggressive. (Therefore, he needs a reason and a target to be pissed.)
When he's pissed, he gets more dangerous (Also, if he isn't pissed anymore, he's back to normal.)
Trigger - The reason he goes berserk
He gets insulted
He gets hurt (or more interestingly, he gets hurt a certain critical amount)
He gets ...
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 - ...
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.
This will really depend on your requirements. How many levels of height are there. Just a few? Hundreds?. Top down? First person? Limit of 1 character per tile or can you use several. What is the terminal size 80x23? or is it going to be resizable. On devices with limited CPU power like a graphic calculator or more beefy modern computers. Text in console ...
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 ...
(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.
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 ...
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.
ASCII games are really nothing more than just tile-based games that use character glyphs instead of pictures of what they really represent. In general, height fields do not work well in tile-based games. Not unless it's in some kind of perspective view. Height fields generally are used for 3D terrain.
When your palette of tiles is limited to whatever ...
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,...
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 ...
Action points. Give each entity a "speed" so that faster actors get more points each turn. Make each action take a specific number of points to complete, and subtract that number from the player's points for that turn when he takes an action. If an action takes more points than the player has left, mark it as "partially completed", and let him finish it ...
But why do the first two elements imply a permadeath approach?
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 ...
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
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 ...
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):
def __init__(self, name, description, activationFunction):
self.name = name
self.description = description
self.activationFunction = ...
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:
You can create a room that is in the shape of a regular convex polygon with arbitrary sides, size and rotation.
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 ...