Sunset in the hills west of Eugene - rendered in FlightGear and Unity3D.

A number of people expressed interest in a recent little side project of mine, wherein I implemented a paging terrain system in T3D, and filled it with real world DEM data from the Willamette Valley in Oregon.

This blog isn't really about that.

This blog is about the journey that began last November with that project... and finally ended up back here in T3D, five weary and haggard months later, with a project that, even in its current state of v0.001 (barely even working) is already one of the coolest things I've ever done.

The weird part started innocently enough. In a moment of relaxation, I did a google search for an open source flight simulator. Back a couple of lifetimes ago IRL, I used to fly an ultralight airplane, and meanwhile had also become interested in a partly flight-sim based game called World War II Online.

One thing led to another, as they tend to do, and before long I was taking a peek around to see what had happened in the world of open source flight sims in the past decade or so. What I immediately stumbled right into was:

www.FlightGear.org

Now this is all well and good. Nothing wrong with a little casual entertainment - even if it does involve much merriment from your non-gamer wife, re: the sudden fascination with your new "joystick". Such is the price we pay...

However, besides being an incredibly detailed flight simulator, with accurate engine behaviors, hundreds of supported aircraft, and even multiple whole flight dynamics systems to choose from... I soon discovered that FlightGear also includes a complete, game ready representation of the entire exposed landmass of the Earth (give or take the polar regions). Along with day/night cycles, moon cycles, a starfield, and local weather simulation complete with a whole library of 3D cloud models, all automatically synched up to accurate realtime weather data by region.


Yes, that is a heavy storm front out over the ocean.

At this point you may well be wondering where exactly I'm going with all of this. Certainly FlightGear sounds like an interesting project, but what does it have to do with Torque?

Very well, if you must know... please allow me to lay my cards on the table. After which you can decide whether to stay with me through the rest of this blog, or run away screaming.

Summary: I have written a modified version of FlightGear to function as a "World Server", for the purpose of serving terrain data and skybox images in realtime to a separate client application, written in Unity or Torque.



The wizard character from Unity's Advanced Multiplayer Kit, in South Eugene looking NE.

Now, in case I've completely lost you with the above proclamation ("You have written WHAT? For the love of God, WHY??") ... please allow me to explain myself.

As mentioned in the above referenced blog, I have a long-term interest in creating a post apocalyptic MMO game based in real world terrain.

Most games have no interest or need to include the entire planet in their assets, of course, but I had this clever idea... "wouldn't it be interesting if my players could run scenarios in their own home landscapes?"

Once one allows oneself to even think along these lines, the potential applications start to multiply exponentially.

However, the 800 pound fly in the ointment, of course, is the fact that the planet we live on happens to be extremely large.

While data exists on the internet to both replicate and surpass all of the work done so far by the FlightGear team - to assimilate the height data, provide some kind of reasonable textures for all land area, and fill in a base level of at least aircraft-relevant objects like radio towers, skyscrapers and of course airports - the undeniable fact remains that this, in and of itself, represents a massive amount of work. As in, many human years.

And if there's one thing I've learned in the past four or five years of smashing my own poor indie existence up against the craggy rocks of Software Time, it would have to be this:

Never, ever, ever start *anything*, unless you have first made absolutely sure there is not an easier way.



Standing in the Coburgs, before local terrain textures worked.

But once I started looking around in the FlightGear world, and seeing the incredible volume and quality of effort expended thus far to make it happen, the thought slowly began to form in my mind that this project had to be relevant in some way to my end goals. I simply could not see it and then just walk away and start over.

The exact mechanism remained, and still remains, open for debate. It is a given that most games do not require the end user to start two separate 3D applications just to make the game run, and this setup would not be my first choice.

However, there are many other ways that FlightGear's accomplishments could theoretically be leveraged, beyond the way I am doing it here in v0.001. It could well be that an ultimate solution would involve chopping out whole sections of FlightGear or its underlying utility code, and incorporating them directly into a first person game engine, so that the game itself could read FlightGear's stored data instead of having to talk to a separate instance.

