Tuesday, December 18, 2012

Upgrading to VS2012

Last week I upgraded my IDE to Visual Studio 2012.  I do not regret this decision one bit.  Based on my experiences so far, I can safely say that I can stick with my opinion that Visual Studio is the one thing that Microsoft got very right.

I especially love the new Dark theme, which matches nicely with my chosen syntax color schemes and makes the program much less of an eyesore when working for many hours.

The upgrade took a full night, since I spent a lot of it refactoring my multiple libraries into one 'libnebulous', as well as recompiling all of my third party libraries using the new C++11 compiler which shipped with the program.

Now I am deep into the process of upgrading to DirectX 11, and I am starting to think it is going to take a long time.  A very long time indeed.

Monday, December 10, 2012

Landing On Planets

This was a long time coming, mostly because I was so wrapped up in other features that I was neglecting the most important part of my game: the planets.  There isn't much to look at yet, but here is a quick screenshot of my scout ship sitting on the surface:


That screenshot is in debug mode so there really isn't much to look at.  Right now the planets are just featureless balls, but one of my next targets is terrain detail.  But this progress still means a lot to me, as I've been wanting to do it for literally years.  I was jumping up and down when I finally got it right.

Backtrack: Engage

As excited as this has made me, I won't be able to push it further for a while because I am about to initiate a massive backtrack just in time for the holidays.  This is pretty convenient because I've got a bit of time off from work coming up which I will be using coding instead of relaxing.

There are a few things I'm planning on getting done which I have been putting off for far too long.

A small change, but still significant, is upgrading to Visual Studio 2012.  I have been using 2008 for far longer than I should have, and it's about time.  This upgrade will give me access to all of the shiny new features of C++11, and from what I hear the visual debugging tools for graphics applications are outstanding.

I will also be un-libifying the project.  Right now I have 12 projects in my solution, 10 of which are libs for different aspects of the engine (scene, procedural stuff, sound, etc).  There is absolutely no need for this, so I will be grouping all of the libs into one libnebulous, and leaving the 'client' and 'server' projects on their own.

The biggest change I will be making is upgrading from DirectX 9 to DirectX 11.  I've seen a lot of amazing things done with 11, and I have been putting off upgrading simply because I learned on 9, and have been very afraid of losing my fixed-function pipeline because shaders are scary.  I haven't done a lot of shader programming, but I guess it's about time I learned to get better considering they will open up so many new doors to me.

As always, one step forward, 10 steps back!

Sunday, September 23, 2012

System Map

It's been a while since I've had time to work on this project, but this weekend I sat down and banged out something I've been wanting to do for a while: the system map!

First, here's a zoomed out shot of the entire system:


 A view of the inner planet and its many moons:


And a view of the second planet and it's huge moon orbits:


The white orbits are for planets, and the purple orbits are wormholes.  When you are in the map, the game is paused.  Right now only the basics are implemented, but I'll be slowly building onto it in the future.  At the moment it only draws planets, wormholes, their orbits, and you can move the camera around.  The camera is controlled with the mouse buttons and movement.

The idea is for the system map to be the tactical center of the space-aspect of the game.  From the map you can see where other objects and ships in the system are, where you are, and you can plot interplanetary trajectories.  I've got a pretty awesome concept thrown together for how the course plotting will work, and I'm really excited to implement it.

Wednesday, July 25, 2012

Flight HUD Mockup

 I put together a quick mockup of what I want the HUD for the one-maned ships to look like.

The center is the standard "ladder", which shows you your angle relative to the horizon.  When you're not close to any planets, it goes away leaving only the center reticule and the "wings".  On the left of the wings is the speed readout, which shows your speed relative to your current target (or absolute speed if you have no target).  Directly under it is the change in speed per second, and below that is the "crab angle" (which is the difference between your heading and track).  On the right is the altitude above the nearest planet, and the change in altitude per second.

The vertical bar on the right indicates your position relative to the atmosphere.  Its height is twice that of the atmosphere of the nearest planet.  The line in the center indicates the top of the atmosphere, and the bottom line indicates sea level.

On top are the warning lights, telling you when things are going wrong.  On the bottom are the status lights, such as gear status.  "THRST FL" means Thruster Flight, which is the flight mode you use in space.  When in Thruster Flight, your maneuvering thrusters control your ships movement.  "SRFC FL" means Surface Flight, meaning the control surfaces on your aircraft (ailerons) control your direction.  This is the flight mode you use when you're inside the atmosphere, and it makes you fly like a normal plane.

