Thursday, October 1, 2009

Still alive

Still alive, upright, and taking on oxygen. Game development is on a bit of hiatus while I enjoy some World of Warcraft. Never fear, progress will begin again soon.

Friday, August 21, 2009

Time for sleep

There is a cargo pod in position on the top of the ship. It is not distributed yet. It does not track inventory yet. It pretty much just looks pretty.

I think I know what is wrong with the server crashes. The creator of the object is the only one allowed to destroy the object. Currently it is created and owned by starfieldAI, but is being destroyed by client.py.

I will have to do more work later, 'cuz it's bedtime.

Views

Couple minor changes tonite. Added the ability to change from the "over the engine" view to closer to a "on the bridge" view. Not on the bridge yet though, and not 100% happy with how it looks.

Also trying to get rid of the annoying server crashes. Still haven;t gotten it ironed out.

Think I may spend a late night tonite messing around with stuff. I want to get the mining ship tracking what it has taken in, and start showing the cargo pods in the game.

Wednesday, August 19, 2009

Troubles

Rough night. Tried to break the chat logic out into a separate module / class. It didn't work well. For some reason the client repository wasn't getting references to the chat manager or the asteroids. The only thing I was seeing in the doId2do list was the time manager.

I suspect that for some reason, it wasn't setting interest in zone 101, which is the starting system that includes the avatar, asteroids, and chat manager object. The avatar was being created in zone 101 though. As I understand it, creating an object in an interest zone automatically sets interest in that zone.

Anyway, ended up doing a revert against the SVN server, and got everything reset to where it was when I started and it all works again. Maybe I can create a separate module without making a chat manager class...

Tuesday, August 18, 2009

Chat

Chat is finished. I have the incoming messages displaying in a scrolling area in the lower left of the display, right above the text input line. As a bonus, I can send system messages to the window as well. Special thanks to 'ThatGuy956' from the panda3d forums for most of the display code. I made minor changes, but most of it was his.

The server stability issues *seem* to be resolving. I suspect that it is related to how I was destroying the distributed objects.

Still waiting for a 1.7.0 to come out, and I will put out a couple downloads for people to test out. I would like to see some more stress testing. I have had 4 connections at once so far, but obviously that isn't enough.

Anyway... I will put links to the videos to the left for all to enjoy!

Saturday, August 15, 2009

Login Screen Video

Since videos are so much fun, Here is a preliminary shot of the login page.

Friday, August 14, 2009

Login screen

Late night. I have a preliminary login screen, but I still need to get "Broken Empire" on screen somehow. I know where, and have a good idea for the font. It is just a matter of making it. Animated flying asteroids. Satellite and mining ship on screen. Need to animate those somehow, maybe some blinkey lights, that sort of thing.

Once it is finished (probably tomorrow) I will post it as another youtube video.

Video

Here is the first demo video for Broken Empire. Hope you enjoy it!

http://www.youtube.com/watch?v=jDQZfWdsLko

Wednesday, August 12, 2009

Chat

Well, it isn't as elegant as I would have liked, but I am now able to pass messages between clients as a chat system. Currently the messages appear on the console, rather than on-screen, but that isn't a big deal. Easily taken care of! Also, I only have implemented zone-wide chat. No whispers or kingdom chat at this time.

The downside? I need an actual node path to get the chat manager to instantiate. I may be able to stash() it to keep it from showing up, but it still isn't what I was hoping would work.

I will have to ask a couple questions in the panda forums tomorrow, but I am happy with where it is at for the night.

Oh, btw: Did you notice I mentioned kingdom chat up there? That is going to be the grouping that corresponds to guilds or corps or whatever in other games. You will be able to establish private jump-nodes to other star systems. These will be 2 linked nodes, that cannot go anywhere else. The up side is that if you want to create a private area in the game, you can lock out other jump nodes, and just keep your own grouping of star systems that you and your friends share. Similar to bubbles in TradeWars, which is exactly the type of concept I was looking for here.

I also updated the flight controls so that the ship rotates slightly as you steer, so it doesn't look so fixed in space. As you pitch and yaw, the ship changes the pitch and heading to make the motion more realistic. Someday I will learn how the particle system works and then add side thrusters as well. The only thing I don't like about it right now is that if you release the steering button, it 'jerks' back to center, which can be a bit disorienting. I need to animate the transition back to center, hopefully with a simple lerp() function.

All in all, a good night.

