Multiplayer Turn-Based Games: Gameplay

I finished Fallout 1 a couple of days ago (like a coward, sold out all my friends and whatever family I had and let them die. oops) and all in all, it was a pretty good experience. I especially like how it handled normal travel/action and combat with the Action Point system: the game really only uses turn-based mechanics during fights. The player has a certain number of points to spend on moving, attacking, accessing inventory, reloading, etc. per turn.

Fallout 1 (and IIRC, all the other Fallout games) is single-player only. If I had to guess why, it boils down to two things:
1) the game world (how relationships and allegiances work, number of people and places, etc) is really only built for one player to finish quests and make friends/enemies
2) if two human players inhabit the same world but aren't necessarily near each other, what happens if only one of them enters combat?

The second question really interests me more, since I think the first is really a creative decision and depends on the type of story. Single player fits the narrative of Fallout really well, and multiplayer may not fit the same way. But that second question...what to do?

Let's say Player X starts fighting something and Player Y is off in another section of the map. You don't want Player Y to automatically be pulled into combat mode, since that would get tedious after a while. X and Y won't always be doing the same thing or be in the same place.

At the same time, you don't want Y to not go into combat mode at all. Otherwise, X could engage the enemy, who would remain frozen during X's turn and thus allow Y to walk by unscathed. It's also "unfair" to the enemy to give Y infinite time to buy weapons, choose a good tactical position, and then enter combat to help out X.

Some possible solutions:
- don't let time freeze during play, but limit what the X can do by giving him/her a limited number of action points for a given time frame. Their action points reset after x seconds.
- in conjunction with the above point, automatically draw Y into combat when (s)he is within a certain radius of X
- do freeze or slow down time in the area where X is in combat, and prevent outside entities from entering. However, this limits combat to 1 on 1 engagements.

What do you think about this problem? Are there other viable approaches to multiplayer turn-based games that allow for deep tactics-based combat? What other considerations are there in creating a multiplayer turn-based game? Would multiplayer Fallout be fun?

