I have been working on everything, and making pretty good all around progress. I'm looking to have a solid cross platform release of the planet viewer with login and maybe chat built in done by the end of the year. The server is far enough for this, but needs to be a bit more stable. The client can already login, so its mainly a matter of getting the user interface done, and getting a release put together. Once thats done, I'll work toward getting ground combat designed and implemented.

Here is a Large Screen Shot

Eventually I will set up an image gallery system that is much more functional with ratings, comments, tags, various sorting options, and better support for viewing and downloading very large images. When this is done (it's a low priority compared to making the game work) I'll offer up some more nice high quality renderings from the client.

There are also lots more new screen shots.

Along with the new client, I designed a new server architecture, which I think will work much better. I have finished the basic architecture, and done some basic testing of it. Everything seems to work well, though there are some features missing as far as automatic crash recovery and distributed processing across multiple servers (basic multi-core support should already work, and the database server can be on another machine), but I think everything else major is solid.

Along with the basic architecture changes, I have now implicated a new networking protocol. It has basic error detection, and should be a solid base for the networking. There are a few details that are currently in need of optimization for high loads, but I will get that fixed soon. I still need to implement it on the client side in python too. (Edit After some testing, for small messages, my code is more than twice as fast as RealBasic's built in alternative, and about 11% faster for much larger messages. I also got it about half implemented on the python side)

Also, I should note that several developers other than me have been active recently working on various design and documentation tasks, as well as the ground combat system which will be ported to the new server, client and networking once finished.

I think that is it for now. No pretty new pretty pictures. I need to rig up a PHP script so I can easily update a gallery of new screen shots for all you (not very numerous) fans :)

On another note, the new FG Game server software got another critical piece finished today (start to finish it took about 15 minuets to make though). I just finished basic testing of our process manager, which currently does nothing but launch a few things. Eventually it will have also the job of detecting crashed and frozen parts of the server software, and trying to kill and relaunch them. For now it will launch the task manager, and any other things that need to get started, like the client communication servers which I will make shortly.

I also have been playing with planet appearance a bit. Nothing major though. Maybe I'll put up a new image and/or video soon.

Edit: Have a sunset! Ya, pretty crummy without atmospheric scattering, but at least the water looks somewhat nice.

On that note, I have made great progress the new server. I actually have the architecture working. The scheduler now properly runs tasks that access the database. Pretty basic, but it is a solid start to build upon, and also I can start bringing in major parts of the old server now.

I have just finished getting the full internal structure and the associated user interface for the ground combat app finished. This means that I can now place facilities on a planet, and a player or players can have full or partial control of each facility. I can apply various settings configurations to the facilities for each player, and edit the list of available configurations. While none of the configurations actually do anything, and there is no actual combat going on, we are getting closer.

Now I have to add some more settings to the configurations, and then make the actual combat happen (update the facility properties periodically to reflect growth, losses, conquest, etc.)

What this means for you? Ground combat game is one step closer! Also, as far as user interface complexity goes, note that the ground combat app is a development tool that controls all players at once, and is in no way trying to simplify anything. The game itself when released will be much more friendly.

For those of you who like numbers, this is all done through 7 separate windows, 4 of which can have multiple instances of open at once (See image).

It has been a while since the last update, and not very much has been done, but much planning has been done, and progress has started in what I see to be a very good direction. Here is the work in progress ground combat simulation app (GC App). Soon it will allow the user to set up facilities on a planet and fight over them.

Though I have to this point always avoided anything time line wise, I would like to say that this should actually be done soon. That means days or weeks, not months. I got about half of the remaining work done yesterday and today.

Once this works, the new server design will be implemented, the log in system will be ported over, and the GC App will be incorporated. Then the client app will be made from the GC App and then we will have a playable MMORTS! It will only be minimal ground combat at that point, but it will be a very solid base to build upon.

It will then be extended to add more features like national boarders, treaties and triggers, resources, technologies, a real time supply demand economy, and much more. This process will produce a fun and interesting MMORTS. Most of these features are independent of each other and thus can be tackled by different developers allowing for much faster progress. I would like to see this getting underway early this summer.

In addition to the game play improvements during this phase, the graphics and user interface will be moved over to OpenGL, and the planet will go from the current slow to generate low detail to a vastly improved immersive realtime experience complete with variable climate and weather, seasons, environmental sound, and deep zooming graphics detail. I can not provide a time frame for this, though I can say that a lot of work for it has already been done but is put on hold until the gameplay is further implemented.

As the ground combat game becomes more fun, it will hopefully pick up a user base which will allow us to tune it properly and be sure it is a fun and exciting part of FG. While this (unavoidably slow) tuning and refinement process is going on, the galaxy and solar system setup will be brought in allowing players to view other planets, and settle some of them. Then the existing physics and AI systems will be brought up to date to work with the new server, and ships will be added. Initially they will only do basic things such as be moved around, travel between solar systems, and investigate and colonize planets. This will be the final state of the development of ground combat. Once this is done, epic space battles!

I can not offer a time frame for epic space battles (I will wildly guess 2.3 years, end of summer 2 years from now), but a lot of work has already been done for them: the database system is pretty well designed; the AI engine is roughly coded; the physics engine has been tested and works with module and thruster based ships and my collision detection engine has been stress tested successfully and imported into the FG code base. It is not like we are starting from scratch; it is more like reassembling and extending.

Here is a planet. The texture is made using the old and slow method. I put in some of my improved code from the planet tool project though to make it faster. Notice how terrain and lines cross the seams without getting totally screwed up. I put a lot of work into making that work right!

The planet has lines on it. They properly follow the shortest paths between endpoints, meaning great circle routes. Also there are some little marker dots. Currently they are placed where you click, and demonstrate the mouse to 3D vector to texture implementation. Eventually it will be used for placing things like facilities, national boarders, and anything else you can click on the planet.

Basic drag navigation and scroll wheel zoom has been implemented and works well.

Where is this going you may ask?
The current goal is to create a ground combat game, which by itself should be somewhat fun, though slow paced and not overly interesting. Once this is done, it will be improved until there is a real economy, somewhat nice graphics, and basic diplomatic tools (setting peace vs. war with various players). Once that is done, work will continue to improve it, but we will also return to working on space combat. The first step of the space based game will be basic colonization of other planets. Once that works, ships, fleets and real space combat will be added. Then you will have ground and space combat. That is when FG will start to be really neat.

What does this mean to you? It means that FG will have spiffy cool graphics that use your graphics card to its potential (considering my graphics card is crap, that means little for me…). None of this 5 seconds to generate a crummy texture. On a decent card, it will make a good texture in less than 1/20th of a second.

I'm pretty delighted with this success and I will be proceeding straight to getting my render to texture code to let me produce textures with shaders. Things are going to get cool!

2 textures mixed with 2 octaves of noise all on the GPU. 4 fps so render time of 1/4 second for 512*512 on my crappy graphics card. Now I just need something that will let me get that image in a usable way. I did manage to get rendering to textures working, but I haven't managed to get shaders running in RealBasic yet. OpenGL ftw.

I still like that system, but today I realized that if we were to use a graphics engine where we have much more control over the GPU (like OpenGL), I could implement the same system, but much faster, and better.

First of all, the reason it can not be done in a shader is that when you zoom in, there are so many possible layers. In reality, very few will ever be used at once, but the pixel shader can not take advantage of the hierarchical nature to eliminate almost all of them. Also, even the amount of layers is use will be so large, and the amount of computation per sample in each layer so larger that it simply would never be close to fast enough.

Solution: Suppose we were to have an already textured planet. Once you zoom in, you get to the point where there is no detail left from the texture. At this zoom, suppose you implemented the appropriate sub layers (trees in the forests, dunes in the deserts) in shaders. They would add in the detail!

Now, you zoom in further, and its time for the shader's sub layers. We use the GPU to convert the current shaders into textures which we draw on top of the old lower detail ones, and generate new shaders for the sub layers (branches on the trees or what ever).

This allows per pixel detail at all zoom levels, and keeps the speed up. There is simply 1 shader drawing a few layers over 1 texture. That should be fast! Getting the GPU to generate the textures that will be combined will be somewhat hard, but apparently it's possible. Also, it would allow high quality effects like per layer bump mapping with proper lighting!

The slightly easier version is so skip the detail shaders and just use generated textures (generate them to higher detail). This would probably be done first, and detail shaders would be added if needed.

Also, the mesh height data could be generated on the GPU as height map textures which would speed stuff up a lot in that department. (Yep, that means fast detailed mesh with fast detailed textures with good lighting!)

What this means to you: If we go forward with this, it will mean some delays in the short run, but planets will look much better, and so will everything else (because of a better graphics engine)

I should note that I have never done anything like this, so it's all very speculative.

Basic design:

Progress wise, Tristan has made an excellent in game help viewer. His setup is far nicer than the one I hacked together in both function and appearance.
I have been looking into how the server should work. Currently we have a relational database system crudely mashed together with sqlite databases in the server app. I understand databases much better now, and I have looked at a real relational database system, I think I might know how it would let us simply the server a huge amount, while easily letting us use an virtual cluster of servers to handle larger loads. It would also let a good php developer implement some controls and stats on the web site, which would be nice.

I have also spend a bit of time playing with different development tools, and messing with open GL shaders (GLSL). That might come in useful when we redo the graphics to use something better.

The current main hold up is my stall on the planet tool. I just don't feel like ripping it apart and fixing my organizational mistake, and that is really the only reasonable option, so we just have to wait until I feel like making a large pile of shredded internals, and then fixing it. Maybe when I have more time.

At least at this point, taking some time to think about the project has helped, so the delay has been useful.