Quote:
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?
|
That would be very possible. The give/take would be the processing requirements being higher at the host end but for a pbem game that isnt supposed to matter. The solo players might hate it but they are low on the considerations anyway. Might even possible to have a level of checking avialable so that solo or hot-seat players dont have to wait for it.
Another nice advantage is that if everything is stored by commands instead of interface/results, it might open the door for scripting which would open the door for programmed bots which would open the door for player-programmed AIs. But lets not go there today.
Quote:
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.
|
I definately see the "web based game server" thinking showing there. In many ways that duplicates requests Ive made. Seperating host from client, and especially the IPserver, would go far toward good management for hosts.
I did understand the response I got about them not wanting to update multiple programs. Just the game and demo have floated quite a ways apart from each other.