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

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 :)

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.

Now if only all those options did stuff! It is certainly not done, but it is beyond a simple GUI mock up (the undo menu for example does work, and so does redo). The image displayed is generated (in less than a second) by the functions and layers listed, but you can't really edit them to a reasonable extent yet.

Thanks for reading. Come back when we have some real news. There will be interesting news in not too long. Maybe in a few weeks, maybe less.

For now, some random thoughts to keep interest in the project:
It would be possible to have layers in the planet data that reflect mood thus effecting the music.
We can have binary (and more) star systems with planets in both types or orbits (around the stars and around the barycenter (center of mass of the stars)). The current orbit system can handle this just fine, but some changes elsewhere would be needed. Don't go looking for a 2 star 2 moon eclipse screen shot tho, its very unlikely!
The economy will have shipping prices, tariffs, embargoes and such. Thus all the resources will have varied prices in different locations.
Weather and seasons on a planet can effect combat stats, resource production, and other things. For example, food could get expensive during drought or harsh winters, mining can become expensive in wet seasons, population growth can slow or even reverse when conditions suck. Very small forces can have a bonus vs. Large armies in the dark (night or arctic circle in the winter, maybe even when its really cloudy) for stealth reasons.
The hierarchical AI will allow ships to act on their own and in group effectively at the same time, as well as group of groups etc. The level of individualism for ships and groups for various factors will be player set along with priorities for ships and groups.
The blind growing tech tree will allow open the possibility of discovering a never before seen technology. Once discovered, it could be kept secret, but using it in the presence of others makes them more likely to discover it.
Using technologies a lot can increase their bonuses to things that use them.
Player will be able to set up extensive treaties, as well as actions triggered by their violations and other triggers.
With the cost of controlling planets increasing with the size of your nation, the quality of planets will be more important than their quantity. The higher quality planets will reside closer to the center of the galaxy usually. Thus, a player can ether engage in heavy PVP there, or spend more time exploring the rest of the galaxy to find valuable resource rich planets.

As you probably know, running a server takes money. As you also probably know, we have spent a lot of time on FG and will continue to do so. Because of this, eventually Fragmented Galaxy will need to generate some income. I posting this here on the public forums, because the players are greatly effected by how payments work. We are fully open to suggestions at this point.

I do have some ideas for how it could work.

I think it is important to not charge people until we have a game that is stable enough that it will not lose their data, and will be available most of the time. Once this point is reached, I think it is a good time to start accepting donations, but not nagging or anything.

Once the game is pretty much fully featured and onto a fast server, it will be time to evaluate a payment scheme. If donations have not reached the volume we want, something new will be needed. I personally think it is valuable to let people play for free. It greatly boots the user base for one thing. The question is then: what would be different for paying customers? Restricting non paying players in some way makes the game unfair, and adding some non game play effecting difference would also not be good as it singles out non paying players, and often offers too little incentive to pay.

Thus I propose a multi server system. We offer a free server tuned to allow very few ships (3-8 or so), and control over very few planets. We might even adjust some other things to keep the CPU and band width lower such as lowering update rates and such. Basically tho, it would be a full version of the game, but scaled to load the servers less, and limit players sooner. It would also probably have a more limited non growing tech tree so new players just joining the check out the game could catch up pretty quick. We would then offer a pro paid server that allows nations to grow much larger and more powerful. It will be tuned for long term play, and have a much higher server load per player because of the higher colonized planet and ship counts. Paying players could play of the pro server, as well as the free one. We could also offer a server resembling the free one tuning wise, but only for paying players. Probably the free server would get by far the most players, and cost the most to host, but the other servers could pay for it, and when the system gets overloaded, or the server costs get too high, we can do stuff to the free server like adjust the tuning and update rates, without feeling like we are preventing people from getting their money's worth. The free server (or a clone of it) would also make a very good high load testing/beta server.

Please post your thoughts on the subject here, so we can make sure our players are as happy as possible when the time to collect money comes (not gonna be soon).

(Developers, as far as what we do with the money, see the Dev forum. I'll make a post there soon.)