misc thought: game over jabber im network?... - Java-Games

I was imagining now details of map/world structure and basic protocol.

for now I was considering tile based maps.

maps will be divided into areas (eg: 64x64m):
the tiles will be stored in multiple planes, for now:
texture;
height;
flags (whether or not one can walk on the tile, ...).

I was imaginging each area as an rle-compressed byte array (simple and can
save transmit cost...).
in the case of textures there will be an array mapping numbers to texture
names.

in the areas will be entities (with misc properties and such).
for now I am using largely 2d logic (things like height and such are
inferred from the tile).
I was imagining entities and monsters/npc's being controlled by the server.
clients will manage movement and passing messages (eg: of weapon attacks and
such) to other clients or the server.

buildings and such can be modeled, and will likely be represented either by
entities or by data attached to the map.

I was also imagining sprite based graphics for most things.


I was generally thinking up the protocol while designing the other bits.
luckily a lot of the more basic stuff will be handled by xmpp, leaving my
work basically as managing the maps/entities/users...
I will look around, xmpp probably allready includes a file-transfer
extension somewhere...

an engine like this shouldn't be too hard to beat together, I can work out
the details when I try to implement it.
I am considering writing this in c (this will help me avoid the temptation
to do anything fancy...).

again, this may be interesting to play with. I am trying to aim low this
time...

any oppinions?...

cr88192 wrote:

> I was thinking (from my current stance of obsessing over xmpp a bit):
> does anyone think it would be interesting, eg, to implement a game that
> works over an im network, namely jabber?
>
> it would not offer the best performance, however:
> it would be readily accessible by a reasonable number of people;
> server implementation would not be too complicated;
> there will not need to be centralized or very powerful servers (though
> hopefully servers would have at least decent bandwidth...);
> the world could be made easily extensible;
> ...
>
> this would not be acceptable for games that require, say, very strong
> security or good performance.
> a simple engine (requiring not that much in terms of servers) could work by
> effectively broadcasting movements to other players and letting the clients
> dictate physics, stats, and such (though this would allow rampant
> cheating...).
>
> conversely, the server could maintain stats and maintain physics and such.
> this would require a little more of the server (the world will lag if the
> server is too slow), this can at least guerantee better security.
>
> for the most part the server will not have as high of bandwidth or
> connection constraints as is common with other game types, since the
> connection is primarily with the im server, thus:
> no need to manage a number of connections;
> no real limits on things like, say, being behind a firewall or having a
> dynamic ip.
>
> an issue may be the "karma" feature, which could get in the way of servers
> (it would not be very good if the server runs out of karma...). as a result,
> having the players broadcast movements, though bad for security, would be
> better in terms of server karma (since it will largely be recieving and thus
> likely not achive as much bad karma, or at least as far as I understand
> things...). the server would work more for keeping note of things (where
> stuff is, player stats, providing some info to clients, ...), while most of
> the real work will be on the side of the clients.
>
> hmm, maybe the game could have built in im as well, since that would make
> sense in this case...
>
> protocol:
> as can be stated, I was primarily imagining the xmpp/jabber protocol.
>
> this does allow for easily adding new features without any real requirements
> set on the server (the protocol passes through any unknown data, eg, in "iq"
> messages). also, extensions do not interfere with the base functionality of
> the protocol or with other extensions.
>
> I was imagining a more "traditional" game protocol, eg, one that thinks in
> terms of entities/commands and little else (eg: having little or no
> rpc-style activities...).
> it could be interesting if wherever possible the protocol could be kept open
> and extensible (eg: by allowing user defined messages and such, avoiding
> having to fallback on extensions to xmpp...).
>
> maps:
> presumably a fairly "cheap" respresentation of maps and such will be needed,
> eg, something that can be easily downloaded. an idea is that it can be
> assumed that the map will be dowloaded piecewise and cached on the client
> (having either a time-until-expire or the client can check for changes to
> areas when going into a not-recently-visited area...).
> xml is the native encoding of xmpp, however something more dense (eg: an
> s-expression variant) could save more space (though xml would likely save in
> terms of implementation, and is not that signifigantly larger than
> s-expressions...). if all else fails compression may be able to make up for
> the loss.
> usefully textures will also need to be kept small, or some basic set can
> come with the engine (I am assuming here that many making servers will
> likely not be much in the line of artists, so a decent size base-set should
> be usable, or they could push for people to download packs of additional
> textures...).
>
> it would be cool if the maps/servers could be linked together (eg: using
> jids of other servers as links). if the server is down it may be possible
> just to refuse to transfer...
>
> the conditions may be very well different for commercial servers, as likely
> they would like centralized control and things like bandwidth are not much
> of a concern.
> maybe details like whether the physics/... are client or server side could
> be set by the server or such.
>
> this is just a thought, I am in now way claiming originality or even that
> much motivation to persue this idea (knowing how many of my recent efforts
> have stalled...).
>
> comments?...
>
> --
> cr88192 at hotmail dot com
> http://sourceforge.net/projects/bgb-sys/
> http://bgb-sys.sourceforge.net/

