Well… networking. This will be a very interesting topic. Within the next two weeks we’ll release 0.7 and then Felix and I will dig deeply into network coding. And we’ve got huge plans

We already thought a lot about networking – the problems you mentioned are just a very tiny tip of an incredibly huge iceberg. And far the most problems will still be hidden beneath the surface of our coding knowledge
For example the current damage system is much too complicated. It’s simply impossible to send this amount of data in real-time over the Internet.
It will be really challenging to create an engine which is capable of powering M.A.R.S. in network mode. We will make this a project in the summer term in our university.

Look around: there is no game like M.A.R.S. out there with network support: On the first glance this may sound ridiculous ( ) but it’s true. Either the game is not really real-time-dependent (like most on-line role playing games, like World of Warcraft for example – a delay of one second is hardly noticeable) with no collision detection and so on, or the game has very few information to be transmitted (like first-person-shooters – just the position, aim and whether the player is shooting). It will be hardly possible to synchronize 20.000 randomly spawned particles.

But we’ve got time, we want to research, and finally we will succeed
Either by having a great game, powered by an awesome new Open-Source Online Library, or by clearly knowing the limitations of nowadays Internet!

But anyway, having config files for the weapons is a good idea…

Greetings,
Simon

How far from MARS do you consider a game like Teeworlds ? It’s fast and there is a lot of shooting.

Yes, there is a lot of shooting and it’s very fast, but not half as “random” as M.A.R.S. is. Teeworlds is certainly using preconfigured damage outputs for each weapon, independend from the amount of spawned particles. We will have to rework our damage model in this direction.
With this change, data size indeed might be no problem anymore.

About random particles: if you use the same seed on both client and server side, things should be consistent. Maybe I didn’t grasp the full issue ?

Using the same seed may be a step in the right direction, but there is so much “randomness” ingame, that we can’t ensure the sequence of random numbers will evoke the same effects on each client.

The biggest concern I see so far are collisions with space objects (both being pushed by ammos and by other ships) … that will probably indeed prove challenging.
If the state of the battlefield is predicted and corrected once the relevant data are received, it could be frustrating.

You are totally right, it will be hard to synchronize each running instance and at the same time keep it fair-looking for every single client. We are thinking a lot of such things and hopefully will find a solution eventually.

On the other hand, I think cheat-avoidance-oriented architectures are sand castles, so it could make things easier if the client has a certain degree of liberty. … I don’t know, maybe progressive correction ?

Progressive correction won’t be as easy as you might think. Not said to much: we will try to use an uncommon architecture.