Now that the basic framework for the game has been compiled into a separate library, the development approach must also change. You see, separating the basecode from the game-specific code comes with a little gotcha: the library code (the generic portion) isn't allowed to know anything about the game code.

To deal with this, i've had to work on a mechanism to bridge the gap, commonly referred to as a "Pluggable Factory" pattern in programming circles. Now that i've got my own, it will probably play a key role in forwarding development.

The first problem it has solved was game state management. When you tell the game to switch to a "title screen", it has no idea what that means, so you have to explain it somehow. Although i've had the state management code in place for a long time, it was tightly integrated with the basecode. Now it's not. But that also meant there was no way to communicate. Now there is!

So, for a "first screenshot" (400k) here's my desktop running a working PointSiege program :-) Of course, it's just a title screen, rotating textbox at the bottom and a "frame-ometer" in upper corner. But it means that new states can now be programmed in with little effort. Woot!

I've finally finished the select drop-box widget. It was a tad bit more complicated than the other widgets. I had to go back and add a few features to the overall scheme of things, namely viewing rectangle clipping to keep widgets from drawing their internals "out of bounds". I figure i put in a good two hours of solid "work", but i'm sure i spent at least eight bug hunting. And i probably stumbled over every problem in the universe to get it finished. Lots of really stupid bugs and some really nasty ones too, plus an abnormal amount of hoops to jump through. I'm glad it's behind me! Since it's just a dropbox widget, i'll withhold screenshots until i get a few more widgets made.

Scrollbars have now been created and work great. The scrollbars i made use some C++ extratrickery for added coolness, but only for programmers. Programming the GUI so far has been strangely easy. Next i'll be doing a dropbox (select list) and a text-entry box and possibly an image decal. That should round out the basic widget set that i need to get started.

PointSiege will ultimately require a lot of "custom" GUI work outside of the standard buttons 'n' scrollbars fare. But those can only be done when the actual gamecode goes in. I have some fundamental design issue to work out first. Most of the design is pretty well in place except for a few key issues. If those issues don't work out, it may require some design refactoring.

That's right, I have finally implemented a ship designer! Now you can create your own ship designs! I haven't yet put in validation for the designs, so you can overload the component slots with WAY too many components!

There are now components which can be installed on ship designs. Actually, the components come preinstalled, because I don't have a UI for designing ships yet. (Hmm, I should validate the data files to make sure that nobody can cheat by editing their mod files to allow extra components on their ships!) Anyway, the components also have abilities - there are currently five ability effects: Build, Hitpoints, Sense, Scan, and Thrust, plus one for each type of firepower in the game. Of course I'll add more abilities as development continues, but those should get us started...

Ships and colonies now have a scanner radius distinct from their sensor radius. Things inside the sensor radius but outside the scanner radius cannot be seen in as much detail as things inside the scanner radius - for instance you will know that there is a star there but not that it has a colony on it, and you'll know a ship's mass but not its design details. Also, I added hyperlinks to the reports. What this means is that if you are looking at, say, a report on one of your ships, and you click on the design name, you will get information about that ship's design. Clickable links appear in blue, just like in a standard web browser. Now all I need is a "back" button! :P

OK, the relational database thing didn't work out... it was even slower than the XML! I asked Ken Reed, the developer of Nova, a much more faithful Stars! clone, how he did saving, and he said he just used binary serialization. I tried it out just for fun, and it actually worked pretty well, so I guess I'll use it - hopefully Java serialization has some sort of versioning feature so I can eventually make savegames compatible between versions! Also, I found a MUCH more lightweight SVG rendering library - goodbye Batik, hello SVGSalamander! Oh, and sorry about the broken download last time - I didn't realize that the classpath was broken and I had to add all the libraries to it!

So I decided to switch from PNG graphics to SVG, so that it's easier to make custom graphics (like ships) that are in a consistent style - it's much easier to draw cartoony lines and stuff than it is to render photorealistic images! I know it's kinda clunky now (you have to download this Batik thingy which is pretty big) but I'll probably figure out which libraries from Batik I'm using exactly and include only those, or something. What to do now? Well, I've been thinking that eventually I'll want the savegames to be a bit more robust - games saved in one version of the game ought to work in the next! Also, the savegames are taking *forever* to create because they contain megabytes of XML data which is then zipped down to a much smaller size. In order to do that, I need to put some work into saving. I'm thinking using an embedded Derby database plus some sort of persistence library like Hibernate, instead of zipped XML dumps from XStream, might help me solve those problems. Or that might be so hard to do that it kills the project... I guess there's only one way to find out...

