Temple of The Roguelike Forums
Development => Programming => Topic started by: Alex E on July 24, 2012, 10:05:24 AM
-
I don't think I've ever even seen a multiplayer roguelike. And I don't think I'll see one that connects people online anytime soon.
But if a multiplayer roguelike was made, how would the multiplayer work?
I thought about this, and I just can't figure it out. It could be turn based, but then whenever someone moves their character they can't move until the other player does. So if you're trying to move around it would just be awful. I can imagine a lot of waiting. If not turn based, then real time will work, right? Well, everything is in tiles, so you would have to line up your moves just right to get anything done. Controls would have to be simplified, to allow fast commands in the middle of a fight, possibly with other players.
What's everyone elses opinion on multiplayer in roguelikes? Is it even possible to get multiplayer to "work" well with them?
-
Here are two that I have played some time ago:
http://www.daimonin.org/
http://euotopia.com/
The problem as I see it is the one you mentioned, wherein getting the right turn length is impossible. There are always going to be people that can't keep up and people that find it unbearably slow.
I think that any way you create a pressure to act immediately makes the game not a roguelike. I can see things working on the small scale, where maybe you have a few people working together. You also need to make it so the player can decide their action ahead of time in certain cases, for instance clicking on the map and pathing there as their turn approaches. This can make the wait lessened.
Before I continue though, I strongly suggest you use the search bar on this forum because this topic has already been fairly discussed recently :)
Edit: There appear to be some topics in the search but I cannot find the one I'm thinking of. This leads me to believe that perhaps that discussion was on irc.
-
Twilight (not the sparkly vampires) was a MMO roguelike that worked fairly well, though it had a large, preset overworld that got a bit tiresome after a while. It used real-time and had a very streamlined interface.
One solution that comes to mind is turn-based but asynchronous - so you can go up to say 10 turns ahead of or behind another player in your party. It would have issues with people doing actions together they didn't intend (accidentally bolting friends, etc) which would be especially bad with lag, but it would solve the whole moving around slowly problem.
-
I've played MAngband with a pal not too long ago, and there's also TomeNET.
S'alright. Basically MAngband works by advancing the game 1 turn ahead every second (maybe a bit less than a second? I never timed it) and having you auto-attack things you're next to. Things get a bit more complicated depending on your character's speed stat, and I'm not TOO familiar with the real mechanics so I won't go too deeply into it.
It all works decently untill you start getting into mortal danger. The game just goes glacial on your ass.
The goal is to give you time to save yourself by making every ingame turn take... 20 seconds or so to advance, but what you really get is this disorienting disconnect between inputs and actions that will drive you absolutely batshit in record time.
As for ranged weaponry, healing-in-a-pinch, and spellcasting, the player just sets up macros.
I'm preeeeetty sure regular ole singleplayer 'bands let you do this too, but I never use it there.
As for multiplayer, it's a lifesaver. Binding all the keypresses for casting that Cure Serious Wounds into a single key is mandatory.
In the end it works pretty well except when someone's near death, but I'm not too big a fan of the 'band playstyle (too grindy). I think it would be a LOT more fun when applied to Rogue/Hack or anything without a "safe place" to return to. (Though that would make it less MMO-y)
Didn't spend too much time with TomeNET, but I read that one slows the realtime turn advancing depending on how deep you are; ie. turns advance slower the deeper you go to compensate for increased lethality of enemies.
Kraflab has a point though. The game being realtime kills the roguelike feel.
-
S'alright. Basically MAngband works by advancing the game 1 turn ahead every second (maybe a bit less than a second?
Annoying, pressured combat doesn't sound very enjoyable. I suppose that if you want more than a few people playing, then it needs to be real-time. Waiting for 8 other people to take their turn would be more of a waste of time than fun. I agree with you and kraflab, real-time makes it not feel like a roguelike.
Before I continue though, I strongly suggest you use the search bar on this forum because this topic has already been fairly discussed recently :)
I actually did do some searching, but I didn't find anything!
One solution that comes to mind is turn-based but asynchronous - so you can go up to say 10 turns ahead of or behind another player in your party. It would have issues with people doing actions together they didn't intend (accidentally bolting friends, etc) which would be especially bad with lag, but it would solve the whole moving around slowly problem.
Moving more than once per turn could work. It seems that the player who gets somewhere first would have the major advantage though. Especially if there was any type of PVP. If one player got to another first, stabbed them 8 times, then the other player wouldn't be able to even react. Well, certain moves could take up more of the turn. For example, attacking will end your turn instantly. Moving will use up a fifth of your turn. So on and so on.
-
Gambits!
When we think about how we play roguelikes, we more or less honor a specific play-style pending upon how our little dude has been built, developed or what equipment we have or whatever.
Most of the decisions that a player makes involve how they're equipped, how they're leveled, and in which situations are consumables used or what equipment changed out or which spell is cast.
With that in mind-- you can incorporate a simple logical language into the game where people describe the basic behaviors of their character.
"If Enemies in a hunting state targeting player > 4, move to closest previously visited tile with 2 adjacent empty tiles."
Basically, run to a hallway if you run into a pack of enemies.
It can get supremely complicated, but if players basically script their own AIs, you can just allow players to pause game progression whenever a genuinely difficult decision needs to be made.
I mean-- when Playing brogue, you only need to break autoplay a few times to get to D11.
-
Personally, when I think "multiplayer roguelike" I don't think of an MMO. (Probably because I hate MMOs.)
My first thought is multiplayer like Civalization. It's turn-based. While each unit has few choices, each player controls a lot of units at the end.
So: a small group of friends play together.
Now consider: there is no actual requirement to keep the turns in sync across all players except when they're within line-of-sight. If I can't see you the difference of you going one turn or 10 to my one turn is meaningless.
So, when players are within line-of-sight, they need to wait for the other players to finish their turns. Talking to each other is still a free action, of course.
Next, more squelching of boring things.
If the group is moving as a unit, one player is given control and everybody moves as a single unit until enemies are encountered. This is simply squelching manual follow commands.
If a player is on auto-explore, their next command is handled automatically by the system so there is zero delay. If every one in the party is on auto-explore together, they should fan out, explore the map, then converge on the first monster found. (Given that talking is free and the first thing a person in their party would do is say, "Hey, there's something I need help with over here!")
So, yeah... the only time you should be waiting for other players is when you're near each other and monsters are around -- or you're near each other and playing non-cooperatively.
Then again, I see multiplayer as an extension of single-player multiple-character. We see those sorts of games in RPGs all the time, but they're rare with roguelikes.
Cheers,
Steven Black
-
There's a problem with async turns regardless of line-of-sight -- it ruins causality, which is a major component of any multiplayer game.
Take Player A and Player B, not in LOS.
Player A hits the Enemy on turn 1. Enemy flees.
Player B runs into the Enemy on turn 2. He throws a potion at Enemy, which happens to be a potion of gigantism. It lasts 10 turns. Player B and Enemy pillar dance for 8 turns.
In the meantime, Player A gets a cup of coffee, comes back and takes turn 2.
Player B hits the Enemy and it flees back to Player A on turn 11. According to B, Enemy has gigantism for 1 more turn. According to A, it's turn 3.
Now what?
-
Player A hits the Enemy on turn 1. Enemy flees.
Player B runs into the Enemy on turn 2. He throws a potion at Enemy, which happens to be a potion of gigantism. It lasts 10 turns. Player B and Enemy pillar dance for 8 turns.
In the meantime, Player A gets a cup of coffee, comes back and takes turn 2.
Player B hits the Enemy and it flees back to Player A on turn 11. According to B, Enemy has gigantism for 1 more turn. According to A, it's turn 3.
That's a good point. I'd say that having a queue based turn system would solve that, but there's still the problem of waiting for the other person. It would just be too slow.
I keep going back to the idea of "real-time". Everyone says that it kills the roguelike experience, but what if it was "sort of real-time"? Let's say that every few seconds the players' turns end, and the enemies get to move. During each players few seconds of each turn, they may move up to once, attack once, or eat some food once. It's still a turn, but it's faster. However, it's also pressured...
-
I keep going back to the idea of "real-time". Everyone says that it kills the roguelike experience, but what if it was "sort of real-time"? Like MAngband. Let's say that every few seconds the players' turns end, and the enemies get to move. Like MAngband. During each players few seconds of each turn, they may move up to once, attack once, or eat some food once. It's still a turn, but it's faster. However, it's also pressured...
I'd give MAngband a try, if I were you.
If you're shy of interacting with the playerbase (which is, like, 4 people.) it's easy as pie to set up your own server.
Once you've actually played it you'll appreciate how it works. I don't think any other system will work well for a multiplayer roguelike.
Which boils down to me saying that multiplayer roguelikes is a novel concept, but ultimately a fool's errand.
You NEED to be free to take all the time in the world and think about your options, especially in combat, because of permadeath.
If you take out permadeath it's not even a roguelike anymore, just boring.
-
I'd give MAngband a try, if I were you.
If you're shy of interacting with the playerbase (which is, like, 4 people.) it's easy as pie to set up your own server.
I'll give it a try.
-
I was thinking about this before. I wondered if it would be worth allowing players to see other player's screens during the other player's turn. That way if one player's turns are taking ages because they are having tough decisions then other players can at least spectate it. That might reduce some of the waiting for other players problem.
-
I think that maybe a multiplayer roguelike where the two players play asynchronously and interact somewhat non-directly could be nice.
As an analogy, there is a chess variant called Bughouse or siamese chess (http://en.wikipedia.org/wiki/Bughouse_chess) (that I have never played myself, just watched) for four persons (white-A+black-A VS white-B+black-B). White-A plays against black-B, and black-A plays against white-B. Each of these pairs play a normal Chess game, except that whenever a piece is captured, the partner can put it on their board. The two subgames are not synchronized, so the game is more realtime (and usually played with a small time limit to discourage waiting for new pieces indefinitely).
In roguelike terms (where, say, white become players, black become monsters): two players play separate games, but monsters killed by one player will appear in the other world. Or they can lay traps for the other player somehow. Something like that. Although you could take your time to perform complicated actions or to think out difficult battles, it would be important to have a good average speed. So that would be a bit of a race, but I think that's not bad (speedrunning roguelikes is another idea that should be explored, I only know Jacob's Matrix, but real time passed is actually a good measure to score winners in most roguelikes).
I was thinking about doing something like this for a 7DRL challenge or something, but I am not sure whether there would be enough interest (it is much easier to try out a single player game... or am I wrong?).
-
In terms of a 7drl, I would definitely try to get some friends to test things out with me. Some kind of organization thread could probably get some pairs together.
A similar idea I was thinking of was having each player set up a dungeon, i.e. control monster and item placement. There would naturally have to be some limits in place so you cannot just place infinite monsters. Perhaps the more loot you place in an area the more monsters you can place for instance. Then each player would try to defeat the other's dungeon.
Definitely I think competitive multiplayer has some options, although I still think cooperative multiplayer is a design challenge
-
Competitive asynchronous multiplayer would be awesome.
You could have a relatively short roguelike (such as TSL or Rogue) and give the player a choice upon ascending;
-upload your score and increase the difficulty of the game from now on for every player by 1 step
-50% chance to lower the difficulty of the game from now on for every player by 1 step, your score is not uploaded
So you'd have the balance between victorious players who want to tone down the brutal difficulty even if they become unsung heroes and the victorious players who want to crank that difficulty as high as possible so nobody ever steals their n1 spot on the leaderboards, even if it renders the game absolutely unplayable.
(Maybe with a ladder season so the difficulty can get reset.)
-
My current (possibly lifelong) project is a text-based multiplayer roguelike:
The ASCII Project
www.theasciiproject.com
It's 100% open source, and I commit code updates at least once a day. Currently I have asynchronous networking working with a client and server (after only 30 days of coding) which allow you to move around the map with other players, and this week I'm going to be putting in a database backend to handle the accounting/login/registration services. I envisage a text-based minecraft-esque game when I move the release up to 0.0.1, but I have very distant ai/scripting/networking/etc features I would like to put in once I get things stable and rolling.
I doubt anyone will ever actually play it, but I enjoy writing it, and I'd be happy if even one person ever logs in haha. I'm sure I'll get much criticism for attempting such a project, but suggestions are always welcome :-) I wouldn't mind having a programmer to help out to speed things along, but most requests for features and ideas make it into my scratchpad where I have a list a of goals branched out into their prerequisite functions.
I'm also trying to keep the API text-based, and I'll get around to sending out map updates optionally as plaintext or xml data feeds, so that people could potentially write their own clients (or web front-ends) based on the open API services. People can also download and run their own servers, but I doubt many people will choose that over just connecting to the main server I'm hosting.
The main reason I'm doing all of this is because I wanted a multiplayer dwarf fortress type game, but after years of waiting and searching for game with the kind of features I've always wanted, I just gave up and started writing one on my own. Now that I've made the jump from C to C++, Boost and the C++11 stdlib give me just enough features and flexibility to clearly sculpt code into my ideas and put them into practice fairly quickly. I spend probably 95% of my time coding or working on the project, and I can honestly say it's very satisfying knowing that for any feature I want to put it, I'm limited only by time and computing power.
-
Cool-- is it real-time? How are you handling it?
-
I doubt anyone will ever actually play it, but I enjoy writing it, and I'd be happy if even one person ever logs in haha. I'm sure I'll get much criticism for attempting such a project, but suggestions are always welcome :-)
It seems very interesting to me. I'll play it once I have some time.
-
Cool-- is it real-time? How are you handling it?
It is real-time, and I'm handling the limitation of player movement based on a "Stamina" system, where certain actions may require more stamina points to to use than others. Of course a skilled player may require less stamina to perform an action in their skill tree than a player who is skilled in something else.
For instance, if you want to be a woodcutter, your woodcutting skill is of course going to increase and you'll produce more from your cutting and you'll be able to do it faster.
Same thing with combat, if you are skilled at fighting with a certain weapon type, you're going to be faster and better at using it.
Which somewhat leads into the skill system I'm putting together. Where you can start off as a generic player with equally leveled skills across the board or you can choose a specialized class where your starting skills may be higher in certain areas than others.
The idea being that your player's only limitations in the world are what you spend time skilling them up for. It becomes harder to be a "jack of all trades" player, because higher levels in specific skill trees may take longer to level up. Also permadeath means that players are likely to specialize their characters for certain tasks rather than attempt to be great at all of them, and perhaps even have multiple characters on their account that are specialized for building, combat, diplomacy, trade, etc.
There will of course be implications of carrying heavy items, such that your movement costs more stamina to perform. The exact mechanics of how combat will work are still being worked out though, as I haven't gotten that far in my list of things to program :p Suggestions are welcome :D
It seems very interesting to me. I'll play it once I have some time.
Thanks! One of these days soon (likely this week) I'll put together a windows executable and a statically compiled binary for Linux / OSX up so that people don't have to compile it by hand :p
-
I've been playing the old boardgame Dungeon! (http://boardgamegeek.com/boardgame/1339/dungeon) a lot with my girlfriend recently and have been thinking that it could form the basis of a pretty good competitive multiplayer roguelike.
For those that haven't played it: as the name suggests, the game takes place in a dungeon which is divided up into six levels. The aim of the game is to 'descend' into the dungeon, grab a certain amount of loot and make it back to the entrance before anybody else. It even has its own form of procedural generation: although the map is set, each room in the dungeon contains a monster and a piece of treasure that is determined by a random card - these cards are split into several decks that are colour-coordinated with the different levels: so the level 1 deck has fairly weak monsters but also much naffer loot cards, while the level 6 deck has super-powerful monsters but also higher-value treasure. So, the game becomes a quite interesting risk-reward problem - do you stick around level one and beat up the weedy monsters, but gain treasure slowly, or do you take a risk and dive down to the richer but more dangerous levels, where you might reach your target amount of gold faster but stand a much higher risk of being squashed...
The 'advanced' game has a few more elements that mix things up a little - you can choose from several different classes with different strengths and weaknesses (Wizards are generally shit, but have a limited number of powerful elemental spells, rogues are weak, but quite good at stealing treasure from other players, Paladins are big beefy knights who kick ass and can heal themselves, but also have no choice but to follow their goody-goody code and spend a turn healing any other player that needs it... etc.) and you can find magic items as treasure that give you combat bonuses, let you open secret passages easier and so on which works quite well as a way of opening up alternative tactics.
I think this could all translate quite well into a roguelike. The main concession I think you would have to make to normal 'roguelikeness' is to make it a bit more board-gamey by letting the player do more per turn. In Dungeon! for example you can move (typically) 5 corridor tiles per turn, and each room counts as a single square all by itself. Maybe I'll have a go at doing something based of this for next year's 7DRL...
-
There's a problem with async turns regardless of line-of-sight -- it ruins causality, which is a major component of any multiplayer game.
Take Player A and Player B, not in LOS.
Player A hits the Enemy on turn 1. Enemy flees.
Player B runs into the Enemy on turn 2. He throws a potion at Enemy, which happens to be a potion of gigantism. It lasts 10 turns. Player B and Enemy pillar dance for 8 turns.
In the meantime, Player A gets a cup of coffee, comes back and takes turn 2.
Player B hits the Enemy and it flees back to Player A on turn 11. According to B, Enemy has gigantism for 1 more turn. According to A, it's turn 3.
Now what?
It only ruins causality if you assume that one turn for player 1 is the same amount of game-time as player 2.
I'm saying that implication is flawed. One turn for me is not the same as one turn for you. Turns != Time.
If I'm not in the room with the other player, they could be in the middle of a Rest 1000 cycle. My character could be in the middle of a Rest 1000 cycle. It shouldn't matter.
Of course, it couldn't just be line-of-sight of other players, it needs to be line-of-sight of players or monsters that can see said player.
What it does do is ruin the possibility of having any concept of "game time" so any mechanic which relies on such a concept should really opt for something else -- like having the concept of time be tied to average player level.
Anyone who thinks you can't do real small-scale turn-based multiplayer has clearly never played Civilization with human opponents. Get yourself a copy of Freeciv <http://sourceforge.net/projects/freeciv/> (Mac, Linux, Windows) find yourself some friends and give it a go. By default it's true turn-based and if someone goes for tea, you're stuck waiting. (Though current versions of FreeCiv support 126 concurrent players, that is clearly overkill.)
With Civilization each player makes decisions at the same time. If you finish your turns at the same time there is no waiting for the other player. This approach should work for a Roguelike.
However, it's better if you only need to do this with the line-of-sight limitation I originally mentioned. If I'm playing with someone and that person needs to rest for 200 turns to heal and restore mana, I don't want to be on my own for that time. It's better if I just leave the room and when they come out they're all rested. (Though this has so many repercussions that I think the "rest to recover" logic needs dropped.)
As far as NPCs -- both friend and foe -- there would be two types: those that are only awake when in line-of-sight of players, and those that are like the players and can mysteriously know where the player is at and suddenly be within line-of-sight.
Being turn-based (even the variant where players do not take turns) should give you very much the same feel as a traditional Roguelike.
Being line-of-sight+turn-based would be a different sort of game. It requires a different concept of time.
The thing is... it's testable within the confines of a 7DRL. Not even multiplayer, as a simple single-player game. It breaks the simple "player goes" / "computer goes" logic that frequently drives simple Roguelikes. Will it feel all that different, though?
More importantly, will it feel more or less like a Roguelike when compared with a real-time game?
Cheers,
Steven Black
-
The only reason why civ 'works' is because the turns are timed proportionately to the amount of actions any given player would take at that point in the game. As the game becomes more complex, more time is given for actions. For the most part, players will automate their tech trees according to a particular desired outcome. In a way, your strategy is pre-programmed, the game just gives you enough time to make tactical decisions or minor adjustments. As long as everyone is pretty decent, the game flows in a way that isn't entirely miserable.
Civ uses synchronous turn-taking (players all 'wind' their decisions at the same time and observe the outcome as the decisions 'unwind'). The game, however, is still synchronous in its concept of time. FreeCiv, as I recall, is synchronous, whether you're playing with synchronous turn-taking or not. It just describes whether you wait for other players to make their turns or whether you take turns at the same time.
I don't think this paradigm works very well for a traditionally fashioned roguelike. Every position and orientation of objects in the map is too important. You can't move objects synchronously and expect for it to make sense to the players. That said, with a smaller group of players you could use an action point system and have asynchronous turn-taking, that would work pretty well. Especially for co-op.
Space Alert! is a board-game that I think addresses this problem the best. Players are cooperatively presented with a problem that requires solving using a small set of action cards. Players play out a string of action cards under a time limit. If players didn't synchronize their actions properly, they won't survive. If somehow the map could be abstracted or simplified for a roguelike, then taking a turn to plan x some-odd moves and seeing how they unfold could be somewhat interesting... not sure though.
-
I'd build it like a MUD engine, except with a roguelike object graph.
When outside of combat, it's an asynchronous free-for-all. When combat commences, the combatants get locked into a recurring timer, where you input your action and then it "goes off" when your turn ticks around. If you don't enter an action, it just makes a normal attack for you.