Realtime Roguelike

[purestrain]

Hello,

I'm currently (several month now) thinking about a realtime roguelike. I can't get enough pro/cons to make a final decision. And almost every week i'm again thinking about it.

Would a realtime roguelike be 'roguesih'?

What mechanics should be used? Mainly turn-based (commands take time, time progess is continous, e.g. 1round/100ms) or almost realtime with non tilebased movement?

Would it be fun? I really like the tense of realtime games but its also hectic and non relaxing.

Should it be chosable? (e.g. player can choose a mode which stops the game logic after the players action is over, or just keep it continous running).

How about multiplayer? I thought about a 30 minutes roguelike which _could_ be played in multiplayer, but only cooperative as a party.

What about controls? Realtime would force the players to use a mouse.

What about the target audience? Roguelike scene is very small, it would even be more smaller if it is a realtime rogue....

thoughts about thoughts, and i never come to a good conclusion.

[Rabiat]

There are some realtime roguelikes around. Recently, I've seen Chronicles of Doryen and Doryen Arena. Dwarf Fortress is realtime in fortress mode, I've never played adventure mode though. There's also an older 'stepwise realtime' roguelike, written in VB6; I think it was called QRogue, but I'm not sure.

Personally I don't think that a roguelike should be turn-based per se. I do prefer turn-based, because it allows me to think about my next move. A realtime roguelike would have to have simpler controls and gameplay than a turn-based roguelike. Inventory management or spellcasting would have to allow quick access, or should be dropped altogether. I don't see why a real-time game would force players to use a mouse, though; using a keyboard is usually quicker.

Offering players a choice between realtime and turn-based is a nice thing to do, but I think it would be very hard to make a game that is both playable in realtime and challenging in turn-based mode. You might consider a trade-off; the game runs in realtime while you're safe, and switches to turn-based as soon as a NPC is in sight.

A multiplayer roguelike would be downright awesome. As far as I'm concerned, this would be the one justification for creating a realtime roguelike. It would have to offer competitive gameplay besides coop though.

Finally, if at all you care about the size of your target audience, go with the realtime idea, and drop roguelikes altogether.

[Gamer_2k4]

You should check out MAngband (multiplayer Angband).  It's realtime by necessity, as a turn-based online game wouldn't be very exciting.  As for your questions:

Mechanics - It's true realtime with tile-based movement.  There's an auto-retaliate feature that prevents you from getting killed if you aren't paying attention, and several extra windows are up that display visible monsters, inventory, and so on.

Fun - I'd say it's fun.

Choosable - MAngband is not choosable; it really couldn't be.

Multiplayer - We've already established that it is. =P

Controls - Keyboard only, no mouse required (IIRC).

Audience - Angband fans, I guess.

[purestrain]

Controls:
So how would you aim to a specific tile with keyboard controls under realtime conditions? Or do a "look" command? Cycling with Tab?

Size of target audience:
Don't most programmers like if at least some small people play their game?

Tilebased movement within a realtime game:
How can the movement be done? If i do a step forward, it takes some time.
3 choices come into my mind:
- First move to other tile, update FOV and wait for action to be finished
- Wait for action to be finished; Move to other tile (if its not used by another creature then) and update FOV
- Do a mix; Take e.g. 50% pre-delay, move to to other tile (update fov) and do another 50% delay

I can't remember diablo1 right now: It had tilebased movement, right? Just with animations between movement from one tile to the next?

[stu]

Cracks and Crevices is a semi-realtime roguelike. Difficulty level determines how 'real' time it is. Hard mode gives the game a delay of .5 seconds per round (that is you get 1.5 seconds to make a turn before you loose your go), on easy mode you get 3 seconds grace.

The benefit of doing real timing in game is you can really see the 'speed' attribute at work, faster monsters get more turns per 'round' than slower ones, slower ones may not get a turn that round etc. spells have better duration.

The way I do it, every monster accumulates a set amount of points per turn to use, default for an unencumbered human is 1000 points. It costs 1000 points to do anything (move,attack), etc. heavy armour/weapons lowers the amount of points you get (so a heavy paladin guy might only get 700 points a round)..

a round consists of everyone with >= 1000 points making their first action. it then continues with everyone still having >= 1000 points making their second action etc. Anything less than 1000 is added to the next round, so you may accrue an extra move over several rounds.

a character with haste may get 3000 points per round so gets three actions per 'round'.

I don't charge different costs for moving diagonally verses not.

Some commands don't cost of course (quit,save, inventory).

aming, I have a target function that will cycle to any monster in your FOV. Manual targetting is obviously slower.

[Z]

Diablo is a realtime roguelike, isn't it? And it is popular.

I don't know why realtime forces to use mouse. For choosing items from inventory? This can be done quickly with keyboard, by assigning keys to items (like e.g. Crawl does). For targetting? Probably yes if one can target at any direction (although it would be also possible to call possible targets with letters), but not for 8-directional targetting, which would be an interesting option for a realtime roguelike.

[purestrain]

Well; My first thought was (for targeting at any tile) to devide the playfield into 3x3 (for the direction keys), after the player chosed the first square, its again divided into 3x3 - So you could possibly aim at any tile within 27x27 square range within 3 keystrokes.

Will have to test if it is usable.

[Z]

