Thank you Stormbinder!

[Gandalf Parker]

Sure there is. As Esben (I think) pointed out, a server-side audit of the incoming 2h file can entirely eliminate the possibility of cheating by editing the .2h or .trn file. However, I agree that if Norfleet was regularly getting his hands on the ftherlnd file (Esben doubts this and so do I) then there's likely no practical fix.

I wouldnt call that a vulnerabilty. Only more checks. But thats all semantics. Basically thats the kindof accounting that is already in place. It would have forced him to spend his illicit gains every turn or have it caught by the cheat-check routine which apparently he did. Of course further checks can be put in (I think I mentioned that) but Im not sure if the processing time and harddrive space would a trade-off that will happen quietly. And that still wouldnt stop hex editing.

[Esben Mose Hansen]

And that still wouldn't stop hex editing.

Sigh. Yes it would. It's like my server pages: You are told that no more games can be started. Of course, you could break out you hex editor and send in a request to have a new game made anyway. What happens then is that the server rechecks that the game creation is allowed, and stops the request. This is no different than casting a summoning spell: Done right, the client would sent a request to the server that caster A cast spell B. The server would then check that the conditions are met, subtract the used gems, and send the result back. (In practice, there would be several orders and so on, but the principle is the same.) '

I repeat: Given a trusted server, cheating can be limited to "better clients". If no trusted server exist, cheating is possible. Try looking in the KDE forums for KBattleship. Battleship --- such a simple game. But there is no way to make it cheat-free without a third part acting the part of the trusted server. Try me, if you want

And yes, I'm aware that this would require such a major redesign that it would not be feasible for Dom 2. But I, for one, are secretly wishing for a Dom3, and for that, it might be done right <tm>

[Gandalf Parker]

Sigh. This is no different than casting a summoning spell: Done right, the client would sent a request to the server that caster A cast spell B. The server would then check that the conditions are met, subtract the used gems, and send the result back. (In practice, there would be several orders and so on, but the principle is the same.) '

I repeat: Given a trusted server, cheating can be limited to "better clients". If no trusted server exist, cheating is possible. Try looking in the KDE forums for KBattleship. Battleship --- such a simple game. But there is no way to make it cheat-free without a third part acting the part of the trusted server. Try me, if you want

And yes, I'm aware that this would require such a major redesign that it would not be feasible for Dom 2. But I, for one, are secretly wishing for a Dom3, and for that, it might be done right <tm>

Im not sure that going from a PbEM type game to a different style of gaming is a "fix".

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.

[Graeme Dice]

Im not sure that going from a PbEM type game to a different style of gaming is a "fix".

I'm not sure what you are saying here. There's no reason to quit having the game as a PBEM one to implement what he's described. In fact, I'm kind of surprised that it wasn't done that way in the first place.

[Leif_-]

Im not sure that going from a PbEM type game to a different style of gaming is a "fix".

I don't think he's suggesting that the server checks everything inter-actively - just that all the rule verification is done by the server, and not by the clients.

The game would still be the same, but you would get rid of hex-edit cheating - as all the information in the turn files would be just player orders that the server would examine for legality (as opposed to just checking for validity and correctness.)

[Gandalf Parker]

I don't think he's suggesting that the server checks everything inter-actively - just that all the rule verification is done by the server, and not by the clients.

The game would still be the same, but you would get rid of hex-edit cheating - as all the information in the turn files would be just player orders that the server would examine for legality (as opposed to just checking for validity and correctness.)

But it does that now. It does quite abit of math to decide if the turn that the player turned in can be legally accomplished. I know because I have been able to bump up against such checks frequently. It takes alot of time and effort to figure out what changes you can make in a 2h file that wont be caught when the host runs.

More checks could be added (and it looks like they will be) but there is ALOT of variation in this game as to how anything can be accomplished so such checks are hard to implement without a rash of (rarely friendly and understanding) Posts by players that they were declared to be a cheater when they werent. Of course any checks will make it even more time consuming to hunt for the way around it so it will serve some purpose. But as a security person my view is that nothing ever stops anything. The best effort is to only make it as hard as possible for as many as possible for as long as possible.

[Esben Mose Hansen]

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?

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.

[Arryn]

No offense intended to the IW folks, but the thing you must understand, Esben, is that IW does not have (AFAIK) any professional software engineers. Dom 2 has been created in the "spare" time of a few folks whose day jobs are something other than being programmers, game architects, graphics designers, network engineers, et cetera. It's actually remarkable that they've been able to do as well as they have given their relative lack of in-depth knowledge of professional computer game design (as compared to almost all other game dev shops) or even the inner workings of the coding tools they're using. I think you may be expecting too much from them, however nice your suggestions sound (at least they sound great to me). Perhaps if they become successful enough to consider giving up their day jobs, or hiring outside 'experts', then we might see the sort of polished product we'd love to have.

IW reminds me a lot of Paradox, who also began with 2 coders. After several years of popular products, they've grown to the point of recently soliciting for additional programmers. (Hopefully they've hired someone who actually has a clue on how to code a competent AI, and even more importantly, gotten a decent internal QA manager.) IW appears, to me, to be sort of following in the footsteps of Paradox. More or less. The largest difference is that I'm sure Strategy First has more money to throw at Paradox than Shrapnel has to throw at IW, since SF is a by far bigger publisher (nor better, just bigger). With more money, you can try to do more (or more difficult) things.

[Gandalf Parker]

No offense intended to the IW folks, but the thing you must understand, Esben, is that IW does not have (AFAIK) any professional software engineers. Dom 2 has been created in the "spare" time of a few folks whose day jobs are something other than being programmers, game architects, graphics designers, network engineers, et cetera.

Thank you for posting that.

Actually IW is 2 guys and I think only Johan K calls himself a programmer. Kristoffer O is a teacher and seems to be the source of the thematic research, graphics, etc.

[Arryn]

You're quite welcome, Gandalf.

Despite my saying that JK is not a "professional" programmer, he's apparently a better one than many of the CS-degreed migrant laborers (what I call the Indian and Chinese H-1Bs) I've had the dubious "pleasure" to work with. And, if one considers the term "professional" to mean that he gets paid for what he does, then JK is, indeed, a professional. Coding not being his day job notwithstanding.

Kudos to JK and KO.

Of course, my admiration for what they've done doesn't stop me from wishing IW had a professional GUI coder.