On Wed, 22 Nov 2006 10:34:12 +0100, "Sam Nova" <sam@xxxxxxxxxxxxxxx> said: > But I do see some issues (Beyond all the extra work). The idea is to > avoid people cheat and as we know people will try.. The main worry is > that if people 'hack' the data been sent to the server and the server > then tries to play through the game with that data, then who knows.. > Maybe it will crash the game, or even play better than the player did ;) > Of course the 'server' could be checking for valid data and make sure > that nothing 'impossible' would happen from the recorded data. Checksums > would be needed. Oh, and of course store seed values for random generate > data, wonder what a change in those values would result in, specially if > it was used to defined enemy positions or level layout ;) Well, yeah, you'd have to store the seed value, cause that's part of the initial state. (Maybe even the entire initial state, if you generate the whole level and enemy position.) Changing the seed but not the input log would result in an invalid log, in 99.99% of cases. Just think about the amount of correct input required to run through a level of Doom without hitting walls or falling off cliffs or getting stuck in dead ends. It's pretty unlikely that you could change the layout of the level and have the same input result in anything like a correct run. As for hacking the data, well, you'd write the server so it couldn't be crashed. It should just read fixed size input at all times, and give up immediately if it gets a piece of input data which looks invalid. Otherwise, any data it gets is valid, and can be used to affect the player's state in exactly the same way it is on the client side. Again, the likelihood of it playing better after hacking is infinitesimal, because each piece of input data affects the ongoing state, so every input after the hacked one has to change. In fact, the easiest way to hack it would be to build up your log in bits. So do the first 10% of the game over and over till you get it perfect, then save the log file. Then do the second 10% until it's perfect as well, then save that log file and splice them together. Repeat until finished. Still sounds like a fair bit of work though. > Hell lot of work if you ask me, but thumbs up for the idea. It might be a bit more work than just sending the score but it's much more secure - any encryption is vulnerable to well-documented attacks. The main problem would be that a gamelog for an FPS, for instance, could be a huge amount of data (though this makes it harder to hack). But you're unlikely to have high-scores for an FPS anyway. For Tetris, say, the game input log would only be kilobytes for each score, and replaying would be trivial. Dave. > > -----Original Message----- > > From: gameprogrammer-bounce@xxxxxxxxxxxxx > > [mailto:gameprogrammer-bounce@xxxxxxxxxxxxx] On Behalf Of > > Dave Slutzkin > > Sent: Wednesday, November 22, 2006 3:54 AM > > To: gameprogrammer@xxxxxxxxxxxxx > > Subject: [gameprogrammer] Re: Scoreboard functionality across internet > > > > > > On Tue, 21 Nov 2006 18:29:55 -0800, "Alan Wolfe" > > <alan.wolfe@xxxxxxxxx> > > said: > > > Hey you guys, > > > > > > I'm thinking of trying to implement a global scoreboard for a game. > > > > > > The game itself is a standard desktop game where you have > > the exe and > > > files needed on your computer (ie its not a web based game > > or flash or > > > anything) and the scoreboard i want to reside on a web page. > > > > > > Doing the web and database thing isn't a problem but I was > > wondering, > > > are there any techniques to make this process secure? > > > > You could send the server the entire run of the game - the > > start state and every piece of input in between it and the > > end state. The server could then run through the game itself > > and generate the score that way. > > This sounds like a lot of data but if stored efficiently and > > then compressed it might be all right, depending on the application. > > > > It'd still be possible to hack this but much harder, cause > > each bit of input affects the state after it and so changing > > one may actually invalidate later pieces of input - at which > > point the server could throw the log away. > > > > Dave. -- Dave Slutzkin Melbourne, Australia daveslutzkin@xxxxxxxxxxx --------------------- To unsubscribe go to http://gameprogrammer.com/mailinglist.html