Is the IM (internet messenger) protocol stuff easily accessable-- library to do

program interface with your app ???

You might look into an idea I looked into years ago -- to use an IRC channel
for the same purpose (all the IRC protocol specs and source code is
available...)

One important limitation to check on is the max data size of a single message.
If its unreliable delivery, it will be simpler to transfer maps etc.. complete
(using a simple retransmit) instead of coming via a fragmenting mechanism and
all
the programming uglyness that requires...

Probably even more important -- how laggy the IM transfer is. How many seconds
delay is there on a one way message. For games like Nettrek where such delays
arent
critical it might be ok and you need to consider what kind of game will work
with a
broad range of delay (like armies moving around a huge world map over period of
many hours...
any Avatar based game might be too painful.)

cr88192 wrote:

> I was imagining now details of map/world structure and basic protocol.
>
> for now I was considering tile based maps.
>
> maps will be divided into areas (eg: 64x64m):
> the tiles will be stored in multiple planes, for now:
> texture;
> height;
> flags (whether or not one can walk on the tile, ...).
>
> I was imaginging each area as an rle-compressed byte array (simple and can
> save transmit cost...).
> in the case of textures there will be an array mapping numbers to texture
> names.
>
> in the areas will be entities (with misc properties and such).
> for now I am using largely 2d logic (things like height and such are
> inferred from the tile).
> I was imagining entities and monsters/npc's being controlled by the server.
> clients will manage movement and passing messages (eg: of weapon attacks and
> such) to other clients or the server.
>
> buildings and such can be modeled, and will likely be represented either by
> entities or by data attached to the map.
>
> I was also imagining sprite based graphics for most things.
>
> I was generally thinking up the protocol while designing the other bits.
> luckily a lot of the more basic stuff will be handled by xmpp, leaving my
> work basically as managing the maps/entities/users...
> I will look around, xmpp probably allready includes a file-transfer
> extension somewhere...
>
> an engine like this shouldn't be too hard to beat together, I can work out
> the details when I try to implement it.
> I am considering writing this in c (this will help me avoid the temptation
> to do anything fancy...).
>
> again, this may be interesting to play with. I am trying to aim low this
> time...
>
> any oppinions?...

Game is run by a centralized server???
That becomes the choke point for communication and CPU power depending on
your game mechanics.
For simplicity keep the entire game world in memory (map, all objects).
If you can, transmit your map zones incrementally as a players avatar moves
(let the client cache the tiles and request missing sets)

If the messanging is lossy, you will need some kind of timeout and resend
in your protocols.
Avatar/NPC positions should be constantly updates (if lost, replacement will
arrive soon - so no retransmit for that)
You might send each player only the positions of moving objects within a
visual range (if you have a large map and lots of dynamic objects)

If the data packets are relatively small, numbering them in sequence and
appending t he previous sends packet together in the same transmission
can alleviate the effects of frequent data loss.

Will you require reliable delivery of events/effects (like being hit by that
bazookoid rocket and taking big time damage/player death...) then you may
have to retransmit events every transmission until an ACK is sent back for it.
Most games require some reliable events.....

Might you be able to use the IM to transmit ip addresses of the server --
to act as the lobby, and then do all the rest of the game comm via udp ???
IM seems to be too much a liability/overhead for any kind of reasonable fast
comm link (unless its a slowwwww game)