Sunday, August 9, 2009

Checklist

I have posted the starts of a checklist of things to do. As people get a chance to try things out, I would hope that additional items would be put into the comments sections ongoing.

Saturday, August 8, 2009

Database (yay!)

The asteroid field is now contained inside a database. It reads into a list structure that works just like the old one, so the change is seamless. However, it will now be much easier to programmatically change the asteroid locations in the database.

Going back to the earlier checklist I made:


(/)Database (ugh) for persistence.
(X)Respawning asteroids.
( )Jump node between starting point and asteroid field.
( )Chat system.
( )Defining minerals and randomly populating the asteroids with resources.

( )Ship detail database storage
( ) 2d Overlay for ship controls

I will give a half mark for database. I now know what I have to do to manipulate it, but there are obviously more things that need to be done immediately (player persistance, for example). I also need to start saving and recalling ship details.

I guess a jump node would be a good next step, since it is mainly just causing the jump on a collision, rather than from a keypress. I also want to get a chat system in place, and work on the 2D overlay for the game controls.

Friday, August 7, 2009

Database (ugh)

I am in the process of learning database access in Python. It really isn't that bad, it just seems that my brain is opposed to absorbing the info.

The good news is that I have a database, and there is a table defined for all of the asteroids. I have info entered in for 2 of the asteroids, and my small test program is now able to read the field names from the table, read the fields, and put them into a 2 dimensional list. This is the same structure that the current CSV parsing function uses, so if I can build a DB access function to put the data into the same structure, I won't have to change anything else in the program to make it work.

The other good thing is that once I can read the DB in code, I will then make it so I can write the DB in code. At that point, it would be almost trivial to make a solar system editor that lets me drag and drop asteroids into the scene, and get them added to the database on the fly.

Work continues tomorrow...

Sunday, August 2, 2009

Weekend Progress

Slow, but got some done. Asteroids now respawn, and as a bonus, they no longer just sit there. Each client handles spinning the asteroids in space. The AI sends XYZ positional data, and the client puts an HPR (heading, pitch, rotation) spin on it, randomly generated for each asteroid. It definitely adds to the effect.

Still need the database, which is getting more pressing with each step, but will require a bit of research before I can implement it. Also, I want to get a chat system in place for communication between players. And, of course, all the other stuff I said in the last post.

I think I will load it all up to the server and check the outside connection tomorrow. If that goes well, I may let a couple people connect to it and see how little there actually is!

Thursday, July 30, 2009

Baby Steps

I got the starfieldAI program moved to the server. I tested with 2 clients. A bit of an anomaly starting the second one, but it sorted right out, and everything worked fine. What was nice is that I just moved it to the Linux box with FTP, and started it up. No re-writes, re-compiling or anything.

Next steps:
Database (ugh) for persistence.
Respawning asteroids.
Jump node between starting point and asteroid field.
Chat system.
Defining minerals and randomly populating the asteroids with resources.

Not necessarily in that order.

Tuesday, July 28, 2009

Of Servers and Storylines....

I now have an Ubuntu server running the server program. It is still inside my firewall, but I have tested it for a full 10 seconds and it worked perfectly! Next step is moving the starfieldAI program to the server and running it there as well. Once that is operational, I may wait for 1.7.0, or I may find a way to distribute a patched version of the development code along with the client for external pre-alpha testing.

So, storyline:

I have a new basic premise for the game. During the height of the Galactic Empire, many colonization ships were sent off to far flung star systems to expand the controlled territory. Colonists were put into cryogenic hibernation during the light speed transport to the new system, with supplies and instructions to establish a colony and activate a intergalactic jump node to link the new colony into the empire.

Expansionism, however, created a strain on the empires economy, and during the unrest and eventual revolt, the Emperor was assassinated. The fight for succession that followed ended in a five way split of the systems in the empire, with several systems cut off from all others. As you awaken to begin a new colony for the glory of the Empire, you discover that not only is there no empire to swear your allegiance to, there are no empirical support ships following you. You may be able to align yourself to one of the new kingdoms that control most of the old empirical star systems. You may be able to become self sustaining, with no need of royal "protection". Or maybe there is room for a new kingdom... Perhaps even a new Emperor.


It needs work, but I think it works. There are many stories that could be told within this framework that can add some depth. It gives a plausible explanation for the multitude of players starting in there own star system. It allows for purely individual play, or bonding to an NPC kingdom for support. Or, you can trade with independent systems in a more rogue/pirate state arrangement.

