Job Offer - Programmer Quote Required for MMO Online Database

RyanC

Member
Hi everyone, I have a game that I would like to include multiplayer in the sense that users can store their variables online and conquer and steal bases from one another etc.

From my understanding I need to link my GMS application to an online MySQL data base via a PHP script.
However I'm open to other suggestions.
I can provide the domain name and web hosting via Linux servers with static IP address.
The reason I'm not to confident doing this myself is that I've never used PHP before or MySQL data bases and most of all I'm concerned about security breaches if not set up by someone with the relevant experience.

So if you know how to use things like random session cookies and all the other necessary code to set up a secure system like this then I'm happy to talk more about this project.

I'll need to have a system that allows users to create and access their username account that will store all their game variables such as text documents that I can export their creations to. So this would mean storing instances and x y positions for them. They'l need to be able to search for other usernames and attack their bases but this will only mean downloading the defending user's base data, as they will not be playing against one another in real-time unless I can see how to implement that feature into an already completed project.

I'm just looking for a quote at this point to see if this is something I can afford?
 
R

roytheshort

Guest
It's not so much if you can afford it, I'd say if it's worth it. Ideally with MMOs you would want a subscription fee from players to keep the server running, so you could just split the cost out. But, if few people play it, it's just a constant stream of costs to you and not many people are online at one time.

If few people play the game, this is really not worth the effort even thinking about. My suggestion would be to release the game, then add multiplayer if it becomes popular. Then you know if it's worth it for both you and your players. People often jump into MMO too early, you need a reputation of previous games or just sheer luck to do something like this right off the bat.

Just the way it seems to me though.
 

GMWolf

aka fel666
I laughed more at this than some of the best jokes I've heard!

Ridiculous.
It really depends on the quality of service provided.
15k is not unreasonable for a very secure, very robust system along with full testing and lifetime support...
Though we are talking about some very thorough work spanning a couple months at least.

If its just a moderatly secure (has the minimum password hashing), and well enough implemented for a simple gm server along with just enough testing to check if it works (a couple weeks work), then i think something from 500-1500 is more reasonable.

A quick system to get things going could be anywhere from free to 300...


Thats just my 10c though. Im not actually much experienced in concultancy and bespoked rsoftware...
 
N

naret

Guest
what makes this not cheap is "I'm concerned about security breaches if not set up by someone with the relevant experience"
for real experts in US that's a month of salary. You can for sure get some freelancer from US who'd work for 3 months for that money, but it's really not that time consuming to write this simple server, yet it's the experience that matters and people who know the inside out of security from former projects aren't the average game programmers.

Tho, question is, does it really need to be that secure and written by a experienced expert? Maybe aiming and the other end would be simpler. Just don't have anything valuable on the server from your users. Generate random 6 digit password they can get by mail and don't request name, data, credit cards etc. If needed, make payment via paypal, hence they'll handle security for it on their side. Then be prepared that every now and then some script kiddy gonna attack you, and might bring your services down, or might get some game data, or even your password.txt in that case you fix the issue, apply the last backup, request everyone to reset the password, continue like you don't care. (because, if you care, they'll reached the actual goal).

if, at any point, you really have trouble with security, you can still pay a top expert, or hire even companies that handle that (these might be cheaper, as they've streamlined the process). A lot of attacks, like DDOS, are infrastructure attacks and then you rather need "expert networks" to solve that, in which case it would be simpler to go for some cloud service than to run it on a cheap (<100$/month) linux server.

For a small game, not preparing for all kind of attack, but having good backups, log files and a short respond time, is IMHO the better way to go.
 
N

naret

Guest
to roll back to last months backup
+1 fully agree. if your provider doesn't run daily backups on your server, change the provider. (my cheap $8/month vserver has daily backups for 7days, 8weekly backups and 12 monthly backups + infinite logfile backups). On SQL databases, preferably use some continuous backups system. (Journaling).

It is upto the server to know these answers, the client can not be trusted.
I wish the world would be that easy :), but there are reasons why a lot of logic runs on the client side and the server has to trust, and in some cases can barely even validate what is happening ( otherwise you'd just stream a video of what the server has calculated, 'cause the server had to calculate everything)
but all this is not really something that can be outsourced to 'any expert', it's fundamental game architecture. Probably beyond the scope of this job posting.
 
N

naret

Guest
Not true.
what exactly of the quoted text is not true?

The client asks permission to the server and the server accepts or denies the request.
that would render a lot of games unplayable if you do that for every aspect of the game. e.g. shooter, racing games etc.

The client can however predict that the server will agree and display what it should.
it's slightly different. it's not predicting what the server will agree. the server is rather predicting what the client can do within valid limits. e.g. if a client can move 10units/tick, then every position-update outside this range will be not legal. but if a 'hacked' client keeps that limits, yet moves faster in that radius (e.g. jumps immediately 10units after every tick update), the server won't detect this.

This is partially the job of 'client side prediction' and 'dead reckoning'.
client side prediction is not predicting what the server will validate, it's extrapolating data until it gets a new update from the server with the real state. e.g. enemy movement based on last position + direction*time_delta. no client predicts what a server will validate, because the server validation is already based on the logic of the client, hence in theory, a not hacked client cannot run outside of specifications.

If a player illegally travels somewhere it shouldn't the server will detect this and order the client to snap its position or state back to where it belongs.
again: I wish the world would be that easy :), but just lag and latency make this tiny task a heuristic challenge already.

