Feb 10th 2001 (saturday) Felt like placing an update here. I did not end up finding time to work on this project over the summer as planned, and when the school year began I (eventually) got to work on a new project: the Roids Project . I have learned a lot doing that one, and some day I still hope to be able to come back and make a whole new version of this game. April 17th (monday) Presentation done, project to back burner. I do have more screenshots and such to put up (as well as getting all the parts of this page done), but since there is no grade for any of that, its not even close to the priority. April 16th (sunday) I think I am about done programming for a while now, at least on this project. I hope to get Scott's stuff worked into mine today, and then we'll have the 4 AI's finally united, and ready for the presentation. April 15th (saturday) Today and tomorrow are all that's left on this project. I tweaked the graphics around more and succeeded in getting a pretty nice speedup in some situations, but mostly the difference isn't very noticeable. My GL code is just not very efficient at its core, but I can't fix it without doing some really tricky things (in other words, its gona stay sort of slow). I also fixed a small movement bug for Spot and Stapler, and messed around a little with Stapler's ship building. Stapler is also now a base-building fiend, running around with armies of convoys and MB's (when there is sufficient money) and sometimes literally chasing the survey ships accross the map with poorly-arranged mobs of bases (organization takes a back seat when everywhere becomes crowded with bases). In addition, Stapler now differentiates between "war" fleets and "survey" fleets as Spot does. Survey fleets grab things near them first, while war fleets tend to run off on grand adventures to surround planets or whatever else it is that seems valuable to them at the time. A list of things that I could improve about Stapler is already emerging, before I'm even done. Those things are going to have to wait for the next AI, whenever I do that, which will actually probably happen this summer. I have also now came apon the latest bug (there seems to be a requirement that something is broken all the time). This one manifests itself as a rare segfault that seems to be related to the activities of convoys and their organizing and re-organizing of their fleets. So far I've had two games die due to it, and so I guess that makes it official. My new pathfinding function I just completed thursday (used by convoys and mobile bases) has become noticeably slow, but only in really really nasty networks of bases, and even then its not a problem unless there happens to be a couple dozen convoy+mobile base pairs running about. April 14th (friday) Today I messed with various elements of how Stapler decides where to put bases, and right now it seems to deploy bases correctly with multiple convoys and mobile bases in action at once. Other than that, I took a lot of screen shots, examined things to see if they were actually working, and finally figured out a bug I've been seeing in the graphical output. That is actually a breakthough, and could lead to a pretty big graphics overhaul, but maybe not before the presentation. I have done what amounts to a minor overhaul already tonight, but the improvement is small to my eye. I will tweak the graphics some more tommorrow and figure out just how much I've been able to gain. Having talked to Adrian some about GL last night, I gained some ideas about ways to really streamline the graphics, but they are going to be very difficult to implement. I may still attempt to do so, wether or not I do depends on a lot of things. I would like to have things run faster... April 13th (thursday) I got the pathfinding working now, and judging by the improvement in the way the AI's now deploy their bases, I can safely say that the old one was not only slow, but it was broken (there are quite a few screenshots showing the broken base deployment, such as #119 from April 3rd). I guess I broke it somehow when I was optimising it a week or two ago. Anyway, its good to get that out of the way. I also squashed a bug in a section of code that Fungi, Spot and Stapler all use that was causing fleet organizational mess-ups, which was also getting in the way of base deployment. Things are now running smoothly. Stapler has taken another big step away from my other two AI's today. It uses a completely different method of deploying bases, or rather deciding where to put them, that is fairly simular to the way normal fleets decide where to go. In doing this I did find something interesting though, and that is that there is some serious overhead to making function calls. I found this when I used the new and fast "all hexes" function to gather all of the hexes from the map by its usual recursive method. This proved to be very slow, and so I made another function specifically for grabbing the whole map (and returning it as a linked list of 10000 hexes just as the recursive function does), which does it all in one sweep. The speedup seems like its 100-fold, but I can't tell for sure. This brings me to an interesting question: what exactly is the penalty for calling new functions? In this situation there were a lot of if's involved also, which were completely elliminated in the purpose-built function, so things are not clear cut. I also just figured out why the project keeps locking up... long story. Basically what is happening is that two threads are running through the map making linked lists out of the hexes using the "all hexes" function, and when they get near each other, they re-link each other's hexes and make a huge mess, generally ending up stuck in loops. They wouldn't ever get near each other if the amount of work to be done was split evenly between the left and right sides of the map, but that is never going to happen. With that problem fixed, new opportunities to tweak appeared, and so I went ahead and changed around the way the Stapler map-evaluating threads did their work. They now work towards each other from opposite corners of the map, and they stop when they encounter each other. This means that the load is always balanced now. Scott has also made progress with his AI named Eunich, if I spelled that right. This weekend we'll have some good 4 way AI surveying competitions, looks like. Perhaps tomorrow I'll have him running on the updated engine, and we will be able to exchange AI updates freely. April 12th (wednesday) Time is really running short now. Two week days, two weekend days, and then its the presentation, and I will be able to do just whatever I want with this project. I was able to get at the project for a number of hours today, and was able to nearly hammer out the new pathfinding function that I had started to work on sunday. The new one is gona be way way faster, but it doesn't do some rule checking (yet) because that can be overlooked in the short term (it doesn't matter for this project). I was becoming very suspicious of the old function anyway, because I hadn't figured out why in the heck bases were being placed like they were. This new one is working great, except for a small bug I am sure I'll see after get some sleep. Which I am going to do now. April 9th (sunday) Well my AI homework is going much faster than expected, and so I can get more of this project done that I had thought. The first thing I did with all this time was attack that "all hexes" function that was slowing things down so much (it was used a heck of a lot). It wasn't nearly as hard as I was thinking, so all that moaning was for nothing. Run speeds are up considerably, especially when dealing with large radius search areas. Stapler now calculates its map values for each hex from every hex within a range of 6, compared to 3, and it still runs faster. Other than that I didn't get anything really big done, but I did start to work again at the pathfinding function. I remember that I've read something about data searching falling under the general title of AI... that helps me not feel bad for spending who knows how much time trying to get this darn thing going good and fast. I've also spotted a so-far unexplainable bug that hangs the game occasionally while Stapler is searching out the whole map. Adrian has said a thing or two about threads having trouble when they go get the same data at the same time, and that certainly could be happening, but I though I'd handled that. I don't see how it would cause what appears to be an endless loop, either. Oh well. What's a program without bugs anyway... Well I am guessing that this is gona be the last time I post till friday or the weekend, and after that comes the presentation. After the presentation, progress will probably nearly stop until school is out (and I have time again). April 8th (saturday) I fixed a small bug in the "link all hexes" function that was giving one range too small a result, and also fixed a bug in the function that draws the hex values to the screen that I talked about yesterday (it was allowing certian values to be drawn as black when they were no supposed to be). I also fixed numerous small bugs with the interaction of auto-center mode and the other modes that were resulting in double-distance jumps when the mouse was clicked. The fact that another whole ring of hexes is being linked by the fixed "link all hexes" function has slowed everything down an awful lot. It doesn't help that I've got my computer at 2x 413mhz either... it needs more speed, but when I run it faster under Xwindows it can't be trusted, and I can't work all day under the threat (nearly 100% chance) of crashing. I am still not sure I want to implement the faster hex-linking function either, cause there isn't a lot of time left to work on this project (and the fix isn't gona be easy). Not including today, I've got 3 weekend days and 5 school days, during which I've got to write a big paper and do my AI take-home test, in addition to the normal stuff. The end draws near, yet the project continues, and the things that could be done stretch out of sight. I started messing with my next AI today. This one is named Stapler, and has a different approach to how it directs its fleets. Spot and Fungi could be described as being bottom-up controlled, but Stapler is top-down. The key to this is that it doesn't simply examine a radius around each fleet and then move that fleet accordingly. It examines the whole map, and when I get to it, it will be able to direct its fleets to do things based upon everything, not just what happens to be near the fleet. Unfortunately, this new approach is bad for run times. Each Stapler traverses the whole map and for each hex it takes every hex within 3 hexes and uses them for calculation. I don't see any way around this type of approach. I did multi-thread the search though (for a 2x speedup), so now the system load tends to hover around 5 while simply running two setis and the project. Just how bad run times have gotten now surprises me. I started a game and set it for 50 turns are 10:30, and now its 1:00 and it has made it to turn 41. This is way too slow. Actually the hex-linking function is to blame, so it may just be worth my while to sit down and apply some serious time to that, even if it does take away from the real idea here: the AI. April 7th (friday) Today I tried to find the source of some bad decisions on the part of Spot, and in doing so, decided to implement some new graphics modes to help. Now I have another graphic mode that will show how much Spot (and any other future AI that is programmed to take advantage of this feature) values different hexes around the map by coloring the hexes shades from purple -> blue -> green -> yellow -> red. I also added a step-by-step fleet movement mode which allows an AI programmer to see things happening (usually things go much to quickly). Fixed a number of small graphics glitches as well. I took that picture to the right while running the project full bore. Two points of the system load are from seti@home, two or so are from the project itself, and the rest must have somehow come from taking sceenshots. April 3rd (monday) Too much stuff to do over the weekend to attend to this project. So far today I got Spot's ship building working correctly, tweaked its warship movement some more, improved the way ships to be built are selected, and improved its war/peace decision making (which remains pretty bad at this time). More important than all of that, however, is the Survey fleet movement improments, which clearly set Spot apart from Fungi now. Some examples of this are over on the screenshots page. March 31th (friday) A little update on yesterday: I actually have gotten the pathfinding running a lot faster now, through rather simple optimizations. It no longer seems to be much of a problem. I figured out how to do the "all hexes" function much much faster without any multi-threading but still using recursion. I haven't done it yet, and probably won't till I get some sleep. I was up awful late last night. Messing around with Spot. Improved the "bully fleet" movement, the war decision process, and the ship building. I hope to implement a way of getting fleets that are completely surrounded by explored hexes across the empire to areas where things are happening, and to improve the base placement, which isn't real well done right now. March 30th (thursday) The function that returns a linked list of all hexes within some range of some hex is complete now, and it is reasonably efficient. I've already made Spot do some pretty neat stuff with it, and it should become one of the most heavily used functions. Unfortunately, the running speed of the project is now suffering from each fleet having to search out its own surroundings each turn, and on long runs it drags. So I tried to multi-thread the "all hexes within range" function, but every time I try to multi-thread something I end up finding that it won't work very well. I did speed up the "all hexes within range" function though, and I tried a failed to use it in the pathfinding function. I still may be able to multi-thread the "all hexes" function, although its gona be tricky, and I also want to multi-thread the brute-force map search. I've got to get the other CPU into the fight before this thing slows down even more. Right now I don't run beyond 20 or 25 turns because of the speed, and the fear that the pathfinding will find a worst-case and basically stop the run in its tracks (extending it to an hour or more). Actually the worst-case of the pathfinder is so bad that if all of the races found one at once, a 35 turn run could take more than 24 hours. Good thing that the general case is pretty good. Accomplished: 1. Completed the "all hexes within range" function. 2. Worked at speeding up pathfinding and the "all hexes" function. 3. Made Spot much more intellegent about how to explore. 4. Worked on Spot's war-making methods. 5. Found and fixed a bug in fleettype::x, the main fleet movement function. March 29th (wednesday) Well I get to work on this project tonight pretty much all night, and that makes me pretty happy. I don't get enough time to play with this. 18 days, not including today, before presentaion time. Accomplished: 1. Began to make a function to more effieciently find all hexes within a range. 2. Updated Spot, worked on improving its movement. 3. Fixed a little peace/war bug that I had accidentally introduced to Fungi. 4. Made mouse-clicking work near perfectly for hex selection. 5. Fixed odd double-move bug when navigating around with mouse clicks. March 28th (tuesday) Well I think I have about run out of major things to improve about the graphics side of the game, other than complex mouse-clicking operations. Combat is still a major project, and retrograde, reaction, and strategic movement all still need some attention. They, at least, are not critical to the AI's. But heck, this whole thing could be a project as is, the idea being to conquer as much turf as possible without killing anyone. Scott is getting geared up to do his AI.... soon, soon there will be a big 3-way AI territory-grabbing showdown. Accomplished: 1. Made info window work, eliminated (replaced) the second stand-alone window. 2. Made a mini-map (also can be turned on/off). 3. Gave combat its pop-up own window, eliminated old combat stuff. March 27th (monday) Well I am leaving the pathfinding as-is for now, since it works ok. I threw together a sorta-good territory claiming routine too, so that now empires take each other's hexes. The last great hurdle is combat, I think. I am leaving some things less-than-perfect, but I need to remember this is an AI project and so I should make sure the AI is fully featured when the due date comes. That day is in 20 days, not including today. 6 weekend days. I would like to begin the big push towards smart AI soon. I was running low on desire to work on combat, so I made mouse-clicking do useful things and started work on the new info-window (transparent rectange on top of the map, can be turned on/off). From the results of that experiment, I think I am going to revise the way combat looks also, and have that also appear on top of a transparent rectange. Accomplished: 1. Simple territory conquering. 2. It is now possible to select hexes and navigate the map via mouse clicks. 3. Started work on new info-window. March 26th (sunday) Didn't have a lot of time today, but I did get the pathfinding done. I am amazed how fast it was to program, once all the other peices were in place. I mean, I was afraid of it, but it too perhaps an hour, including debugging. In order to speed up the pathfinding in the general case, I have been working on mutli-threading the pathfinder. Does't work yet, but the other thread does sit there and waste its own CPU just for fun while the real work is being done. I will actually make it productive as soon as I can. Sure is neat (for me) watching a program I made peg both CPU's at 100%. Actually, including the graphics thread, this thing maxes out a total of 1374mhz worth of CPUs on a regular basis. Neato. On the down side of things, all this whipping of poor ol skud has brought back the compiler errors pretty bad, so I am definately thinking heat. Running at a system load of only 3.2 for extended periods of time shouldn't be a problem for a dual, but it seems to be for skud. Need to reconnect those 9's that I unplugged cause I didn't think I needed them. Accomplished: 1. Made pathfinding work, although in worst case, it can be terribly slow. 2. Moved some rule enforcement from Fungi to pathfinding. March 25th (saturday) I've been busy with physics and english today, but I found some time to work on this project. Accomplished: 1. Added more rules to mobile base and convoy operations. 2. Fixed an odd bug in Fungi that caused the game to get stuck in a loop. 3. Fixed a small (but annoying) bug in racetype::addFleet. March 24th (friday) I made no actual progress on the project today, but I did update this webpage a little and I took a few screenshots. March 23rd (thursday) As I am sure you can see, I have done a lot of work on this page today. I kept plodding along on the project today (along with an english paper). I did make some good progress yesterday. So far this whole busness of working convoys, mobile bases, and base construction into the game (and the Fungi AI) has taken at least 400 lines. Before path finding. Before Fungi is even making intellegent decisions on what sort of base to build, or even very smart decisions on where to put it. Geez. Turns out that there is just so much to do with these last few tasks that I can hardly keep focused on what I am doing at any one moment. I need to change things here, things there, things everywhere, and then when they are all changed and debugged it generally does what I expect. I wish I had another spring break. Another week without distraction. I was noticing today that the records the game is keeping now cover no less than 15667 race-turns, which is different from game-turns cause each race has one turn per game turn. Anyway I think thats a lot. And I haven't recorded very many of the short games I run for quick tests. Accomplished: 1. Made Fungi build bases. 2. Added new methods of building bases. 3. Began to add fleet reorganization to Fungi. 4. Enhanced the addShip function. 5. Eliminated the starting BS and the old way to build bases. March 22nd (wednesday) Doing some work today. I started to tackle some particularly daunting tasks, such as convoys, base building, path finding and enforcement of the "one fleet moves at a time" rule. The date has also been set for the project presentation. We have 25 days, of which 8 are weekend days, to finish this project. The talk is to be one hour long. Wow. Accomplished: 1. Implemented the "one fleet at a time" rule. 2. Updated the ship data files. 3. Began the process of getting the convoys and bases going. March 20th (monday) No real work on the project today, but I messed with the website a little. The screenshots are still here. March 18th (saturday) Things are gona be winding down for me on this project, because school is getting started again. Today I worked on my physics project a fair amount, and I will probably move onto other subjects as well, so I won't be doing anything more for this project this weekend. March 17th (friday) Well today I messed with graphics a fair amount and have since been working on making combat and all the related ins-and-outs work. I may get it working tomorrow. I have been taking screenshots, available here, of each game I test as I go, and right now I've got 8 different games at turn 50 posted. Worth a look, and the .jpg's are pretty good quality too. Accomplished: 1. Made progress toward combat on several fronts. 2. Added small features to graphics, boosted run speed by 20%. 3. More small improvements in war/peace decisions. March 16th (thursday) It is quite clear that Fungi is going to be improvable. This whole busness of deciding when to fight and when not to, for one thing, is just a bunch of arbitrary numbers thrown together in arbitray formulas that generate a result apporximately like what I want to see. Of course that result has no units, so its hard to appoint an action threshhold, I mean, what does "1" mean, or ".561" or any other number? There are many elements of Fungi that are not very well designed, in fact, and I think when scott gets back we're gona really set out to make a whole new AI, the goal being to slap Fungi silly. The only big thing left to do, besides more arbitray formulas inside Fungi, is to implement combat. Well, actually thats not true, we need reaction movement, retrograde movement, strategic movement, and methods of building bases in deep space. I am slowing down some on my getting the truly ugly functions, like pathfinding and combat, done. Instead I started messing with a new AI, which I named Spot. I am getting soft, after only a week of 12 hours a day... In other news, I also found my way back to graphics today, and I spent a number of hours trying to reduce the latency and increase the refresh rate of the viewing window. I did not accomplish much, but I did discover that drawing the hex lines slows the thing down to 2/3 of no-lines mode. I am also getting very tired of what would appear to be a still-broken planet placer. It seems to ignore star density, and so tomorrow I think I'll actually have the program count everything and find out. Accomplished: 1. Made strategic and retrograde movement work (sort of). 2. Added a number of general use "has a..." and "is a..." type functions. 3. Modified the game for random selection of multiple AI versions. 4. Added new graphics options, spead them up some, added frame rate counter. 5. Expanded the ship files. 6. Sped up the threat evaluation quite a bit in complex situations. 7. Reworked the enumerated type clas. March 15th (wednesday) There was a time when the game ran so fast that there was no way that the graphics could keep up: 10 turns a second. A turn being each of the 15 or so races moving once ("once" meaning all of their ships six times). I was thinking about things like building in delays so that we could have the view follow the action around. But then I implemented an inefficient function that, for each race, scans the entire 10000 hex map perhaps 20 times every turn. That fixed it, now we run one turn every 3.8 seconds (update: I got it down to a turn each 2.2 sec). Of course the function in question has a good use. Soon the races will be able to detirmine, without a doubt, which neighboring empire has all its stuff closest to all the empire in quesiton's stuff. This is an important part of figureing out who needs to be attacked first. Accomplished: 1. Made significant progress toward Fungi making proper war/peace choices. 2. Added record write-out so now records are kept of every game. 3. Changed recordtype from local-function-creating to a main-function-creating. 4. Improved Fungi's warship building: now it builds a bigger variety. 5. Unit research is now allowed before encounter (at a greater price). 6. Various tweaks (ship dependencies, race colors, random planet placement, etc). March 14th (tuesday) I know its been a long day when the things on this list seem like yesterday. I mean it feels weird reading about the cheap ground bases... really odd. Today I did a bunch of things that moved the project towards the AI-only development stage. It won't be that much longer before Fungi is capapble of making war/no war decisions based apon its environment, and after that I think its time for the actual combat resolution. That is going to be pretty hard, because it deals with multiple AI's at once, for one thing, and is going to use a completly different GL look from the rest of the game, for another. Accomplished: 1. Made encouters work. 2. Fixed empty fleet deletion bug. 3. All ship operations are now conducted through functions. 4. Fixed random immediate segfault bug (I think). 5. Fixed a bug where the buildtree was being made backwards. 6. Fixed a bug where shipdatatree was called instead of buildtree. 7. Made trade go. 8. Added neighborly respect into Fungi's little brain. 9. Made file I/O work for Fungi's extra variables. 10. Supply now takes into account the whole supply grid. 11. Cheap ground bases auto-build on all inhabited planets. 12. Made icons for base-only fleets. March 13th (monday) I spent many hours today fighting with the range function. It made my head hurt. In the end I used GL to show me what was going on with ranges, and then I was able to solve it within 15 minutes. I took a few screen shots of what was going on, available here, but those are possibly not going to be very interesting. One thing that is interesting, though, is that I could implement "fog of war" now if I wanted to. I am getting pretty good at inserting and deleting things from doubly linked lists now... soon I will be able to do it in my sleep, and I will be seeing them in the mirror. Perhaps there are too many pointers... naw. Other than that, I've done some stuff with the graphics and messed around trying to fix bugs here and there. Accomplished: 1. Made the range function workable. 2. Implemented ship supply ranges. 3. Added population expansion. 4. Added no-hex-density graphics mode. 5. Hammered out some bugs in fleet sorting. 6. Improved the graphical data window's readout. 7. Planets now change from yellow to green as they get filled up. 8. Better random race placement. March 12th (sunday) Today I split the code up into .hh's and .cc's for easy readability (after Dayne, Adrian and Scott all thought my code was hard to read). It should help things. 27 files, 5397 lines, 14923 words, 140851 characters... compare THAT to an english paper... ouch. If you were to examine those numbers a bit you'd see there is about 2.8 "words" per line on average, and the average "word" is about 9.4 characters long. I am surprised the average words/line is that small. All my work today has been much more mundane than before, but I hope to be able to grind out the core functionality as soon as possible. I started out, basically, working on making range-of-supply work but ended up doing all sorts of other stuff. Big plans for tomorrow. Accomplished: 1. Split up code into .cc and .hh files for improved readability. 2. Ships now degrade (and die) if they are out of supply too long. 3. Fleets are now split between those with bases and those without. 4. Completed delFleet and delShip. 5. Improved the map maker. March 11th (saturday) I took a lot of screenshots as I worked today, both because its easy and I think its neat to be able to see the game develop. They are available here. Accomplished: 1. Made the GL more efficient, running speed is better by about ten times. 2. Fleets are now drawn in race's colors. 3. Empire borders are now drawn. 4. Planets are drawn now (as circles of three sizes). 5. Now GL does not open its windows until the map its drawing has been made. 6. Replaced the class name "cWorld" with graphics, and "Krynn" with MAP. 7. More neatening of the GL code. March 10th (friday) Didn't spend as much time with the 'ol code today as I hoped, but I did examine all of Scott's code in detail and fix a few things. I also have joined the newest version of the game engine with the graphics. Accomplished: 1. Examined Scott's code. 2. Merged newest game engine with the graphics. 3. Made the hexes much closer to actual hexagons in shape. 4. Eye candy: added a "chase" effect to the border of the active hex. March 9th (thursday) Scott was able to enlist the help of Adrian today and discover for us the secret of how threads work. We are now multithreaded. I am very happy. As of 9:00pm we have 4554 lines of code, not including the whole GL deal, but including some good comments and not 100% efficient code. I also got my hands on Scott's code, and have GLX installed and running (on both skug and skud) so now I can run with graphics. They are a bit slow, but not too bad. They certianly show me more than text does. Tomorrow I am going to start doing a lot of work with Scott's code to make it into stuff I like. I don't agree with his organization, although it is more like what most people do in some ways. So anyway tomorrow is gona be another big coding day. I grabbed some screenshots of the map window today, available here, which I will be updating as I improve the graphics (assuming I can). The picture page is also under development. It will certianly be reworked as I add more and more images to it and they require organization. Accomplished: 1. Implemented threads. 2. Added construction of warships and shipyards to AI "fungi." 3. Added the race relation array. 4. Made exploration fleet movement non-random in AI "fungi." 5. Improved the UI and the record output function. 6. Fixed bugs with exploration. 7. Found and fixed a bug in racetype::newShip. 8. Eliminated "NONE" from the enumerated type race_name. March 8th (wednesday) Its been a big day already today. I found and destroyed the fleet movement bug. It was not what it appeared at all, and in fact was based apon a flawed error-checking program as well as flawed methods of outputting what was wrong. It turns out that the entire buisness about fleets moving when they were not supposed to was an illusion generated by a pointer error, and in fact the fleets were working fine. I saw the zero-money bug again today. It should be easy to find once the graphics are done. Accomplished: 1. Found and fixed more bugs in racetype::accountant_1 error checks. 2. Made movement functional. 3. Implemented exploration. 4. Implemented a fleet ID number for fool-proof fleet identification. March 7th (tuesday) Dissapointing day today. I spent many hours attempting to work out some of the strangest bugs in fleet movement. You see, movement of one fleet seems to be effecting the position of others in the same hex and it certianly should not be. I have never seen errors quite like these before. They are both inexplicable and apparently random. Of course it would help a lot if the graphics were running so I could see what is going on better. I also saw a bug today where a race was created with no income and the game was unable to build the initial units. I don't know what happened there. Accomplished: 1. Found and fixed several bugs in racetype::accountant_1 error checks. 2. Tried to fix problems with fleet movement functions. March 6th (monday) First news posting. The news, basically, is that the game is 4155 lines long. Of course lines of code are a simple measure of program size, so we can't put our faith totally behind it. Probably 500 of those lines are either filled with comments or spaces for readability, and it has been pointed out to me that some of the things I do could be done better/faster with things like hash tables. I, however, am not concerned. I am happy the darn thing works. Today has been a productive day. I accomlished: 1. Added renewing buffers for shiptypes, fleettypes, and shipdatatypes. 2. Removed the old "time" variable in favor of global "turn." 3. Made all pointers in fleettypes private. 4. Added simple functions to handle all fleet movement.