Sitting over the ship is the target indicator for non-selected targets.  It simply makes other ships easier to see, and shows you their distance and relative velocity.

Saturday, May 19, 2012

Interstellar Highways

Well, I'm graduating college tomorrow, but that's not important.  What is important is Wormholes!  Here's a picture to start us off:


That's taken from the starmap, displaying bridge-type wormholes between several systems.  I'll get into more detail about the wormhole types in a bit.  Right now the starmap shows all generated bridge wormholes, but in the future it will only display wormholes the player has "explored".  As the player travels to each system, its wormholes are generated along with the rest of the system.  Those wormholes do not get marked as "explored" until the player has traveled through them.  Once they are explored they'll show up on the starmap, so the player can keep track of how to get where.

Wormholes will serve as a means of faster-than-light travel between solar systems, in order to cut down on how much waiting the player will have to do.  However, they don't have to use the wormholes.  Though it's not implemented at the moment, eventually you will be able to just point your ship at a star and fly there.

Wormholes In The Wild

Wormholes will appear in the game as spheres through which you can see the destination system.  I really hate the stereotypical funnel look, I think it's silly.  This is the effect I'm going for (screenshot from EVE Online):

However, since I'm not very good at writing shaders yet, I think it will fall far short of my expectations.

They will be labeled as ERB-########### (standing for Einstein-Rosen Bridge).   They will also orbit their primary like planets.  Wormholes can appear around both planets and stars, and will orbit their parent body like any other moon or planet.

Wormholes will exert a strong gravitational pull.  Small objects such as ships and stations can enter orbit with a wormhole with great care.  Because of this gravitational pull, navigating a successful jump can be tricky.  You need to make sure you have enough speed when entering the wormhole so that you can escape the gravity on the other side.  Speed and direction will be preserved through wormholes.

Ships can scan wormholes for their energy signature (the type of energy they're scanning for is yet to be determined.  I still have to do some research on this to figure out what's realistic).  The type of energy will give hints (only hints!) about the type of wormhole, though you won't be sure until you travel through it! 

Wormhole Types

There are two types of wormholes which I'm implementing.  If I can think of more, I will make more.  At the moment, these are all I've come up with.

Type 1: The Bridge (Stable)

The first, and simplest, type of wormhole is the Bridge.  Two wormholes form a static link between two star systems, and that link will never close.  You can travel back and forth between those systems without losing your way.

They appear on the starmap due to their stable nature.

Type 2: The Unstable

If you've ever seen one of these guys, you know exactly what I'm going for here:



Imagine that the bottom of the wacky waving inflatable tube man is the wormhole you're passing through.  Now, imagine that the top is the exit wormhole.

The entrance of an unstable wormhole is always located in the same system, but its exit is constantly shifting.  Two ships passing through more than a few seconds apart may end up on completely opposite ends of the galaxy.

Traveling through an unstable wormhole is a huge gamble, because there's no easy way back.  However, it may be the quickest way to your ideal system.  When traveling through these, cross your fingers.

These types of wormholes also play a large role in the plot of the game, as they are how you got to this strange galaxy in the first place.

Tuesday, May 1, 2012

Starfield Builder


I've been working on a module lately which will generate a starfield from the point of view of any system in the galaxy.  The shot above is a composite of pieces of the skybox taken from a system inside the outer ring of a galaxy of 100,000 stars.  I had to let the galaxy generator run all night to get that database.

In the center you can see the core of the galaxy, and on either side you can see the outer ring arcing away from us.  I think it's a pretty spectacular view, to be honest.

Here is what the galaxy looks like from above, for reference:


The system that starfield is for is in the upper right-hand corner, midway through the ring.  You'll notice the core is a rather well-defined circle, and I'm planning on fixing that soon.

I'm considering tasking one of my servers to generate a 1,000,000 star galaxy over the next few days (or weeks, depending on how long it takes), but I'm really not sure what that would do.

Capital AI


After the students had such a hard time with the docking, I decided to work on the AI a little bit for myself as a fun little challenge.  What I ended up constructing was a basic planning AI which can dock with the station given any set of waypoints.

First, it waits until the station's air traffic controller contacts it and asks for intent.  It then asks for docking permission, and when it's been cleared (and given a set of waypoints to the docking point) it generates its plan.

It loops through each waypoint and determines its distance.  If it's more than 20km away, it will burn the main engine to get there.  Otherwise, it travels there on maneuvering thrusters.  Once it's at the second to last waypoint, it aligns for docking and slowly travels towards the docking point.  When it's in range, it calls the docking solver which returns and error or success code.  Based on this code, it determines what to do next.