Of course, that in itself represents a seriously non-trivial amount of programmer time - and we are pretty much out of budget around here for extra months of programmer time.

So, yes, it is awkward, and probably undesirable for a finished game, but regardless of any future ambitions we may have, in the current implementation of this project, we must run two major apps side by side to get the results we need. That is where it stands, and for now we must take it or leave it.

Let's look at another pretty airplane picture while we get used to that.


Isn't that better?

Now that we have that little dose of reality out of the way, let's look at the myriad number of silver linings that I discovered along my path of least resistance:

• The world server is completely application-agnostic. The same world server build can talk to any client application that is capable of opening a socket and following the rules, it does not have to be recompiled to work with a different client.
• The world server need not be limited to operating on the same machine. In certain (cough, mobile) environments it might make sense to stream skybox images and terrain data over a network, to allow major data storage and image rendering to be done in the cloud.
• The world server is still a perfectly operational copy of FlightGear, which could become highly relevant for any first person games that have ambitions of including a flight sim among their vehicle options.
• While it may seem weird for a game, in a serious simulation app it is not all that bizarre for multiple windows to open up.
• FlightGear is licensed under the GPL, but by operating a completely separate application over a socket, the client software is free to operate under whatever license it wants.

Gotcha with that last one, didn't I? I kind of forgot to mention it earlier, but yes, FlightGear is GPL. For my purposes, that does not actually scare me that much, but for others, it could obviously be a critical factor.



In the Coburg Hills, looking southeast, before terrain textures worked. The lighting problem between different skybox sides is fixed now as well.

How It Works

To avoid rambling on interminably here and instead start wrapping this thing up, I'm going to have to leave out most of the technical details. To put it in the most basic terms, the client application opens up a socket to FlightGear and sends the current player position in latitude/longitude, as well as some other data, such as the heightmap and texture resolution of our local terrains, and the path to which image and data files should be written.

FlightGear then samples its own terrain data and returns a set of nine terrain height files, nine terrain texture index files, and five skybox images. The client app then loads these into the game world, and voila, we have an FPS portal into the FlightGear world.

Of course, it wouldn't be version 0.001 if it didn't have a host of problems. It's currently slow and clunky, and there are whole subsystems not even implemented yet (like handling FlightGear objects in the game engine and vice versa.)

The most important part for me, however, is that I now have a solid foundation, a starting point, for all of my future megalomaniac plans of world domination.

HINT: Imagine a shared online real-world-based sandbox environment, like Second Life crossed with Google Earth, but in a first person game environment. And then imagine it is open source, and users can host their own servers or add their own "multiverse" layers to an existing server, and ultimately create their own mini-games, simulations, art projects or anything else they want to share, with everyone or just with their own friends.



Well, that escalated quickly, didn't it? I apologize for the roller coaster ride here, but there is really no way to explain this whole project without getting into my ultimate end goals. And while it may seem rash to spill such long term plans in a public forum like this, that's one reason I'm starting here in my beloved Torque Community instead of blasting it out to the whole world yet. In the end, though, you really can't create an open source project in secret, can you?

I'm looking for feedback of all sorts at this point, including:

1. Does this project interest you?
2. Would you use this technology in a game or other virtual reality project, with a separate standalone World Server application?
3. Would you use this technology if it could be designed without the extra application opening up, or with it happening less obviously?
4. Would you participate in the multiverse sandbox environment described above, and if so would you pay a fee for special privileges like being able to create your own "layers"?
5. If this was an open source project, would you join it and contribute code and resources to improve it?
6. Finally, and perhaps most importantly, would you consider contributing to an indiegogo campaign or in some other way be willing to help finance the effort to make any or all of these things happen?

Because that is where this is going... I have intentionally bitten off a lot more than I can personally chew this time, and I fully intend to put it out to the world as a project worthy of your contributions. If it takes off, it could be the biggest thing I ever do for the internet. But first, I need to convince a lot of people that I'm on the right track. This blog is my first official attempt in that direction.