Thoughts? Let me know....

Friday, July 24, 2009

Broken Empire

I am thinking of using that as the name. Has a decent ring to it, and unlike my other ideas, there didn't seem to be any other games by that name... Thoughts?

Wednesday, July 22, 2009

Game Title

I really need to be figuring out a real name for this game at some point. Spaceflight is not what I want to end up with. It would sort of be like calling World of Warcraft "Groundwalk". Just not very...... inspiring.

Leave a post and let me know of any suggestions, please.

Oh, and

Free PIE!!!

Multi-Playerdness -or- Free Pie!!!

Hey, remember me?

The distributed object code is now working as I had hoped, as of this morning at about 6:30 am. If anyone ever comes across this blog (most likely by accident, by clicking in the wrong place, or if I manage to trick them into it by making a link that says "Free Pie" and instead brings them here) I want to give massive props to David Rose, of Disney Interactive, who has been absolutely instrumental in helping me understand how this stuff works.

So where is it at? I have a server, which does practically nothing but pass messages between clients. I have a starsytemAI client that currently manages all of 18 asteroids in the game. This will be grown to handle all of the "astral bodies" in the game (asteroids, stars, planets, etc). I have a Player Client (forevermore referred to as the PC) that allows you to log in fly around, and use magic to harvest minerals from the asteroids (there are no animations in place yet, so it just kinda vanishes). As asteroids get harvested, they are removed from the other clients, and if someone new logs in, the asteroids field is accurately represented.

I know that doesn't sound like much, but you don't even want to know what it took to get there...

Anyway, I am waiting for the 1.7.0 release of panda before I can start distributing code. I am using the development version right now, since it is required to support the distributed object stuff. If someone is rabidly desperate to try it out, drop me a note, and I will get everything packed up and sent off. Otherwise, 1.7 is supposed to drop in a couple weeks, and by then, I hope to have a server built and running with an IP address to connect to. Also, I want to start making player state be persistent across logins, which means a database.

Moving ever forward!

Saturday, June 27, 2009

Distributed Objects

I am working on the distributed object model for Panda3d. The good news is that it will make everything work much, much better. The bad news is that it is difficult, and requires a complete rework of the code.

Towards that end, I have started from scratch.

I currently have my server implementing the Message Director, an AI client that handles all of the time synchronization, and a player client that logs into the server, connects to the time sync "channel", and renders the star field. Tomorrow, I will instantiate the ship that is in the video below. This will be created as a distributed avatar. The player client will call it into being, and as multiple clients connect, all the ships will be visible to each other.

It will be beautiful!

After that, I will be making a star system AI that will create distributed versions of the sun, planet(s), asteroids, etc. Space junk will be local to the player client only.

Check back soon!

Wednesday, June 17, 2009

Some Video (I hope)

So, it has been quite a while, but I haven't abandoned the game. I am working on getting the distributed object stuff sorted out, and a decent server set up.

In the meantime, Christopher Spiritstone, My super-fly graphic artist friend, has put together a couple videos of the asteroid mining ship.

I will try to attach it here, otherwise, I will edit this message once I get them hosted properly.



Sunday, May 24, 2009

2 clients!

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.

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.

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

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!

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

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

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

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.

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!

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

Tuesday, April 28, 2009

More code refactoring

The main script file is becoming a bit disorganized. I *did* refactor the code when I had planned to previously, but I think the time has come to break things out into separate classes. The main game class, a new class for the player, another class for the current solar system. This way, if a new system is dramatically different, we can create a class for it, and bring it up when you enter. Carrying this further, I may make a generic system class, and inherit most of the standard operations from it, but still be able to override / extend for special cases.

In any event... Later tonight there will be an update to the latest code. Orbiting is about half implemented. You can enter / exit orbit using the o key, but it is always a latitudinal only orbit, regardless of what your latitude is (even if you are above the 0 degree point). Also, you ext with no speed reference.

Plans will be to make the orbit reflect your entering angle, and add a 'Z' element to the orbit path. I will prolly have to change to calculating the path rather than cheesing out and using an orbit node that is constantly rotating and just attaching to it.

Anyway. It will be a couple days (prolly over the weekend) to get the classes broke out and restructure everything so that it works the same. The result, though, will be significant. This will step it up from being a demo to something usable.

Thanks for playing along!

