My multiplayer RTS

[User137]

Just letting you know what's going on behind the scenes :P And this is just a spare time project that is done somewhere between everything else and World of Warcraft when motivation strikes hit... (It may never complete at all but i think its idea worth mentioning)

Inspired by good old Total Annihilation, Settlers and Mmorpg network gaming styles, this is small game, a futuristic realtime strategy game with massive forces in player control. I would make it for single to upto maybe 8 players AI or human controlled players. Games would take place in a world that is saved on exit and continuable upon start. Idea is to have a huge map, now imagine largest possible map in Starcraft that is 256x256. This game would have that size times 10. Max unit counts per player are likely set for 30000 or more, they decide whether those units are all buildings or other units.

Using Next3D (and maybe some from old Tlib) that is my own OpenGL graphics wrapper and function libraries. dglOpenGL 1.8 beta?, WSockets 1.20.

How is it possible to make massive forces, consisting of thousands of units and buildings and then synchronize it all through TCP/IP? Now, as i don't have a technical test ready yet its in theory level. Lets put security aside and think of this as a small game for some fun wanting people. The game server or client will never send a single tcp packet holding information on unit location, bullet shot or resource gained etc, its all game engine. When i draw a rectangle over 1000 units i see on my game client, i will not transmit what those 1000 units are to server. Instead i send cursor coordinates and camera position. Additionally i can click a single unit when i can send that unit ID. (There are numbered unit groups to ease selection aswell.) Server gathers data in its pace and in timed intervals (perhaps every 50-100ms) send all clients order to increase tick. This tick is key to synchronizing everything. All physics and movement are calculated on both server and client side. When that selection comes to server, it transmits it back to all clients including the sender. This is when sender and all other clients get to know what that player has selected and next command through server might be order for that selection to attack.

Edit: However, if someone has plan to make a cheat, it will only effect his own client. Other clients will see the cheating player play stupid and only he just becomes non synchronized. Cheater might not get all his commands through when server thinks unit he is commanding may not even exist.

Now, during the ticks is the animation. Any command that comes from server during that time is executed when tick changes, same tick every client. Clients send a reply for receiving each tick so server will know if they are lagging behind, halt game and resend until players match. Because games are done in small friend networks it is acceptable, alternative to store all data from during lagspike to server side can grow big. Or third alternative to completely send the whole game situation to new guy is a little stressful. New players can perhaps join midgame but should game pause then aswell... Small problem here is to animate movement during ticks, it may require a little interpolation or not, but i have math functions ready for all of that anyway.

Ideas for game itself (lots of things from Total Annihilation sound sweet):
- 2 cybernetic races evolved in 2 distant galaxies, annihilated their biologic creators and expanded in numerous star systems, collide to gain control over universe
- Air and ground forces, big starships
- Workers
- Buildings, these have a number of workers assigned to them that automatically move to the task
- Construction use materialization tech to create units from atoms using resources and energy
- Defensive and very offensive turrets designed for quick and creative annihilation for short to whole map wide range
- Shield generators for base defence using energy available
- Propably power lines

And because the tick system is all theoretical so far, my worst fear is tick system that would make delay unplayable. But i hope for best and maybe find some support here :P And if it works it would be unique first one of its kind multiplayer rts game that noone thought was possible to build.

Edit: First ship prototype made on my own modelling program:
http://i42.tinypic.com/2d83o8n.jpg

[User137]

Happy to say i got 3D textures supported in engine now:
(Seemless terrain tiling with simply adjusting texture Z coordinate)
http://i39.tinypic.com/2enruc9.jpg

Also planned on storyline a little... It is hard to think like a machine would, or what the circumstances would be. Anyway humans will survive, however artificial computer breaks free to form a colonization of its own. It doesn't need humans (yet) but also don't have a reason to exterminate them. For human perspective it is a unstoppable force that keeps expanding in galaxy. They have hard time to expand and develop on by themselves.

Few hundred years in the future of the incident, AI scouts other galaxy only to find about a big rival. With some logic 2 AI might plan to integrate into 1 being, however this AI did not think alike, or found that be unnecessary and complicated thing to do. Needless to say, scout was vaporized. It became a war to decide who the supreme being in the universe is. For humans are different case as they are no threat to balance of everything like another "unstoppable" AI with different logics. 10 years later, battle had expanded to huge proportions while real winner was not able to be decided. It is logical, too mathematical thinking that became obstacle for both.

