Temple of The Roguelike Forums
Websites => Off-topic (Locked) => Topic started by: purestrain on June 16, 2008, 06:35:42 PM
-
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.
-
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. ;)
-
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.
-
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?
-
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.
-
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.
-
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.
-
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).
-
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.
-
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??
-
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.
-
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 :)
-
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.
-
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/
-
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.
-
AKA Dicin' Knight! ;) http://www.romhacking.net/trans/1073/
I gave that a try since you mentioned it.
I think it's fun at first, and as I thought, the concept has a lot of potential, but it lacks depth, and to me it got old kind of fast.
The levelling system is really unique and interesting. For those who haven't tried it - your experience points gained from dungeons are handled something like a high score in an arcade game, and only the highest score counts towards your exp total, so if you clear the first dungeon twice, getting 1000 exp the first time, and 500 exp the second, you get 1000 exp from the first dungeon added to your total, but maybe later you can come back after levelling up elsewhere and get it a bit higher.
Then, when you do level up, you don't get more powerful. What you get instead is another slot to put an orb in. You win orbs from a lottery system, and some give you more hp, some improve the item drop rate, and so forth.
Overall I think that again, the idea is full of potential, but I don't think Dicing Knight quite meets it, and once you figure it out, the fighting is someone shallow. There's some fun to be had with the game, but I wouldn't say it's good enough to be considered the roguelike equivalent to Link's Awakening.
-
Indeed. But it is the only experiment thus far after all these years. I so fondly wish for some sort of remake with more gusto for DS, PSP, PC, whatever.
There is an infinite dungeon though IIRC...
-
I don't know to what extent my real-time game will end up being a roguelike, but my solution is to divide the dungeon into screen-sized rooms. There can be only one monster in each room and the player automatically targets it. The player can choose to fire different kinds of projectiles at it or enter "fight mode", in which he and the monster, once adjacent to each other, will engage in hand-to-hand combat until one is either dead or moves away. So, when a player enters a room with a monster in it, the monster will run towards him and the player might press "fire magic arrow" a few times, then press "f" when the monster is near him to fight the weakened enemy hand-to-hand.
The tactical challenge in this game comes from the fact that ammunition and healing potions are relatively rare and not often found in the dungeon. Instead, the player has to undergo perilous travels to reach safe havens where he can restock. If a player is low on regular arrows, he has to decide whether to engage in hand-to-hand combat and use up healing elixers instead, or whether to use his magic arrows and risk not having any when he encounters a creature that is not harmed by the regular kind (there are in fact three kinds of projectiles - iron arrows, magic arrows, and phials of tana powder, all of which do different amounts of damage to different monsters.) Projectiles are also more accurate the closer the monster is to the player, so the player has the choice of shooting at the creature when it is far away, and potentially wasting arrows, or of only shooting at it when it gets close - then, he runs the risk of it getting too close and having to go into hand-to-hand combat. When he's running low on resources, he also has to decide whether to return to a known haven to restock, and then have to fight his way back (random monsters spawn at a rate dependent on the amount of treasure the player is carrying,) or to press on in the hopes of finding a haven or a chest of arrows soon.
I've considered two systems of targeting if I end up allowing more than one monster per room. If there are only ever two or three in a room, then the player could easily just press a "switch target" key. If there are more monsters than that, or if I ditch the room-per-screen system and have a scrolling map, I'll have to use the mouse. ncurses allows for using the mouse, but I don't think you can do that over SSH or telnet, which would be a bit of a disadvantage.
If anyone knows the old Apple II game "SuperQuest," you'll see how my game was influenced by it.
-
Why have noone made a real-time multiplayer roguelike, like the modern MMOs/semi-MMOs do? I've seen this solution be used on a recent console-RPG, though I can't remember the name atm. Consoles have always had abit of a challenge with multiplayer, especially "massive multiplayer".
Anyway, the way it was done in this game in particiluar, which sounded really awesome, was that the game was actually single-player..but other players appeared in your game as "ghosts".
I've always loved the thought of multiplayer-RL, and played abit ToME.net..but it was way too hard, and it felt cumbersome and impractical. (Turns or ticks pass by actual time, not moves) I still love the idea of a multiplayer-roguelike though, and think that this is the area of the RL-world where the most potential atm lies. Also, I don't understand the motivation of turning RLs into realtime unless we are talking about multiplayer.
My ideas for a mutliplayer roguelike would in reality more or less be a roguelike like any other, with afew additional features and the social aspect of it. (Like merging a forum with the actual game)
The game's mechanics would be turnbased. Other players would only be seen as "ghosts" - you can see them run past you etc. but their movement don't affect -your- game's timeline.
You could also initiate "duels" with other players, where you both would be thrown into a random pit, and combat would be turn-based. You could also chat, and write posts on (a) ingame board(s).
Some epic quests could be to go to a certain area or level and kill a bossmonster (unless a player was already there as a boss) and if you succeded, you would now be the "boss" of this level till another player comes along, and if you beat them, you'd get some nice ability or whatever.
The game could feature an ingame highscore list. Perhaps certain achievements could give you an "extra-life" or just keep it hardcore instadeath-style...ooor remove the instadeath aspect alltogether, I don't know :P
-
That has kinda been done actually, among others, there's Crossfire, Lost Labyrinth kinda and Deliantra---the latter 2 seemingly the most robustly developed but kinda hard to get a bead on really.
-
Also, I don't understand the motivation of turning RLs into realtime unless we are talking about multiplayer.
a much more thrilling experience. Maybe you've noticed that in the last 10 years most games (except boardgames, and some strategy franchise) turned realtime because cpu can handle the mechanics in realtime. ;D
"run and hide" would be much better in a realtime environment because i could watch smooth facing changes; currently i can only see discrete steps, no way to discover if the zombie is turning to you next step.
For roguelikes i would prefer a realtime environment with either a freeze-button or a mechanic to keep the game only running while i move. Anyway, both can be turned easily into a multiplayer roguelike.
-
Also, I don't understand the motivation of turning RLs into realtime unless we are talking about multiplayer.
a much more thrilling experience. Maybe you've noticed that in the last 10 years most games (except boardgames, and some strategy franchise) turned realtime because cpu can handle the mechanics in realtime. ;D
Well actually, that's the thing.. It's never a more thrilling experience, to me. The most thrilling experience I have, is in a tough battle in a turnbased RL, your HP so low that now it's too late for any "safe moves", now you just have to scan through your inventory and make the best out of the grim situation..begging that that bolt of lightning will take out the dragon, because it is most likely the last move you get in this battle!
All realtime RLs I've tried, have become a dull experience, because everything is always so simplified to make it possible to play. Diablo 2: leftmouse (attack), leftmouse, leftmouse, rightmouse (special), leftmouse, 1 (Heal!), 1, 1, 1, leftmouse, leftmouse, 1, 1, 1! Or as for "true" roguelikes: leftarrow, leftarrow, leftarrow, leftarrow, leftarrow..hp is low, flee! rightarrow, rightarrow, rightarro- :P
-
replace leftmouse with keypress (bump into monster), rightmouse with a keypress, and every belt-shortcut with 3 keystrokes to your inventory.
But comparing a highly known commercial game with a much broader audience, more success and a actually need to be successfull with games created by hobby-devs ist not that good. I believe blizzard could have put much more complexity in the game if they didn't wanted it be be bought.
-
That has kinda been done actually, among others, there's Crossfire, Lost Labyrinth kinda and Deliantra---the latter 2 seemingly the most robustly developed but kinda hard to get a bead on really.
And Daimonin, a Crossfire offspring. I think it's also in development.
-
That has kinda been done actually, among others, there's Crossfire, Lost Labyrinth kinda and Deliantra---the latter 2 seemingly the most robustly developed but kinda hard to get a bead on really.
And Daimonin, a Crossfire offspring. I think it's also in development.
It is but I never knew it also hailed from Crossfire same as Deliantra.
Omni: Give Scallywag: In the Lair of the Medusa a shot sometime on the Realtime RL front as it is surely closer in many respects to complexities than Diablo---not to mention it has some damn good unique features in it that really should be incorporated into more Roguelikes and ARPGS....
-
My ideas for a mutliplayer roguelike would in reality more or less be a roguelike like any other, with afew additional features and the social aspect of it. (Like merging a forum with the actual game)
A while ago I thought it would be an interesting experiment to take Rogue or some other roguelike and add some social features like these. Nethack and other roguelikes already have some inter-player interaction in the form of bones files, but there's a lot more interaction that could occur without fundamentally changing the typical turn-based roguelike gameplay style. For example, there could be a shop or auction house on certain levels where players can leave items to be bought or bid on by other players.
-
but there's a lot more interaction that could occur without fundamentally changing the typical turn-based roguelike gameplay style.
You can actually go a lot further than you suggest. Interhack is fully turn based and multiplayer. And no, one player does not have to wait for another player to move. Social interaction was added some time ago, so players can "talk" or "yell" to others on the level. It is not real-time, although it can feel like real-time with multiple players on the same level. However if you stop, go get a coffee and come back, you will find your '@' in fundamentally the same location, and with the same HP (there are a few very minor exceptions to this, such as a monster displacing you).