Quote:
Quote:
(In practice, there would be several orders and so on, but the principle is the same.)
|
I'm not sure that going from a PbEM type game to a different style of gaming is a "fix". 
|
The game could be identical in every single way from the player's perspective. The only difference is that all commands are executed by the server, instead of the client. So the client simply sends a list of commands he wants executed (Move commander A to province 2, cast spell X with commander B, alchemize 4 astral to water gems, etc.) and the server would check the orders and execute them (can A reach 2, are the gems available for both the spell X and the alchemy? Does command B know that spell? Does he have the correct paths?). See? No difference from the players perspective. The only difference is that cheat is impossible. If you don't believe, try me! Tell me how you would cheat with the above setup?
Quote:
Yes that would allow for MANY things to be fixed if all actions were interactive at the server. Of course even more would be fixed if you just went all the way to an Online world environment. Of course then you have to shift attention from hex editing to packet editing. Everything has its pros and cons.
|
Everything IS interaction with the server TODAY --- that's why there is only one fatherland file. I'm not talking Online play.There are no cons, actually --- except that the game would need extensive refactoring, which is a showstopper for dom2.
If I were to make such a game, I would make at least these separate components:
- libdom2rules --- the actual game engine, which knows about gems, spell, movements and so on.
- dom2processor --- Uses libdomrules to processes turn files into new turn data files, ready to be sent to the client
- client --- Can represent the client
- ipserver --- Accepts files over IP, checks passwords and so on.
- mailsserver --- The same over SMTP or MTA or whatever.
The work is about the same, but using a software stack instead of one gigantic program makes every much more flexible.