Slight modifications for fleet were needed for organic, random, illogical, brutal humans were given chance to lead some starships into battle! And there we get to player part 8)

[User137]

So where the game is now...

Most interesting thing about making it has been world that wraps in X and Y directions :) There is so many things 1 has to take in to account, but glad it's all solved and done now (rectangular unit selection, rendering near borders and functions will work for AI pathing).

What's also done is particles and units that has so far just falling physics colliding and little bouncing from heightmapped terrain but at least it's some movement. I managed to make this all with integer numbers while still looking very smooth. Sine, cosine and arccos tables are precalculated and i will aim not to use floating point numbers where accuracy is needed in networking.

I made thousands of these falling 3D models on terrain while it didn't affect fps by much. Next up would be simple multiplayer demo once i find time for it...

[chronozphere]

Wow. that's really exciting. Seems like you have some great plans for this game. :) I honestly hope you can finish it.

[NecroDOME]

Hi User137. I see you have splatting working :) nice work!

I also noticed the repetitiveness of the texture. For your intereset: Tile-Based Texture Mapping http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter12.html

[JSoftware]

I am most definitely interested in this. Sound very intriguing

[User137]

Hi User137. I see you have splatting working :) nice work!

I also noticed the repetitiveness of the texture. For your intereset: Tile-Based Texture Mapping http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter12.html

Hey thanks! That doesn't seem too hard to implement on my current system, actually 3D texture might make it look even cooler.

In current system texture coordinate is linearly count from heightmap (not exactly same as terrain screen above) but yes tiling is still noticable, so that would need a different approach. Maybe separate texturemap along with heightmap.

[NecroDOME]

Yeah just give it a try and post the result :)

[User137]

Lol it was fast to make :p ..anyway i'm not yet happy enough about result because it looks worse than before. This is now caused by issue that each tiles are not seamless with themselves (and each other?), i think. But that's artistic problem..

http://i39.tinypic.com/2lw6b5y.jpg

[NecroDOME]

it looks like that yeah. Nice work though.

[arthurprs]

nice progress, keep us informed! 8)

[User137]

Added lighting to terrain along with little improved seamless but poor texture :D

Ok here is a new benchmark with 10000 units. CPU usage was showing at 0-2% (mostly 0) when i took this screenshot (i know the building model is bad...). Fps is on purpose limited to 32:
http://i44.tinypic.com/9u80ax.png

If you're interested in "how", the terrain is a vertex array (vertex,texture 3-dimensions,color) is 41x41 grid (rows of trianglestrips) while map itself is 1000x1000 in size (could be bigger later, but for now that would take unnecessary memory and time). It just updates only needed values where camera moves.

[Traveler]

Very interesting User137! Please do keep us informed :yes:

[WILL]

Hey a cool new RTS! :D

I'm gonna want to play this. Keep us posted indeed. The idea of controlling my own super-cool Robot army to take out other not-as-cool-but-pretty-darn-close-to-as-cool robot armies is rather appealing to me. :)

[User137]

Doh.. I always think too much, maybe more than should.. anyway i think it's impossible to create a storyline for game like this. Future wars are not held on planet surface, it doesn't make a difference to real outcome. Mobile big starship would be so much superior force... that is, unless the planet itself is turned in to a big weapon that can reflect long range attacks and bombing and fire back, and be able to start moving :o

Though i think it's critical to think of these things cause honestly i still don't have clear picture of what kind of objects are on the battlefield.

Ideas:
- Firstly i have long had this idea of modular structures, like cells form a living being, multiple parts would form a structure or capital ship. This needs an editor for it and if doing will be coming much later.
- Energy is needed as the only resource, open question is how to transfer it. Possibly visible light bursts or beams. Collected by small to big structures.
- Maybe unit that simply gathers mass (would be dynamic with modular structure) bigger and bigger until at any moment of building player wants to send it flying, stomping enemy base as it falls. Try stop such thing coming at you :D
- Walking mechs are very likely along with flying units, but something little more agile than those Imperial walkers known from Star Wars.
- Everything would be build with beams of matter and thinking of 3 things: Capital ships and small construction dedicated ships, both receiving their energy pulses as needed. And tall spike like structures which have some range to build all around it.
- New unit: BIG starship that is out of player control, build once and it moves to orbit firing at enemy bases. Long time to build, and vulnerable at it, but unless you have defence and counterattack, it's game over...
- Also i'm in favor of little customization in units. Player can decide if all things get more armor or attack power at cost of time, energy and mobility.

