As I promised here, I'll post the details of my monsters spawn/ move algorithm.
What this algorithm is useful for? Well, for example you want to provide constant challenge for player by adding or moving waves and waves of monsters on player's way or you just want to spice up a game play with occasional monsters spawn.
If you don't really care, you can just spawn monster where player doesn't see. It is easy and cheap way, but can lead to "OMG, this red dragon spawned right behind me in room I cleared! It isn't fare!" situation.
If you are okay with it, do it this way. It is no problem in most of roguelikes and still funny.
The problem comes when you have lot of pregenerated monsters or big map to travel, or you dislike "spawned behind" feelings.
So, you want monsters to spawn in front of player, not behind it. It is no problem, lets look.
@ - here is player or player character (PC).
PC can move in 8 directions.
1 2 3
4 @ 5
6 7 8
The easiest way to check direction, where player moved, and place monster in this direction.
For example, player moved to direction 5, so we can place monster to 3,5 and 8.
It looks simple, but it wouldn't work, because PC rarely moves in one direction for long time. PC maneuvering, fighting or exploring.
It woun't be really helpful to save last 10, 30, 100, 90890809 PC moves. Because, it can be messed up, after combat or labyrinth.
What to do? We would use weight based algorithm.
First of all, we will make an array of PC moves for 1 to 8 or Up_Left to Down_Right, if you like it this way.
Then, every time PC makes turn, we decrease all array variables by 1 and when PC moves we add 2 to direction it goes and 1 to close direction.
For example, if PC moved to direction 4. We place 2 points to 4 and 1 point to 1 and 6. (You can extand algorithm and place 3 points to move direction, 2 to closest, and 1 to close to closest. It is up to you.).
Then, when you want to spawn monster you just select direction, where monster appears by using weight based selection (the bigger value of variable the bigger chance it has) from directions, that has value bigger then 0.
It isn't ideal, but simple and would guarantee rather sane monster placement.
Procedurally generated roguelike rpg set in the underground world waking up after a major catastrophe.
It's really interesting, I really want to play your game ! :)
ReplyDeleteOh my, my! Thank you for kind words, first of all.
DeleteSpeaking about functioning game.
Well, I understand, that people who read my blog could get an allergy on worlds "we would have something now", but frankly I want to tell it again.
It is rather different game now, with different concept and developing doctrine.
I'll fill About Fallen page today or tomorrow and show, why do I think so.
It's probably healthier to count the number of turns since the player last looked at a cell. (This is easy to do, and inexpensive -- just mark "last turn seen" whenever the cell is onscreen.) When you want to spawn, you can bias towards cells the player hasn't looked at in a long, long time. It eliminates the feeling of being cheated but it also prevents cheesy tactics like walking towards a corner to encourage monsters to spawn there.
ReplyDeleteSounds like good idea, if we have small dungeons.
DeleteFor example, if we have 100x100 cell per dungeon simultaneously in memory it sounds like a good option. I think, that we can do even simpler algorithm.
The problem is that I make big open world in Fallen, beyond 2000x2000.
It isn't huge and doesn't copy true world. I don't think that rougelike game (or any other game) really needs this, but it is big. That's true.
Big world that stays in computer memory is really nice and open great possibilities, but also opens lot of questions, that wasn't really expected.
Like monster spawn, direction check, exploration etc.
It needs rather new and fresh point of view on roguelike gameplay.