Hey all,
I have a quick question about the setup of logic for a Worms type game. I have written the client in flash and using electrosever - socket server and written the plugin in java.
The problem I'm having is where to put the logic. Do I put it client side which gives the user more potential to hack the game or on the server. The main problem I'm having with putting it on the server is I then have to load in the bitmap image for every game going on which could be hundreds of images being edited at any given time.
Is there any example out there of server side logic for a terrain destruction game.
Worms server logic?
The server must be in control of it, otherwise your going to get people cheating in your game.
However, the server doesn't need to do all the work, just the one that affects gameplay.
In the original worms the terrain was basically just used to calculate terrain collisions. This means you can use a monochromatic bitmap to do that on the server, and any other cosmetic changes can be calculated on the client side only (like charring the terrain for instance).
However, the server doesn't need to do all the work, just the one that affects gameplay.
In the original worms the terrain was basically just used to calculate terrain collisions. This means you can use a monochromatic bitmap to do that on the server, and any other cosmetic changes can be calculated on the client side only (like charring the terrain for instance).
Suppose there's a byte of data per pixel. Suppose one screen is 4096x1024 pixels (probably too much, but oh well). Suppose you have 100 games going at the same time. That's 400 MB of data. That's hardly too much for a normal server these days -- most "real" servers have 100 times as much RAM, and even low-end servers have 10x as much RAM these days.
Author
Thanks for the reply guys. I thought I would ask before finding out later that 10 games kills my web server and I have to re write the whole thing.
So essentially just use a black an white terrain on the server and the fully coloured version on the client and ram shouldn't be an issue when having a couple hundred games going.
Nice! Thanks for the info, really appreciate it.
So essentially just use a black an white terrain on the server and the fully coloured version on the client and ram shouldn't be an issue when having a couple hundred games going.
Nice! Thanks for the info, really appreciate it.
If it's a _web_ server you may have problems with persistence of processes. Specifically, web servers traditionally don't keep data alive between requests, so it would have to inflate each level for each command, and then save it back out. That means 8 MB of data traffic per request, which will limit a normal hard disk to about 10 requests per second.
If you have an application server with persistence and "live" sessions, you avoid that cost, but instead have to keep the data in RAM until the session terminates.
If you have an application server with persistence and "live" sessions, you avoid that cost, but instead have to keep the data in RAM until the session terminates.
The responses so far are all reasonable, but I recommend that you do whichever gets the game working with the least amount of *time* and *effort*. That probably means mostly client side, which has the additional advantage of making the logic easier to change and update later.
Yes, this allows players to cheat with trivial effort, but if you get enough players for this to be an issue then you have already surpassed 99% of indie multiplayer projects. I think your biggest concern should be getting your game playable and released, and building enough of a user base so your servers don't stay completely empty. You can always worry about cheating later, once your game becomes a smashing success.
Yes, this allows players to cheat with trivial effort, but if you get enough players for this to be an issue then you have already surpassed 99% of indie multiplayer projects. I think your biggest concern should be getting your game playable and released, and building enough of a user base so your servers don't stay completely empty. You can always worry about cheating later, once your game becomes a smashing success.
Klapaucius is right. Get your game to market, and when you have achieved success and cheating becomes an issue ( cheaters target popular games, it isn't worth the effort for low pop games ), then fix it.
The cheating problem you will encounter with a worms type game is auto-aimers. A cheat program that reads out player position and wind speed to calculate the perfect angle for the weapons used. No client or server side logic can detect this. This was the big problem Gunbound had to resolve. Their solution ( last I checked, which was a long time ago ) was to use some very deep almost root-kit technology to prevent third party apps from accessing the Gunbound memory space. I don't know how successful they were.
--Z
The cheating problem you will encounter with a worms type game is auto-aimers. A cheat program that reads out player position and wind speed to calculate the perfect angle for the weapons used. No client or server side logic can detect this. This was the big problem Gunbound had to resolve. Their solution ( last I checked, which was a long time ago ) was to use some very deep almost root-kit technology to prevent third party apps from accessing the Gunbound memory space. I don't know how successful they were.
--Z
Author
Your probably right. Should treat this as a prototype sort of release, see if there is any interest first before I start wasting my time with cheaters that aren't even playing the game.
All I'm really worried about is that it's intergrated into a website so a heap of unlockables and high score boards. If people cheat to get the top stuff it will ruin it for others. Unless I just keep good logs and ban and correct anything that looks suspicious.
All I'm really worried about is that it's intergrated into a website so a heap of unlockables and high score boards. If people cheat to get the top stuff it will ruin it for others. Unless I just keep good logs and ban and correct anything that looks suspicious.
Quote:Original post by Klapaucius
The responses so far are all reasonable, but I recommend that you do whichever gets the game working with the least amount of *time* and *effort*. That probably means mostly client side, which has the additional advantage of making the logic easier to change and update later.
Yes, this allows players to cheat with trivial effort, but if you get enough players for this to be an issue then you have already surpassed 99% of indie multiplayer projects. I think your biggest concern should be getting your game playable and released, and building enough of a user base so your servers don't stay completely empty. You can always worry about cheating later, once your game becomes a smashing success.
I agree in principle. Polishing the game too soon is useless, it's just really necessary when the game becomes popular. However in this particular instance, I'd disagree.
First a game's ascension to fame can be severely hampered by cheaters, and this particular form of cheating would be really nasty because given map control the client can just make a hole in it under the adversary until it hits water, it's an instant win, and it'd be very frustrating for the victims.
Then there is the fact that by the time the game becomes popular, the core server code is buried under several layers of all the other protocols used to get the game off the ground, so it's going to be a significant bit more difficult to correct it then.
If you really don't want to do this now, you can always mass ban ips of cheaters to mitigate this problem (this comes with it's own set of challenges though), and later on just sub-contract the work to fix the server.
There is a concept of "minimum viable product" -- as soon as you have something that someone actually wants, ship it!
However, the word "viable" is important. A game where it's easy to cheat, and the incentive to cheat is high, is probably not viable.
Thus, it may be that a correctness requirement is server-side anti-cheat. If that's the case for you, you should implement it before you ship.
Btw: In thist context, I'd like to re-iterate that the world's two most famous computer science quotes are both too often taken out of context:
"GOTO considered harmful" argued that block scoping (as found in ALGOL) was more readable than if-then-goto (as found in FORTRAN). This does not mean that the argument was that all GOTO statements are harmful; it means that block scoping was a preferred alternative for most cases, something which we may not fully appreciate in this day and age.
"Premature optimization is the root of all evil" argued that instruction-level optimization, trying to squeeze bits out of operations, was not something that should be done before the program was working. This phrase has often been interpreted to mean "don't spend any time thinking about performance," which is patently false. Every program you write has some performance requirement, which is as important as correctness, security, usability and other requirements. If your program doesn't reach this requirement, it is a failure. Often, some of the biggest failures come from programmers failing to do algorithmic and systems performance analysis up front.
However, the word "viable" is important. A game where it's easy to cheat, and the incentive to cheat is high, is probably not viable.
Thus, it may be that a correctness requirement is server-side anti-cheat. If that's the case for you, you should implement it before you ship.
Btw: In thist context, I'd like to re-iterate that the world's two most famous computer science quotes are both too often taken out of context:
"GOTO considered harmful" argued that block scoping (as found in ALGOL) was more readable than if-then-goto (as found in FORTRAN). This does not mean that the argument was that all GOTO statements are harmful; it means that block scoping was a preferred alternative for most cases, something which we may not fully appreciate in this day and age.
"Premature optimization is the root of all evil" argued that instruction-level optimization, trying to squeeze bits out of operations, was not something that should be done before the program was working. This phrase has often been interpreted to mean "don't spend any time thinking about performance," which is patently false. Every program you write has some performance requirement, which is as important as correctness, security, usability and other requirements. If your program doesn't reach this requirement, it is a failure. Often, some of the biggest failures come from programmers failing to do algorithmic and systems performance analysis up front.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