Finally, i think it's great idea for a game even for single-player if network game turns out not to work good enough. But i still don't see any reason it wouldn't work.

[jdarling]

Hey User137, this game sounds right up my alley from a play perspective. Can't wait to get my hands on it.

Now, from a storyline and technical perspective let's see if I can shed some light on things.

Story:
Sounds like you want to go post apocalyptic/end of species modified storyline based on two similar races (no problem here). Don't worry if your "story makes perfect sense" players WILL ACCEPT IT (just look at the games on the market today, heck even SC/WC have oddities). Make your story open-ended to allow play based closure (shuffles through books and links, ahh... here they are http://lostgarden.com/2009/03/what-is-your-game-design-style.html and http://www.gamasutra.com/view/feature/3957/games_of_2020__the_winners.php?page=5)

Technically Speaking:
Ok, you can't actually sync up 10'000's of units via TCP/IP (you already figured that out). Instead what you have to do is ONLY worry about what is going on on the players screen RIGHT NOW! If the player can see 100 new units then you send those 100 new units positions. As a unit changes position you send ONLY its updated position to the player. Remember you have to give the illusion of massive while keeping the reality of small viewing windows. Even when you zoom out to get a better view, switch display modes. You don't show 10,0000 individual units. Instead transmit that for quad x,y it has a weight of n. Then use this info to display the visual weight (who cares if visually its a bit off, its a satellite view).

Also, look base compression types. RLE, Dictionary, and many other types of compression theory come in useful. Of course you don't have to implement these types its just the idea behind them. EG: Dictionary Compressions utilizes a known set of conditions pre-recorded and then referenced during playback. If you took a similar approach in network communications you could send common party layouts via a single simple description that would be expanded on the client.

Transmit ONLY must know info on TCP/IP transmit non-important stuff over UDP. Take for example a moving unit on vector x,y/t (that's x pixels by y pixels over t time). Important details would be that it started moving and the position IT STOPS at, unimportant info would be the exact path it took to get there. After all, the people playing the game will never know if there is a small difference (in most cases they wouldn't know if there were a LARGE difference, remember they can only see a small part of the play field).

- Jeremy

[User137]

I think you missed my idea in first post :)

My plan is to make network game that have never been done before. Shows exactly same on every machine, on every map part and all times, while network traffic is even less than Starcraft. Who knows playable with old 56kbit modem for that 10000 units.

In example, i create a ground defence turret that shoots all nearby hostiles. There is only 1 packet total sent between server and clients which creates it, rest (shooting, deaths) is simulated only locally and synchronized in ticks. It's mainly ticks i'm worried about and having it look smooth.

[jdarling]

I understood what you said, and if it were that easy all game companies would be doing it (no offense) :). I'm suggesting you look at alternative ways of implementing your transmission protocols as you build to save yourself headaches.

Also, read up about TCP/IP and UDP as your statement is incorrect. Depending on the TOTAL amount of data you send out the pipe will decide how many packets are utilized. This isn't something you have control over, the OS and hardware control packet size limits and will automatically breakup anything over standard size. Of course, if you mean "your private packet" then yes, you can do it in a single bound :).

No matter what you do, you need to make sure that you apply a thought process to them being dropped and what happens when you do drop one. Even TCP/IP can loose/drop a packet from time to time (timeout of packet errors).

[User137]

I understood what you said, and if it were that easy all game companies would be doing it (no offense) :). I'm suggesting you look at alternative ways of implementing your transmission protocols as you build to save yourself headaches.
No, it is easier by miles but it's more vulnerable to cheating. As if you make fps in this way you'd know position of all players on the map and someone could just "toggle" hacks on and see players through walls. Also making fog-of-war with this kind of network would be bit pointless if someone manages to read map from memory. These things wouldn't be possible if server only transmitted data from visible areas. However in this game, above mentioned is not issue.