"Eternal Vigilance" <wotan@oneeye.com> wrote in message
news:3FE04CEF.44C08A9E@oneeye.com...
>
>
> cr88192 wrote:
>
> > I was imagining now details of map/world structure and basic protocol.
> >
> > for now I was considering tile based maps.
> >
> > maps will be divided into areas (eg: 64x64m):
> > the tiles will be stored in multiple planes, for now:
> > texture;
> > height;
> > flags (whether or not one can walk on the tile, ...).
> >
> > I was imaginging each area as an rle-compressed byte array (simple and
can
> > save transmit cost...).
> > in the case of textures there will be an array mapping numbers to
texture
> > names.
> >
> > in the areas will be entities (with misc properties and such).
> > for now I am using largely 2d logic (things like height and such are
> > inferred from the tile).
> > I was imagining entities and monsters/npc's being controlled by the
server.
> > clients will manage movement and passing messages (eg: of weapon attacks
and
> > such) to other clients or the server.
> >
> > buildings and such can be modeled, and will likely be represented either
by
> > entities or by data attached to the map.
> >
> > I was also imagining sprite based graphics for most things.
> >
> > I was generally thinking up the protocol while designing the other bits.
> > luckily a lot of the more basic stuff will be handled by xmpp, leaving
my
> > work basically as managing the maps/entities/users...
> > I will look around, xmpp probably allready includes a file-transfer
> > extension somewhere...
> >
> > an engine like this shouldn't be too hard to beat together, I can work
out
> > the details when I try to implement it.
> > I am considering writing this in c (this will help me avoid the
temptation
> > to do anything fancy...).
> >
> > again, this may be interesting to play with. I am trying to aim low this
> > time...
> >
> > any oppinions?...
>
> Game is run by a centralized server???
this is common, but may be too expensive. I was thinking of leaving control
of npc's and monsters primarily on servers, but player control/actions will
be left on the client (allowing possible cheating, I know).

> That becomes the choke point for communication and CPU power depending on
> your game mechanics.
> For simplicity keep the entire game world in memory (map, all objects).
> If you can, transmit your map zones incrementally as a players avatar
moves
> (let the client cache the tiles and request missing sets)
>
yes, I am keeping stuff in memory. however, the client only has itself
registered with a few areas at a time (thus limiting updates). further off
entities will disappear.

> If the messanging is lossy, you will need some kind of timeout and resend
> in your protocols.
> Avatar/NPC positions should be constantly updates (if lost, replacement
will
> arrive soon - so no retransmit for that)
> You might send each player only the positions of moving objects within a
> visual range (if you have a large map and lots of dynamic objects)
>
as far as I know xmpp is lossless.
it is also by comparrison fairly expensive, eg, since everything is sent as
xml...

there will likely be a pretty low cap on the clients per server limit.

> If the data packets are relatively small, numbering them in sequence and
> appending t he previous sends packet together in the same transmission
> can alleviate the effects of frequent data loss.
>
not dealing with packets in this case.

> Will you require reliable delivery of events/effects (like being hit by
that
> bazookoid rocket and taking big time damage/player death...) then you may
> have to retransmit events every transmission until an ACK is sent back for
it.
> Most games require some reliable events.....
>
again, not using udp for this.

> Might you be able to use the IM to transmit ip addresses of the server --
> to act as the lobby, and then do all the rest of the game comm via udp ???
> IM seems to be too much a liability/overhead for any kind of reasonable
fast
> comm link (unless its a slowwwww game)
>
well, if I use udp then that defeats most of what I could gain from using
im...
crap like: what if the server is behind a firewall? well, in the case of udp
(unless one sets up the firewall specifically) then they are sol. udp
generally increases administrative costs.

I am considering something which will be probably unusable for servers where
you have very many players or entities, but if done right it might be easily
usable by end users (eg: to set up/administer servers, create game maps,
....).
I will presently ignore, eg, the cost of tcp, and the cost of sending
everything as xml...

all for now.