If the dock succeeded, it does nothing else.

If it failed, it checks the error to see what went wrong.  If it was out of range, it attempts to re-approach.  If the angle was too steep, it attempts to re-align and then approach.

Monday, April 23, 2012

System Generator - Iteration Two

First, a video:



That was created by the second iteration of the solar system generator.  I finished it this morning and spent the rest of the day flying around different systems until I realized it would be a cool idea to make a video.

The first "iteration" of the generator just placed an earth-sized planet and moon in each planet slot.

The first real iteration was basically me throwing code at the engine and seeing what stuck.  I developed some basics ideas for how the generator would work.  I refined those a little bit, but the thing was still a hulking mess by the time I called it "done".

For this iteration I went back to square two.  Using the strategies I had developed last time I rewrote the entire class.  The methods were cleaned up, things were reorganized, data structured were expanded, cake was had.

A lot of the stuff that changed in this iteration was simple number tweaking and reorganization.  The coolest thing though was planetary motion.  Planets and moons now have realistic orbital periods.  In the video, you can see the white circles representing each planet's orbit.  Unfortunately all orbits are circular at the moment, but perhaps in the future I'll expand them to ellipses.  Afterall, how hard can that be?

One of the things I'm not quite happy with is the moons.  Their orbits look great, but it's their size I'm concerned about.  If you look at the information scrolling on the left, you'll notice that most of the moons are around the same size.  I'm definitely planning on adding some more variety there in the future.

The System

There are two major parts to the procedural galaxy.  The first is the galaxy generator, which is run once at the beginning of the game.  It initializes the database and fills it with as many star systems as you want.  But these systems aren't complete yet.  When each star is created, the generator chooses a fraction of their mass to be left in the protoplanetary disk to form planets.  It also holds an integer entry for the number of planets in the system.

Those star system entries sit in the table until the player visits one.  At that point, the incomplete entry is handed off to the system generator which finishes the job.  The system generator takes the mass left for the planets and smears it out across a disk, and then integrates that mass function in concentric rings to form planets.

Next Iteration

I'm going to be taking a break from this for a while (not too long, probably a week or two) so I can work on other stuff.  Here's roughly what I'm hoping to accomplish next time:

- Moon Variety
     As mentioned above, moon sizes are a little too consistent.

- Wormhole Bridges
     These will serve as the main form of transport between solar systems.  There's a lot of interesting stuff I want to talk about with these, so I'll save it for another post.

- Other System Types
     Right now the system generator only creates planetary systems.  Eventually (hopefully next iteration) I'm hoping to expand it to the other two types of systems in the database: barren and debris.  More on those later.

- Rings
      Rings were removed since the last iteration because they were just randomly put in there.  In the future I'll be looking at a more realistic way of creating them.

- Planetary Characteristics
     Each planet data structure has three float parameters and three integer parameters as unused placeholders (easily expandable if I need more).  This is the least important of the things I want to get done, so I might not even get to it.

Monday, April 2, 2012

Bubbles Mk 2

This is probably the 8th or 9th time I've rewritten the core of the scene graph. My girlfriend says its because I keep learning more and figuring out how to improve it, but I think it has more to do with my grandmother's old adage "If you've got a weak mind, you'd better have strong legs."

I've flipped back and forth between using a spatial partitioning method I've called bubbling, where space is carved up into sections which all have their own independent coordinate system. They divided space up into a three-dimensional grid, but only when objects were in their specific cell. In other words, the a bubble only existed when an object was in it. This was a pretty straightforward memory- and performance-saving optimization. 99.99999% of space is empty, so why should I bother keeping track of all that emptiness?

They last went away when I switched everything over to doubles for position vectors. However, trimesh collisions were getting a little wonky as distance from the origin increased, even with double precision. Once they got past a certain distance trimeshs stopped colliding all together.

So I spent a not-insignificant amount of time in the lab today bringing bubbles back.

Instead of creating a dynamically-spawning grid again, I anchored a static bubble at each planet, since I can pretty safely assume that's where most of the gameplay will happen. This gives each planet its own local coordinate system, which is helpful in a lot of ways. These static bubbles have a radius, and when nearest celestials are recomputed every 30 seconds each object is checked against this radius. If they have passed outside, they're considered in interplanetary space.

The next step in this is implementing interplanetary space. This will consist of a new bubble class, called DynamicBubble. Dynamic bubbles move around space as the average of the positions of all the objects they contain. If any objects get too far apart, the bubble splits in two. This should keep coordinate systems from getting too large and causing the wonky collision problem again.