Comments

  • Most multiplayer games that are turn-based tend to stick to it - they don't try to attempt any sort of asynchronous gameplay because it can actually get quite complex. There is not really a good work around, other than to keep players busy while it is not their turn. Often, this is done by anticipating moves or inspecting your available resources (i.e. looking at your available cards and devising a strategy in a CCG).
  • edited January 2015
    In my opinion turn based multiplayer gameplay only works if the flow of the game isn't stop-world completely, and instead at least has a timer between decisions made. Another option is having characters that have a specific number of managable skills that you can sort of control 1 while the rest fights routinely to a certain extent.

    Turn based combat makes big army battles nearly impossibly slow in many contexts. And this does bring up the discussion of how to manage groups or large amounts of units. For example how world of warcraft or diablo 2 has "parties" for collections of groups, or how some real time strategy's organize armies. That is a whole other topic that would probably not be something that is dealt with on the first release of the game I think though or at least not extensively dealt with too much. This is definitely not anything of a priority, as I think the focus of the game is supposed to be RPGish at the moment but you can correct me if I'm wrong.
  • It does help to parralelize the turns, so each turn only takes as long as the slowest person, rather than the length of every person in sequence. The game mechanics do need to be made with this in mind, perhaps a scheme where you set your action, then they all unfold simultaneously at the end after everyone made their choice.
    A similar approach is to have the turn progression occur at a fixed rate, say 1 turn every 30 seconds. You must enter your commands within this time window. This removes "oh no, someone is slow" from the equation, and the biggest issue in combat is someone who is fast and can make their decisions quickly, then has to wait for the turn to tick over, but this does limit how much they may have to wait.
    An advantage of this approach is that you can link the amount of time each turn is supposed to represent with how long it actually takes, so people can act in real-time outside of the turn structure, and not have synchronisation issues. If they take 5 minutes to travel to the store, buy a weapon, and return back, then 10 turns have passed in that combat. Then you just have the question of when to transition them to turns, but that is easily solved based on when they see the combat or their proximity or some other metric.
  • Slightly unrelated question - was Fallout 1's slow group combat (even with combat speed turned up as high as possible) due to CPU bottleneck or design decision?
  • edited February 2015

    Slightly unrelated question - was Fallout 1's slow group combat (even with combat speed turned up as high as possible) due to CPU bottleneck or design decision?

    Partly both. At the time it was released, it could only render so fast without skipping too many frames.

    I am attempting to address this in VQ with simultaneous turn-based movement. My first idea for addressing this is that all turns play out at the same time, limited to one action. So, you "state your intention" rather than directly applying the action, and once every NPC has stated their intention (i.e. the CPU has calculated the next move), the turn plays out. This can have some interesting consequences like doing cover fire or avoiding incoming fire. There are still action points, which you accumulate over time (up to whatever limit your character(s) have), so while moving might only cost one action point, attacking could cost more (based on how heavy the weapon is, reload time, etc). Also opens up some interesting ideas for how action points are accumulated and drained with different skills (i.e. more rapid regeneration with some perk, or ability to overload action points at a cost to future regeneration, etc).

    Perhaps most interestingly, this could provide meaningful actions for different attacks. A slash could attack the three squares that are one unit in front of your character, thus negating the enemies ability to side-step your attack. A stab could attack two squares in front of your character (as a line) to anticipate the enemy dodging your attack by stepping backwards. Similar ideas could be used in defensive maneuvers and parrying.

  • Sweet! I really enjoyed the action point system of Fallout, and it sounds like you're taking it to next level.

    Are you planning on implementing a discrete square/hexagonal position system like Fallout, or leaving it continuous?
  • the main thing to watch out for with an action point system is action point reduction. A point or two of reduction on something cheap can make it several times as powerful.
  • Are you planning on implementing a discrete square/hexagonal position system like Fallout, or leaving it continuous?


    It will be square-based. Way back when I first conceptualized VQ it was hex-based, but square-based systems are generally easier to work with and program.
    Mystify said:

    the main thing to watch out for with an action point system is action point reduction. A point or two of reduction on something cheap can make it several times as powerful.

    Yes, it is inversely related. In a traditional AP system, if you have 10 AP, a 3 point action can be done 3 times, a 2 point 5 times, and a 1 point 10 times (inverse of 1/10 = 10). Rather than reduce, an alternative is to give bonus AP in certain circumstances, which has less extreme effects.

  • Yeah, bonus AP works well. Extra AP just for moving, for instance, is great for increasing your mobility.
  • gavanw said:

    I am attempting to address this in VQ with simultaneous turn-based movement. My first idea for addressing this is that all turns play out at the same time, limited to one action. So, you "state your intention" rather than directly applying the action, and once every NPC has stated their intention (i.e. the CPU has calculated the next move), the turn plays out.

    That makes sense, and that is also how Mayfair's (paper and pencil) DC Heroes RPG did things----I was pretty happy with how that was set up. (there were some other things in that system which I wasn't crazy about, but their turn system was interesting)

    Still, I am a bit curious how that would work in your setup for contrasting types of actions (combat vs cross-country-travel for instance). If everybody was following the same turn-by-turn time system, it might be a problem in some situations. . . .

    I can imagine doing a 15 km trip to a nearby town, where my character moves 5 meters at a time, while I wait for the others to state their actions at the end of each turn. That "go 5 meters wait. . . . go 5 m, wait. . . . go 5 m, wait. . . . go 5 m, wait," sort of thing could get old fairly quickly.

    On the other hand, if characters use different time systems (some going turn-by-turn in combat, while others take longer term actions), then it would seem like things could get out of sync between different characters in the same world.

    I suppose that you could have people's characters state their intentions to do longer term actions, and then the players could simply leave, and come back when the character has accomplished the task. In other words, I'd state that my character was heading to a near-by town, and then check back every few hours (or every few days) to see if enough time had passed to reach my destination.

  • edited February 2015
    Warp9 said:

    gavanw said:

    I am attempting to address this in VQ with simultaneous turn-based movement. My first idea for addressing this is that all turns play out at the same time, limited to one action. So, you "state your intention" rather than directly applying the action, and once every NPC has stated their intention (i.e. the CPU has calculated the next move), the turn plays out.

    That makes sense, and that is also how Mayfair's (paper and pencil) DC Heroes RPG did things----I was pretty happy with how that was set up. (there were some other things in that system which I wasn't crazy about, but their turn system was interesting)

    Still, I am a bit curious how that would work in your setup for contrasting types of actions (combat vs cross-country-travel for instance). If everybody was following the same turn-by-turn time system, it might be a problem in some situations. . . .

    I can imagine doing a 15 km trip to a nearby town, where my character moves 5 meters at a time, while I wait for the others to state their actions at the end of each turn. That "go 5 meters wait. . . . go 5 m, wait. . . . go 5 m, wait. . . . go 5 m, wait," sort of thing could get old fairly quickly.

    On the other hand, if characters use different time systems (some going turn-by-turn in combat, while others take longer term actions), then it would seem like things could get out of sync between different characters in the same world.

    I suppose that you could have people's characters state their intentions to do longer term actions, and then the players could simply leave, and come back when the character has accomplished the task. In other words, I'd state that my character was heading to a near-by town, and then check back every few hours (or every few days) to see if enough time had passed to reach my destination.

    My intention is to have AI running in background threads constantly, and whatever task they have settled on is the one that gets picked almost immediately after you have moved. This basically means that there is no delay between turns. The longer you decide how to do something in a turn, the longer the AI has to compute as well. AI compute intensity can be adjusted in the settings as well. My other intention is to have AI cycles be fast enough such that they can do basic strategies in under 200 milliseconds total. AI could also theoretically be computed retroactively - say I "draw" my planned path with no delay whatsoever, and the AI catches up with that computation as I move - and perhaps stop me on some major event, like being attacked whilst in a noncombat situation.

    If there is any serious lag, it won't be fun, so I have to work around that.
  • gavanw said:


    My intention is to have AI running in background threads constantly, and whatever task they have settled on is the one that gets picked almost immediately after you have moved. This basically means that there is no delay between turns.

    That sounds great in single player mode, but for multi-player stuff wont there still be a problem?

  • Warp9 said:

    gavanw said:


    My intention is to have AI running in background threads constantly, and whatever task they have settled on is the one that gets picked almost immediately after you have moved. This basically means that there is no delay between turns.

    That sounds great in single player mode, but for multi-player stuff wont there still be a problem?

    A similar tactic for multiplayer could be employed (and in fact many multiplayer games, such as RTS games, employ something like this).

    Players could move (or rather, state their intention to move) without lag, simultaneously. You have one of two scenarios going on:

    Either human players are so far apart that we can simulate their moves independently, since they do not effect each other (at least significantly - there is the so-called butterfly effect though, but this need not be incorporated in a turn-based manner).

    If human players are nearby, you can draw out your moves (say up to a certain limit ahead of other players, like 100 moves ahead, as has been mentioned by others here before.

    All of that said, the first goal is to get a single player game working well, and then we can attempt to tackle these problems. :)
Sign In or Register to comment.