"Eternal Vigilance" <wotan@oneeye.com> wrote in message
news:3FE048FA.EF7BDD50@oneeye.com...
>
>
> cr88192 wrote:
>
> > I was thinking (from my current stance of obsessing over xmpp a bit):
> > does anyone think it would be interesting, eg, to implement a game that
> > works over an im network, namely jabber?
> >
> > it would not offer the best performance, however:
> > it would be readily accessible by a reasonable number of people;
> > server implementation would not be too complicated;
> > there will not need to be centralized or very powerful servers (though
> > hopefully servers would have at least decent bandwidth...);
> > the world could be made easily extensible;
> > ...
> >
> > this would not be acceptable for games that require, say, very strong
> > security or good performance.
> > a simple engine (requiring not that much in terms of servers) could work
by
> > effectively broadcasting movements to other players and letting the
clients
> > dictate physics, stats, and such (though this would allow rampant
> > cheating...).
> >
> > conversely, the server could maintain stats and maintain physics and
such.
> > this would require a little more of the server (the world will lag if
the
> > server is too slow), this can at least guerantee better security.
> >
> > for the most part the server will not have as high of bandwidth or
> > connection constraints as is common with other game types, since the
> > connection is primarily with the im server, thus:
> > no need to manage a number of connections;
> > no real limits on things like, say, being behind a firewall or having a
> > dynamic ip.
> >
> > an issue may be the "karma" feature, which could get in the way of
servers
> > (it would not be very good if the server runs out of karma...). as a
result,
> > having the players broadcast movements, though bad for security, would
be
> > better in terms of server karma (since it will largely be recieving and
thus
> > likely not achive as much bad karma, or at least as far as I understand
> > things...). the server would work more for keeping note of things (where
> > stuff is, player stats, providing some info to clients, ...), while most
of
> > the real work will be on the side of the clients.
> >
> > hmm, maybe the game could have built in im as well, since that would
make
> > sense in this case...
> >
> > protocol:
> > as can be stated, I was primarily imagining the xmpp/jabber protocol.
> >
> > this does allow for easily adding new features without any real
requirements
> > set on the server (the protocol passes through any unknown data, eg, in
"iq"
> > messages). also, extensions do not interfere with the base functionality
of
> > the protocol or with other extensions.
> >
> > I was imagining a more "traditional" game protocol, eg, one that thinks
in
> > terms of entities/commands and little else (eg: having little or no
> > rpc-style activities...).
> > it could be interesting if wherever possible the protocol could be kept
open
> > and extensible (eg: by allowing user defined messages and such, avoiding
> > having to fallback on extensions to xmpp...).
> >
> > maps:
> > presumably a fairly "cheap" respresentation of maps and such will be
needed,
> > eg, something that can be easily downloaded. an idea is that it can be
> > assumed that the map will be dowloaded piecewise and cached on the
client
> > (having either a time-until-expire or the client can check for changes
to
> > areas when going into a not-recently-visited area...).
> > xml is the native encoding of xmpp, however something more dense (eg: an
> > s-expression variant) could save more space (though xml would likely
save in
> > terms of implementation, and is not that signifigantly larger than
> > s-expressions...). if all else fails compression may be able to make up
for
> > the loss.
> > usefully textures will also need to be kept small, or some basic set can
> > come with the engine (I am assuming here that many making servers will
> > likely not be much in the line of artists, so a decent size base-set
should
> > be usable, or they could push for people to download packs of additional
> > textures...).
> >
> > it would be cool if the maps/servers could be linked together (eg: using
> > jids of other servers as links). if the server is down it may be
possible
> > just to refuse to transfer...
> >
> > the conditions may be very well different for commercial servers, as
likely
> > they would like centralized control and things like bandwidth are not
much
> > of a concern.
> > maybe details like whether the physics/... are client or server side
could
> > be set by the server or such.
> >
> > this is just a thought, I am in now way claiming originality or even
that
> > much motivation to persue this idea (knowing how many of my recent
efforts
> > have stalled...).
> >
> > comments?...
> >
> > --
> > cr88192 at hotmail dot com
> > http://sourceforge.net/projects/bgb-sys/
> > http://bgb-sys.sourceforge.net/
>
> Is the IM (internet messenger) protocol stuff easily accessable-- library
to do
>
> program interface with your app ???
>
the specs were available. the net stuff was easy enough to write (the main
issue was authentication, largely because the method used by the server was
actually found in a different spec...).

http://www.jabber.org/ietf/draft-ietf-xmpp-core-20.html
http://www.jabber.org/ietf/draft-ietf-xmpp-im-19.html
http://www.jabber.org/jeps/jep-0078.html
http://www.jabber.org/jeps/jep-0009.html

I have all this written allready.

> You might look into an idea I looked into years ago -- to use an IRC
channel
> for the same purpose (all the IRC protocol specs and source code is
> available...)
>
yes, same here.

> One important limitation to check on is the max data size of a single
message.
> If its unreliable delivery, it will be simpler to transfer maps etc..
complete
> (using a simple retransmit) instead of coming via a fragmenting mechanism
and
> all
> the programming uglyness that requires...
>
not that low level.
basically, my point of abstraction was set at sending and recieving xml
fragments (passed to and from the engine pre-parsed...).
I also have an rpc interface (a lot older, originally written for xml-rpc
but trivially extended for jabber-rpc).

