So I am up to 2 clients, able to connect to the server, and see eachother on the screen.
Now that I have that, I am going to tear the communication apart again. lol. I need to implement packet ID codes, have the server assign clientID rather than hardcoding or typing it in, etc.
With packet ID's, I will be able to add things like asteroid destruction and spawning, etc.
I am still feeling pretty excited. On that note, I am off to bed.
Sunday, May 24, 2009
Friday, May 22, 2009
It keeps getting better....
....and better. I am now researching something in Panda3D called Distributed Objects. Apparently, you can instantiate an object on the server, and by using this distribution model, it will automatically instantiate on a multitude of clients and keep the attributes of the servers instance.
I hope it works that way, anyway. I have an hour long video lecture to watch. After that, a whole lot of reading.
For any who might be following, feel free to drop a note in the comments section, even if just to say hey.
I hope it works that way, anyway. I have an hour long video lecture to watch. After that, a whole lot of reading.
For any who might be following, feel free to drop a note in the comments section, even if just to say hey.
Tuesday, May 19, 2009
Panda-Net
So I abandoned the low level, socket programing, multi-threading stuff. Panda3D supports it's own networking functions, and they work very well. I have 1 client, connecting to a server on a separate machine. The client (laptop) is around 40 fps, which is normal. The server is rock solid at 60 fps. It no longer blocks on network comms, and connections / disconnections are seamless.
Next step is going to have to be some way of identifying the login. For starters, I guess I can have the client just enter a user id number, which then translates to an id in the data structure for sending positions to the other clients. Eventually, that id code will map to a database primary key. The DB will hold all the player info, which will make the login process seem almost like a real game! HA!
I am going to try to set up a computer running the server code that is exposed to the outside world. I will not publish the connection info, but I will give it freely to anyone that asks. I don't want to expose it to people trying to crack the server is the only thought behind that. Before I can do that, though, I need to remove any display rendering from the server. I have cut out the planet, and I have removed collision detection for the player ship so far. Since the client handles collision detection and avoidance, there is no need for redundancy. Note that the server is not yet ready for public use. Don't ask yet. I will let you know. Also, once it does go live, it will go up and down frequently as I work on development.
So, to recap: Client/server is functional for a single client. Next steps:
1. uniquely identify each client so that each client can be rendered onto the other client displays. (assumes multiple client connections to the server)
2. Add the database code so that players status is persistent.
3. make the looting system functional so there is something to be persistent.
That will keep me busy for a while. Throw in there somewhere the process of making a public test server.
Ever onward and upward! Thanks for reading. I apologize for not having anything published for download and testing. If anyone *really* wants something to play with, let me know, and I will zip up the client and server code both, and you can run yor own pair. Note that it will work with both on the same machine, if you like.
-Joe
Next step is going to have to be some way of identifying the login. For starters, I guess I can have the client just enter a user id number, which then translates to an id in the data structure for sending positions to the other clients. Eventually, that id code will map to a database primary key. The DB will hold all the player info, which will make the login process seem almost like a real game! HA!
I am going to try to set up a computer running the server code that is exposed to the outside world. I will not publish the connection info, but I will give it freely to anyone that asks. I don't want to expose it to people trying to crack the server is the only thought behind that. Before I can do that, though, I need to remove any display rendering from the server. I have cut out the planet, and I have removed collision detection for the player ship so far. Since the client handles collision detection and avoidance, there is no need for redundancy. Note that the server is not yet ready for public use. Don't ask yet. I will let you know. Also, once it does go live, it will go up and down frequently as I work on development.
So, to recap: Client/server is functional for a single client. Next steps:
1. uniquely identify each client so that each client can be rendered onto the other client displays. (assumes multiple client connections to the server)
2. Add the database code so that players status is persistent.
3. make the looting system functional so there is something to be persistent.
That will keep me busy for a while. Throw in there somewhere the process of making a public test server.
Ever onward and upward! Thanks for reading. I apologize for not having anything published for download and testing. If anyone *really* wants something to play with, let me know, and I will zip up the client and server code both, and you can run yor own pair. Note that it will work with both on the same machine, if you like.
-Joe
Sunday, May 17, 2009
server connection
So, there is some progress.
I have forked the development to consist of a client and server version of the base code. The two will evolve separately now.
Currently, the only thing working is that the server supports a single client connection. This client connection sends the ship's positional and orientational (X,Y,Z,H,P,R) data to the server. The server display is then updated to reflect the new values. Biggest problem? My server computer framerate dropped from 60 fps to 5 fps by doing this.
I think the problem is that the current code does not launch a separate thread for communication, so all comms are done in the main thread. The sockets are supposed to be non-blocking, but I think it will come back up when I start threading and passing data through a queue. I currently check the socket for data after each frame render, and parse the string if it is there.
Going forward, I think I will (obviously) thread each comm channel separately, and do a back and forth communication. Ie: the client talks, then waits for the server, then talks, then waits. This back and forth will need some short-ish timeouts set so it doesn't hang, but by doing the exchange this way in a unique thread, the rendering engine should be able to run full speed again.
Yay!
I have forked the development to consist of a client and server version of the base code. The two will evolve separately now.
Currently, the only thing working is that the server supports a single client connection. This client connection sends the ship's positional and orientational (X,Y,Z,H,P,R) data to the server. The server display is then updated to reflect the new values. Biggest problem? My server computer framerate dropped from 60 fps to 5 fps by doing this.
I think the problem is that the current code does not launch a separate thread for communication, so all comms are done in the main thread. The sockets are supposed to be non-blocking, but I think it will come back up when I start threading and passing data through a queue. I currently check the socket for data after each frame render, and parse the string if it is there.
Going forward, I think I will (obviously) thread each comm channel separately, and do a back and forth communication. Ie: the client talks, then waits for the server, then talks, then waits. This back and forth will need some short-ish timeouts set so it doesn't hang, but by doing the exchange this way in a unique thread, the rendering engine should be able to run full speed again.
Yay!
Tuesday, May 12, 2009
Update.
Just an update to say that there are no updates. I am busy getting a website launched at work, which is slowing down anything else that I am doing right now. Hopefully will get the server going soon!
Sunday, May 10, 2009
Idling....
No, not the real-time python interpreter. Not much progress was made this weekend. Hopefully I will get more time to work on it through the week. Getting a plan together for the C/S stuff is going to require more planning than I have done so far. I want to make sure that it gets done right the first time.
More updates as events warrant.....
--Joe
More updates as events warrant.....
--Joe
Saturday, May 9, 2009
Some progress
OK... So I got a multi-threaded echo server functioning. Now I just need to figure out how to roll that into my game code. I am trying to decide what should be done locally at the client, and what should be done on the server.
As far as I can determine right now, the server needs to handle all NPC activity. It needs to handle things like asteroid spawning, and loot table population, but I think that once it is spawned and populated, it should be handed off to the client completely, since it is non-mobile. If a player harvests the asteroid, the client should send a "start mining asteroid 'X'" message, the server should respond with a status message that the requesting client has exclusive access to the asteroid at that point. The client then animates the mining process, plays the destroy animation, runs the looting process, and tells the server at some point in there that the harvesting is finished. If the client requests to start mining, and someone else already has it, then the server would deny the request, and the client would play some sort of 'blocked' animation.
Each update would consist of the client sending it's current X,Y,Z,H,P,R data to the server, and the server sending back NPC and other player data back, along with any asteroid destruction data, etc. My biggest concern is how to perform some sort of culling process so that characters (player and NPC) that are not in view, or nearby, don't have to have positional data sent. Also, some method of adding and removing player avatars into the update list because of login, logout, disconnection, or entering / exiting the solar system.
This was a "stream of consciousness" post. If it doesn't make sense, I will fix it later.
-Joe
As far as I can determine right now, the server needs to handle all NPC activity. It needs to handle things like asteroid spawning, and loot table population, but I think that once it is spawned and populated, it should be handed off to the client completely, since it is non-mobile. If a player harvests the asteroid, the client should send a "start mining asteroid 'X'" message, the server should respond with a status message that the requesting client has exclusive access to the asteroid at that point. The client then animates the mining process, plays the destroy animation, runs the looting process, and tells the server at some point in there that the harvesting is finished. If the client requests to start mining, and someone else already has it, then the server would deny the request, and the client would play some sort of 'blocked' animation.
Each update would consist of the client sending it's current X,Y,Z,H,P,R data to the server, and the server sending back NPC and other player data back, along with any asteroid destruction data, etc. My biggest concern is how to perform some sort of culling process so that characters (player and NPC) that are not in view, or nearby, don't have to have positional data sent. Also, some method of adding and removing player avatars into the update list because of login, logout, disconnection, or entering / exiting the solar system.
This was a "stream of consciousness" post. If it doesn't make sense, I will fix it later.
-Joe
Subscribe to:
Posts (Atom)
Posts
