Comments - cucu

Well, he *did* conquer the Milky Way. The terraformed planets of humans were destroyed, bacause they cannot use them, but other planets suitable for their chemistry are pretty much used since then.

Nice music, nice mood, nice game!

******* cool concept! Tetropolis FTW!!!

Zandagort is just partly a wargame. The input-output relations shown above require hard strategic decisions even in the economy.

Thanks for the answer. Just one minor note: by spying I meant getting any kind of info that only another player can see. Like the health point or ammo of an enemy unit. I suppose I cannot create accounts to see everything (right?), so if the client does receive everything (and filters it after that), I can see more than I should.

Btw if you check the game's blog ( Heroesandgenerals.com ) I'm not the only one who has concerns about this issue.

"For instance if I needed to get hold of all the Assault Teams that a user has control over, I would ask the server for this and it figures out which ones I need. This is neat and simple for the client side programming, but on the other hand it uses the servers processing power to do this." "Instead all data in the database is sent to the client and we leave it to the client to do the data handling."

In my reading this means:
1. The server sends all the units and the client selects those I can control. So if I can hack the client (or just the client-server) communication, I can control units I should not be able to.
2. The server sends all info and the client filters those I might see (cf fog of war, spying). So if I can hack the client, I can see everything.

This applies to static data as well (static map vs fog of war).

Lagging: the homepage says "The Action game is a modern multiplayer First Person Shooter game". If you have a tank on a field and I have another one there, the position of the two tanks must be computed on the server (otherwise I just send manipulated data about the position of my tank) and be sent to both clients all the time. Without clientside forecasting this will lag.

If all data like that is handled on the server, then of course you are right. But the article suggests otherwise: "In order to achieve that we have almost no server operations (only login). Instead all data in the database is sent to the client and we leave it to the client to do the data handling."

Although I don't know much about the details, here's a piece of advice. The problem with giving out data manipulation tasks to the client is cheating. If the client is anything more than a GUI (terminal) some players will find a way to hack it which is not so hard as they can observe the communication between the client running on their computer and the server. And in multiplayer and mmo games, it's not really acceptable.

If on the other hand all the operations are done on the server, the game can be only hacked if the server is hacked. And that is way more difficult (and serious as well). There are of course two problems with this:
- lagging: to counter this the client should forecast what's going to happen and synchronize these forecasts with the server (where the real in-game reality takes place)
- performance issues: the core program needs optimization. As I've said I don't know much about this project, so just one experience I had with my project: MySQL MEMORY tables are a great way to enhance performance as I/O is one of the narrowest bottlenecks. As for joins: use the appropriate indices, this will solve 90% of your problems.

Good luck with Heroes & Generals! :-)

The graphics of the game will be completely replaced with hand-drawn and painted images. This will be a long process (lasting about a year), but elements of the new graphics will be publish from time to time.