Greetings guys!
As I’m learning as I go (it feels like once you learn to program, a new world of game design reveals itself in front of you), I’d like to have login and log off possibilities. I’m waiting for Oldjim to make a proper server for CoS, but since is extremely busy, and is unable to respond, I’m placing my request here!
I need a python server that allows me to use a database to register or compare user data. And send simple info to the clients, to show they are connected.
I tried a simple online tutorial, but the server disapears as soon as it blinks :no: it doesn’t run till I press Esc.
the server code goes like this:
# UDP server example
import socket
server_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server_socket.bind(("", 5000))
print"UDPServer Waiting for client on port 5000"
while 1:
data, address = server_socket.recvfrom(256)
print "( " ,address[0], " " , address[1] , " ) said : ", data
and the client:
# UDP client example
import socket
client_socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
while 1:
data = raw_input("Type something(q or Q to exit): ")
if (data <> 'q' and data <> 'Q'):
client_socket.sendto(data, ("localhost",5000))
else:
break
client_socket.close()
Firstly, it means you’ve got an error. If this s for python 3, then your print statements need to be updated to functions - print(‘x’) not print()
Secondly, what does <> mean?
easy. You bound the port, but then it was rebound when you ran the script again, before old session closed. Use a random port mnumber (set to 0) or close the socket at end of script.
Well, just to make it clear: My example runs in the BGE, so if you make a standalone, you won’t need to launch blender itself.
You can certainly shut the BGE server down without blender; As I demonstrate in the tutorial, you can communicate with the server from an arbitrary python interpreter, or any other program that can send with sockets. So, assuming that the server is programmed to accept and act on a shutdown message, you can simply send one.
If you want the server to be a non-BGE program, that’s certainly possible, but then you have to essentially write your own game engine, because you don’t have the BGE to calculate logic/physics, so it’s up to you to figure out what the player controls actually do, and how that changes the shared game-state.
That’s true to a degree Goran, but essentially you can leave anything that doesn’t need to be purely server side to client physics etc.
I’m considering using blender for the server, because otherwise i would have to include physics and pathfinding in python, which wuold likely be slower than using integrated C++ physics and pathfinding when the numbers increase. However, it is always useful to have an external server.
If you’re using the physics engine to simulate simple effects (like dust particles) which don’t have to be exactly the same from client to client, then yes, that would be a good strategy.
However, in almost every other case, it is in your best interest to produce a consistent game-state on the server.
^
It’s more effective, in almost every conceivable manner, which is why most modern games use that architecture.
I’m considering using blender for the server, because otherwise i would have to include physics and pathfinding in python, which wuold likely be slower than using integrated C++ physics and pathfinding when the numbers increase. However, it is always useful to have an external server.
I don’t really understand what you mean by “external server” - A server is a server, be it a BGE application, or some other program.
Hmm, I see the problem here!
Well, you see, my game is designed in a way that the game world cannot be reproduced in the server side. So there’s no point in running a server from the bge, since the physics cannot be calculated in a global manner.
So although the network setup will include various levels of “serving”, the initial server will handle database data, and avatar state transmitting.
In short the physics will happen in the client side. But interaction in the server side. Basically, there wont be “real” physics in the game, just position comparisons.
The client will send it’s keys state to the server, and from time to time it’s position/orientation, the key state will represent the change in that position/orientation/state. The position is calculated based on the collisions happening in the client.
The server transmits the position to all clients, and if for instance an avatar is shooting at another, a vector is produced in the server side, and the trajectory is calculated based in time. If the bullet position is in range with another avatar, then a hit is registered.
This is still messed up I know, but for now it’s the way I see it!
So the server can be standalone thus also avoiding extreme calculi such as physics and scene graphs for hundreds of objects, that might happen in a BGE server. Of course, you are welcome to suggest alternate solutions. But as far as I see the standard client /server setup wont work for me!
The game state should be produced on the server side (the server should be the game).
I would recommend that you redesign your current system to work like that.
So the server can be standalone thus also avoiding extreme calculi such as physics and scene graphs for hundreds of objects, that might happen in a BGE server.
If you set the avatar objects (on the server) to be invisible, that should remove them from the graphics processing pipeline.
As for physics, logic, and everything else that actually effects global game state: Doing it on the client is actually slower, because now you have to wait for clients to inform the server of what they think the game state should look like, and the server has to spend additional time to keep everyone in sync, and also resolve conflicts between clients who have a differing interpretation of some event X.
And then there’s the whole cheating issue, which is virtually impossible to address in that architecture.
It becomes a real mess real quick.
When you do everything on the server: you have a single, absolutely valid global state, and you can send portions of it to clients that need to see it, as some set frequency.
It’s simple, elegant, and far more efficient than some convoluted “fat client” method.
I really which I could do it that way.
Let me illustrate it to you.
We have 4 teams of 4 avatars each ,players and NPC included. One is on planet 2 are on Planet A and the others are on Planet B. On client side, for planet A, both teams occupy the same positions as their counterparts in planet B. If all this data is handled in the server side, I’ll have player on planet A colliding with the ones on Planet B (unnecessary calculations). Each planet has 24 sections, if there must be a server per planet, there can be millions of planets… and that goes without counting the space between stars and planets!
Furthermore, the client’s positions are calculated in the server side, but because there are no collisions, the client does it for the server, and from time to time sends the correct position/orientation. This is similar to the key states, only the data here is the player’s states changes(independently of user input). Could have been and seems slower, but for me is the same ping pong as the other way. The user sends info, the server updates the data on the server and sends it back to the clients. Since there’s no garanty all commands are received by the server, the client only moves when it gets an OK from the server. Interactions are still happening on the server side, but are calculated in global space. In the BGE, that would imply doing physics calculations with floats and objects scaled down 10^15 times at least!
The game simulates seamless travel through the galaxy, I need at least 64bit physics accuracy to run stuff on a beefy server on a BGE server. At least I think so!
this is, to a degree a problem. what you could do is the following;
impose a sight limit on clients.
force the server to avoid informing clients of clients they can’t see.
at the moment you’re looking at distributed networking. that may be a good idea if you want to have lightweight servers. @goran by external server, I mean a server that runs outside of blender. In blender loghc. is limited to the frame rate that is set (logicticrate) and it also runs various other calculations.
by using a sight limit like fog or clipping, you can just use magnitude of a vector between clients to determine whether they are relevant to other clients. If you need any clarification on ideas pm me. I could recommend my multipy library - http://code.google.com/p/multipy which handles all the connections, though it is only a dumb repeater that may not suit the style requirements of your game
impose a sight limit on clients.
force the server to avoid informing clients of clients they can’t see.
at the moment you’re looking at distributed networking. that may be a good idea if you want to have lightweight servers.
This is already part of the plan, but it’s actually distance based update percentage( logical LOD). Besides, that wouldn’t solve the same space in the same scene problem.
When a planet section is generated, it’s actually the planet object that is added to the planet Scene. So for players in different sections of a same planet, they might share the same space, but be in different parts! The scene being the same, the server wont care for it having different objects, all interactive objects have 2 relative positions(stellar level and planetary level), and one absolute position ( galactic level). The server only needs the galactic level for position calculations.
The only way I could use a BGE server(I really want to avoid that) is to scale the game down 10000. And then use the galactic level for Positions. And still wont do collisions, since the planet would be really minuscule…
As for cheating, well, that happens even in fortified games. The planet surface is generated in a semi procedural way. The user sends data about the changes the avatar is making. Each movement have 1/2 sec as min. length. The data is sent and received 4 times for each movement, for guaranteed reception. Every 1 or 2 seconds, the client sends it’s actual position to the server, for correction. Cheating can happen anywhere between these stages, but for that to happen, the network must work in the first place!