Also, the tick system may in theory cause a little sort of "lag" which doesn't fit any game.


Also, read up about TCP/IP and UDP as your statement is incorrect. Depending on the TOTAL amount of data you send out the pipe will decide how many packets are utilized. This isn't something you have control over, the OS and hardware control packet size limits and will automatically breakup anything over standard size. Of course, if you mean "your private packet" then yes, you can do it in a single bound :).

No matter what you do, you need to make sure that you apply a thought process to them being dropped and what happens when you do drop one. Even TCP/IP can loose/drop a packet from time to time (timeout of packet errors).
I don't understand what you mean.. My packets should be averaging to 10-30 bytes, very rarely higher but not above 2kb. If i'm aware, TCP packets can go up to over 60kb. I don't know if OS gathers packets to send them in 1 go, and if it does how my game would handle it, and yes timeout errors are very annoying.

Still.. if you caught on my idea you know that for example AI controlled players, all their units and structures are completely played on client side and never send or receive any of their data except game beginning.

[User137]

Before i let myself loose on network code which can mess up everything (because movement for now is not ticked), here is the first public Tech Demo of the game. Recent addition was ships that find a target and begin following it, randomly picking new targets so they will spread allover the map. Also optimization on particles which will not be created outside the view...

Controls: Arrow keys, both mouse buttons and mousewheel on main screen and minimap. Hold down right button to create ships.

Screenshot:
http://i39.tinypic.com/334nm8j.jpg

Demo:
http://uploading.com/files/3M55KK1A/TechDemo1.zip.html
or (slightly newer)
http://www.mediafire.com/?sharekey=f25edf19ab018697bda4076e811714c8e04e75f6 e8ebb871

[Wizard]

I downloaded your demo and it looks good so far :) One thing I realized is that when you spawn over 900 ships on one or more areas the fps dropps and movement becomes jerky... mabe it's just me who would spawn 1000 ships... :P

[arthurprs]

i don't know how to download from uploading.com :(

can you upload the file to another host, mediafire.com for example ?

thanks ;D

[User137]

The link comes in uploading.com when you look the page down.. there should be little countdown 80 seconds or something, but yeah i wasn't aware of alternatives.
On Mediafire now then:
http://www.mediafire.com/?sharekey=f25edf19ab018697bda4076e811714c8e04e75f6 e8ebb871

This is only slightly modified version xx( There is now 7 active players and 1 inactive which will just drop ships to ground. Chasing and flying is little fine tuned. I'd maybe like to add shadows myself...

"Wizard: One thing I realized is that when you spawn over 900 ships on one or more areas the fps dropps and movement becomes jerky..."

Yeah happens, in real game the ships should be much more scattered through the play area and in the second link demo they do scatter more unless you create them in 1 place.

Edit: maybe it's just my machine, my fps stays at 31 with 2000 units in same view but i can hear the cpu fan wakes up :p 3000 units and it was pushing at maximum of first processor unit (this isn't using multicore at least yet, it comes to rendering anyway i think which can't be optimized that way?) but fps still 30. Move view elsewhere and it relax...

[Wizard]

Maybe build something into the game that limits the amount of ships that can be spawned in one specific area? Anyway, as you say it probably won't be a issue in real game play. :)

[chronozphere]

This is looking promising. ;)

I really like the "wrapped" map and the way you can move your camera (It's a big quick though). Could you let the camera zoom out a little bit more?

I have a couple of other questions:

> Which API's / libraries will you be using for graphics/sound/network etc?
> Where did you get, or how did you make those terrain textures? 8)
> Is there anyway to select units and make them move in to a certain location yet (might have missed this)?
> Any chance you will release the sources in the future?

This is an awesome project. I will keep an eye on this one. ;)

[User137]

I have a couple of other questions:
> Which API's / libraries will you be using for graphics/sound/network etc?
Graphics use Next3D which is my own wrapper made on dglOpengl. Network uses WSockets and no sounds yet. If there is musics it'd be TMediaplayer but effects propably OpenAL which i've also made a small wrapper in the past. I heard this demo currently works well in Wine under Linux so i can try keep it that way.