there exists my pdlib project (which I may need again to seperate from the
lang/bgb runtime, since I am currently using it apart from my lang...). this
is where I implemented the xmpp stuff at.
actually, my xmpp code also does not deal directly with sockets either as I
put a psuedo-protocol (I called "meta0") between them. this basically serves
to deal with crap I was having to endlessly screw with while implementing
other protocols, namely, handling new connections and buffering. meta0 was
originally written for the mud-server project I did a few months ago, and
has since been used a fair amount in my projects. it is an event driven
interface, which I have found useful for net stuff.

> Probably even more important -- how laggy the IM transfer is. How many
seconds
> delay is there on a one way message. For games like Nettrek where such
delays
> arent
> critical it might be ok and you need to consider what kind of game will
work
> with a
> broad range of delay (like armies moving around a huge world map over
period of
> many hours...
> any Avatar based game might be too painful.)
>
I have not checked over the internet, but it should be ok...
my experience with what few online rpgs I have used seems to show they are
not very fast anyways, so time is not that critical...
movement is local, so it is more you can move and perform actions and wait
for them to arrive at the other end (crap like monster damage checking is
done locally).

all for now.

cr88192 wrote:

> "Eternal Vigilance" <wotan@oneeye.com> wrote in message
> news:3FE04CEF.44C08A9E@oneeye.com...
> >
> >
> > Might you be able to use the IM to transmit ip addresses of the server --
> > to act as the lobby, and then do all the rest of the game comm via udp ???
> > IM seems to be too much a liability/overhead for any kind of reasonable
> fast
> > comm link (unless its a slowwwww game)
> >
> well, if I use udp then that defeats most of what I could gain from using
> im...
> crap like: what if the server is behind a firewall? well, in the case of udp
> (unless one sets up the firewall specifically) then they are sol. udp
> generally increases administrative costs.
>

Im not familiar with XMPP -- does it use the HTTP ports 80 ??
If its some other port, then it probably has to be opened thru the firewall
anyway.
(Some workplaces kill just about everything, at a previous job they had
to do HTTP tunneling to get data thru customers firewall/network for
a client server application)

Have you done a test yet of sending data thru XMPP to another machine
and echoing back, to see what typical data turn around (and how variable
the lag can be). How slow the turn around is will determine how interactive
any game could be using that data passing method.




>
> I am considering something which will be probably unusable for servers where
> you have very many players or entities, but if done right it might be easily
> usable by end users (eg: to set up/administer servers, create game maps,
> ...).

Test #2 would then be seeing how alot of message traffic going in and out of
a single XMPP link effects the data transfer (those servers that control the
traffic may have data flow limiters which may only let a limited amount of
data/ number of messages thru to each connection...)



>
> I will presently ignore, eg, the cost of tcp, and the cost of sending
> everything as xml...
>
> all for now.

cr88192 wrote:

> "Eternal Vigilance" <wotan@oneeye.com> wrote in message
> news:3FE048FA.EF7BDD50@oneeye.com...
> >
> > Probably even more important -- how laggy the IM transfer is. How many
> seconds
> > delay is there on a one way message. For games like Nettrek where such
> delays
> > arent
> > critical it might be ok and you need to consider what kind of game will
> work
> > with a
> > broad range of delay (like armies moving around a huge world map over
> period of
> > many hours...
> > any Avatar based game might be too painful.)
> >
> I have not checked over the internet, but it should be ok...
> my experience with what few online rpgs I have used seems to show they are
> not very fast anyways, so time is not that critical...
> movement is local, so it is more you can move and perform actions and wait
> for them to arrive at the other end (crap like monster damage checking is
> done locally).
>
> all for now.

I played UO for 5 years and even tho the game does the combat automaticly,
maneuvering was still very important, and the diffrence between lag going from
..5 sec
response to > 1 sec killed the playability of the game.

If you are targeting a 'superMUD' then 1+ sec delay wont matter.

"Eternal Vigilance" <wotan@oneeye.com> wrote in message
news:3FE59AFB.B7D63321@oneeye.com...
>
>
> cr88192 wrote:
>
> > "Eternal Vigilance" <wotan@oneeye.com> wrote in message
> > news:3FE04CEF.44C08A9E@oneeye.com...
> > >
> > >
> > > Might you be able to use the IM to transmit ip addresses of the
server --
> > > to act as the lobby, and then do all the rest of the game comm via udp
???
> > > IM seems to be too much a liability/overhead for any kind of
reasonable
> > fast
> > > comm link (unless its a slowwwww game)
> > >
> > well, if I use udp then that defeats most of what I could gain from
using
> > im...
> > crap like: what if the server is behind a firewall? well, in the case of
udp
> > (unless one sets up the firewall specifically) then they are sol. udp
> > generally increases administrative costs.
> >
>
> Im not familiar with XMPP -- does it use the HTTP ports 80 ??
> If its some other port, then it probably has to be opened thru the
firewall
> anyway.
> (Some workplaces kill just about everything, at a previous job they had
> to do HTTP tunneling to get data thru customers firewall/network for
> a client server application)
>
xmpp does not use http. it uses port 5222.
the xmpp server, however, does not necissarily run on the same network as
the game server.

