some thoughts on multiplayer roguelikes
nightstalker
i've just started developing a roguelike (nothing to see here yet :).
i was thinking of making it very OOP based so it can more easily be
changed /
expanded.
i was also thinking about making it a multiplayer roguelike. i'm just
making the
ground work for now, but i would like to see some opinions on this.
First : making people cheat less (or preferably not)
i was thinking about keeping as much on the server as possible. for
example:
only send info to the client about the tiles his player can see (if
you would send
the full map, ppl would be able to rework the client so they can see
all
monsters / all items.
also : strong checking must be made by the server to check wether a
move from
a player is possible (for example a client could be recoded to make
a player move
two squares instead of one)
ofcourse these methods still makes it possible for the server owner
to cheat ..
it's a risk i'll have to take :)
Second: how to make it interesting for new players to join the game.
For example : a player dies or a new player enters .. he will find
that the dungeon
is empty of items ! also in the case of special level monsters, you
might have one
guy on the server hacking away like hell, so the other ones won't
even get to see
any 'boss' character (you could still go with quests .. but this
isn't the right
solution either i think.)
one thing i got around : shops will always have an unlimited supply
of goods (but
always the same goods as it was generated with). This is to keep
players from
getting all his equipment from a shop and not leaving anything for
another
player.
How is this all done in multiplayer roguelikes that already exist ?
Third: how to get past the issue of turn based systems (i think i'll be
able to tackle
this though :)
Shruuf
nightstalker wrote...
>hi,
>
>i've just started developing a roguelike (nothing to see here yet :).
>
>i was thinking of making it very OOP based so it can more easily be
>changed / expanded.
>
>i was also thinking about making it a multiplayer roguelike. i'm just
>making the ground work for now, but i would like to see some opinions
>on this.
>
>First : making people cheat less (or preferably not)
> i was thinking about keeping as much on the server as possible.
> for example: only send info to the client about the tiles his
> player can see (if you would send the full map, ppl would be able
> to rework the client so they can see all monsters / all items.
> also : strong checking must be made by the server to check wether
> a move from a player is possible (for example a client could be
> recoded to make a player move two squares instead of one)
> ofcourse these methods still makes it possible for the server
> owner to cheat .. it's a risk i'll have to take :)
>
This sounds quite reasonable, but that would make gameplay slow,
especially if there's not much action around, as for every step you
make in an empty hallway, you would have to send the "player wants to
make a step" info, wait for the server to check if it's possible for
the player to move and then send back "okay, go ahead". Apart from
that, good ideas.
>Second: how to make it interesting for new players to join the game.
> For example : a player dies or a new player enters .. he will
> find that the dungeon is empty of items ! also in the case of
> special level monsters, you might have one guy on the server
> hacking away like hell, so the other ones won't even get to see
> any 'boss' character (you could still go with quests .. but this
> isn't the right solution either i think.)
> one thing i got around : shops will always have an unlimited
> supply of goods (but always the same goods as it was generated
> with). This is to keep players from getting all his equipment
> from a shop and not leaving anything for another player.
> How is this all done in multiplayer roguelikes that already exist
?
>
I don't know how it's done in other multiplayer roguelikes, as AFAIK,
only MAngband is a multiplayer game. All other roguelikes I know are
single player. And as I've never found a server for MAngband, I
couldn't try. But I would suggest that every time a new player enters,
every dungeon level which has been visited before gets some new
monsters and items. This would repopulate the empty levels (which must
have been visited before, otherwise they weren't empty) while leaving
the unexplored ones as they currently are, i.e. it would not make the
unexplored levels harder just because someone entered the game. For
the bosses, I would suggest that you either make the bosses re-appear
every time a certain number of players has joined after the boss was
last killed. So if the boss is killed, a counter starts counting the
numbers of player which have joined since the boss died and once it
reaches a certain number, the boss would reappear.
>Third: how to get past the issue of turn based systems (i think
>i'll be able to tackle this though :)
>
Turn based games have a large drawback: the more players there are,
the longer each player has to wait for the others to finish so that
he/she may finally take his/her turn. But real-time roguelikes would
take that special roguelike flair away, I think.
I reformatted your original post (i.e. changed line breaks but didn't
change the words) because it looked messed up when I quoted. Hope you
don't mind too much. :)
Shruuf
--
No home page. And proud of it.
"All must abide and all must adhere"
Future oppresion becoming more clear
This is a warning so you must take heed
This coming vision is reality -- Fear Factory, "Securitron"
Thomas Olausen
nightstalker wrote:
>
> Second: how to make it interesting for new players to join the game.
> For example : a player dies or a new player enters .. he will find
> that the dungeon is empty of items ! also in the case of special level
> monsters, you
> might have one guy on the server hacking away like hell, so the other ones
> won't
> even get to see any 'boss' character (you could still go with quests ..
> but this
> isn't the right solution either i think.)
> one thing i got around : shops will always have an unlimited supply
> of goods (but always the same goods as it was generated with). This is to
> keep
> players from getting all his equipment from a shop and not leaving
> anything for
> another player.
> How is this all done in multiplayer roguelikes that already exist ?
>
When I one day (*sigh*) finally start to understand the basic concepts of
c++ programming, I would like to make a RL as well. I have some of the same
ideas as yours - not muliti-player, tho.
My plan is to make some kind of Roguelike-MUD hybrid! Closed sorce like
ADOM, free area-creation for dedicated players. More text... ("That's so
not-RL!", they screamed. I merely smirked and sighed "so....what...?")
Anyway - try playing a MUD for inspiration.
(Areas can have level-restrictions, players regain mana and hitpoints at
"ticks" that occur every 60 seconds (more regain when you sleep...). Areas
re-pop monsters and on-the-ground-items at special times defined specially
for each area (the newbie-area re-spawns every 10 ticks, the Super-Evil
Undead High Kings Undead Death Castle only re-spawns every 6000 ticks (or
never...))
>
> Third: how to get past the issue of turn based systems (i think i'll be
> able to tackle
> this though :)
Same thing as above...
Sorry if this was incoherent - I'm tired tonight.
Thomas
Brian Robinson
> When I one day (*sigh*) finally start to understand the basic concepts of
> c++ programming,
>
was confused by C++, but when I learned Java, most of the new knowledge
transfered over nicely.
--
Brian Robinson
brob...@ist.ucf.edu
Institute for Simulation and Training
Brad
news:38E2727E...@vip.cybercity.dk...
>
> When I one day (*sigh*) finally start to understand the basic concepts of
same
> ideas as yours - not muliti-player, tho.
> My plan is to make some kind of Roguelike-MUD hybrid! Closed sorce like
> ADOM, free area-creation for dedicated players. More text... ("That's so
> not-RL!", they screamed. I merely smirked and sighed "so....what...?")
Hello,
As it turns out I've been lurking in this ng a while because there are
some great ideas thrown around that are applicable to muds. I believe the
RL/Mud hybrid has been attempted before, however it was a while ago and I
don't believe the source is open. Not much info I know, but a little
checking might reveal what it is (I'm too tired/lazy, sorry).
- Brad
Jean Luc Picard
nightstalker <nsta...@tvd.be> wrote:
> hi,
>
> i've just started developing a roguelike (nothing to see here yet :).
>
> i was thinking of making it very OOP based so it can more easily be
> changed / expanded.
OOP is the best practical programming paradigm I've ever used. (Sorry
for all the P's). It works most of the time. It can also make a big
mess, but with all things programming, it's always the programmer's
fault. OOP does help in organising your thoughts/code.
> i was also thinking about making it a multiplayer roguelike. i'm just
> making the ground work for now, but i would like to see some opinions
> on this.
I think multiplayer is best. Two of my favorite commercial games were
multiplayer roguelikes, Diablo and Darkstone. Darkstone had the unique
ability to have two characters under the control of the same player
play the game.
> First : making people cheat less (or preferably not)
> i was thinking about keeping as much on the server as possible. for
> example: only send info to the client about the tiles his player can
> see (if you would send the full map, ppl would be able to rework the
> client so they can see all monsters / all items.
> also : strong checking must be made by the server to check wether a
> move from
> a player is possible (for example a client could be recoded to make
> a player move two squares instead of one)
> of course these methods still makes it possible for the server owner
> to cheat ..
> it's a risk i'll have to take :)
There is an endless debate on how to do this best. Diablo had this
problem severely when it first came out. The solution you have is the
one that EverQuest takes. It has also proven effective.
> Second: how to make it interesting for new players to join the game.
> For example : a player dies or a new player enters .. he will find
> that the dungeon is empty of items ! also in the case of special
> level monsters, you might have one guy on the server hacking away
> like hell, so the other ones won't even get to see any 'boss'
> character (you could still go with quests .. but this isn't the right
> solution either i think.)
> one thing i got around : shops will always have an unlimited supply
> of goods (but always the same goods as it was generated with). This
> is to keep players from getting all his equipment from a shop and not
> leaving anything for another player.
> How is this all done in multiplayer roguelikes that already exist ?
In the multiplayer roguelikes like Diablo and Darkstone, once the boss
is dead, he's dead. In games like EQ and UO, there are spawn points
where monsters regenerate. Just ask any dedicated EQ player how long
they've waited for a spawn to get that precious magical item they need
so badly. I personally would avoid spawning and stick with once their
dead, they're dead, but that's a personal preference.
> Third: how to get past the issue of turn based systems (i think i'll
> be able to tackle this though :)
Diablo and Darkstone are "real-time" roguelikes, meaning that their
concept of turn is a minute slice of time.
Sent via Deja.com http://www.deja.com/
Before you buy.
Peter 'Freak Boy' Hall
>
> In article <38E103CB...@tvd.be>,
> nightstalker <nsta...@tvd.be> wrote:
> > hi,
> >
> > i've just started developing a roguelike (nothing to see here yet :).
> >
> > i was thinking of making it very OOP based so it can more easily be
> > changed / expanded.
>
> OOP is the best practical programming paradigm I've ever used. (Sorry
> for all the P's). It works most of the time. It can also make a big
> mess, but with all things programming, it's always the programmer's
> fault. OOP does help in organising your thoughts/code.
>
I've just started to learn eiffel as a 1st year software engineering student.
I'm considering starting up a roguelike with it, no for the sake of making a
roguelike, though that comes into it, but as a fun way to practice programming.
Any comments?
> > i was also thinking about making it a multiplayer roguelike. i'm just
> > making the ground work for now, but i would like to see some opinions
> > on this.
>
> I think multiplayer is best. Two of my favorite commercial games were
> multiplayer roguelikes, Diablo and Darkstone. Darkstone had the unique
> ability to have two characters under the control of the same player
> play the game.
>
I don't think multiplayer works in roguelike games. But thats just personal
opinion, I also think Vegemite and Honey sandwiches are great.
> > First : making people cheat less (or preferably not)
> > i was thinking about keeping as much on the server as possible. for
> > example: only send info to the client about the tiles his player can
> > see (if you would send the full map, ppl would be able to rework the
> > client so they can see all monsters / all items.
> > also : strong checking must be made by the server to check wether a
> > move from
> > a player is possible (for example a client could be recoded to make
> > a player move two squares instead of one)
> > of course these methods still makes it possible for the server owner
> > to cheat ..
> > it's a risk i'll have to take :)
>
> There is an endless debate on how to do this best. Diablo had this
> problem severely when it first came out. The solution you have is the
> one that EverQuest takes. It has also proven effective.
>
You could have the client only send keypresses and the server only send
characters that are then drawn by the client to the screen. This would be slow,
I assume - though I don't really know what I'm on about here, but it would make
it very difficult to cheat.
> > Second: how to make it interesting for new players to join the game.
> > For example : a player dies or a new player enters .. he will find
> > that the dungeon is empty of items ! also in the case of special
> > level monsters, you might have one guy on the server hacking away
> > like hell, so the other ones won't even get to see any 'boss'
> > character (you could still go with quests .. but this isn't the right
> > solution either i think.)
> > one thing i got around : shops will always have an unlimited supply
> > of goods (but always the same goods as it was generated with). This
> > is to keep players from getting all his equipment from a shop and not
> > leaving anything for another player.
> > How is this all done in multiplayer roguelikes that already exist ?
>
> In the multiplayer roguelikes like Diablo and Darkstone, once the boss
> is dead, he's dead. In games like EQ and UO, there are spawn points
> where monsters regenerate. Just ask any dedicated EQ player how long
> they've waited for a spawn to get that precious magical item they need
> so badly. I personally would avoid spawning and stick with once their
> dead, they're dead, but that's a personal preference.
>
An idea for respawning: Don't make the same item respawn in the same place
after a set amount of time. If players realise that a really good item will be
respawned in a particular place in a set number of turns/seconds then you will
see the character who last picked it up picking it up again and again because
they know exactly when it will be back and where. Two alternatives here. Have
the item only respawn when it is destroyed/used up. There are problems with
this, mainly with players standing on the spot where they found a potion of gain
foo and drinking repeatedly, or at least returning to that spot after the
suitable delay knowing exactly when/where the item will be. Second randomise
exactly where/when/what the item will be. As in the an item is generated
somewhere on a particular level, every foo or bar hundred turns, and could be
anything. This leaves the problem of items that are important to the plot, as
in they have to be in a particular place/form to make any sense. In this case I
would make these items unique and undestroyable.
> > Third: how to get past the issue of turn based systems (i think i'll
> > be able to tackle this though :)
>
> Diablo and Darkstone are "real-time" roguelikes, meaning that their
> concept of turn is a minute slice of time.
>
This is why I don't like the idea of a multiplayer roguelike. You either have
to give those players who type/think faster an advantage, or make all players
wait for everyone to complete their turn. I think the best solution would be a
compromise. Set a time, fairly short - say .25-.5 seconds in which all players
can make their move. Anyone who has not moved in this time could be assumed to
be standing still. This way everyone has enough time to perform basic tasks,
moving and attacking, and those people who are doing something more complex,
rearranging inventory/equipment, would take several turns to do so, which is
slghtly more realistic.
--
Peter Hall
Currently studying *laugh* for his BSEng at ANU
Beaurocracy cuts red tape... lengthwise