Status: Contact: Email: fsras(AT)uaf.edu. Aug 28 2005: The latest SVN copy has various minor improvements, including the usage of trees rather than lists to keep track of multiple objects within a sector. This should allow substantially larger sectors without killing performance, and larger sectors allow larger objects in the collision model. This change has broken a few things that were used to looking at the lists directly, however these things should be replaced anyway. I think the damage has been limed to some AI features. Mar 7 2005: I have resumed working on roids, starting from the source available on this site and not the mangled stuff I've worked on since. There is now a subversion repo for roids at this location and I've been toying with things I might integrate here and here. Aug 22 2003: I keep getting hung up on the right way to organize the more complex objects (ships, aliens, missiles). I'm pretty much just going in circles. July 24 2003: The "significant" part of the next update seems to interfere with me doing it. Dec 18 2002: I've made a lot of progress and changes on roids recently, or at least it sure feels that way. Significant particle system changes, collision damage application changes, a new damage-shake feature, a new type of alien, all sorts of little changes to move towards networking, the menu system, and my latest task: total revamp of the sensor/scanner system. I need to get it fixed so that I can get the aliens working right. Anyway the next release should be significant. Dec 7 2002: I started working on Roids earlier this week, motivated by the need to use it for a networking class project. Now that I'm going again I seem to be regaining enthusiasm. I played a lot of games and relaxed a good part of the summer and this past semester, but perhaps I've done enough of that for a while. Anyway, I've worked up a menu system based on the one I was working on towards the end of Roids version 4. I've neatened it up a lot behind the scenes, but it's still a rather work-intensive thing to mess with because the menus are often too diverse to benefit from some sort of object-oriented design. Another work-maker is that the larger fonts used in the menus are something I don't think I could easily arrange to print in game like I have done with the little font, so I have to manually write it all out using the Gimp and import each word as a texture. I also seem to have somehow lost working object-particle collisions. I remember them working somewhere in the past, yet they don't work now and I can find any source where they are working. This is rather annoying. Oct 5 2002: Thought I should mention that roids is still alive, simply laying low because I am a very busy guy these days. I think a fair amount about details of an all-integer engine. May 27 2002: Early today I was able to get roids working on Mac OS9 with Codewarrior 7. I believe it ran faster than on OSX, but more impressive was how smoothly it ran, I'd say easily the best showing by any computer I've seen. Even with the game loaded up so that the FPS dropped to the 30's it played fine, just because it was so smooth and even. I guess 100% CPU hogging helps. But alas, in addition to being smooth, the G4 (800mhz, 2mb L3@200mhz, PC133 RAM, geForce2mx) was also rather gutless. It's performance was nowhere near my Athlon XP (1533mhz, PC133 RAM, G400MAX) when large particle explosions occurred on screen, or when a lot objects were in game. May 26 2002: As of this weekend, I have once again returned to work on roids. I put up a new source tar.gz, complete with a Makefile, Project Builder files, and VisualC files. I also posted a windows binary that should run on any windows machine. One issue that I tackled was the possible need to integerize roids because it is likely that different computers performing floating point math will come up with answers that are very slightly different (I believe we can point the finger at the 80-bit x86 floating point stack, as opposed to the RISC-standard 64-bit and 32-bit registers). It so happens that roids was once an integer program, for a few days during Xmas break, but I converted it to float in order to attempt the asychronous update model, if memory serves. Converting it back seems like too much of a hassle right now though, without even a gaurentee of being possible, so I'll plan to re-sych float values at the end of every turn and hope that the differences are not enough to be problematic. Having been away from the project for months, I was also able to clearly see that my total lack of an official plan was hurting me, because I couldn't remember many of the things that were going on when I put things down, and I found many glaring loose ends. To fix this, I've been working some on a plan this weekend. Not sure when it will be done, but I want it to be the most detailed roids plan yet. January 22 2002: Roids is now using a much simpler conventional iterated update scheme than it was last update. Although this fixed various inconsistientcies between what appeared to happen and what actually happened when roids was running, there was a performance hit of perhaps 30%. I am currently working on adding threading support to this in an effort to increase the number of objects my computers can run. This threading support can be totally removed by removing a #define statement, so there is no performance or portability losses for those who aren't as hot about threading as I. I encountered an odd error in Linux where SDL_CreateThread returned an SDL error of "Not enough resources to create thread" which made no sense to me. After much screwing around (hours), I was at a simple test case, and I found that I couldn't get various pthread things to link (of course all of these things are supposed to be hidden behind SDL). Various experiments later, after adding -lGL of all things, it linked, but generated the same error. Notably, since roids uses GL I was linking openGL, which is why it was compiling for me before. I then tried adding -lpthread (of course "pthread" never appeared in my program, its all hidden begind SDL) and now things linked and worked right. January 17 2002: I've been tinkering with roids a lot, I did some work on it over Xmas break. I've changed "everything," but I'm not currently interested in writing up a plan5 to cover it. I will probably be too busy to do very much with roids this semester. New source and screenshots. November 18 2001: There will be no significant releases in the near future. I have too much crap to do for school, but the good news is that I can get two big research papers on topics related to roids (networking, and the "Orbiting Asteriod Problem"). November 8 2001: I have started to split the shiptype tree between server/client, and I can now confirm that I will not be able to get a meaningful release finished this weekend. I think that I can keep the objecttype general still, but shiptype will need to be split into serverShiptype and clientShiptype (hopefully I don't need a shared branch). From these, each race/clan will likely have a single inherited server side class and a single inherited client side class. One trend I have long been witnessing is the reduction of importance of the ship-specific classes, and now with this re-org the transition should be compete. I had streamlined things enough already so that the only ship-specific functions are two constructors (client/server) and one draw function, which can easily be generalized or loaded into a case statement. Wouldn't it have been neat if I'd thought of this when I was just starting this whole project? Actually back in those days, my goals were somewhat more general and so I couldn't rule out greater ship-to-ship and race-to-race variation... but still I am amazed how much time I spend re-writing things. November 7 2001: I have finally gotten the entirety of roids to compile, however the server executable won't link. This is rather expected. One of the things I did in this latest version (the last few months) is start the separation of variables that are server-only or client-only into headers dedicated to their causes. This works fine until I get into shared classes like the whole shiptype tree, as well as the terriantype tree. The solution is to create branches of the trees specific to server/client (which makes a lot of other things neater too really) but that's a lot of work. :( The whole separation of things into client server based on "where does it need to be?" is actually a very good thing. Although a lot of work, it is possibly one of the best things to happen for organization in a long time. For example, the client executable has thus far been burdened by the entire parttype class tree, although clients never see that stuff (except, some day, as parts floating in space). Shiptypes (well, their children) also have two constructor functions: one only for the server, and one only for the client. Quite pointless. Same goes for drawing, update, and networking functions that hold the features of both. So anyway, this is a good thing. Other than the linking battle, I still need to clean up the server networking. I did get the new code in there and compiling, but now basically everything is sitting around disconnected and worthless. I need to do things like implement handling of new client connection requests again (of couse the old code is still sitting around). Things are really a huge mess in the server still, but at least it'll compile. Actually things are still a big mess everywhere. So after I get this phase done, maybe this coming weekend, then comes the phase where all these dozens of untested pieces are expected to work together. I'll be amazed if there's not some serious problems at first. This is not how things are supposed to be done.... maybe next time. November 3 2001: I did find some time to work on roids. I reworked the menu system, getting rid of the huge switch statements and replacing them with arrays of function pointers (I figure its faster in this application). I got things done enough so that having a working server became a good idea. Of course resurecting the server is quite a job... but after I get done re-writing the networking parts of it... October 30 2001: Woops: sickness, schoolwork, and people who want help on another project mean that roids is gona be slowed down again. I had just gotten the basics of a working menu (and I was wondering if I was loosing track of the interesting parts of the program just to make it complete). Hmmm, actually I've got a big programming project for Numerical Anaylasis coming up this semester too... so I'm gona be busy busy busy. October 16 2001: Today I made a huge breakthrough with textures, and the future is bright. I do not forsee any further delays related to fonts... now I'm working on something of a menu system. October 11 2001: I solved the major problem I was having the past few days. Basically, whenever I ran some GL commands on textures, the stars wouldn't show up (the stars are just normal GL_POINTS). Turned out that in the end, I was drawing the stars with glVertex3f and a z of -2 in a 2D world, which was a holdover from, oh, last Xmas. Sheesh. I did find out a few other useful things along the way, however, so I can't complain. I should now be able to proceed with the replacement of all glut writing. Things look very promising, however my time is still limited. October 9 2001: Some progress has been made on the text front, however I am now up against a bizzarre bug where seemingly unrelated things interfere with each other. This may take some time to resolve. Assuming that happens, I will then finish the removal of all Glut from roids and count myself one step closer to having an SDL app. Major work remains in resurecting the server and moving all threading over to SDL. Following that, I need to learn more about automake (or whatever it is) so that I can get roids running between Linux and OS X with minimal effort. October 2 2001: Uh oh, been working on roids for more than a year. Anyway, today I found a way to do nice GL text over at SDL's openGL page, here, lesson 17. This should allow me to not go to sprites after all, which really would be better. I may try it out this week. I'm not sure what this means for plan #4, which of course is also still under development (and so is full of holes). Sep 15 2001: I have started working on roids again. My progress was stopped by me changing jobs, and a keen interest in not overloading my wrists. I am happy to report that I am doing quite well now. I worked a little more on plan #4. Note that it calls for no 3D acceleration... as in, I'm moving towards sprites! All this in pursuit of pretty text... I think I will try to get the game working with sprites before I try to implement plan #4. I've got the client running in SDL, but its in GL still, and the server is currently broken (for reasons I hinted at july 21st). This will be very messy. July 21 2001: I don't expect that I will release anything this weekend, because I am embarking on an even larger house cleaning project with the code. I just can't get this networking model working right, so I've done some actual reading from an actual book on sockets, and now belive that I can implement a much better solution. While I'm at it, I think I'll go shove things over to SDL and probably break 95% of the project. So I guess we could almost call this "The Roids Project: Version 2". July 15 2001: I cleaned house on the code this past week, removing several classes and simplifying some inheritance. More is probably in store (in the shiptype area). Quite a few major changes involved so far, such as: client's ships now have an object id that matches the client id. I spent a long time trying to cut out all the the ship location jitter, but despite a twice as long, four times as accurate timestamp, and packet filtering based upon that timestamp, it still persists (irratically) at higher rates of movement. I did at least smooth out the main-engine acceleration jitters (thruster anti-jitter is still not implemented). Other than the reduced jitters, movement and collisions work quite well. I messed around trying to improve the object update sending, but I don't think I actually helped it much. I'm seeing more of a mess from client-side mis-guessed collisions that are not caught until much later (perhaps until after the error has propagated through more collisions that weren't supposed to happen at all). Damage works again, the client ship can be destroyed, and the client even displays the crappy explosion. The server isn't really aware of all this though, so it needs to be restarted after each death. I didn't get the status bars working right yet, but they work a little. I'm going to have to change a lot of things for them to work properly. I will probably rework the shiptype packet system a little again. While I'm doing that, I think I will get the fuel-as-a-resource system finished as well. It'll probably be another week before I can start on the SDL port while I get the above stuff done, along with a few visual effects I wanted to add: upon collision, I'll look at getting a ship shake going along with some visual static. July 8 2001: I have mostly completed the transition from the old network model to the new one (the difference being that now the server keeps track of the client ships, and the clients only send key codes). Variable lag (even on my own machine) has been causing quite some headaches, because the updates to the client are always a little off, so the world would shake around it (ship centered). I've fixed that with a 8 bit timestamp (4ms accuracy) for low speeds at least, but the reduced jittering becomes apparent again if the client moves quickly (and during acceleration). I may move to a 10 bit timestamp, but it would mean adding another byte to my packets, so I'm not sure yet. Other new features of this release include the ability of the server to pack multiple "datatypes" into a single packet just before sending it, provided that the server has a backlog and that the whole mess stays under a size limit. I've seen it send up to 4 "datatypes" in a single packet, but most packets still travel with only 1. The status bars and such for the clients are totally broken now though, and I suspect that if two players where in the game together, they wouldn't get updates as to the activities of the other as often as they would like. July 3 2001: From the TODO file: 01. Move client maintenance to server; send keys over network. 02. Fix status output and damage allocation bugs in theoian + upp. 03. Port project to SDL (text is a particular issue). 04. Write up a general, powerful menu system. 05. Complete client/server connections with #4. 06. The dialog box system (complex, far reaching). 07. Smarten-up server's object update to client code. 08. Various ship IU improvements. 09. Inter-client messaging, server-sent messages. 10. Basic projectile weapons. 11. Team selection submenu (pretty complex). 12. Ship selection submenu (pretty complex). 13. Bases (inc AI, repairs, upgrades, docking, graphics...). 14. Black holes (inc gravity, random part selection, new asteriods placement...). 15. Free floating parts. 16. Method to pick up free floating parts and also eject them. 17. Method to handle locations of parts within a ship. 18. Real explosions, particle systems. 19. Enter values for the ship modifiers. 20. Method for changing keys (with playertype, complex). 21. Return to neatening part inheritance, add more parts. I changed too many things (bugs, features) the past few days to remember them all, so I won't even try to list them. I had forgotten lots of little things when I last released and declared last-collision-awareness was "working," such as telling the client that there had been a collision. Well, now that I have it working another problem is apparent: there's too much lag in this system. Allowing the client to manage itself isn't just a HUGE security hole, its not even feasable because it generates too much lag when the server has to step in and announce things like official collisions. The reason why the ship jumps so bad during most collisions is that the server's image of the ship lags behind the player's image, and so when a collision occurs, the player rewinds perhaps 1/20th of a second with the arrival of the official data from the server. This would probably be unbearable in player-vs-player (hum, I need to get that 2nd machine over here...). I originally arranged for local player control to reduce the key lag, but now I can see its not going to work so well. In the longer run, I intend to get this all ported over to SDL, primarily to make it easier to port to other platforms (SDL includes nearly all the functionality of glut, plus threading and timers). The biggest problem is going to be changing all the text in the game from its current script to (probably) bitmaps. One of my biggest problems with bitmaps is the fact their color font isn't easy to change. May 21 2001: It has been about 3.5 months since I last released a version of roids, but I've had enough time and enough wrist-health the past week or so to complete another upgrade. For this version, I managed to get rid of the ugly situation that was the update/establish packet system. In the process (closely related) I completely re-worked the shiptype packet structure, and in the process of doing that I should have fixed another large problem: last collision awareness checking. Basically, what could have happened under the old system is something like this: client hits rock, server does the math and goes about transmitting this fact to the client. The client also is aware on its own, but perhaps just before the collision occurred it had sent out a new packet which arrives at the server after the server has already applied the course corrections to the ship and asteriod. If unchecked, this new packet from the ship could place the ship back in the path of the rock, resulting in a second collision (very rapidly) that should never have happened. With the new system, a collision number is sent to the client, and if the server doesn't see the correct number on incoming packets, they are ignored. There is an issue, however: right now that packet from the server is not arrival-checked... better stay away from busy networks. Feb 25 2001: Yet another weekend down. I am still very busy with graphics, and as all 4 of my hardest midterms are coming up in the next two weeks (easy one is already done), I will certainly not make any progress on this project until at least spring break. Even then, I may have to modify this project so I can use it for cs481 (basically I'd have to make 3D models for everything, add lighting, and add fancy visuals). I would also have to make a windows port again... this means windows networking and threads... Feb 18 2001: Another weekend down. Other than spending some time finally getting solid, fast, 3D acceleration going, I had to work on homework and was unable to work on this project. At least I can call my cs481 work "3D asteriod development." If I have my dates correct, there is only two more weekends between now and spring break. I am still undecided as to if I am staying here (to program) or going home. Feb 11 2001: No update this weekend because I am (trying to) rest my arm. Too much clicking. Feb 03 2001: Two things that are really nice: the server does not seem to crash anymore, and also the asteriod collisions are working correctly. I've been working on those asteriods for sooooo long (never thought it would be so bad), and as far as my excuse about the server... well its easy to miss things in such a large program. So as soon as I tear the concept of update vs full packets from the system, it should be a simple task to fix the other-ship-drawing problem (which came from the growth pattern of the program). After that, the plan calls for messaging, which shouldn't be bad at all (well, with the possible exception of the text input, not sure where that fits into the big interface picture). Those features should be in next weekend's release. Jan 28 2001: Code is cleaner once again, improvements on various fronts, more complete use of mutex locks. The version I posted earlier today has a number of pretty serious packetdatatype linking (loss of, loops, etc) errors I have since found and fixed, but I was hoping to fix a bug relating to shiptypes and the interaction between new and update packets representing them before I put up another version. Also, the server is still leaking packetdatatypes from somewhere. I will probably post another version next weekend with various additional bug fixes and hopefully some new features. Jan 22 2001: A short but eventful day on this project today. A few firsts: first connection to server by remote computer, and first multi-player game. Although that didn't last long due to, uh, problems with the server. Jan 21 2001: Made changes to virtually every file, cleared up lots of ugly things that made me unhappy. I turned nearly genocidal on plain integers, and replaced most of them with unsigned shorts. I created define statements to replace Ushort with unsigned short, Uint with unsigned int, etc. I have also configured NEdit to realize this and do the highlighting correctly, which adds to other handy tweaks I had done to NEdit over Xmas break. My top priorities are now getting the server's decision process as to what to send to the client steamlined, getting the client disconnect working, and then getting collisions working right (and on the server). I intend to make another release after that. For now, amuse yourself with my updated todo list: 01. Smarten-up server's object update to client code. 02. Client exit handling. 03. Network game speed syncronization (pause, etc). 04. Working collision model (server side). 05. Add last collision data to shiptype and its packets. 06. Inter-client messaging, server-sent messages. 07. Fix status output bug(s) in theoian + upp. 08. Basic projectile weapons. 09. General menu options, exiting through menu. 10. Team selection submenu (pretty complex). 11. Ship selection submenu (pretty complex). 12. Bases (inc AI, repairs, upgrades, docking, graphics...). 13. Black holes (inc gravity, random part selection, new asteriods placement...). 14. Free floating parts. 15. Method to pick up free floating parts and also eject them. 16. Method to handle locations of parts within a ship. 17. The dialog box system (complex, far reaching). 18. Real explosions, particle systems. 19. Enter values for the ship modifiers. 20. Method for changing keys (with playertype, complex). 21. Return to neatening part inheritance, add more parts. Jan 18 2001: Not even close to an alpha product. Work with networking and threads has been much more difficult than I had anticipated, but I think that most of that is now behind me thanks to the 3.5 weeks of Xmas break. A peak at my todo list should prove enlightening: 01. Finish server's object update to client code. 02. Client exit handling. 03. Working collision model. 04. Add last collision data to shiptype and shiptype packets. 05. Fix battery level bug in theoian + upp. 06. Basic projectile weapons. 07. Team selection menu (pretty complex). 08. Ship selection menu (pretty complex). 09. Bases (inc AI, repairs, upgrades, docking, graphics...). 10. Black holes (inc gravity, random part selection, new asteriods placement...). 11. Free floating parts. 12. Method to pick up free floating parts and also eject them. 13. Method to handle locations of parts within a ship. 14. The dialog box system (complex, far reaching). 15. Real explosions, particle systems. 16. Enter values for the ship modifiers. 17. Method for changing keys (with playertype, complex). 18. Return to neatening part inheritance, add more parts. To the main roids page.