No, I haven't given up... I've just been busy with real life and also with converting the savefiles over to a new format. Now the game hosting and the player pieces are mostly separate (I should really separate them completely, but not right now) so nothing much has changed from your perspective, other than the main menu and login process is a bit different. There are 3 types of savefiles: *.cchost files, which belong to the "game host" (whoever's running the game and processing the turns on their PC) and contain all game data; *.ccview files, which are generated every time a turn processes and need to be distributed to the appropriate players; and *.ccturn files, which are created by the player's game client and need to be sent back to the host for processing. This change necessitated ripping up a lot of code, so some things are broken right now, namely: 1. You can't order ships to move to a location in deep space, only to another space object (a star or a ship). 2. The empire flags are displaying really small on the map. 3. Turns are taking a long time to process, especially when there is a battle or the game ends. 4. There are a lot of nulls in the battle reports - they seem to appear in place of the name of whatever gets destroyed in combat. (There may be other issues which I haven't yet discovered - I really should have kept up with the unit testing I had started with!)

Since the game is getting to be a pain to install, what with XStream and such, I decided to make a proper installer, using IzPack (http://www.izpack.org). Hooray for IzPack!

Nothing much new today on the user side of things - just fixed a bug causing destroyed space objects to leave sensor ghosts even when you KNOW they're destroyed, and cleaned up various stuff in preparation for splitting the savefiles down into a "host" savefile (which will be encrypted with a master password that only the game host should know) and "player" savefiles (which are not encrypted, and should be distributed to the individual players). Also learned that if you take three 256x256 BufferedImage's and convert them to XML with XStream, you get about 70 MB added to your savefile... stupid empire flags! :P

It took me a bit of time, but I finally got "fog of war memory" working - by that I mean that if something is no longer visible, you'll still be able to see it on your map, but you'll get an old report! Now if Aaron Hall could only get that implemented in Space Empires V...

Now you can save the game - actually the game does so automatically - and you can resume the next time you start it up! Hooray! Of course installation has to be a bit trickier now since I'm using an external library for saving, but eventually I'll make an installer...

With that last build I managed to break both the threading code and the loading of saved games... Should be fixed now! Lesson learned: DO NOT move code with a Thread.sleep() call into a Swing class!

Yes, now it is possible to win the game... just bomb the enemy planets into oblivion! Nothing too spectacular happens, just a log message. Oh, and I've discovered a strategy tip which will apply once I implement ship designs: Don't send an unescorted bomber to battle an enemy fleet at their homeworld, no matter how much anti-ship weaponry you have equipped on the bomber. Why, you ask? Well, homeworlds tend to be targeted first because the "targeting priority" for ships depends on their mass, while the priority for colonies depends on their population and factories. Homeworlds have a LOT of population and factories, so if your bomber is unescorted, it will be spending all its time dropping bombs while the enemy fleet blasts it to pieces! Even if you have a battleship versus an enemy corvette and homeworld, the battleship will get blown away, even though it could destroy the corvette in one shot! (It will make a nice crater on the enemy homeworld before it does, though...)

Cosmic Crises will now display the blow-by-blow of a battle - just find the battle report in your message pane and click "Go To"!

I've set up a wiki for Cosmic Crises - not much is there yet, but click on this news item's link to have a look-see!

I made some empire flags... Scalable vector graphics are definitely fun; I'll have to consider allowing game graphics to be stored as SVG as well as PNG.

Woo, combat is implemented! I still need to add better combat logs so you can see the "blow by blow" or at least a list of survivors, but ships are definitely taking damage! (For some reason colonies aren't engaging in combat... oh well, they currently can't shoot or take damage, so it's just as well...)

I've made some simple graphics that actually look decent for many of the starship hulls now! Less staring at ugly mouse-drawn pics! Of course, I need to make empire flags or draw ships bigger so you don't have to squint at the screen when you run across a corvette...

I added in an element of SpaceCiv today... the damage or firepower types vs. various hulls! Of course I haven't implemented actual combat yet, so there's no way to see that in action, but hey, it's a start...

It's a new 4X game! Check it out! :D It's inspired by Stars! but there will eventually be elements from other games such as MOO, Space Empires, and Space Civilizations.

Since PointSiege is a strategy game and therefore UI intensive, it needs a robust GUI framework which i currently do not have. While I have coded basic widgets for The Ark, they really didn't plug in well with the new library concept and were mostly standalone objects. So I decided to warm up to some of the options. I finally chose a library called "sigslot" which allows objects to communicate with other objects using a very simple "plug-in" system.

After spending an hour or two cleaning up someone else's code, only to find out someone else had already done it, i starting recycling my previous GUI code and gluing it together with sigslot. With just a little bit of work, i got it wired up to my screen objects. They can now respond to user events. In the picture you can see the "Red Square" test widget which follows your mouse around the screen (responding to mouse movement) and turns blue or green if you click the mouse (so it can respond to both buttons). It's not the least bit exciting, but does illustrate the underlying mechanics of what will be a much prettier UI in the future.

The classic TextEntryBox has now been programmed. It isn't ultra-fancy, but it gets the job done. It supports all the normal printable ASCII characters. It's not currently set up for International character sets, but i'm sure that could be changed in the future. The TextBox widget, unlike the others, responds to keyboard data, so i had to add that to the system.

Another gotcha is "modal" support. Modal means that a widget has exclusive focus (such as a dialogue box). I needed this to make drop boxes work correctly. If a drop box did not have modal operation, it would overlap other widgets on the screen and confuse the poor mouse pointer.

I'm not sure what i'm going to do about true overlapping widgets yet (such as a draggable window or chat box over the screen). I suppose i'll cross that bridge when i get to it. Of course, i'll avoid it if i can. I wasn't originally planning on supporting such a feature.

Also programmed was an image button and an image decal. The image button uses almost all the same code from the regular button, but with a few images on top. The decal was the simplest widget. Just a simple image to display. So, this completes the basic UI widget set that i wanted. I have enough widgets to play with and build a game from. I'm now very close to getting into game-specific code at this point. Yeah!

On the design front, i've been reworking a few things and i believe i have an acceptable design solution. I'll give more details when they are needed.

After a day of tinkering with GUI widgets, i managed to produce two new ones: a label and a button. The button comes with a mouseover and on-click highlighting. I also programmed in some eyecandy. One of the primary GUI effects i want for PointSiege is fading in/out (quickly, of course; i don't want to drive anyone nuts). So i put that in too. You can now fade in/out GUI elements. In the picture i even wired up a toggle button to hide and show the sample button pane. All the buttons work nicely. Not bad for a days work!

"Project 3" is getting a total overhaul. The name has been changed to "PointSiege" and the very heart of the project has been replaced with a leaner, meaner strategy game concept.

Visit the forum announcement post for a (very long) discussion on the project's new aims as well as a mockup screenshot.

After about 9 months of abstaining from any programming. i finally decided to give a shot at getting back into the basecode for PointSiege. In the last several days i've been off work with a mild cold, so i was able to get some computer work done.

So that everyone understands what's happening, the basecode as it is now needs major "surgery". It was originally designed for another project. Since i have lots of game project ideas on the backburner, i thought it would be good to make the code as generic as possible and repackage it as a shared library.

Last spring i did the major gutting, taking out all the game-specific code. This week, i spent some time trying to actually create a library out of it. All did not go well however. I've never made a library before! Following tutorials and help pages just led to errors, even on trivial test examples. Thinking that it might be some system-incompatabilities, i decided it might be time to upgrade my Debian Linux development computer to the latest and greatest. So i spent the next two days upgrading everything. I now have a brand-brand new linux kernel (2.6.15), all new software packages including my latest-version text editor (KATE), new graphics drivers (nVidia), development tools, etc. The seriousness of the upgrades broke a lot of things on the system, so it took a full two days to get it wired back together and usable. For a while i didn't have anything more than a command prompt.

After much frustration, i returned to the original problem of creating a library. With some help from GameDev.net, i got a simple library compiled and then this morning i got the full basecode packaged into a library. The new library is called "libLevGC" or "leiavoia's Game-Core" and will be maintained separately from the actual PointSiege code and/or any other future projects.

The next step in development is to reintroduce much of the game-specific code that was removed and place it into PointSiege code (not the library code). Presently, all that exists is a black screen and ESC to quit. I also want to make improvements to the drawing routines, audio, and basic architecture before starting any "official" PointSiege code.

For now though, at least it works. That's more than i could say before! This portion of the project is a lot like separating conjoined twins. It's technical and ugly and full of potential problems. I'm not totally finished yet, but i'm definately on the home stretch.

While the game is still a work in progress, screenshots have been added to the Pax Galactica screenshot gallery. Be sure to visit the forums for the latest information and discussion of this upcomming 4x strategy game.

The testing process is underway, with the third version released just recently. If you're interested in joining in the beta process, there's still room. A new shot of the research screen has been put up in the screenshot gallery since the last update, and if you haven't yet seen it, a brief description of the planned combat system has been placed on the web page.

Several new screenshots have been added to the screenshot gallery since the last update. In addition, testing is scheduled to begin soon. If you would like to help out, simply post in this thread. Once beta testing starts, everyone who's expressed an interest will be sent a password and web address that they can use to download the most recent version of Pax Galactica.