Oh yeah, before I forget... as a reward for making it all the way to the end of this blog, how about a LINK? Yes, it's true, the project is already past the point of pure vaporware and into the zone where I have an actual download. Be warned, however - it is limited to the area around Eugene at the moment, it is slow, it is full of programmer art and stock GUIs from the Unity Advanced Multiplayer Kit, and it is stocked with only the ultra-low resolution default FlightGear terrain, which at 90m is obviously far too low for a first person game. This is all fixable, given more time to throw at it.

Finally... sorry Torque users, but the first version that works well enough to share is the Unity3D version. However, here are a couple of screenshots to prove that it is almost working in Torque. I could have kept going and fixed everything, but I thought I should test the waters here to see if anyone is even interested before spending many more hours on the Torque version.



Anyway, about those links! There are actually two files to download: a fairly large (450M) file which contains the FlightGear end of things, and then a much smaller (40M) Unity client for Windows.

The FlightGear side is here:

www.brokeassgames.com/MMOKit/FGWorldServer.zip

Sorry for the hoops to jump through, but the install process at this point is a little awkward. You need to make a shortcut to /bin/fgfs.exe after you unzip that file, and then give it the following command line arguments:

--fg-root="..minimal_fgdata" --aircraft=UFO --lat=44.02 --lon=-123.082 --altitude=800.0 --heading=0.0 --disable-splash-screen

Once you have that working, it should bring up a square flightgear window, 800x800 pixels in size. You may want to press F10 to get rid of the menu before proceeding. If you are doing this at night, Oregon time, then you will want to go to Environment->Time Settings first, and set the time to something with daylight.

Next, you will need to unzip the Unity side:

www.brokeassgames.com/MMOKit/MMOKitClient.windows.zip

This should be fairly straightforward, just run the MMOKitClient.exe. In order to use the demo, please make a new account with a valid email, and click through the required character-generation screen (the skills etc. don't actually do anything but you have to allocate them all in order to proceed). If all goes well you should end up with a character standing on a hill in South Eugene. Terrain and skybox refreshes should happen automatically but you can hit the 'p' key to force them.

Good luck! There is much that could go wrong (again, v0.001) but if by chance it all works and you get in, please let me know!

If you have less stomach for bleeding edges, feel free to wait a while until some of the bugs are worked out.

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------

EDIT: (5/31) Speaking of bugs getting worked out, there is a new download available on this project! I'm going to leave the above downloads as they are, for archive/comparison purposes, but the new version of the unity project is here:

www.brokeassgames.com/MMOKit/MMOKitClient.02.windows.zip

You can use the same flightgear download as above, but you'll need to drop three files into it to update it to the new version. You can find them here:

www.brokeassgames.com/MMOKit/FGWorldServer.patch.zip

Inside that are two directories, "bin" and "minimal_fgdata". Inside the bin directory is a new fgfs.exe, which you'll want to put in your FlightGearWorldServer/bin directory, and in the minimal_fgdata are two xml files, which you'll want to drop into your FlightGearWorldServer/minimal_fgdata directory.

There are two major changes made by this update, one for skybox image creation and the other for terrain loading.

For skyboxes, previously I was forced to move the camera five times in flightgear and take five pictures, which was very, very slow. Now I've figured out how to set up five simultaneous camera views in flightgear and render them to one very wide window and then I chop apart the single huge screenshot into five pieces, all in one operation. MUCH faster. Still not realtime or anything, you will notice the lag, but it's not as horrendous as it was.

For terrain, in the interests of space efficiency I was previously having flightgear look up and replace the same nine terrain storage files as the player moved around... but with the terrain lookup also being terribly slow, I decided to trade some space for speed and cache the data instead, under tile latitude/longitude coordinates. Now when you move around over terrain you've already seen, it should reload fairly quickly, and only drag on the edges of your known universe.

More news upcoming, but that will be in another blog...