Multi-character party in roguelikes
Joonas Hirvonen
the option of controlling a multi-character party.
The game is quite traditional roguelike, turn-based, no action points and no
"battle-screen" (like in Ultima, AD&D Goldbox-games etc.) so everything
happens on the same map-view.
I already have joinable henchmen which simply follow you and fight beside
you. Then I thought that it would be nice if henchmen got experience and
advanced or that you could equip them with better items etc. Which then led
to this idea.
Character's state could be "controlled" or he could be ordered to:
- be the leader
- follow the leader
- stay at spot
- fight
- etc.
Roguelikes are mostly quite fast-paced to play. I'm thinking would it be too
tedious to play a big battle when you control 3 or 4 characters. Some of
them could be set to "auto-fight" but still..
I tried Team Angband and it wasn't fun to play.
The interface for changing character states should be very streamlined and
fast to use. The game is graphical but it's controlled with keyboard only.
What do you think?
(I need to change the game quite a lot to even try this so that's why I'm
asking for opinions)
DaveB
http://todoom.sourceforge.net/
I also like the way Exile did it - but I don't think that will work if all
you're doing is dungeon delving. Basically party moves as one icon until
you enter battle mode - at which point they spread out - however same map
is used (I might be wrong - could only be same map in towns / dungeons and
a special "battle-screen" if on the main map).
Exile can be found at
http://www.spiderwebsoftware.com/productsOld.html
Dave
Antoine
wrote:
> I'm about to continue an abandoned roguelike-project and been thinking about
> the option of controlling a multi-character party.
Check out Guild, http://www.roguetemple.com/guild/
A.
Xecutor
They have parties.
But 8 characters combat could be somewhat long, you know :)
When I was thinking about mission based roguelike, I came
to conclusion that optimal number of characters in a party is 3 :)
Prior to this I came to conclusion that single character
mission based roguelike would be somewhat boring and/or hard to
balance.
However being non-single-character it couldn't be called true
roguelike...
Anyone cares a lot about trueness?
Risto Saarelma
> There are Nahlakh and Natuk which some people consider as roguelikes.
> They have parties.
They're part of a lineage that goes back to at least Ultima III. Nahlakh
and Natuk are particularly inspired by the AD&D Goldbox games and
Wizard's Crown which was their precursor.
I don't think they're considered roguelikes any more than Ultimas or
Goldbox games are though.
> But 8 characters combat could be somewhat long, you know :)
> When I was thinking about mission based roguelike, I came
> to conclusion that optimal number of characters in a party is 3 :)
The game becomes quite different the moment you have more than one
character to control. In these games, combat rounds are generally
divided into actual turns, during which the player controls each
individual character and each character can perform multiple actions.
Roguelikes are much nicer to play in this respect. The game advances
with each atomic action the player makes, and there's no need to worry
about turns separate from the actions. The player also doesn't need to
switch context between different characters and remember what each of
them was supposed to be doing.
The Avernum games had team combat and adventuring on the same map. This
works quite well, but I've always found the artificial switching between
adventure and combat mode a bit jarring in the game mechanics. There are
basically two movement and action systems jammed into the single
interface. The newer indie CRPG Eschalon compares favorably here. It has
just a single player character, and the timing model is pretty much
identical to the roguelike one. Not needing a separate combat mode feels
like a big win for simplicity.
So the Goldbox games, Nahlakh, Natuk and similar ones work by going into
a tactical RPG mode for each encounter, and have the encounter be
strictly limited in time and space compared to the rest of the game.
This doesn't fit well with the reasonably continuous game worlds of
roguelikes. Controlling multiple characters is a lot of work, so the
encounter will need to end when the intense battle is over and calmer
exploration needs to use a different mode.
Multiple modes are a big burden on design. Not only do you have to
design both modes instead of a single one, you'll also have to specify
all the ways stuff can move between the two modes.
I liked the approach of the Baldur's Gate games, where the game was made
single-mode by making the control scheme one from real-time strategy
games instead of the traditional one, where the player controls every
step of a single character at a time. Now it's simple to move the party
as a group by commanding all the characters at once, or commanding the
characters individually. This approach doesn't really work without
graphics and mouse control though, so it's not a good fit for
traditional roguelikes. Many people will also consider real-time to be
anathema.
Another approach would be to keep a roguelike control on a single
character, and let the other characters run around using AI, possibly
with some kind of command interface. The player might also switch
between directly controlled characters. This is how Guild works. The
pets in traditional roguelikes and the party members in the Fallout
games work like this as well. This looks like the most promising
approach for roguelikes, but the AI presents a bit of a design problem
again. If it's incompetent, it maims important characters. If it's
competent, it will feel like the game is playing itself and the player
isn't really necessary. If the characters need complex queued commands
to be effective, the game will essentially have two command interfaces,
one for instructing the AI and one for controlling the character
directly, which feels like ugly design just as the control mode
duplication does.
So it looks like game design will definitely be simpler when you have
just one character, possibly with some always-AI sidekicks whose
survival isn't that important. Roguelike pets and the party members in
the Fallout games are examples of these. If the game is going to have a
party of equally important characters, the whole design should reflect
this.
Joonas Hirvonen
viestissä:gb0siv$hu7$1...@nyytiset.pp.htv.fi...
> So it looks like game design will definitely be simpler when you have
> just one character, possibly with some always-AI sidekicks whose
> survival isn't that important.
I made a quick try of controlling just 2 characters every turn. It was
horrible.
What made it even worse is that I center the view around the character that
is in control and so the screen jumps awfully between the characters. Even
if I change that I don't think that it can be made playable.
So, I'm going to stick with just one character and put recruitable henchmen
here and there.
Billy Bissette
@nyytiset.pp.htv.fi:
> So it looks like game design will definitely be simpler when you have
> just one character, possibly with some always-AI sidekicks whose
> survival isn't that important. Roguelike pets and the party members in
> the Fallout games are examples of these. If the game is going to have
> a party of equally important characters, the whole design should
> reflect this.
Making the allies pets or lackies also lets the creator cheat a bit
more in the design.
For example, if you have a food system like most Roguelikes, you can
just ignore food for pets/lackies. That can prevent a lot of player
frustration, as they might otherwise need to micromanage party food
supplies.
With only one "important" character, you don't have to worry about
the player possibly splitting his party over multiple dungeon levels.
If the entire party is important, then what do you do when the wizard
steps on a trap door and falls to the next level? What if the fighter
takes the stairs while the priest is paralyzed? You don't even have
to deal with the thief hitting a teleport trap and ending up on the
other side of the dungeon level, with the player having to bounce
back and forth between each turn.
The average Roguelike just isn't what I'd consider "team friendly".
You've generally got a lot of walking between battles, but any turn
even of just walking around could be a tactical turning point. A
single trap or a monster coming around a corner can change the game
in a moment. You don't have discrete "move" and "fight" sections of
the game.
Risto Saarelma
> With only one "important" character, you don't have to worry about
> the player possibly splitting his party over multiple dungeon levels.
> If the entire party is important, then what do you do when the wizard
> steps on a trap door and falls to the next level? What if the fighter
> takes the stairs while the priest is paralyzed? You don't even have
> to deal with the thief hitting a teleport trap and ending up on the
> other side of the dungeon level, with the player having to bounce
> back and forth between each turn.
This is another problems. Baldur's Gate needs kludges to keep this from
happening. This is also why the most elegant team-based designs only
have the team scatter around in encounters where everything takes place
in one enclosed space.
From a technical and game design perspective though, these aren't
impossible problems. If we don't want to do design kludges that ensure
that the party stays together, the engine would just need to be able to
have multiple areas of the game world active at the same time.
Characters that get teleported into mapped areas could just be
instructed to pathfind their way back to the party. If a character ended
up in unmapped place, the player would have to juggle focus between the
stranded character and the current party until one is reasonably safe
and can be told to wait while the other does a rescue operation.
Maybe you could do a party game where you can't directly control any of
the characters. Instead, you could only affect the general
responsibilities and tactics of the characters, e.g. "Go in all-out
melee with any enemies, use healing potions freely." or "Use ranged
attacks, flee if enemies come close, collect magic items." or the most
important "Collect gold and keep bringing it to the home base so I can
hire new guys once you guys get yourselves killed with your stupid AI."
The somewhat obscure sim game Majesty did something like this. And of
course Dwarf Fortress is like this.
Krice
> So the Goldbox games, Nahlakh, Natuk and similar ones work by going into
> a tactical RPG mode for each encounter, and have the encounter be
> strictly limited in time and space compared to the rest of the game.
> This doesn't fit well with the reasonably continuous game worlds of
> roguelikes.
Why not? This is one of the ideas someone should really give
a try, because I think the tactical battle in old Ultimas
was cool. In Nahlakh it was too hard and had too many enemies.
I think it would be nice to enter the tile always when you
want to and keep the scale change consistent, so for example
when you find items you need to enter the tile for closer
look and pick them up by moving with group's characters
just like in battle. But I guess it could be nice to be able
to select how many characters you want to move while others
wait.
corremn
wrote:
Sewerjacks has henchman (allies) with simple state orders and they can
level up. I think the ally interface is very simple. http://sewerjacks.sourceforge.net/
Billy Bissette
@nyytiset.pp.htv.fi:
> Maybe you could do a party game where you can't directly control any of
> the characters. Instead, you could only affect the general
> responsibilities and tactics of the characters, e.g. "Go in all-out
> melee with any enemies, use healing potions freely." or "Use ranged
> attacks, flee if enemies come close, collect magic items." or the most
> important "Collect gold and keep bringing it to the home base so I can
> hire new guys once you guys get yourselves killed with your stupid AI."
> The somewhat obscure sim game Majesty did something like this. And of
> course Dwarf Fortress is like this.
Such an approach drifts more into the realm of a character
management game. You are no longer so much trying to defeat the
dungeon as you are trying to manage your characters so that they can
defeat the dungeon. The distinction doesn't bother me so much, but it
can and will bother some others.
It does have an advantage when it comes to AI faults though. As
the player has no direct control of anyone, it isn't as much in his
face when an AI character does something bad. (For better or worse,
the player may even think it is part of the overall challenge of the
management game to work around the faults of the AI.)
Ray Dillinger
> Maybe you could do a party game where you can't directly control any of
> the characters. Instead, you could only affect the general
> responsibilities and tactics of the characters, e.g. "Go in all-out
> melee with any enemies, use healing potions freely." or "Use ranged
> attacks, flee if enemies come close, collect magic items." or the most
> important "Collect gold and keep bringing it to the home base so I can
> hire new guys once you guys get yourselves killed with your stupid AI."
> The somewhat obscure sim game Majesty did something like this. And of
> course Dwarf Fortress is like this.
This is ... interesting. I'd never cared much about "party" games
because either the actions are all single-character oriented which
makes the interface a tedious mess, or there's a "main" character
and all the others (pets, henchmen, etc) feel like tagalongs or
afterthoughts.
But this is a better idea. If we step back from the single character
perspective and make the basic unit be the group instead, we get a
different game. Basic control keystrokes would mean different things.
I think if you put together a good set of commands that apply to
parties instead of to individual characters, you could get a party
game that plays as naturally as a single-character game, where
the additional party members don't feel like an afterthought.
So the ubiquitous arrow-movement key would refer to the party center
instead of a particular character, and the party would galumph along
all trying to stay in the vicinity of the party center.
'a' for ammo check; view information about ammo/charge supplies
for all characters.
'b' for buff, a command to prepare for combat (quaff potions,
etc). Hit once, twice, or three times for light, medium,
or heavy buffing.
'c' for call, an order to try and find separated party members.
'd' for drop, displays party inventory and allows player to drop
something - no matter who's carrying it.
'e' to toggle explore mode, allows/requires characters to range
further from party center and makes party center move slower (so
there's time for some party member to step in and look around
as the party passes each room).
'f' for fight, one character takes one action to further the progress
of the party fighting whatever designated targets (see 't') exist.
'F' with a count, the same as hitting 'f' that many times.
'h' for quick heal, the party members at low hitpoints quaff/heal self
if capable, or bleat a "help, medic" message indicating how hurt they
are if not. (a character whose standing orders designate his/her
job as healer-in-combat may heal characters who bleat, even while
a fight is going on.)
'H' for heal, party members interrupt any fighting to heal each other
as needed, where capable.
'i' for inventory, a command to manage and distribute party inventory.
'l' to designate objects for *EVERYONE* to leave alone, regardless
of whether their order/role would otherwise have them picking it up.
'm' for adjust marching order.
'o' for adjust a character's standing orders.
(standing orders would need to specify a bunch of roles/jobs,
and which ones are how important for that character).
'p' would designate objects for the party to pick up
(although "grab everything not nailed down" might be a
standing order for some characters).
's' search, whatever searching capabilities party members have,
they use. Maybe the player designates an area, maybe it
just defaults to an expanding area around the party center.
't' targets: player designates one or more targets. Subsequent
repeated pressing the 'f' key presses attacks on these
targets as long as any are alive.
'w' for weapon check: display how all characters are armed, as
well as party weapon inventory. Allow for redistribution of
weapons.
etc....
Bear
Billy Bissette
426e7a...@73g2000hsx.googlegroups.com:
Hrm...
How about movement around the level handled at "map scale." Rooms
are single entities. Corridors could either be segmented by size
limits, by forks and doors and room entrances, or a combination of
the two.
Combat is at "combat scale". Enter a room with monsters present,
and you zoom to a detailed room, with a bit of any connecting
corridors also present. Your team is placed where they entered
the map entity. Combat itself is a tactical battle in miniature.
If you have some kind of time systems, such as hunger or keeping
track of game turns, then you'd need to balance map and combat
scale situations so that one is not necessarily preferable to the
other. (At the very least, you don't want combat scale to be more
efficient than map scale.) You could go as far as to make time
primarily a map scale issue, with either no overall time passage
at combat scale or a unit of time passing only after several combat
scale turns.
The game would preferably be designed around the whole map/combat
scale difference. While standard Roguelikes may have random weak
enemies wandering around alone, you'd probably want to avoid that
here. Put enemies in groups, or make them challenging. Give more
thought to what can and should appear in an area.
Such a design might also benefit from pronounced room themes.
If there is an orc army present, then there might be a barracks or
two, maybe a weapon storehouse, and a dining hall. Walk into an
orc dining hall at lunch and you should expect a crowd. Combat
scale could also take advantage of room themes for obstacles and
decoration. A barracks would have beds, while a dining hall would
have tables, and a weapon storehouse would have weapons. Players
could get an idea what to expect of surrounding areas by what they
already see, and if lucky might stumble across a safer and emptier
room first.
Magical abilities or perhaps scouting abilities might give more
detailed information on adjacent or even distant areas without
actually entering them.
Whether enemies move between areas is optional, but pathing from
map entity to map entity would presumably be easier than at normal
Roguelike scales. Maybe even could have "patrol routes" or
"everyday event" routes for creatures to take.
If the player's party enters an area with significantly
inferior foes, then just auto-kill them at map level without even
going into combat scale. Flag a note to the player that they've
fought and won, and against what. At first I figured such
windshield kills should be engineered out of the level design
excepting special situations (such as wounded monsters that managed
to flee to another area), but then I considered it is again a decent
method of warning the player of what might be nearby. If they are
lucky, they might fall upon a lone orc in a hall before they enter
the dining hall at lunch.
Jeff Lait
wrote:
> I'm about to continue an abandoned roguelike-project and been thinking about
> the option of controlling a multi-character party.
>
> The game is quite traditional roguelike, turn-based, no action points and no
> "battle-screen" (like in Ultima, AD&D Goldbox-games etc.) so everything
> happens on the same map-view.
>
> fast to use. The game is graphical but it's controlled with keyboard only.
>
> What do you think?
Playing a lot of Dungeon Master recently it occurs to me there is
another choice. You can have a party that *never* splits, not even
during combat. This keeps a single map level and ensures there are no
control changes.
Further, you no longer need the whole "switch the leader" mentality -
"you" are always the party.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Martin Read
>Playing a lot of Dungeon Master recently it occurs to me there is
>another choice. You can have a party that *never* splits, not even
>during combat. This keeps a single map level and ensures there are no
>control changes.
This was quite common in 80s CRPGs (Bard's Tale, Phantasie, Dragon Wars,
Dungeon Master, Wizardry, Might and Magic) and is unremarkable in
console RPGs today.
--
\_\/_/ turbulence is certainty turbulence is friction between you and me
\ / every time we try to impose order we create chaos
\/ -- Killing Joke, "Mathematics of Chaos"
I Own The Letter O
something that I have considered when I get my game beyond the basic
level it is at now. ADOM had something similar on the world map. I
think travel within the dungeon would be 'map' scale and would revert
to 'map' scale from 'combat' scale after set conditions.
I also wanted 'combat' scale to be more than just for tactical combat.
It would also allow 'puzzle' rooms or unique rooms to be made with
intricate designs and greater floor plan-sizes as you have more room
in that scale. Leaving the room or hitting 'up' keys would revert to
'map' scale.
As mentioned above it would make tactic combat much better. Especially
if you have furniture in the 'combat' scale or other cover/hazards
that would simply take up too much room in normally 'map' scale.
This furniture then lends itself to more places to search for traps/
treasure/clues/etc making the RPG side of Roguelikes possibly more
prominent.