--Joe

Friday, April 24, 2009

Roll Call

Just double checking to see if there is anyone following. If so, I will continue making updates. If not, then there is really no point, is there?

The current development version has added camera controls so you can change your view of the ship. Allows for some cool views of watching the collisions occur.

Next steps include adding the ability to enter and exit orbit around the planet. Add a starport near the planet. Add the ability to mine minerals from the asteroids, dock at the starport, and sell/buy/trade various materials.

Still kicking around how the multiplayer server is going to work. Part of the challenge is figuring out how to expose a server to outside connections.

Anyway. Please leave a comment to this post if you read it to let me know that someone is there. I will keep posting updates unless and until it becomes obvious that nobody is looking.

Wednesday, April 22, 2009

Collisions

So, the code is a bit messy, but collisions are working. Here is the deal:

Collision spheres have been added to the asteroids and the ship. I turned on the visibility of the collision spheres so that you can see what is going on. The next revision will have the spheres turned off.

Also, because I am impatient having to fly to the asteroids every time I test, I have added another control key. Pressing 'j' will jump you to the next asteroid in the control list.

Other interesting notes. I changed how the asteroids get added to the scene graph. I had been creating instances of the asteroid model but I am better off adding each one separately.

I am also coming to the conclusion that the flight controls suck. I am looking for suggestions on what to do instead of what I have. I do plan on adding a 'semi-auto' pilot function that will allow you to enter orbit around the planet, lock onto asteroids for mining or whatever, etc. Hopefully this will ease some of the control issues.

I am trying to decide where to go next. Part of me says to write a server that will allow multiple connections, the other part of me wants to start working on the piloting and mining functions, as well as building a space port and adding a docking function.

Any votes? Anyone reading?

--Joe

PS: Use the same download zip as before. I have updated it to include the collision routines.

Monday, April 20, 2009

Storyline.....

Some fiction to help set the mood. Written by Sean Crane...

Not for the first time since he took this job, George Walton caught himself wondering what exactly he had been thinking in accepting this contract. George swore softly as he slapped down his engine throttles and masked his ships emission signatures. a slight sigh was the only noise that alerted him to the arrival of his passenger on the flight deck.