> Where did you get, or how did you make those terrain textures? 8)
I can show you :)
http://i40.tinypic.com/10fomjl.png
I came up with making a simple editor that takes random small parts from larger texture as seen in first slot. The parts are drawn so that they wrap from 1 side to other to be seamless. I clipped and clipped to make several large source textures with light and dark grass and use those... result is very rough tough. That is 1 reason i stick with Delphi, it's so fast to make all these small editors for all occasions, they have really piled by now. BUT it would be possible to improve this editor by making it draw sharper real alpha channeled forms of grass and other parts, if needed. Or possibly soft "clone painting".

> Is there anyway to select units and make them move in to a certain
> location yet (might have missed this)?
Not for now, there is vague plans for more sophisticated UI for unit groups. But i may aswell do them after basic networking works. This game can go far with full automation :) Units move in so wide area and in such speeds it would not be fun to only select by hand.

> Any chance you will release the sources in the future?
It's possible but if i was to make fog of war kind of thing to game, releasing source would basically give everyone cheat in their hands. (So maybe i can forget fov altogether...)

Edit: > Could you let the camera zoom out a little bit more?
This affects 2 things: I would need to increase vertex buffer and it would mean more very careful math which affects a few places, and it would slow rendering a tiny bit. Secondly terrain becomes more "pixelized" with linear filtering. I would need to enable mipmapping but such isn't implemented in dglOpengl header so it would mean a little more work...
(hmm.. now that i think about it, mipmapping is mainly about reducing texture size in half, which might be doable manually and easily)

[arthurprs]

I have tested it, works fine on my E7200 + GMA3100

it looks really good! ;)

[User137]

Shadows added, and i can guarantee it hardly effects performance at all 8) Gives new life to the whole thing...and yes it looks much better live. (they cover all objects that are on ground)
http://i43.tinypic.com/205yy42.jpg

Maybe i could create a small vid to youtube...

Edit: Also made a small test with different timer and without vsync, fps was at 70 with 10000 units. But i don't like stressing cpu like that ;) Save energy, save the planet lol

[User137]

There's a video now, enjoy ;) .. though youtube reduced quality of it...
http://www.youtube.com/watch?v=kzDrqhHbwKw

[chronozphere]

Looking awesome (wish it was my project haha. :yes: :D )

One thing though: I think the whole map looks a bit dark. You could do awesome things with lighting. Maybe you could make a sun shining from the north and add some fog. Using a few parameters you could easily change the entire atmosphere of the game. :)

Good luck. Hope to see more!

[WILL]

Very nice looking great so far. :)

[pjpdev]

Looks great... Keep up the good work. ;)

[Reiter]

I am impressed by the examples. However about the netcode I am also unsure as Jdarling already mentioned:


if it were that easy all game companies would be doing it

Companies like Blizzard Entertainment (SC, WC, ...) which always had a strong focus on smooth and clean network code would probably have introduced such a technique. These features are also one reason for their titles success at all. - However, I hope you prove me wrong :)!

[User137]