Again, never trust the client. The server decides everything.
yet many big games go for client side decision, e.g. overwatch:
http://eu.battle.net/forums/en/overwatch/topic/17611871199
your simple theory isn't that simple in real world and there are reasons why there are a lot of games have to trust client side decisions.
there are surprisingly few games validating every aspect of a client on the server. especially if the server is based on a different code base (e.g. php on the server, GM on the client).
 

RyanC

Member
All this is great information guys, It's opening my eyes up to potential flaws in my initial idea of implementation. This particular game is a turn based game where each player only has one shot per turn, so that may rule out the risk of latency, as I'm guessing the client will just send the initial x and y speed for each shot to the server and as long as all the level data is the same on the clients then the consequences of the shot will be the same on each client wont they?

If you think of Clash of Clans, once the user has loaded another user's base to attack, most of the game is then handled client side I think?
 
Last edited:

GMWolf

aka fel666
All this is great information guys, It's opening my eyes up to potential flaws in my initial idea of implementation. This particular game is a turn based game where each player only has one shot per turn, so that may rule out the risk of latency, as I'm guessing the client will just send the initial x and y speed for each shot to the server and as long as all the level data is the same on the clients then the consequences of the shot will be the same on each client wont they?

If you think of Clash of Clans, once the user has loaded another user's base to attack, most of the game is then handled client side I think?
Doing it that way will lead to synchronization issues.
Its best to send the initial x&y velocities to each client as you said, but then dont have the client update the concequences. Have the server send the position of the impact, and what there is to change.
This is because if the timing is slightly different, and floating points slightly off, the shot could end up slightly off on each clients. If you repeat this multiple times you end up getting very different results.
 

RyanC

Member
I see what you mean, this is a physics based game though so I'm not sure the server can really interact in a way that it assumes control of the physics world.
If the room starts at slightly different times on each client I can see how this may become a problem. What about accessing the random_seed() for the physics movement and let the server set the same value for each client?

Anyone know the advantages of using GM Server compared to using GMS networking functions?
 

Mr Magnus

Viking King
that would render a lot of games unplayable if you do that for every aspect of the game. e.g. shooter, racing games etc..

And yet that is exactly what is done with anything that slightly matters. the server does not trust the client for anything that affects the game state. Shooters don't trust the fact you moved twice the length you are supposed to, that's why random teleportation happens, because your client got a bit too frisky with the client-side prediction. the client never tells the server "I shot in X direction and killed player Y", it simply tells the server "I shot in X direction", predicts the outcome, and then the server sends back what happens so the client can fix it.