"Do we have a problem captain?" asked the neatly dressed humanoid that had just crowded (his? her? it's?) huge bulk into HIS bridge. George thought 'why can't cargo just stay fracking below' to himself for a second before replying. "Not at the moment, but if you will notice, that just happens to be a big hunk of Ta'ren patrol cruiser sniffin' around out there, and I'm pretty sure that YOU really really do NOT want to meet it's commander." 'Personally all I want to do is survive this run, get paid, and then get the hell outta this sector' thought George.

"Well, remember our deal captain, you transport me safely to haven, and your debt to the u'theran consortium is wiped clean. Fail, and there will be NO safe place for you in the universe.... if.. you .. survive"

.......CRAP! "Grab something quick ya overgrown toad. it's gonna get a might bumpy.. those fat cows have spotted us." George's hands flew over the controls as he spun the engines up to max power and prepared to RUN LIKE HELL!

Not for the first time, George wondered just how interesting things could possibly get...

Sunday, April 19, 2009

Asteroid Belt

So I got the file generation and file parsing working! Woot!

There is now an asteroid belt forming a ring 750 units out from the origin point (0,0,0). I also have a program that will regenerate the location file if I need. The good thing is that now they are always in consistent locations, and it is repeatable. If we were to tie in networking for multi-players right now, I could create the same environment for both players. Also, since I maintain an index of pointers to all asteroids, if one gets destroyed, I can pass the index number back to the server with a "destroy" code, and that index then gets passed to all clients, with the command to run the "destroy" animation, and then stop drawing that unit until it respawns.

Good times. I have updated the zip file with a program called AsteroidBelt. Run it and let me know what you think. According to my last post, it is time to do some software engineering work to layout the modules and keep the code efficient. May be a day or two before anything interesting happens.

Thanks for looking!

Debris Field

SpaceFlight.zip

New download. This will be the cumulative package from now on, until it starts to get too large.

The planet is now appropriately larger.

I have accepted the flight controls for now, and have moved on to other things. One of the things I didn't like was that when you were simply flying along, without doing any steering, the painted starfield doesn't move. To try to compensate for that, I have added 10,000 pieces of floating debris. These are small objects that are there to help indicate motion.

Next, I changed the algorithm for asteroid placement. Currently, it is back to being randomly located, clustered around the planet. Also, (if you look at the currently very ugly code) I am maintaining a list of pointers to each asteroid. This allows me to go back during the run loop and update rotational data for each one. If you get a good look at the asteroids you will see that they are all now spinning in space as well. I have no plans on adding rotational vectors to the debris objects, however.

One other thing. If you press the e key, you will be rotated to point in the direction of the planet, and all thrust vectors are zeroed. This allows you to then add a bit of forward thrust, and will fly you back to the planet.

Upcoming plans: Map locations for the planet and asteroids. Read geometry, texture, and locational data from a .csv file and insert them into the scene graph based on this data.

Once I am able to recreate the same system every time based on .csv file entries, it will be time for a refactoring of the code. Get rid of extra crap, and start breaking parts of it out into modules to ease readability.

After that will be collision detection.

If anyone is reading this and wants to help brainstorm ideas for what the user interface should look like, I would certainly love to hear it. I am looking for the 2D overlay on top of the scene graph should look like. Things to include: Simple map of the current system, a radar display of some sort, a simple ship health overview (top view and side view, most likely), some clickable control buttons, and whatever else you may think is needed. Once I get some ideas rolling, I will put something up, even if it starts out as completely non-functional. It will be good to see how the interface "plays" on top of the scene graph.

Friday, April 17, 2009

Flight control test version 2

OK, I got the controls feeling more "floaty", meaning that thrust vectors are cumulative, rather than transitional. Rather than being able to thrust forward at a given speed, then turn left and have your vector change direction, now the speed variable is actually a thrust variable. Currently, if you leave the thrust at a non-zero value, you will accelerate perpetually. That will need to be capped once I have a max speed set for the ship.

Also, If you apply thrust in one direction, then rotate and apply thrust in the new direction, you will have a vector in both directions. As it should be. Q no longer stops motion, but instead only stops thrust application.

Play with it and it will make sense.

Use the same download link as before. If you already installed, it will replace what you had with the new version.


--Joe

And......

I don't like it. It is too abrupt, and doesn't give the feel of weightlessness in space. It flies too much like an airplane, rather than a spaceship.

I will continue to work on the feel of it. let me know what you think of the rest of it, though.

Thursday, April 16, 2009

Flight Control Test

So if you have your C:\SpaceFlight directory created, download and unzip this file:

http://www.jansenphotographyonline.com/SpaceFlight/FlightControlTest.zip

into that directory.

You should have C:\SpaceFlight\models

with several files in it, as well as 2 files in the SpaceFlight directory.

In theory, you can double click "RunFlightControls" and it should fire up.

I did add that steering requires that you click and hold the right mouse button. I also assume that you are using a 3 button mouse.

If you open a Dos prompt, and execute RunFlightControls from there, you will be able to watch some debug info in the dos window while it runs. Good times!

See what ya' think, and let me know.

--Joe

Opening Ceremonies

Ok. For all two of you that may even look here, I decided to give a central location to check for updates, rather than having to look in email all the time.

So. To get started, you will need to install Panda3D. This is the game engine that everything runs against. It is pretty simple. Go to:

http://www.panda3d.org/download.php

I am not using 1.6.0 as it is not entirely stable yet. Instead, scroll down and find version 1.5.4 and download that. it is about 57 MB

Next, run the installer and leave everything as default.

Finally, create a dircetory off of your C: drive called SpaceFlight

This will result in a directory called C:\SpaceFlight

Because I have to create a shortcut to run the file, I need to make sure that everyone uses the same directory to run from. This is where any downloads that you get should go into.

I will have a link to something to download for you pretty soon. The first sample will be nothing more than testing out the flight controls. Currently, I have the following implemented.

Accelerate = a
Decelerate = z
full stop = q
reset position to starting point = x
quit the program = Esc
zoom in and out = mouse wheel

Steering the ship is done by moving the mouse around in the main window. I will probably have it modified to require that the mouse button is held down to steer before I release. The world consists of a planet and a row of 150 asteroids all nicely lined up to provide visual feedback for relative motion.

Once it is posted, test the flight controls and please leave feedback on what you think. This is when I want to work out problems in sensitivity, etc. This version only implements the smallest ship, so it is far more maneuverable than what any upcoming capital ships will end up being.

Thanks again for helping with the testing. I hope that you find something interesting to play with eventually.

--Joe