Forums

Exactly, same mechanism in terms of the code. I'm not sure to what extent was the Mauryan ram Easter egg intentional though.

So it's like the updated version of the Mauryan ram Easter egg.

I don't think it's necessary to remove this unit because it is not particularly OP and it's nice to have an Easter egg. Han capturing a Persian is a rather rare situation 

Nice background bro! Viva Immorality!

Scythians maybe, at least the Saka seem to use something similar, although maybe without the dragon/wolf head: https://en.wikipedia.org/wiki/Orlat_plaques Although the Dacians clearly should have them, in the future.

I don't know if there still really is a treasury committee, or who's a member of it, but in general the report sounds good and it's hard to argue with money coming in to the projet rather than going out

I won't argue on what is the definition of "cheating", but I would like to leave a comment on the "real solution" proposed. Having a system with a single host computing everything and sending out the data would be a great simplification of the code and indeed solve some of the cheating issues. It definitely would make our work as programmers a lot easier (no more cross platform out of sync, no more deserialization bugs etc.). However, there is one particular good reason why we (and every similar game too) go through all the hassle of a lockstep networking model (i.e. simultaneous computation of the simState in all the clients): A single host computation system will not work practically. The problem lies into the fact that the bandwidth of an internet connection is limited. (An old article on the topic is here: https://www.gamedeveloper.com/programming/1500-archers-on-a-28-8-network-programming-in-age-of-empires-and-beyond) In a single host computation system, the host will have to send (a large portion of) the gamestate to every client multiple times per second. The data of the gamestate is required to show the player what (s)he is supposed to see (units in its vision). This needs to be updated with a good frequency so that the player can respond accordingly. Currently we have turns of 200ms, so that means a frequency of 5 per second (in the past in 0 A.D. we used turns of 500ms, which wasn't ideal, but sure one can tweak a bit here). A gamestate can have a size of several MB's. I just tested: a new game on the acropolis map is already 500kB, so having a big map with 8 players in late game will be like 5MB. This means we need to be sending 25MB to every client per second. With 8 players and some observers, this will easily be a few hundred MB per second. Even on 1Gbit/s fiber class connections you won't be able to do this (1Gbit/s usually gives just over 100 MB/s). This issue prevents any MP game from running stably, so it really is not a practical solution. Even if one would have sufficient bandwidth, there is also the issue of latency. A message send over the internet takes time to arrive at the other end. Currently one a player can give a command based directly on the current turn in the simstate. The command then has to travel to the host and then back to all clients for it to be executed. So basically one needs to send stuff twice over the internet. If one has a single host computation system, the player sending a command is actually already lagging behind (since the simstate has been send from the host to him). Then secondly, the player gives a command, which is send to the host, and lastly the host sends a new simstate to the client. So in total 3 times things have been send over the internet. Meaning that the latency of commands is increased by 50% (and probably more since the package sizes have increased too). Also a single host computation system is filling one hole with another: since the host will now have full control of the simstate, and no one is controlling it, (s)he can change it. So such a system makes it possible to cheat the simstate for the host. Creating an (imo) even bigger problem than the information leak problem in a lockstep networking model. Surely one can come up with "solutions" like dedicated (trusted) servers, but then one runs into the question: who will maintain and pay for those servers? In all it boils down to the quote, quoted above too: While technically it certainly is possible to design a system without information leaks, such a system is nonviable to produce a playable game.