Major games want quick reaction times, this kind of network code may not provide that if you understand how synchronized ticks would work. It may be roughly usable in game like starcraft (IF it didn't have fov but it does so it is not usable) but take fps, diablo or world of warcraft like game this would not work.

And for another downside, if you disconnect for some reason you have to transfer image of the whole game situation. To do that you have to be quick enough for catching up (caching the ticks that pass while starting up) with the normal packets or stop the whole world while doing that.

As for current status:
- There is now 2000 polygon mothership class ship with "plasma" animated hull, (not completely happy with model yet) but i got wild ideas for big lightning based attacks for it :p And being as logical defence mechanism also.
- Matter-beam pylons are modelled and put in game and i'm happy enough for those to be final.
- Water is seamless with map but looks bad depending on map size.

[User137]

The mothership first prototype (fully animated, don't know if i should use that high poly version..):
http://i39.tinypic.com/ay4zt5.jpg

- Mothership consists of 2 layers of texture-animated vertex arrays + particles
(Object renderer is dynamic enough to allow anykind of effects and object mixing)
- Minimap texture now more accurately reflects the terrain and follows mouse clicks
- Water seamless and properly scaling
- Network code has been in the "mind process" for long time and is starting to prove simpler than i first thought, though some remain unclear until tested. I can likely use current physics completely as is. Thought about joining while game is in process, it should be possible without stopping world.. needs queue that is just a little complicated. Basically i can first send all static data like terrain and then start queuing and send everything dynamic.

[NecroDOME]

Looks nice with the shadow!

[chronozphere]

wow.. It looks really... eh... alien. :D :yes:

Great work!

[User137]

(First apologies for long delay which will still vaguely continue. If you want to help with project in any way i have msn available.)

Hmm.. you may scrap the idea of that mothership, i have :-[ Maybe much different kind will be in though later.

I've had much time to think things and i still don't doubt the possibility to do this in network realtime. This is not like starcraft, the system is entirely different.

I will rethink the terrain completely in light of new idea that has risen... This fight will not be held on planet surface, but above it. I want camera that is completely free to zoom, rotate and show beautiful atmospheric imagery, stars and sunlight! I realized that it is very necessary to control the big army, creating HUD for unit groups across the planet. It's all hectic amount of work incoming but i want game that i like to play, really want to play.

Mechanic race travels the stars with big colony ships, planting the "seed" that is structure enough for player to establish a mining colony and in the end gather enough resources to dominate and secure the planet. It will be the basis to build new colony ships and galactic fighters to support in the big battles which this game does not cover. However i might make a galaxy little similar to Spore in which players can join each planet at the time and continue the conflict (however i don't think i will make any central server or such). Take it as single/2/4.. player campaign to take over the galaxy.

So.. big problem will be rendering the planet itself which can also be a gas giant. In my mind of mining colony i see starbase like structures, matter beams sweeping the surface, energy stores and so forth... with quite sophisticated user interface.

What i have done though is testing throughly my TCP/IP component to see how i will handle sending and receiving data, that is now very clear. There are limits if i send too much packets too fast the socket buffer will get filled and destroy data without telling me anything. Each client had unique buffer which are handled smoothly even if both send data simultaneously in between each other. I will propably do first TCP test before the terrain change.

[User137]

Had this funny idea again on moving from Delphi to world of open source and Free Pascal... and this time it became real!
http://i49.tinypic.com/2v7ugxk.jpg

My graphics and game libraries are in biggest parts converted to work with Lazarus and Free Pascal so i don't ever have to worry about licensing stuff anymore. Besides the UI is extremely good, in some ways better than Delphi. Biggest problems were with PNG and JPG alpha channeled loading functions but after little reading they are now propably faster and better than before.

Simplicity for adding textures to project still remains:

tex.AddTexture('mypng','textures\image.png',true); // transparency enabled
tex.AddTexture('mybmp','textures\image2.bmp');

Edit: Network component's propably going to be Synapse.

[Reiter]

Had this funny idea again on moving from Delphi to world of open source and Free Pascal... and this time it became real!

Whenever I see a chance to substitute some software by an open alternative without losing all the benefits I would do it. Good decision :)!

[User137]

Conversion is now 100% complete and project on Lazarus runs in exactly same visual and control quality and 0% cpu usage aswell as on Delphi.

I actually had a lot of problems when i was testing basic network stuff on my Delphi's component. WSockets was dated 1997 anyway... so Synapse has much better support and should work much more reliably. I wrote a high level wrapper unit to it automatically creating threads for sockets, and giving out onData and onEvent's for main program making it very easy to use. Same class works for TCP and UDP so if i wanted to use UDP all of the sudden all i need to do is call a different constructor and everything auto-magically works 8)

Well obvious difference is that UDP server only listens to 1 socket and should only ever send something after client asks for it. You CAN store clients address for UDP server and make a list to use it same way as TCP server but i don't know if that's proper way to go... might be cool to do though.

Edit: Gotta have proof ofc! http://i45.tinypic.com/1zbfc51.jpg
And Free Pascal .exe size? I can squeeze that to 726kb with strip+upx.

[chronozphere]

Good job on the port! Snapshot looks cewl too. :)

I'd also like to get into lazarus, because I have a Win7/Ubuntu dual boot and I want to develop for linux too. I did encounter quite some problems while installing FPC and lazarus on Ubuntu. At the moment, there are still problems (e.g I cannot debug my apps on linux). :(

Do you intend to compile your code on other platforms?

[paul_nicholls]

Good job on the port! Snapshot looks cewl too. :)

