Multiplayer in Roguelikes

[yamamushi]

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.

[requerent]

Cool-- is it real-time? How are you handling it?

[Alex E]

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.

[yamamushi]

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

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

[Paul Jeffries]

I've been playing the old boardgame 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...

[yam655]

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

[requerent]

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.

[Leaf]

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.