MMORTS game engine

I know that. But how is the game cycle management and control under players organized in MMORTS? MMORTS and RTS are completely different in code logic.

In my experience, a lot of constants are made when doing a smaller multiplayer RTS as opposed to a MMORTS

I will assume you are referring to a persistent universe.

Many questions have to be asked such as:

1) What happens while the player is offline?
2) What is the server responsible for?
3) What is the client responsible for?

For my explanations, I will assume that the player''s units remain in the game while the player is offline (such as Mankind and other MMORTS games).

Special care has to be taken to look at how the server application runs. For example, many conventional commands that a player can give to a unit can be extremely taxing to the server. One such command is Patrol. Telling a unit to patrol means that even when the player is offline, the unit will still continue on the patrol. This means that the server has to maintain that unit''s location and patrol route and the unit''s reaction to anything within its range. This isn''t a problem if it is one or two units per player but if you have dozens to hundreds of units per player on patrol routes... can you say Bringing a Server to its knees???

Another thing that becomes an issue is FOW (fog of war). Calculating the viewing range of each unit is easily done on the clients but what about when the player is logged off???

A lot of considerations have to be made. Do you just leave those features out?

Anyway, as for any examples of a game loop... the above post is actually right. It runs just like any other RTS game. Except you do not do any graphics work on the server. Instead, you do all your validation on the server. You do collision detection and such on the client.

Its really a deep question..... :/

Enoch Dagor

Is it just me or have I seen this topic earlier this week (with a lot more replies so this can''t be the topic)

Maybe it''s just deja-vu but else it''s spam-posting

BTW: I''m not trying to flame this topic... Just wanted to say that if I''m right and you posted this question multiple times, please don''t... if everyone does that the biggest spammer will win the game. If I''m mistaken: sorry!

I have made a posting on the Game Programming forum. But that posting is concerned with overall game logic. And this one is about the logic of the networking code.

Actually, the RTS game loop is quite clear for me. There''s no problem about it. I need info on massive multithreaded (posix threads are used) game apps. How is communication organized? The problem is about reducing huge traffic... Network code for massive RTS. I don''t need tutorials. I am experienced in coding net apps.

Im not sure this will help you much, but there is a book in development about RTS by a dude that wrote another book on Multiplayer Game Programmin (heavy focus on MMORPG - some multithreading and stuff included). I assume that the section on multiplayer in his new book will be quite good, but Im not sure he will take a mmog approach (maby only peer-to-peer).

http://www.lostlogic.com/book2.shtml
----------------------
Anyway, it seems MMORTS are much more dificult to pull off than MMORPG, basically because you handle multiple units in the MMORTS-universe. When another player plans his strategies, he considers his enemies much more than one would do in a MMORPG, for instance.

What happens then when his enemy suddenly disappears for an extended period of time?

If his units are left in the gameworld, the battle will be played without him overseeing things. This would requier heavy AI to be implemented so that units would be virtually independent once orders were issued.

If his units just disappear, then other players planning would be for nothing - very frustrating.

It seems that Shadowbane have succeeded in making a MMORTS, but thats only because thay have made it in large extent a RPG, and the players dont handle multiple inanimate units - they ARE the units, and can issue commands to eachother as if it was a strategygame. Pretty cool, actually.

Well, it would be interesting to know what approach your game will take, klio. Hope you give us some updates