the server *must* assume that the client has been compromised at all moments. nothing the client says is trusted off the bat if it can change the state of the server in the slightest: Or at least that's the philosophy. If there is a vulnerability in your networking protocol there will be a user smart enough to find it and exploit it. Heck, there are games that have decided *not* to send other player positions in a shooter if there isn't a direct line of sight between the client and the player to break wall-hacking.

Name me a game that would be unplayable if the server doesn't trust anything the client says? it's a multiplayer game, that information is passing trough the server anyhow and a few if statements are not even a drop in the latency ocean. Remember: A client doesn't wait for the permission of a server to change the client-game state, it pretends it has 'permission' and keeps going until the moment the server says "Hold on, no, that isn't correct." in which case it simply fixes it.
 
N

naret

Guest
And yet that is exactly what is done with anything that slightly matters. the server does not trust the client for anything that affects the game state.
The devs of overwatch, planetside, quake,... say they have client side hit detection (isn't that what matters most in an FPS?) (check my link above for proof).
Gran Turismo has client side physics (if clients start to diverge, other player get to see ghosts of you until you are far enough apart to not matter for their game).

Hence I feel like not derailing this thread further, as I rather trust the devs and if you don't trust them, you won't change your opinion just because of my posts anyway.
 
N

naret

Guest
All this is great information guys, It's opening my eyes up to potential flaws in my initial idea of implementation. This particular game is a turn based game where each player only has one shot per turn, so that may rule out the risk of latency, as I'm guessing the client will just send the initial x and y speed for each shot to the server and as long as all the level data is the same on the clients then the consequences of the shot will be the same on each client wont they?
In theory you are correct, if all input is the same, all output will be the same.
BUT
1. Is really _all_ the input the same? e.g. does your physic simulation of the bullets run in fixed time steps, or does it depend on e.g. the framerate ? (time delta is input too).
2. Different hardware can potentially calculate different output. e.g. float/singles on different type of CPUs have slightly different results. you will never see a visual difference with your eyes, but boolean decisions like length(HitPos-TankPos)<radius might be different (this is in very very very rare cases, but in a chain of math formula, this might sometimes matter).

I'd suggest you a simple solution:
-transfer the input of your simulation to both clients (client which makes turn sends it to the server, server sends it to the 2nd client)
-both client run the simulation
-both clients create a checksum based on all important states and submit it to the server
-states should match and game continues; if not, there is a sync issue, either cheating or some weird bug. restart the game or synchronize the clients by a full state copy
(yes, this is not a perfect cheat protection, yet you can at least perfectly detect if there was something async and it's not that much work to get this running).

-replay on your PC all the games with these checksum mismatches, maybe you can find some bugs and fix it.

as a first step, record all input and replay it. if the replay works flawlessly on your own machine, try replaying your game on other machines etc.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
1. Is really _all_ the input the same? e.g. does your physic simulation of the bullets run in fixed time steps, or does it depend on e.g. the framerate ? (time delta is input too).
2. Different hardware can potentially calculate different output. e.g. float/singles on different type of CPUs have slightly different results. you will never see a visual difference with your eyes, but boolean decisions like length(HitPos-TankPos)<radius might be different (this is in very very very rare cases, but in a chain of math formula, this might sometimes matter).
As they have mentioned, the game is turn-based, meaning that the actual logic is processed once per turn, the rest being client-side visualizations.

GameMaker's use of epsilon for comparisons surprisingly fixes vast majority of synchronization issues that you would normally encounter - so long as you don't multiply very small numbers by very large numbers or divide by very small numbers (both cases being ones that can bring the floating-point mis-math out of the epsilon range).

Overall, while building scalable server applications is no easy task, with turn-based games it is usually not that bad (unless the game is huge and you insist on contractor writing all the code), and probably not as bad as the estimate of the fellow that seems to be doing everything possible to destroy any credibility that they may have appeared to have at some point.
 
N

naret

Guest
As they have mentioned, the game is turn-based, meaning that the actual logic is processed once per turn, the rest being client-side visualizations.
yeah, I agree, it's a good starting point for adding server side multiplayer. having latency out of the way makes it way simpler.
but my concerns were for the actual turn processing, as he mentioned he uses some physics simulation.

GameMaker's use of epsilon for comparisons surprisingly fixes vast majority of synchronization issues that you would normally encounter - so long as you don't multiply very small numbers by very large numbers or divide by very small numbers (both cases being ones that can bring the floating-point mis-math out of the epsilon range).
the divergence I've mentioned is not a float-epsilon issue. It's that different hardware calculates different results (within IEEE754 specs). e.g. Intel FPUs can have 1.5 ULP of rounding error for sinus. this is very marginal, but if you use that as initial y direction of a bullet, after hundreds of simulation steps (within one turn) it might sometimes hit different than on AMD FPUs. If this impulse is propagated in a physics system, and.... basically, potential butterfly effect.

Overall, while building scalable server applications is no easy task, with turn-based games it is usually not that bad (unless the game is huge and you insist on contractor writing all the code), and probably not as bad as the estimate of the fellow that seems to be doing everything possible to destroy any credibility that they may have appeared to have at some point.
+1
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
the divergence I've mentioned is not a float-epsilon issue. It's that different hardware calculates different results (within IEEE754 specs). e.g. Intel FPUs can have 1.5 ULP of rounding error for sinus. this is very marginal, but if you use that as initial y direction of a bullet, after hundreds of simulation steps (within one turn) it might sometimes hit different than on AMD FPUs. If this impulse is propagated in a physics system, and.... basically, potential butterfly effect.
Depends on whether it is actual (Box2D) simulation or not.

If it isn't, GameMaker happens to take some (supposedly accidental) steps to making things easier, such as rounding coordinates used for collision checking via place_meeting, and using lower precision for multiple of built-in variables (most noticeable on x,y - seem to be rounded to 32-bit floating point).
[I wouldn't be surprised to find math functions doing some rounding as well, but that is a little harder to verify.]

As result, things may go better than expected.
 

Mr Magnus

Viking King
The devs of overwatch, planetside, quake,... say they have client side hit detection (isn't that what matters most in an FPS?) (check my link above for proof).
Sorry, but the link is not acting in your favor

game client processes hits on your pc and then transmits hits to the server (which then decides if the enemy lives or dies)
the example being overwatch: The server decides if he hit something and tells the server. The server doesn't trust the client and verifies it before deciding if the enemy lives or dies. The client isn't controlling anything: he is submitting a "I killed this player" request and the server doesn't trust and has the final word if it really did kill a player. That's what client-side hit detection means:

Server-side: Client tells the server he shot at something, the server tells him if he hit.
Client-side: Client tells the server he hit something, the server overrules if something doesn't add up.

Server never trusts the client. If client-side detection would be a "I trust you 100%" from the server a malicious player could very easily state "I killed that player" and the server simply go "Oh, ok, but he is on the other side of the""-NOPE, I shot him". and the server accepts.

Imagine any system where the client is trusted 100%. How do you prevent a malicious player from simply declaring something and the server accepting it because the client is trusted? That's a giant game-breaking hole that leads to what the Division was during the beta.
 
N

naret

Guest
Sorry, but the link is not acting in your favor
game client processes hits on your pc and then transmits hits to the server (which then decides if the enemy lives or dies)
lets put it in the table:
0001.png
(sorry for the quick coder table art)
I don't see why the developers statement is not in my favor.


the example being overwatch: The server decides if he hit something and tells the server.
that contradicts with what the dev says:
developer said:
game client processes hits on your pc



The server doesn't trust the client and verifies it
the developer explains this as the alternative (which they don't do) 'server side hit detection':
developer said:
Server side hit detection would mean that the server, registers all the hits from hundreds/thousands of players and then decides the outcome.
They explicitly say
developer said:
your PC is doing ALL the work

before deciding if the enemy lives or dies.
exactly, the server decides about life and death, based on the hit detection of the client. These are two decision makings, don't mix them. Maybe that's the source of confusion.



The client isn't controlling anything: he is submitting a "I killed this player" request and the server doesn't trust and has the final word if it really did kill a player. That's what client-side hit detection means:
That's not what the developer said. The client is _not_ submitting a kill request.
developer said:
your game client processes hits on your pc and then transmits hits to the server
in your terms: the client submits a "I hit enemy_id". The server calculates
a) "enemy_id had 150 health, client hit for 180, that means enemy_id is killed by this client"
b) "enemy_id reported a headshot to client before, this hit report does not lead to any effect"
there is no "I don't trust the player, lets check in my state if the bullet hit". In both cases you will see blood splashing out of the enemy and a hit animation.
(this is particular for Overwatch, other games do it as you've said, with 0% trust).


Server-side: Client tells the server he shot at something, the server tells him if he hit.
again, the dev says the opposite:
developer said:
game client processes hits on your pc and then transmits hits to the server ... YOUR pc does all the work.
Client-side: Client tells the server he hit something, the server overrules if something doesn't add up.
That's true, the client tells the hit.
It's also true, if there is a contradicting situation between two clients, the server has to overrule a hit. BUT not because of validation of your shots (-> no raycast), but solely to resolve a contradicting situation. e.g. two snipers shoot at each other. you might see that you hit first, but the server received the hit from the enemy's client first, your hit will be overruled. e.g.:
but if you see you hit something, and there is no contradiction of states with other clients, the server will accept your hit even if you contradict a server state (e.g. the server accepts a hit of an enemy that is behind the wall regarding the server state).
And yes, that also means, if you hacked the client or network traffic, you don't even need to pull the trigger or aim exactly at the enemy, as long as you send a 'hit' and it does not contradict other clients, the enemy will die.



Server never trusts the client. If client-side detection would be a "I trust you 100%" from the server a malicious player could very easily state "I killed that player" and the server simply go "Oh, ok, but he is on the other side of the""-NOPE, I shot him". and the server accepts.
it's not about 100% trust. you said the server never trusts the client -> 0% trust. I state that's not true. The server in Overwatch trusts the "hit" reports of the client. Overruling happens, but _not_ because of a trust issue, but purely to solve a conflict. In most cases, conflicts are resolved in favour of the shooters, they call it "favour the shooter". That's why you hit someone behind walls. They add "exceptions" to some conflicts in where they will not favour the shooter. You can watch the details here:

Again: It's not because of a lack of trust to a client as you state, it's really only to resolve conflicts (stated in the developer video).



Imagine any system where the client is trusted 100%.
ok, lets imagine this for a second on a NOT hacked/cheated game. what would happen if the client decides? lets take the developers explanation:
gamedev said:
Example: Tracer peeks through a corner, sees a sniper and blinks into safety of cover then suddenly dies. Death cam shows tracer was shot in the face by Widow and never blinked away.
Explanation: This is because of client side hit detection.
(Note, an exception was added in a newer patch, now the blink is favoured over the hit. but again, not a trust issue, solely a solution to conflict).

There would be situations, where:
client state: enemy player is visible, player attacks and hits the enemy.
server state: enemy player is hidden behind the wall, hit is impossible, yet as the server does not verifiy it, it will still accept the client's hit report (in case you don't know this game, that's the end-of-game-replay that everyone sees as the server saw it. you see the completely occluded enemy):

There will be a situation, where:
client A state: enemy B is visible due to network latency, will be hit
client B state: enemy A cannot see you for half a second, server would know that due to time stamps of pos updates etc. if it would verify hits, but if the server just believes client A, client B gets hit anyway and sees an impossible situation:

The whole post in the overwatch forum is due to the fact, that hits are handled on the shooting client. A lot of replays look weird and player think the game is buggy. But in fact, it's not a bug, it's simply due to the decision to handle this part on the client.

I agree, the Devision gone bad. Maybe because this code was rather written for consoles where you cannot hack binaries.
From the architecture, overwatch is inbetween devision and your perfect model, but with better security. From the gameplay it's a better feeling for shooter(e.g. sniper), as you don't suffer from vague prediction, you don't have to aim ahead.
 
Top