I'd also like to get into lazarus, because I have a Win7/Ubuntu dual boot and I want to develop for linux too. I did encounter quite some problems while installing FPC and lazarus on Ubuntu. At the moment, there are still problems (e.g I cannot debug my apps on linux). :(

Do you intend to compile your code on other platforms?


Hi chronozphere, if you want to debug under linux you have to install the dgb linux package...

I had to do this under Ubuntu.

Google should find what you want - google for "apt-get" and "gdb" I guess LOL

cheers,
Paul

[User137]

Do you intend to compile your code on other platforms?
I only have WinXP at the moment, maybe switching to later, possibly even Ubuntu dualboot that i had once before. So thing is i can't test it on other OS's :) Freepascal compiler however warns if code is not multiplatform compatible so there should be no issues.

[User137]

Maybe it was easier to understand the whole network idea if i explain it this way:
The whole system is based on turn based game. Whenever player does something he does it through server which passes information to other players that will put actions on hold for next turn. Now imagine a turn based game that automatically switches turn for all players per 30 seconds by a command that comes from server to all clients same time. Up till now everything's synchronized and network traffic is minimal because here server doesn't need to send info on game events themselves.

Finally, reduce time between each turns to 100ms or highest ping connected to server. At this point, time between turns is so small that amount of actions clients store on hold are close to 0.

If i wanted to expand this idea into mmo, game would need to be put in zones. Player entering zone would download a full current status of it first and immediately join the communication that is going between players there.

[phibermon]

Hi User137, I've been developing a game for a year now after many previous years of learning about game engine design and experimentation in a multitude of areas.

Trying to keep all your gamestates identical across all clients according to the lowest ping is a bad move for anything other than the slowest paced turn based games. Pings could fluctuate, bandwidth limitations could mean that a given client has not updated before the next 'turn' etc.

At any point in time, the server and all the clients should be allowed to have a different state that's kept as close as possible to the server state. Tie breaker situations (who shot who first for example) are decided upon by the server according to it's internal gamestate.

The network library I designed for my game, the associated message manager and net-synchronized classes are now complete (add me on msn (phibermon att hotmail c o m) if you want to discuss anything in detail).

The setup allows for clients to connect to a running game at any point by keeping all the information that needs to be shared between clients and server (entity positions, any deformed level geometry etc) in a container that assigns each peice of data an ID.

when a client connects, the server communicates the gamestate by pushing all relevant ID's onto a queue which begins sending the data to the client. For each ID, the server gets the size of the data, sends it over along with the ID and a timestamp and then sends the data itself.

This allows for the gamestate to be reconstructed on the client side using the same ID's.

As the game is progressing for the other clients, messages are fired back and forth between the server as normal.

Any message that makes a change to the server gamestate is added onto the message queues for all other clients (if relevant), including the one that's currently connecting.

The queues are priority queues so critical things such as position can be bumped up and less critical things such as say, money in the bank can be sent when there's time.

Message invalidation comes into play at this stage, any ID that's already on the queue can be removed as it's not already sent, this helps out laggy clients struggling to keep up. I've optimized this process using a hash table so the entire queue doesn't need to be scanned each time a message is pushed.

Essentially everyones pumping messages around on queues, just the connecting player has to play catchup with it's queue until it's in sync, it's determined to be in sync when a predefined offset between the current messages being pumped becomes small enough to be concidered realtime. For my game FPS grade performance is not required so I concider the client in sync if the messages it's handling are less than 400ms old.

If the offset steadily increases, the client can assume that the transfer rate is not enough to sustain a realtime connection to that gamestate and disconnect with a message to that effect.

As stated, message invalidation and synchronization problems (that arise from different packet turn-around times of the various clients) are all sorted out on the server end (Except for some basic invalidation on the client when appropriate), the server is god, it's gamestate gets the final word. However this part of game net-code is challanging, dealing with temporal offsets between clients can be done in a multitude of ways, the quake 3 source code was released ages ago and I highly reccomend reading thru that.

Remember : The server is god. No two players have exactly the same gamestate at any moment in time, only an approximation based upon the last peice of information recieved. The tie breaker problems you've attempted to avoid must be handled for a game that works well over the internet with many clients.

I'm not sure if this is the best approach but it works well for me.

Sorry if this isn't too clear, I got no sleep last night due to the apparently newly wedded couple next door.