In Pixel Cannon
server-side technology is essential. The server is the only thing
that has full knowledge and full control over the entire game. It
accepts shot and move request from the individual tanks and performs
all animation and collision detection in memory. No client has the
authority to perform collision detection. The server is essentially
the brain in this game while the clients are not much more than
dummy terminals.
So, server-side technology is used for a few reasons. Here are some
of them
» To simply exchange information (e.g. Mini Golf, Chess, etc)
» To control the game (e.g. Pixel Cannon)
» To perform game validation and/or game control if security
is a concern. Imagine a game company that wanted people play Poker
for real money. The server would have to control things like shuffling
the deck so that know client knows all of the cards. The server
would have to validate moves to make sure they are legal, etc.
Q: Do you think Flash technology is good enough for RTMGs
?
Hell yes.
Q: What are the main difficulties in developing a RTMG
that a "traditional" Flash developer would face ?
There are several hurdles. The first hurdle is trying to
understand how RTMG’s work on a conceptual level. It is important
to understand how the server falls into the mix and what the Flash
client should handle and what it should handle.
Then you get technology specific. How do you want to pull this game
off? You can use Flashcom, ElectroServer 3, Unity, etc. Which one
is best? What features are provided that you’ll need.
Once you have chosen the technology you need to learn how to use
it. It’s a lot of work doing the fundamental ground work.
But once you’ve done it one time you can move on and make
several games with this knowledge!
Q: Synchronization is critical in a RTMG, what "tricks"
should be employed to ensure that all clients are kept in synch?
In general, yes synchronization is important. You want
to find a way to have every client show the game state as close
to what the server knows is the true game state.
In order to pull that off every of importance (moving tanks, projectiles,
etc) must be controlled 100% by time. They must be completely independent
of frame rate.
Time synchronization is a tricky business and I hope to write an
article about it soon. The goal, as mentioned, is to sync the clients
to the server. That is done by accurately determine the latency
of each client…which can be slightly tricky to do well.
Q: Do you think it is possible for users with a 56kb/s
modem to play RTMGs ?
Yes. The only restriction that a 56k user will have is
bandwidth.
That may mean that they have to play a 2 or 3 person game instead
of a 10 person game. But they can still do it.
I have tested it myself with Pixel Cannon. I will soon be adding
a new protocol to that game which will drop the bandwidth usage
down 10 times.
That means that from a bandwidth point of view even people on 56k
modems will be able to play along with 10+ people no problem. With
that many people there may be other issues, but it won’t be
bandwidth related.
Q: Talking about "lag" can you tell us what are
good values in terms of network latency for a good gameplay, and
what happens when these values increase ? How do you manage it ?
Latency is defined 2 ways.
Some define it as the total roundtrip time it takes a packet to
go from the client to the server and back. Others define it as half
that time, server to client. I define it as the server to client
time.
Over the Internet you can expect latencies from 50ms to over 1 second.
A good latency, if there is such a thing, is under 150ms.
There are ways to reduce bandwidth, but there is no way to decrease
latency, short of rewiring the world. The only thing you can do
is make the games time base, as you are most likely already doing
in a RTMG, and to add in some sort of latency hiding.
Latency hiding is an article by itself. But in short, you can schedule
events to occur like 100ms or 200ms in the future to sort of hide
a little of the latency, so that more people see the event simultaneously
than before. Otherwise, people with lower latencies will have an
advantage in the game.
Q: Games like Quake and Unreal Tournament use "prediction
algorithms" to keep moving all characters even if the server
is not precisely aware of their positions. Is it possible to implement
these solutions in Flash ?
Yes. But at this time I have not experimented with any.
It is unclear to me how code execution time per frame this will
take in a game. But my gut is that it will be perfectly fine for
3-4 players at a time.
Q: Let's say we're playing your "Pixel Cannon"
game, and my tank shoots yours.
Can you tell us what is the typical request/response exchange between
client and server ?
Client A (your client) sends a request to the server asking
to fire a projectile at a certain angle.
The server will check to see if you have enough ammo.
Then it will create the projectile in memory and fire it in memory.
It will broadcast this “CreateProjectile” event to all
connected clients.
Both Client A and Client B receive this CreateProjectile event and
spawn a new projectile on screen and start animating it in a time
based way.
The projectile will continue animating until the server tells each
client to remove it.
Q: In a typical RTMG there is usually one "smart side"
represented by the server which is responsible for the whole game
logic and a "dumb side" that only executes the server
commands. Does this schema apply to all multiplayer games ? Are
there any exceptions ?
It is not always done in a client-server way. The client-server
method is how we should do it in Flash because the alternatives
are more difficult. But there are peer-to-peer RTMG’s that
sync with each other and send data to all other peers. It’s
a complicated network and has almost not advantages. But it is used
sometimes.
As mentioned earlier, many TBG’s are accomplished in Flash
where the server is dumb. But it will be a rare RTMG that can be
pulled off in that manner.
Q: Currently the Flash Player only supports socket connections
through TCP/IP which can be slow when compared to the UDP protocol.
Do you think that this is a limit for Flash as a game client ?
No. It is a common misconception that UDP is faster.
It has the same speed through the Internet as TCP/IP. What makes
it appear to be faster is that there is no guarantee that it will
arrive. With TCP/IP, if you send a packet of information it is guaranteed
to arrive at the destination. This may mean that it dies along the
way 5 times and is silently retransmitted 5 times until it makes
it. That is common and can make it seem slow.
UDP on the other hand has no guarantee that it will arrive. So if
it dies along the way, which is not uncommon, it will not be resent.
Games like Quake use a combination of UDP and TCP/IP. They send
important information via TCP/IP but unimportant “update”
information via UDP. So in Quake you might send 10-20 updates of
your position to the server per second via UDP, but something like
firing a weapon would be TCP/IP.
Q: ElectroServer is known as an XML Socket Server, which
means it exchanges XML encoded messages with the connected clients.
Isn't XML a bandwidth waste for RTMGs were lots of messages are
being sent and received by the server ?
Yes. XML is a fat verbose format. The big advantage of
XML is that it is very convenient to use.
The big disadvantage is that it can take up too much bandwidth.
We are currently adding something to ElectroServer that will allow
you to flip to a low bandwidth mode. It is complicated to explain
why you cannot just have the entire server always use low bandwidth
mode.
The simple explanation is that using XML (high bandwidth) lets most
users do many things with ElectroServer 3 in an easy way. Low bandwidth
uses a compact protocol that is not very flexible at all and requires
more knowledge of the server. Everything is a tradeoff.
So we’ll be able to configure some games specifically to use
a lower bandwidth protocol, but it takes extra work per game to
do so. If you want it to be easy that the protocol gets fatter.
Q: Can you tell us about the origins of Electroserver ?
When did you start with this project and how did it evolve ?
We started ElectroServer before Electrotank was officially
founded, in 2000.
It was created so that we could create our own multiplayer games.
ElectroServer went through a few names and several revisions.
ElectroServer 2 was released in 2002. ElectroServer 3 was released
in October of 2003.
Every feature added was added because we could see a use for it
for ourselves. We still develop on it with ourselves in mind.
It was developed for the sole purpose of multiplayer Flash games,
but is capable of working with any technology that can exchange
XML over a socket (Director, Java, etc).
Q: "Pixel Cannon" was presented at the "Flash
Forward 2004" as a game demo, can we expect to see it released
as a full RTMG during the year ?
We intend to release a game built on this engine in late
April or early May. You can expect something much greater during
the summer. We have something great in the works that I can’t
currently talk about. But it is an extension of the same idea!
Q: Can you unveil some other projects coming soon from
Electrotank ?
Tankcore: Tournament. That is the game built on the Pixel
Cannon engine. And then something bigger this summer. We have some
small games in the works as well, like a Jigsaw game and a few other
puzzle games.
Q: The last, inevitable question: what do you expect from
the next version of Flash ? Any whishlist ?
Flash 7 brought with it much faster code execution which
makes me happy as a programmer. But what is still lacking is any
power behind graphics rendering. We are now being limited by how
fast Flash can render things on screen. The code is super fast but
the games can still be dramatically slowed down when too much is
happening visually. I hope to see improvements in the next version
of Flash on that front.
Also, I think that we’ll see greater enhancements for programmers.
I think we’ll see runtime error handling rather than just
compile-time checking.
Extra notes: the presentation notes and source code
for "Pixel Cannon" are available for download at the Electrotank
website.
|
