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
Friday, May 8, 2009
Server...
It is going to be a few days before the next update comes out. This weekend is going to be spent writing a server of some sorts. Initially, it will most likely run as a loopback only. Once that is done, the loot tables for the asteroids will be populated. A server will be set up to allow testing inside the house here. If anyone expresses an interest, I will expose a server to the world that will allow others to try it out.
Let me know if you are interested. Otherwise, thanks for reading and following along!
--Joe
Let me know if you are interested. Otherwise, thanks for reading and following along!
--Joe
Wednesday, May 6, 2009
Get Phat Lewtz!!!
Another day, another update. Tonite, I added the beginnings of ore harvesting. Although currently, each asteroid only awards "Phat Lewtz", there are a few things behind the scenes.
There is a number after the lewtz. This is the index into the array of asteroids. This number lets me keep track of each asteroid in the scene. This data will include what the asteroid will award when harvested, and will also contain the respawn timer. Further thought may allow me to remove that array, put the awards onto the nodes using the addTag() function. Destroyed asteroids can be added to the master schedule for respawning when the time comes, etc. I will have to decide whether I can do that.
Also, there is now a maximum range on how far away you can be and still harvest the asteroid.
Bugs: The max speed that I added is having a problem. Once your overall speed (indicated in mdata) is equal/grater than 10 (max speed) it won't let you turn around and thrust in order to decelerate.
Next Step: fix the bug, and add the ability to auto-pilot towards clicked asteroids that are outside of harvest range.
Enjoy! The download link to the right has been updated.
There is a number after the lewtz. This is the index into the array of asteroids. This number lets me keep track of each asteroid in the scene. This data will include what the asteroid will award when harvested, and will also contain the respawn timer. Further thought may allow me to remove that array, put the awards onto the nodes using the addTag() function. Destroyed asteroids can be added to the master schedule for respawning when the time comes, etc. I will have to decide whether I can do that.
Also, there is now a maximum range on how far away you can be and still harvest the asteroid.
Bugs: The max speed that I added is having a problem. Once your overall speed (indicated in mdata) is equal/grater than 10 (max speed) it won't let you turn around and thrust in order to decelerate.
Next Step: fix the bug, and add the ability to auto-pilot towards clicked asteroids that are outside of harvest range.
Enjoy! The download link to the right has been updated.
Tuesday, May 5, 2009
New Version
I have set up a new download. Look right for the link. SpaceFlight000b.zip
Inside are 3 python files, and a shortcut to run the game.
Orbiting is removed. It sucked. Camera control is temporarily disabled. I need to make it share button 1 nicely. What does it need to share with? I am glad you asked!!!
use the j key to jump to one of the asteroids. Click on it. It vanishes!! Woo!
Ok, maybe it isn't that exciting, but being able to select asteroids, and know which one is selected is the first step towards a semi-auto piloting system, as well as being able to mine the asteroids. And asteroid mining is where the game starts. Honestly, this is good stuff.
The plan is to test how long the button is pressed. If it is pressed and released within a second, then it is selection. If it is held, then it will be camera flying. If you check carefully, you will notice that the current selection doesn't actually happen until the button is released.
Cheers!
Inside are 3 python files, and a shortcut to run the game.
Orbiting is removed. It sucked. Camera control is temporarily disabled. I need to make it share button 1 nicely. What does it need to share with? I am glad you asked!!!
use the j key to jump to one of the asteroids. Click on it. It vanishes!! Woo!
Ok, maybe it isn't that exciting, but being able to select asteroids, and know which one is selected is the first step towards a semi-auto piloting system, as well as being able to mine the asteroids. And asteroid mining is where the game starts. Honestly, this is good stuff.
The plan is to test how long the button is pressed. If it is pressed and released within a second, then it is selection. If it is held, then it will be camera flying. If you check carefully, you will notice that the current selection doesn't actually happen until the button is released.
Cheers!
Sunday, May 3, 2009
Redesigning the code....
Wow....
Well, Progress continues on the code design. I am splitting it up into 3 files. A main game file, a file for player class and function definitions, and a file for solar system classes and functions. The biggest pain is that I am learning python and Panda3D at the same time, so things sometimes feel a bit slower.
In any event, I *am* making progress on it. I am removing the orbit stuff while I do this because it was completely sucky. I will be reworking the orbits later.
I am still not real thrilled with the flight controls. I would definitely love some feedback on how to make this better. I am almost tempted to use a joystick, although I know that would limit the number of people that can play. Dunno yet. Maybe once I get the auto-pilot-ish thing working, it will get better. I guess I can implement it enough that there won't be much need to take manual control very often.
Multi-player is still in the near future. Obviously testing amongst the computers here at the house will be easy, but if anyone else wants, I will expose one of my computers to the network for login.
Finally, I ran fraps on my laptop to check framerates. As a result, I turned down the amount of junk that floats around. I am down from 10,000 to 2,000 pieces. at 10K, with a scaled down ship and a much more scaled up universe, I was running about 3 frames per second. I tuned down the universe some, and reduced the junk count, and am back to about 47 fps. For the laptop, I think that is prolly good. Once the refactor is complete, I will throw it on the desktop and see what it does.
Thanks for playing!
*UPDATE*
The scene is rendering properly again. I have not yet implemented any of the keymapping or event handling, but that should be easy enough to finish off tomorrow. The whole thing turned into a re-write of the code, since it was actually easier than trying to shove what I had into the new data structures. I guess when I am done, it will have to be version 0.0.0b lol
Well, Progress continues on the code design. I am splitting it up into 3 files. A main game file, a file for player class and function definitions, and a file for solar system classes and functions. The biggest pain is that I am learning python and Panda3D at the same time, so things sometimes feel a bit slower.
In any event, I *am* making progress on it. I am removing the orbit stuff while I do this because it was completely sucky. I will be reworking the orbits later.
I am still not real thrilled with the flight controls. I would definitely love some feedback on how to make this better. I am almost tempted to use a joystick, although I know that would limit the number of people that can play. Dunno yet. Maybe once I get the auto-pilot-ish thing working, it will get better. I guess I can implement it enough that there won't be much need to take manual control very often.
Multi-player is still in the near future. Obviously testing amongst the computers here at the house will be easy, but if anyone else wants, I will expose one of my computers to the network for login.
Finally, I ran fraps on my laptop to check framerates. As a result, I turned down the amount of junk that floats around. I am down from 10,000 to 2,000 pieces. at 10K, with a scaled down ship and a much more scaled up universe, I was running about 3 frames per second. I tuned down the universe some, and reduced the junk count, and am back to about 47 fps. For the laptop, I think that is prolly good. Once the refactor is complete, I will throw it on the desktop and see what it does.
Thanks for playing!
*UPDATE*
The scene is rendering properly again. I have not yet implemented any of the keymapping or event handling, but that should be easy enough to finish off tomorrow. The whole thing turned into a re-write of the code, since it was actually easier than trying to shove what I had into the new data structures. I guess when I am done, it will have to be version 0.0.0b lol
Subscribe to:
Posts (Atom)
Posts