An interesting idea, although you have to count one extra keypress to accept (so if you are targetting in one of the main directions, you'll need to press two keys).

[getter77]

The other option is to try a Roguelike along the lines of Dicin' Knight---the likes of which seem to be incredibly obscured and forgotten.

[Brigand]

I think it's a good idea, and have been toying with this a while. My roguelike is fairly simple to play (being designed so that 1 key press = 1 action - I HATE Angbands 5+ keypresses to cast and target a spell, even with macro support), and uses autotargetting, so just adding a timer to continously run the main loop seems to actually work. However, there are 2 (non-programming) gameplay issues that come up that probably need to be addressed in a non-3D (quasi/isometric/whatever) roguelike you make in real time. Well, really the problem has to do with the roguelike convention that you use a grid. Maybe someone has some thoughts on a possible workaround??


If you try real-time in a 2-D/grid-based rogue (meaning the granularity is lousy - there's no 'partially' between locations), the main problem seems to be player input. If you allow the player to act every time they press a key, their keypresses may be much faster than the monsters act/main-loop processes (unless your main loop is really fast, in which case the player gets massacred) - in essence, the player gets lots of free turns compared to the monsters, or vice versa. Conversely, you can have the players LAST input get acted on each game cycle, which in it's self leads to 2 problems -1) Multiple keypresses between turns get ignored, leading to unresponsive controls, or if you're fast, the ability to correct your key presses before the next main loop cycle, or 2) If you process the entire keypress buffer, you get long periods of real time where the character has to 'act-out' everything that was pressed, leading to the inability to react in real-time.

I must admit, I have't found a satisfactory way to deal with this issue. The best I can come up with is to put it as fast as I can, and try and 'tune' the monster speeds so that they are similar to the players.

Any thoughts on how you could make it work simply from a timing/input perspective??

[Skeletor]

Hello,

I'm currently (several month now) thinking about a realtime roguelike. I can't get enough pro/cons to make a final decision. And almost every week i'm again thinking about it.

Me too, good thread!

Would a realtime roguelike be 'roguesih'?

Why not.. Spleunky is 78% roguelike and it's even a platform game.

What mechanics should be used? Mainly turn-based (commands take time, time progess is continous, e.g. 1round/100ms) or almost realtime with non tilebased movement?

100% realtime. But the game can be paused with a key; in critical situations, this gives the player all time he wants to decide what to do.

Would it be fun? I really like the tense of realtime games but its also hectic and non relaxing.

I agree, turn based is more relaxing and tactical, but the "pause" command can help with this. Another thing that could help would be the implementation of some sort of "slow time" scrolls that make game time go slower for a short lapse so in critical situation the player may have more time to decide what to do.

Should it be chosable? (e.g. player can choose a mode which stops the game logic after the players action is over, or just keep it continous running).

I personally don't like something like that; I think the "pause" command works well.

What about controls? Realtime would force the players to use a mouse.

Take a look at Triangle Wizard. WASD + mouse works pretty well.

What about the target audience? Roguelike scene is very small, it would even be more smaller if it is a realtime rogue....

I don't agree. What keeps people away from roguelikes is usually the huge list of commands they need to learn to play.. real time action is definitely more appealing at first.

[Numeron]

Would a realtime roguelike be 'roguesih'?

Dont let this concern you. If you want to make a game, you shouldt feel you have to conform to any standard but your own

[Vanguard]

They've been mentioned before, but I'd say that the best places examples there are of realtime roguelikes are Diablo and Spelunky.

I think that if you wanted to make a more traditional, top down style game, a great approach would be to adopt the gameplay from Link's Awakening/A Link to the Past, and then add randomization and other roguelike features.

[getter77]

I think that if you wanted to make a more traditional, top down style game, a great approach would be to adopt the gameplay from Link's Awakening/A Link to the Past, and then add randomization and other roguelike features.

AKA Dicin' Knight!     http://www.romhacking.net/trans/1073/

[Confuto]

If you try real-time in a 2-D/grid-based rogue (meaning the granularity is lousy - there's no 'partially' between locations), the main problem seems to be player input. If you allow the player to act every time they press a key, their keypresses may be much faster than the monsters act/main-loop processes (unless your main loop is really fast, in which case the player gets massacred) - in essence, the player gets lots of free turns compared to the monsters, or vice versa. Conversely, you can have the players LAST input get acted on each game cycle, which in it's self leads to 2 problems -1) Multiple keypresses between turns get ignored, leading to unresponsive controls, or if you're fast, the ability to correct your key presses before the next main loop cycle, or 2) If you process the entire keypress buffer, you get long periods of real time where the character has to 'act-out' everything that was pressed, leading to the inability to react in real-time.

I must admit, I have't found a satisfactory way to deal with this issue. The best I can come up with is to put it as fast as I can, and try and 'tune' the monster speeds so that they are similar to the players.

Any thoughts on how you could make it work simply from a timing/input perspective??

One solution to this problem is to have certain actions take time. Give each character an activity variable. When they try to perform an action (moving, attacking, etc) check to see if their activity variable is greater than zero. If it is, they cannot perform the action. When they do perform the action, increment their activity variable by some number. Each time the game loops, decrement every character's activity variable by an appropriate amount.

One issue with this solution is that it plays similarly to some turn-based systems. It is, however, fairly similar to how most real-time RPGs do things simply without the animation.