|
Socoder -> Blitz -> Need a suggestion... |
|
| Mon, 07 Apr 2008, 14:14 | |
Orion Pax
|
I cant seem to decide how to go about this. Should I have each client report to the server that they got hit. And let the server add/subtract the life and return it. Or Have the clients handle the add/sub and report their health? The first one sounds more secure. With the second one I am affraid someone will come along with a cheat program scanning the memory and change the values. Where as the first one, if they do change it and the server has recieved a reason why its changed then they cheated.... Any body else have anyideas here? Oh yeah and I noticed when each player is created in the game, you can see them appear in the center, and then ZIP across the screen to their starting position. Could I just do a HIDE entity when the player is created until they are positioned then SHOW entity? 
|
| Mon, 07 Apr 2008, 14:23 | |
JL235
|
No idea, but I'm sure there are probably articles about this on Gamasutra and GameDev. What I'd worry about is not people able to get into your memory, but instead just building their own client that will communicate with the server. Then they can tell the server whatever info they like, such as having 1 billion health. That's how I could see it being abused. |
| Mon, 07 Apr 2008, 14:50 | |
Jayenkai
|
The best thing to do is to have everyone keep track of everything.. That way, if player 1 says "I hit player 4 - player 4 loses 25 HP", All the rest of the player's can see if this is a feasible event. If it's do-able from their data, they send a 5. If it's slightly dodgy send a 3.. If your data says it's way off, send a 1. Send each other's scores round the network, tot up everything, average it out, and only treat high scores as real events. That's probably going overboard, but it'd certainly be safe.. And yes, use hide/show entity, or maybe entityalpha ,0, or whatever else you can think of, when shifting the position of the entities. -=-=- ''Load, Next List!''
|
| Mon, 07 Apr 2008, 17:19 | |
Afr0
|
 The best thing to do is to have everyone keep track of everything.. No, no, noo, no, noooo, no, no, no, no! Notice that he's using a client+server model, and when using that model, the clients should only act as dumb interfaces for the game. The actual game takes place on the server. So what you do is you report to the server that you got hit, and you receive an OK reply with a PacketID number and the number of health points that you lost. Then the server also sends that same package to every player within your visible area that will actually be affected by the fact that you got hit (which may or may not be alot of players, depending on whether or not you wanna show quick health-point indicators above a player's head or whatever). That way you save bandwidth and you get watertight security. Oh and I hope you're not making an MMO game of sorts with Blitz? If so - forget about it. Go here and read every post by me and Scienthsine in that thread. -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Mon, 07 Apr 2008, 19:35 | |
Scherererer
|
Have the server keep track of everythign and tell the client what's what. All the client should do is tell the server that it's moving in x or y direction and firing its weapon or whatever. if you let the clients keep track of health/hits/death/etc, then it will only lead to more hacks.
-=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
|
| Wed, 09 Apr 2008, 16:13 | |
|
Orion Pax
|
Well I planned on having a limit of 50 people per game/server anyways. I took the advice of others in an earlier thread and downsized everything in my game. Still downsizing tho. And I really couldnt see more than 20 people in a game at a time.
|
| Thu, 10 Apr 2008, 00:34 | |
HoboBen
|
I think Jay's idea was really cool - but only if the game was based around cheating. That way you would only be able to write plausible cheating programs!
-=-=- blog | work | code | more code |
| Thu, 10 Apr 2008, 06:43 | |
|
Orion Pax
|
Eh. If I was going to do that then I could just code cheats right into the game just like others. And I wouldnt want this as its an online game and the other players wouldnt like it. I do have some minor cheats in the game now for debugging purposes, but other than that its not really needed. It would spoil it.
|
| Sun, 13 Apr 2008, 13:32 | |
|
Orion Pax
|
And not to cracking on anybody but I just got this from another post. Afr0, I'm not doing my game in tcp. Its UDP. In Fact I am using Blitz Play Pro. Which was a wonderful package. As it took me forever to understand UDP protocol with blitz. TCP is too slow for what I want and I know UDP is gonna get me what I want. So my game is everybit possible from where I am standing. But I still dont see more than 50 people at one time in each game. Each game will run its own instance of the server software. I hope that is atleast possible in blitz...lol Quoting Afr0 from another post. "Hm... this brings up an interesting subject: Does DirectPlay enable you to create an MMO in Blitz? I don't really know the answer, but unless it's built on top of UDP, I'm guessing it's using select() to switch sockets, so then the answer would be no. Short summary: If you wanna build an MMO game in Blitz, Google for something like 'select() + DirectPlay', or use UDP. Always keep in mind that using TCP in Blitz will limit you to 64 players max (unless you use Scienthsine's idea, and create a main server application that relays it's connection sockets to different worker applications. But the design approach sounds kinda wobbly, and there's no guarantee you'll ever be able to go above the threshold unless you can guarantee that none of your threads are ever using more than 64 sockets). Edit: As per the interpersonal comment above, I mean no offense to Scienthsine, and I will be as proud as anyone (if not prouder) if he actually manages to pull off his approach and successfully prove that you can manage more than 64 sockets at once with TCP using Blitz." [/qoute]
|
|
|
| |||
|
| ||||