fischkopf

Hubert Yes indeed the key must be hidden in the save file. But consider that the smallest possible save game is what, about 30k? (It's been a while since I played PBEM). So in the worst case you're hiding 4 bytes in 30,000. That's a needle in a haystack. Of course you don't just want to throw it in there, because someone with a hex editor will eventually find it. (Note that maybe 5% of your gamers know how or would care to learn how to use a hex editor, so we're doing ok even as is). But to cut that 5% down to 0.5%, this is what I would do: Save the 4-byte game id in 4 seperate 1-byte chunks. These should be in different portions of the file. For a quick and easy first implementatation I would try out this structure: -generate and store a random offset (say 0 to 100 bytes) -store garbage random values (make sure they're random though) up to the determined offset -store the byte of the id -store remaining garbage randoms Then do the same for the other 3 pieces of the code. The use of random numbers makes it a lot harder for the cracker to isolate what's changed file to file. (Personally, my first attempt at cracking would involve comparing differences between two seperate but identical-in-setup first turns. e.g. create two Fall Weiss pbem games and compare them to see the differences. With noise in the file it's a lot harder to find what you're looking for). The random offset of the byte into the garbage zone just makes it harder to find out what's happening. The other thing that would make this much stronger would be the inclusion of CRC (Cyclic Redudancy Check). The file stores the CRC value, and if the file has been modified the CRC won't match the CRC stored and you can detect tampering/corrupt file. This is core comp sci. Again there are ways around this but now you're moving into elite and dedicated hacker territory. It's not easy recreating CRC values! CRC checking code is extremely samll and freely available. And actually there's one another way to protect it. Take advantage of the fact that there two people playing the game. The only time a player should be receiving a key that doesn't show up in his list is if it's turn 1, or if he's playing the game on a different computer. So if it's not turn 1, and if he's playing on the same computer, then if a new key is reported he knows that the other player has modified the save game. An example: Player 1 starts the game, the game id is created and stored on his machine and in the turn file. He sends this turn to player 2, who keeps hacking out the id so he can keep replaying it. Once he's done he sends this back to player 1. But now player 1 has received a turn 2 game with an id that's not on his list. How can this be? Either player 1 got a new computer + hard drive, or player 2 hacked the file. I would just pop up a warning in this case. Player 1 will know that something is rotten if this keeps happening... Technically, this could be circumvented, but in addition to finding the key in the save file and correcting the CRC, the hacker would then have to change the turn that he just generated, fixing the ID and re-adjusting the CRC. Not easy!! Btw, we shouldn't really be discussion security detials in an open forum These barriers are not difficult to code, and I think you would agree that very very few people have the skills and motivation to circumvent them. On the other hand you're the only programmer on the team (quite impressive), and your to-do list is no doubt pages and pages long. Anyway, if you need any help feel free to contact me at andrew@alloymail.com. We're in crunch mode ourselves but I could certainly spare a few hours here and there to code this up for you. (Hopefully you've moved off Eiffel by now Andrew

Just a note about someone cracking the system. I'll be the first to admit that someone somewhere will crack this. For some it's just fun to take on the challenge. To be perfectly honest, if this we're implemented I'd try to crack it myself. (Yes, I cracked the time-crippled demo versions of SC, just to see if I could. Yes, I cracked the CD-requiring version (remember that one?)). But very few people would or could crack it, and the crack would not readily apply to other's people's installs. So ask yourself, how many people successfully cracked the time-limited demo of SC? Very few. How many people cheat on PBEM replays? Many. Would you not rather have very few people cheating on PBEM replays?

Just to clarify. Uniqueness: A 100-bit number gives you the following number of combinations: 1,267,650,600,228,229,401,496,703,205,376. That's a large number. That alone would effectively guarantee uniqueness. (Note that lotto 6-49 gives you odds of 13,983,816 to 1. Compare the number above to 13,983,816 then think about how often you've won lotto 6-49). Also, I was suggesting you use 256-bit ids. For every 1-bit increase, the number of ids doubles. So double the huge number above, and keep doubling the result 155 more times. I can assure you, you will not have two games with the same id. As for the size, each key is 256bits + a turn number (you only store the latest turn for a particular game), so that's 33 bytes. If you store up to 100 of these on a player's machine (so he couldn't cheat on his last 100 games) then you're using 3300 bytes. That's 3k. The size of a small readme.txt or an extremely small image file. Size is not a problem. As for someone finding out the locations of the stored keys and telling others: Ideally you would store 2 copies of the keys (we're now using 6k. peanuts). One would be hidden in the registry, under a name unique to that particular install of SC. (Could be a hashed value from the hard drive ID). And another copy of the keys would be stored in a hidden file on the machine, also with a name unique to that machine. This name can be hashed from hardware settings, or just be randomly generated and hidden itself. So it would be extremely difficult for someone to be able to find _both_ sets of keys (the game would query both locations before allowing a turn to be played). And even if a person did find both locations, they couldn't tell others because the files/registry keys would be different for everyone's machine. It's a basic technique in security and it's tried, tested and true. I think it would benefit SC enormously. In terms of implementation time, I've written similar systems in a day, but these things always vary with the project so it could be longer.

That would be fun.

Just some input from a professional programmer (and a big fan of SC, and someone who sometimes replayed his PBEM moves...): A sytem to prevent replaying moves can easily be implemented. (Note that this is transparent to the user, except for when he tries to replay a turn). SC generates a unique (say, 256-bit) number whenever a new PBEM game is created. This number is attached to all saved turns. When the other player first plays the saved turn, the game's id and the current turn number are added to a locally stored cache of recent games. If he tries to replay it, the game id and the turn number will be in the cache, and SC can detect it. In this manner the only turn that could be replayed would be the first. Deleting the saved turn, and getting it again from your email account wouldn't work because that particular game's unique number is stored in your cache. The cache could easily be 100 or more games because the amount of data being stored is very small, 7 bytes + 1 for current turn number in the 256-bit example. This has to be cleverly hidden by Hubert, ideally in a combination of registry keys, game folder, and a uniquely named hidden file on the user's hard drive. There are ways for people to cheat this system, but it would be very involved and certainly less than 1% of the population could do it. For better security, the SC clients would need to be registered with server and would need to communicate with it for each turn. Not a big deal, but still probably not worth the effort. But something should be done, because I really enjoy PBEM (TCIP involves too much waiting), but I don't enjoy the cheating, even when it's me that's doing it..

So strange the whole HoI thing. I thought it was just awful. But, as with Europa Universalis (which were wildly popular in ..europe) I read that HoI sold very well. I can't imagine why, I thought it to be unplayable... oh well..

Yeah no kidding. They actually released Age of Empires for PS2. I tried for the better part of 5 minutes to direct my villagers using a joystick. Brutal!

AND Germany's air fleets are plentiful, in or near position, and in good fighting order. If I'm feeling aggressive I'd attack w/ more than 3 Allied ships. Also, I'd only attack of France fell early (historical or earlier).

Hmmm. I suppose it does boil down to realism versus gameplay, and gameplay should almost always win that argument. It could very well be that historically research spending was something like 1-3% of the war budget and thus the option of spending the big bucks on chits is purely a fun fantasy. Who knows....

bump.. this is important!

Apologies if this has been answered elsewhere, but does anyone know how (historically) research costs compared to wartime GDPs? Should this ratio be used to establish a limit on maximal research spending (eg you can spend up to 3x the historical percentage)? Very curious.

The most important thing is to bring cold-weather lubricants, lots of fur and wool, and tanks with a good, wide base.

I would have given Bock a 6 instead of 5.

It's not dying, just shrinking in market share for the next little bit. It'll never die, PC gamers just want something that consoles can't deliver. And it's so cheap to develop for PC. Just a motivated programmer and couple years work, good publisher and there you go. Developing for consoles is whole other ball of wax...

I agree, it would be nice for it to throw some in some suprises. Carriers attacking Ireland is pretty gamey though...

Hehe. Indeed. In the case of Germany against Russia I think a war of economies is hopeless. But that won't stop me from leveling Leningrad, Moscow, Stalingrad, and every other bolshevik city represented in SC2...

Other than Miss April, I'm really looking forward to the expanded ability to wage war on the enemie's economy. (Maybe because my first degree was in economics...) Strategic bombing, u-boats, maybe even some way for the allies to interfere with shipments from Norway/Sweden? Can't wait. "Because if there's one thing those generals can't understand it's the economic aspect of war."

Hard to say what would have happened. Both armies were of the same size, a little over 3 million men strong. But Russia at the time had another _17 million_ men of fighting age ready to be conscripted. That's a lot of men...

If a Civil War mod gets made, don't forget that southern men are made of thicker stuff than their northern counterparts (who are pale lazy bankers and shopkeepers).

Excellent idea w/ the offensive/defensive rating. Such a simple thing but it could really add a lot of depth, not to mention difficult decisions to make. Just finished reading an operational history of the US Civil War, and yup, they sure had some generals that were good at defense but lousy at offense, and some (albeit fewer) of the opposite.

To be honest, I'd pay $100 for the game. I'd rather not... but I'd pay it. WWII grand strategy -- I love that stuff.

Now please quit distracting the man. He's proven, with a single title, to be a game designer of the finest quality. Now let him design his next masterpiece.

Lol, imagine the response if hubert had made it quasi-realtime like HeartsOfIron.

Awesome! They will perish in a heap of fiery rubble.

The only drawback to having engineers is that they tend to deplete your nation's beer supply.