Temple of The Roguelike Forums
Development => Programming => Topic started by: mughinn on March 12, 2013, 03:10:31 AM
-
Since I've read Darren Grey's post about randomness in games, I've though a deterministic combat model.
Now, I haven't yet designed everything, but I have some kind of idea where it is going and before getting too deeply in it, I wanted to put it here and ask if it was just too complicated or too boring from a player perspective.
Here is more or less how I designed it.
For this to work, in my opinion, it's necessary to have a fine granularity turn system, by which i mean a binary heap or something like that.
Then, each action takes an X amount of time to get done, and an Y amount of time to be able to start another action.
Leaving the possibilities for vulnerability.
For example, say you are like this:
.....
.....
..@..
.....
.....
and you want to move up.
It's turn 350. You ended the rest from your last action. You press up to walk.
The character changes stances and is in the moving stance, swords attacks fail.
Turn 360. You walked and are now in the destination.
.....
..@..
.....
.....
.....
You now are resting from your last action and are vulnerable to any attack.
Turn 370. You end resting, and are now ready to start the next action.
This is a basic example, but it escalates from there, fighting would involve a lot of stance changing and maybe mixed attacks, like a quick stab or a powerful upward swing, to mix up timings.
Things like defensive and offensive stances could work or be included.
Stats can be added to make certain attacks be automatically dodged or defended against with armor or shield.
An arrow would have a direction and just hit anything in an occupied tile 100% of the time (unless it has a high enough dexterity?)
I personally like it, but i wanted opinions since it seems like something that could confuse and put away players.
Although i believe it could be played like a normal roguelike and give the feeling that it's random.
Now, i probably didn't explain it very good, so any question is well received and will be answered as soon as possible.
Thanks for any criticism.
-
I don't mind complexity as long as the controls are intuitive for it, which can be difficult when making a roguelike because in most cases, they have many keys that do different things.
Just because something is complex doesn't mean it has to be confusing. Whether the game is confusing or not is largely based on the execution!
-
What i meant by confusing or boring is that the optimal strategy to play, is to (if possible) having the information on turns and do calculations.
This could be liked by some people, i read somewhere that roguelikes usually give you the internal information so that players who want actually can do that, and that makes roguelikes roguelikes, but maybe this is going too far?
And besides that, if it is well executed, do you think it is a viable/interesting system or not?
-
The idea seems interesting, but beware that it doesn't turn into a system where the player needs a "machine brain" to be able to calculate his best strategy. If playing successfully means knowing internal speed stats of every single opponent and remembering their N last actions ("That goblin is vulnerable for 7 more time ticks, but if I hit it now, I'm gonna get bashed by the ogre, who is about to act in just 2 ticks.")
There are games like ADoM and Caves of Qud with convoluted time systems, where sometimes you'll get one extra action per ten turns against opponent X, and such. Noone keeps track of stuff like that, which is no problem in these games, where die rolls abound and hit points are cheap. I think a deterministic system needs to be crystal clear – although it can well be complex. If I were in your shoes, I'd probably aim to figure out a UI to communicate exactly what's going on, and make a system not based on complex math operations. (OTOH, games like chess or go rely on extremely complex board positions, without being about eg. calculating equations with twenty unknown factors.)
As always,
Minotauros
-
Since I've read Darren Grey's post about randomness in games, I've though a deterministic combat model.
Yay!
For this to work, in my opinion, it's necessary to have a fine granularity turn system, by which i mean a binary heap or something like that.
Boo, hiss :( If there's anything I hate more than over-reliance on random dice in combat, it's overly granular time systems! Both fall into the same trap of too many numbers floating around and too much to keep track of for real turn-by-turn tactics. Not to say it won't work, but I likely won't like it :P
I like the stance ideas. And the thought of certain actions being followed up by vulnerable turns. But this should be done within a rigid turn structure, with information displayed clearly to the player (a vulnerable enemy has a red background for instance). There should be a reliance on movement in combat, and thinking of turn by turn attacks. Attacks should have special effects, knockbacks, place-switching, etc.
Sil is quite nice for its speed system - there are only 4 speeds. The base speed is 2, and most monsters act at this most of the time, but some will have double or half speed. I've got a similar system in Rogue Rage. It means you can always roughly predict the next turn, who moves when, how many moves to reach an enemy, etc.
-
After playing around with the single hit-point model a bit I think the secret to making it work is interesting enemy behaviours. Which is something Darren has always mentioned when talking about it.
For example I have an enemy (a leaper) that when you're two cells away will bounce for a turn, then the turn after will leap to the cell you were at when it started bouncing. So it's quite easy to avoid a single leaper, when it starts bouncing you move away, it then lands on the cell you were just on and is an easy kill.
However if you have two or three leapers in the same room it becomes a lot more interesting. You can even get them to kill each other if you can engineer the situation; you get two leapers to bounce at the same time, then move away so one leaps and lands where you were the then other leaps in and kills the first.
I have a big list of behaviour ideas that I plan on trying out. If it helps you, here they are (very short an simple, not a lot of detail and some reference monsters in other roguelikes):
- Leave a trail of stuff.
- Have a cloud or bad stuff surround the monster, e.g. Brogue's Zombies.
- Attack all surrounding cells.
- Knight's move. Not sure how that would work in a graph based map though...
- Only able to move to cells with a distance of 2 from the current cell.
- Move two cells every other turn.
- Move very quickly when not in LoS.
- Obscure LoS.
- Reset Fog of War.
- Summon and run away.
- Summon and consume summons for some kind of bonus.
- Explode on death.
- Sap the player at a distance (not allow player movement) and run in for the kill.
- Become insubstantial and walk through the player.
- 'Haunt' the player and control movement.
- Impregnate the player with a parasite that will burst out later.
- Rotating laser beam, i.e. attack each surrounding cell in an order.
- Throw nearby enemies at the player.
- Kill other monsters to 'level up'.
- Multiply on hit, e.g. jellies or rats in MicRogue.
- Telegraph attack by bouncing then leap where player was next turn.
- Telegraph attack with crosshairs on the floor and attack next turn.
- Mimic player movement directly or oppositely.
- Buff nearby monsters, e.g. Brogue totems.
- 'Turtle' and become invulnerable to some or all attacks.
- 'Ignite' or otherwise transform the terrain the player is on.
- Steal items from the floor or the player, e.g. Brogue's monkies.
- Reanimate after death, maybe a few turns lag.
- After an attack become a fast moving but non-attacking form, e.g. Shiren's Master Hen.
- Teleport or blink the player.
- Pull the player closer to the monster.
- Push the player away from the monster.
- Swap positions with the player, e.g. Eyes in MicRogue.
- Try and surround the player with invulnerable monsters that only attack once fully surrounded.
- Mimics and shapeshifters.
- Combine like Power Rangers...
- Disperse 'seeds' like those mushroom things in Crawl.
- Be invisible unless very close.
- Temporarily reduce players view distance.
- Restrict player movement, e.g. can't move away from monster like DCSS's Sirens.
-
The leapers idea I really like - lots of tactical thinking involved. Lots of other nice ideas in there too!
-
Naughty, although single hit-point is very interesting, is not exactly what I'm talking about, although thanks for that list, since those behaviours can be implemented in any game and are all interesting.
Darren, I don't like high granularity systems a lot, but it seems for me that that's the way it should be for something like this to work, although something like Sil's system may work, it seems to me like there must be a big amount of turns so that there's more variety in the kinds of attacks and other things that can be put in.
Agingminotaur, that's exactly the reason i made the thread, it seems like it is too oriented on that kind of thing to make a viable strategy, it's not really complex math, but having three monsters with different speeds, and differents kind of attacks (like the quick stab or the big swing i mentioned in the post) could be something that is just too much for someone that ants the optimal strategy.
In the end, I'd love to end up with a system that could be inserted in, for example, Nethack, and not just a gimmick for a 7drl. Single hit-points are interesting, but don't work in big games like Nethack (again, for example).
Any suggestions to make it work better are also welcome, this can be another way of designing a roguelike and until i realize there's no solution to the problem of having to have a machine brain i will try to see if it can be done in a simple way.
EDIT: Giving it some though, would it be better if turns were divided like this?
Fast-decide dummy-turn dummy-turn dummy-turn dummy-turn
medium-decide dummy-turn dummy-turn dummy-turn dummy-turn
fast-decide dummy-turn dummy-turn dummy-turn dummy-turn
slow-decide dummy-turn dummy-turn dummy-turn dummy-turn
or something like that? i heard of someone dividing turns like that, where monsters can use a turn of a speed equal or below them. So i leave the deciding turns where monsters can take up an action, some dummy turns to let things unfold (pre-action and post-action stances) and another deciding turn.
Is this better or less math-oriented?
-
I think the "chess" idea is better than the complex time simulation idea.
How about this: the type of attack is determined by the player's and monster's positions on the board, and the attack type determines (deteriministically) the type and amount of damage.
For example: an attack on an adjacent tile (N,S,E,W) is a "stab". An attack immediately following a stab is a "shield bash". An attack on the diagonal (NE,NW,SE,SW) is a "slash", and an attack immediately following a slash is a "counter-slash". When an enemy's back is against the wall the player makes a "chop" or "bash". Extra damage is done from the wall hit. When the player's back is against the wall he pushes off the wall and makes a "lunge". Weapons differ in relation to these attacks (e.g. spears are better at stabbing, swords at slashing, axes at chopping) and so do monsters (e.g. large monsters are damaged more by stabbing, small ones by slashing, armored ones by bashing).
This would require tactical play, as players are thinking about where to move and which direction to attack from, with which weapon, given the enemy they face.
-
Although the idea is nice, i don't how i could extrapolate it to a big game, some things like wall attacks are possible, but i'd like to actually be able to stab, chop, shield bash, etc. wherever and however i want.
I'll have to think about it, the time simulation seems too random or weird for someone who doesn't know about the system and too spreadsheet-like to those who know.
-
Although the idea is nice, i don't how i could extrapolate it to a big game, some things like wall attacks are possible, but i'd like to actually be able to stab, chop, shield bash, etc. wherever and however i want.
I'll have to think about it, the time simulation seems too random or weird for someone who doesn't know about the system and too spreadsheet-like to those who know.
Well, the idea would still work if you let the player decide which attacks to use. If there's sufficient variety of tactics to choose from (and for enemies to choose from), you could still have it deterministic without the player catching on to whether there's one best weapon and one best attack in every situation.
In this case you might want monsters to behave differently in terms of carrying shields, dodging, parrying attacks, and so on. That way your players still need to adapt tactically to what the monster is doing, as the monster's moves will change its vulnerabilities.
-
When we dive into the world of states between ticks, much less into the world of ticks between turns, we are making it even more difficult to understand the repercussions of our decisions. With slick graphics (tweening and other tomfoolery)- it may be possible to communicate such ideas in an intuitive way, especially if there are few enemies at any given time.
If you lock your timing system into, say, powers of 2- so that an action with a speed of 1 and an action of speed 2 always differ by an amount measurable in terms of the other, then I think it works. You're always moving twice as fast or some other factor of power of 2 than some other entity, then it's really easy to grasp. As soon as you go lower than powers of 2, you will lose the player. If the unicorn takes 10 ticks to move a tile and you take 11 ticks to move a tile, after 10 ticks the unicorn will seem to move twice... this is fundamentally bad and arbitrary. If the unicorn moves twice as fast, however, you know that it's always taking two turns for your one- it's easy to visualize and rationalize. If you really want the unicorn to move asynchronously with powers of two, you can give the unicorn a special ability that increases it's speed by 1 for a turn- and that ability has some delay that fits into the timing system. The player, being aware of this ability, can then think about this asynchronous movement in a way that makes sense (kind of like blitting in Brogue).
Non-deterministic combat is a way to create the sensation of combat variety-- a nice lunge chopping away at their head may be a lucky hit that deals a lot of damage. Without graphics, I don't think it's meaningful to give the player control over these sort of things. You can vary it up with damage types, parrying, equipment modifiers- etc, make certain things pertinent in certain situations- but the philosophical advantage of going non-deterministic is moot unless the gameplay itself is interesting. Roguelikes really are about the map and positioning, in regards to combat-- you can achieve a Bushido-Blade-esque experience in this setting, but it won't be by emulating a fighting game. It will be by making your movements and equipment selection meaningful. You can capture ideas like a shield bash by being able to select primary weapons and have those result in positional differences of some sort, or stunning, or whatever- but the simulation of real-time combat in which the player occasionally makes decisions in a manner that isn't consistent is more frustrating than non-determinism.
I recommend checking out DROD (there are free versions). A 1-HP deterministic puzzle-roguelike. 'Combat' in DROD is a lot of fun and very intuitive. You might consider extrapolating from DROD-like rules to achieve what you want in a much simpler manner.
-
Darren, I don't like high granularity systems a lot, but it seems for me that that's the way it should be for something like this to work, although something like Sil's system may work, it seems to me like there must be a big amount of turns so that there's more variety in the kinds of attacks and other things that can be put in.
Then let there be a big amount of turns! But the real interesting stuff is when there are multiple enemies around and you have to consider all of their behaviours.
The 1HP stuff is good to consider ideas around, by the way. You may not think it is of relevance to a Nethack scale game, but it can really help with pushing your mind to think of new areas to attack beyond just standing still and trading attacks with an enemy.
-
The 1HP and Deterministic design choices have really helped me w/KlingonRL. It's not entirely 1HP, but in certain situations (from cloak) you always kill in one shot. It may end up being entirely one shot one kill, we'll see how it balances.
It forces you to make enemies more interesting. Fed Cruisers might just be bump and die fodder, but scouts can move diagonally and outmaneuver you (but not out run on a straight away). Starbases don't move, but can shoot your at range, so never approach uncloaked! Battleships can move AND fire at range.
Far more interesting than Move:1, HP:2, Dam:2, Range:3. Enemies are different by their behavior not just their stats.
-
I'll have to think about it a bit more then.
As I understand now, there are 3 viable choices.
What I originally though, with some differences like only allowing timing in powers of 2.
1HP with lots of tactical play an monster behaviour variety.
Chess-like play with attack variations.
I like them, I'm leaning towards a mix of the last 2, without 1HP, but I've to think about it a lot.
Of course the best way would be to get going and make some playable demos of everything i can think off.
I think i may have to remove the dust from my python skills and download libtcod (or if there's something else i could develop some quick demos i accept suggestions).
-
It can be very confusing when the player or enemies get 'out of sync', e.g. if the normal tick rate is 10 and you do a move that takes 5 ticks you can feel that you're out of sync from then on. It can happen in crawl sometimes and I've had it bite me on my own project. This can also be caused by using heaps as a priority queue, they are normally unstable in the sense that two actions that have the same tick counter can happen in either order.
I think it's best to restrict to whole multiples or simple fractions like 1/2, 1/3, 1/4 (so no 3/4 or 2/3). In mathematical terms either the numerator or denominator should be 1. In fact using fractions for ticks is something I surprised isn't really done, it's always integers which causes all kinds of problems if you want an action that takes exactly 1/3 of a usual tick. (I think Brogue uses 100 base ticks per turn and there's at least one action in the game that's supposed to take 1/3 of a turn but 1/3 of 100 is exactly representable. Not a major issue perhaps but it triggers my programmer OCD).
You could remove some of the out of sync issues by forcing actions to always take a whole number of 'big' ticks. So a stance could be modelled as a set of actions that always add up to whole number, e.g. defensive stance move is 1/2 tick movement then 1/2 tick defend (defend is a state that reduces damage say), fast stance is 1/2 tick move, 1/2 tick move (so you get two moves but you aren't defending so take more damage if hit), aggressive stance is 1/2 tick move and 1/2 tick 'prepare to counter' so you can hit back at enemies if they hit you but you take more damage than when defending.
-
There is a way to make it so that same tick moves always happen in the same order. If i remember right it's using the > comparison instead of >= (or the other one, depending on how you order the heap), that way, if 2 monsters are doing the same things, they always are doing it in the same order.
But of course i get what you're saying, and i think using multipliers of 2 can solve that.
Say the standard tick is 32, you get, 1/2 with 16, 1/4 with 8, 2 with 64 and 4 with 128. You don't get thirds, but i guess I can live with that.
There are things against the system, and that's the reason i posted it, i'm trying to get feedback before i go an implement everything and end up with something boring or confusing.
I'm in the process of trying to combine everything said here, I feel the heap method is very good, but i won't know until i code it, and I'm currently somewhat far away from there, So I'll have to wait until I do it.
-
You can fix the heap issue by using a user-defined < operator or function and having a 'tie-break' value, e.g. an incrementing id assigned to each actor. So if the ticks values are the same it uses the tie-break value to determine who goes first.
You can easily calculate a number of ticks per turn to use given the smallest fraction you want by using a factorial. So if you want to be able to use 1/2, 1/3, 1/4 and 1/5 you calculate 5! which is (1*2*3*4*5) = 120.
To be honest I'd guess that quarter turns would be enough so that's 1*2*3*4 = 24 ticks per turn.
-
I had a very granular system in my last project, and I found that the system broke down if the player could become very fast. Also, some players reported having difficulty telling how many turns they got relative to the enemies (I like a fairly gentle learning curve; to me it's more fun to come up with strategies than to figure out the information necessary to come up with strategies).
So for my current project, there are only 5 speeds:
Speed Cost Actions per 6 ticks
Very Fast 2 3
Fast 3 2
Normal 6 1
Slow 12 1/2
Very Slow 18 1/3
Every creature has an energy level; when they act, their speed is deducted from their energy level. This means that faster creatures are noticeably faster. A change in speed is a big deal; creatures will only have speeds from Slow to Normal, with buffs and debuffs making the extreme values possible. There will be a couple of different values, specifically Attack and Move have their own speeds. Some actions may receive a bump up or down a tier (such as (o)pen speed being Move + 1 tier).
-
Okay, thanks for the information, though, what do you mean by broke down? did the player have infinite turns because he had 0 tick moves?
The difficulty you speak of is my main concern with my system, it' be awesome if I could do the granular time without that confusion.
I was thinking something along the lines of your speed tiers, maybe I'll use something close to that.
-
You can fix the heap issue by using a user-defined < operator or function and having a 'tie-break' value, e.g. an incrementing id assigned to each actor. So if the ticks values are the same it uses the tie-break value to determine who goes first.
You can easily calculate a number of ticks per turn to use given the smallest fraction you want by using a factorial. So if you want to be able to use 1/2, 1/3, 1/4 and 1/5 you calculate 5! which is (1*2*3*4*5) = 120.
To be honest I'd guess that quarter turns would be enough so that's 1*2*3*4 = 24 ticks per turn.
That can create inconsistencies if the number of ticks used doesn't sum to 1 (or whatever your factorial is) at the end of each turn. That is, if you have something moving at 1/3 for 2/3 of the turn but then changes to some other movement factor, it goes out of sync. While this isn't necessarily undesirable, it can result in the 'extra turn' phenomenon relative to the player's experience. If you lock the user into a specific speed for the duration of a turn, that can be solved- but, imo, it's unpleasant unless you have a fatigue system or something of the sort that makes it clear that a player's last action in a turn is limited to, say, a move or something- but this really gets into certain degrees of incoherence- the currency of fatigue, ticks, and turns only obfuscates the experience. There's also the issue of a monster having different attack rates and movement rates, or different abilities functioning on different timescales- you can't ensure that they resolve in a consistent way.
-
You can fix the heap issue by using a user-defined < operator or function and having a 'tie-break' value, e.g. an incrementing id assigned to each actor. So if the ticks values are the same it uses the tie-break value to determine who goes first.
You can easily calculate a number of ticks per turn to use given the smallest fraction you want by using a factorial. So if you want to be able to use 1/2, 1/3, 1/4 and 1/5 you calculate 5! which is (1*2*3*4*5) = 120.
To be honest I'd guess that quarter turns would be enough so that's 1*2*3*4 = 24 ticks per turn.
Don't use the factorial. Use the lowest common multiple. In complex cases the factorial can be a lot bigger than the least common multiple. For instance if your speeds went from 1 to 8 (which is not uncommon) the factorial would be 8 * 7 * 6 * 5 * 4 * 3 * 2 * 1 = 40320, and the least common multiple would be 8 * 7 * 3 * 5 * 1 * 1 * 1 * 1 = 840. The LCM can be computed pretty easily using the Euclidean algorihm.
-
Okay, thanks for the information, though, what do you mean by broke down? did the player have infinite turns because he had 0 tick moves?
The difficulty you speak of is my main concern with my system, it' be awesome if I could do the granular time without that confusion.
I was thinking something along the lines of your speed tiers, maybe I'll use something close to that.
A standard turn was 20 ticks; the fastest speed allowed was 2 ticks. If the player was making 10 attacks for each one the enemies made, those enemies were no longer challenging. You had to find some fairly rare gear to do it, but once you had it set up, victory was easy.
How much faster the player can be than the enemies without upsetting game balance would depend on a lot of factors, like the size of enemy groups, how hard they hit, etc.
My thought process at the moment is, "how much normal variation do I want, and how far are the extreme cases?" For the system I described above, the usual limits would be the fast guy getting four moves to the slow guy's one. The extreme limits (player uses consumable resources to make an already fast character faster, and more consumable resources to make an already slow character slower) make the ratio 9:1.
The differences are big enough that it's easy to tell who's faster, and by how much, at a glance, but not so large that being slow is crippling.
-
Okay, thanks for the information, though, what do you mean by broke down? did the player have infinite turns because he had 0 tick moves?
The difficulty you speak of is my main concern with my system, it' be awesome if I could do the granular time without that confusion.
I was thinking something along the lines of your speed tiers, maybe I'll use something close to that.
A standard turn was 20 ticks; the fastest speed allowed was 2 ticks. If the player was making 10 attacks for each one the enemies made, those enemies were no longer challenging. You had to find some fairly rare gear to do it, but once you had it set up, victory was easy.
How much faster the player can be than the enemies without upsetting game balance would depend on a lot of factors, like the size of enemy groups, how hard they hit, etc.
My thought process at the moment is, "how much normal variation do I want, and how far are the extreme cases?" For the system I described above, the usual limits would be the fast guy getting four moves to the slow guy's one. The extreme limits (player uses consumable resources to make an already fast character faster, and more consumable resources to make an already slow character slower) make the ratio 9:1.
The differences are big enough that it's easy to tell who's faster, and by how much, at a glance, but not so large that being slow is crippling.
My KleinRL had a similar problem. Speed stats ranged from 1 to 100, but the game mechanics reduced that to a constant number of ticks per move. The result was a big jump in actual speed from 24 to 25, from 33 to 34, from 49 to 50, and from 99 to 100 (the latter was almost impossible to achieve in game).
It's a good idea to have diminishing returns for stacking speed bonuses. The biggest boost to speed (x1.5 or x2, for instance) should be the first bonus the player takes, not the last.
-
Oh, I get it.
But of course, that's what balancing is for, I'll have to make sure speed differences are not making the too easy or impossible.
That can create inconsistencies if the number of ticks used doesn't sum to 1 (or whatever your factorial is) at the end of each turn. That is, if you have something moving at 1/3 for 2/3 of the turn but then changes to some other movement factor, it goes out of sync. While this isn't necessarily undesirable, it can result in the 'extra turn' phenomenon relative to the player's experience. If you lock the user into a specific speed for the duration of a turn, that can be solved- but, imo, it's unpleasant unless you have a fatigue system or something of the sort that makes it clear that a player's last action in a turn is limited to, say, a move or something- but this really gets into certain degrees of incoherence- the currency of fatigue, ticks, and turns only obfuscates the experience. There's also the issue of a monster having different attack rates and movement rates, or different abilities functioning on different timescales- you can't ensure that they resolve in a consistent way.
I don't think having an out of sync monster would be noticed, the player would notice it if suddenly the monster changed speeds. But if the monster start the turn at tick 360 and you start at 365, and both just move (let's say 16 ticks per movement) then they'll have the same number of turns in X ticks.