I suspect that dynamic bubbles are going to be harder to implement than they sound. But they will be extremely useful.

Wednesday, March 28, 2012

Student AI Trials

I've compiled some clips of the AI Game Programming class's attempts at docking with the station. Here's the video:

Monday, March 26, 2012

Maneuvering Thrusters

Because it's going to look really cool to have the student's AIs tomorrow thrusting the ship all over the place, I really wanted to see the maneuvering thrusters firing. So I started working on a particle emitter class which can do just that:

Here's a picture of the bow thrusters firing to slow the ship down. There will be thruster emitters placed all over the ship which will correspond to different maneuvers.

Thursday, March 22, 2012

Small Features

After big pushes in development are completed (such as the AI dll prep that had been consuming me) I like to settle down and work on small features before starting on something big again.

This time I decided to touch up some simple UI stuff, as well as add a small feature to make motion more apparent.

First came the UI. I originally had a huge ugly progress bar that took up the center of the screen for scene loads. To replace this I made a stackable, unobtrusive progress bar system which allows progress bars to stack up on top of each other at the bottom of the screen. They're pretty in their simplicity and tiny-ness. Because they sit at the bottom they can be used to show loading in threaded subroutines without interrupting play. The fact that they stack means more than one process can display its progress at the same time.

I also touched up the graphics for the flight HUD, making the attitude indicator and warning lights much sleeker.

In order to make the player's ship's motion more apparent, I introduced a system which renders what is supposed to be specks of dust streaking past. This shows your overall direction of motion in a nifty way.

Above is a screenshot of the new flight HUD graphics. You can also see some of the streaks in the picture. They are very faint because I wanted to show the direction of travel without making it blatant.

Friday, March 16, 2012

Corona


I thought the current star rendering scheme was rather ugly (just rendering a sphere and letting the bloom shader but a little halo around it) and wholly unsatisfying. Not to mention unrealistic.

Since I'm giving the galaxy the little more attention this week I figured I'd write a quick shader to put a corona on the star. It's just a simple first-try, but it already makes the star look a lot more impressive than a full-bright white sphere.

The star is white because it's a product of the older version of the galaxy generator, which did not interpolate colors and just set them all to white. The shader also takes in the star color, but you can't see it here.

Tuesday, March 13, 2012

Star Coloring


In my mad rushes to complete large portions of the game for various school projects over the last year, the galaxy generator has kind of fallen by the wayside. Because it's such an important part of the game's concept, I'm going to be giving it a little more love in the days to come. Starting with stars.

I hadn't really given much thought to how to color stars initially, and they're all just generated as white regardless of their temperature. Using the table on wikipedia (http://en.wikipedia.org/wiki/Stellar_classification) I created a gradient of colors which I can lerp between to find the color of each star based on its temperature. The range is from 3700K to 33000K. Anything above or below those limits just gets the end color.

The actual coloring for the rendering will be done in the star shader, which has yet to be started but should prove to be interesting to write.

Once I've got coloring done I plan to start work on generating the starfield skybox textures based on the player's actual position in the galaxy. The size and colors of the stars in the starfield will be representative of the color of the actual stars, as well as their distance from the current system.

Tuesday, February 14, 2012

A Push Towards Hard Sci-Fi

I've long been searching for a means to distinguish my game from other similar 1:1 scale procedurally generated universes such as Infinity. This is mainly because Infinity is just so damn pretty I can't compete. Instead of trying to beat them at their own game, I've decided on pushing further into hard scifi than ever before.

This engine was always intended to support a hard scifi game universe, but until now I was willing to make concessions to improve playability. Things such as gravity on ships just made the game easier to play (and to code). But now I'm switching gears.

For one, I've settled on more realistic ship designs for the actual game. Pictured here is a small scout ship. The crew area is the front cylinder, and the decks are stacking along the boosting axis. Acceleration by the main engine produces gravity "downwards". When the ship is not accelerating, there is no gravity inside.

This design choice will require me to develop a way for the player to move around inside the ship while in freefall, and I think I've come up with it. But more on that in the future once it's actually been prototyped.

As for other concessions that are going out the window, Jump Drives are among them. Previously, capital ships had jump drives which would allow them to instantly travel to any star system which was inside that ship's jump range. That will no longer be the case. Instead, FTL travel will be accomplished via wormholes. I already have an early prototype in the galaxy generation algorithm which will grow a wormhole network between stars in the galaxy. Ships will need to travel to these wormholes at sublight speed.