firewalls typically don't place any limit on outgoing connections as far as
I know (mine doesn't at least, and this port is closed... this means I would
probably just not be able to run a local xmpp server, but this is not a big
loss as I was concerned with game servers...).

> Have you done a test yet of sending data thru XMPP to another machine
> and echoing back, to see what typical data turn around (and how variable
> the lag can be). How slow the turn around is will determine how
interactive
> any game could be using that data passing method.
>
this is an idea.

I can probably test using a public server or something, and see how long it
takes to go over the internet.
when sending messages to myself before over the net the response seemed to
get back pretty fast, so I hadn't figured it was that big of a deal...

to get a better test I would need to test between multiple servers (eg: one
link may be to jabber.org, the other maybe to a different server...).

>
> >
> > I am considering something which will be probably unusable for servers
where
> > you have very many players or entities, but if done right it might be
easily
> > usable by end users (eg: to set up/administer servers, create game maps,
> > ...).
>
> Test #2 would then be seeing how alot of message traffic going in and out
of
> a single XMPP link effects the data transfer (those servers that control
the
> traffic may have data flow limiters which may only let a limited amount
of
> data/ number of messages thru to each connection...)
>
I think they do. my assumption was trying to keep general load as small as
was reasonable (and assuming anyone who expects a lot of traffic to have
their own xmpp server anyways...).
what I had read was referring to the limits as "karma", and karma is lost
whenever too much data is sent (causing the link to be stalled until more
karma is gained).

>
>
> >
> > I will presently ignore, eg, the cost of tcp, and the cost of sending
> > everything as xml...
> >
> > all for now.
>

"Eternal Vigilance" <wotan@oneeye.com> wrote in message
news:3FE59CA2.8856234F@oneeye.com...
>
>
> cr88192 wrote:
>
> > "Eternal Vigilance" <wotan@oneeye.com> wrote in message
> > news:3FE048FA.EF7BDD50@oneeye.com...
> > >
> > > Probably even more important -- how laggy the IM transfer is. How
many
> > seconds
> > > delay is there on a one way message. For games like Nettrek where
such
> > delays
> > > arent
> > > critical it might be ok and you need to consider what kind of game
will
> > work
> > > with a
> > > broad range of delay (like armies moving around a huge world map over
> > period of
> > > many hours...
> > > any Avatar based game might be too painful.)
> > >
> > I have not checked over the internet, but it should be ok...
> > my experience with what few online rpgs I have used seems to show they
are
> > not very fast anyways, so time is not that critical...
> > movement is local, so it is more you can move and perform actions and
wait
> > for them to arrive at the other end (crap like monster damage checking
is
> > done locally).
> >
> > all for now.
>
> I played UO for 5 years and even tho the game does the combat automaticly,
> maneuvering was still very important, and the diffrence between lag going
from
> .5 sec
> response to > 1 sec killed the playability of the game.
>
in my case I was imagining local movement, thus, you can move in real time
and it just takes longer for your movements to show up elsewhere...
too much lag could still kill playability though, eg, you are battling a
monster and doing ok (well, the monster seems frozen on your end) but in
reality it had done some uber-powerful attack (or a whole lot of attacks)
that will kill your player once they arrive. ok, so after a little while the
attacks get through and both you and the monster die...

unless the combat was fairly rapid or the connection incredibly slow, things
like this should not really be too much of a problem.

> If you are targeting a 'superMUD' then 1+ sec delay wont matter.
>
maybe. actually, using some manner of turn-based combat may be interesting
for an online rpg...
eg:
when you target a monster, or it decides to attack you, you are teleported
(maybe along with some of it's friends) to some other place to combat at.
another possibility may be that when engaged in combat, you remain in the
same spot but your world becomes turn-based while everything else remains
active. monsters will not engage a person allready involved in combat, and
it is not possible to attack a person in combat (besides maybe getting
locked into the turn-based configuration as well...).
maybe it could also be possible to leave battles, eg, if the other person
does not make an action within maybe 5 seconds or so...

this could be interesting...