Freefall

Order Matters

noreply@blogger.com (Unknown) — Fri, 23 Feb 2018 03:58:00 +0000

Shortly after the previous blog post I began socializing the test build with some friends, several of whom are experienced video game spaceship designers (if that actually means anything). This initial version required the player to create the interior of the ship first, then design the outside around it. Despite their experience they found it incredibly frustrating to produce anything more than a box-ship when designing from the inside out. Even I, the person who programmed it, admitted to having some difficulties.

This style of design was difficult for a number of reasons, not the least of which was that people find it very difficult to think about shape when they're only presented with 2D slices. Estimating weapon coverage and maneuvering thruster placement was next to impossible.

So of course I told my play testers they were wrong and kept forging ahead.

No, what I did instead of spend about two months re-writing the hull designer to work in the reverse order which turned out to be much more intuitive. Players now design the exterior of the ship first and place their interiors inside that shell. To be honest, I had taken inspiration for the inside-out style of design from Shores of Hazeron, but given how obtuse just about everything in that game is I really should have known this would be a losing proposition.

The best news: people now tell me they are actually having fun with testing, and have even reported firing up the game on their own just to play around with it. So without further ado, here are some example builds.

The next milestone is a few usability improvements to the designer, including the ability to save and load multiple ships instead of always using the same file. After that, it's time to leave well-enough alone and move on to turning these ship models into usable RTS units.

Ship Building Demo

noreply@blogger.com (Unknown) — Sun, 10 Dec 2017 06:46:00 +0000

I spent today ironing out some "final" bugs in the ship builder and re-building the demo ship from the ground up. I now have an alpha build of the editor which I sent to a few friends, so it'll be interesting to see what they come up with.

The next step is baking this construction model into a real, functional strategy game unit.

Resource Networks

noreply@blogger.com (Unknown) — Wed, 06 Dec 2017 07:51:00 +0000

One of the core mantras I really want to come across in this game is the 6 P's (proper preparation prevents piss-poor performance). Players who think through the design of their ship will always win versus players who slap a lot of guns on a box and hope for the best. One of the most important factors in how a ship will perform in combat will be how well it can withstand damage.

Unlike most voxel-based games, damage to blocks will not necessarily make them disappear (this will only happen where a specific DR for the block is beat, mostly from very heavy weapons). When the exterior blocks take hits, they will have a probability of causing damage to interior blocks. This damage can include starting fires, bursting pipes, severing data links, causing atmosphere leaks, etc. For example, if the communication link between CIC and a gun is severed, that gun will need to switch to local control (which will incur penalties).

This suggests that there are pipes to burst and conduits to break. In order to provide the player the ability to build redundancy into their design (e.g. so a single hit to the wrong place won't knock out power to half the ship) I had to implement a system of piping and wiring. This system is called Resource Networks


Foreground: Water pump (left), Fuel pump (right) Background: Circuit breaker (left), Reactor (right)

In the images you can see a simple version of an engine room with its various connections. These include fuel and water tanks, engines, a reactor loop (reactor, steam turbines, condenser), and pumps.

Every resource system tile (4 per regular tile) can have a conduit traveling through it in 2 of 3 directions (e.g. if a pipe it going lengthwise and widthwise, nothing can go vertically). Certain types of conduits can also jump others on the same level, as you can see in the very center of the top image where the grey power cable goes through the red pipe. I haven't implemented specific geometry to illustrate this jump yet, so right now they just clip through each other.

Equipment can have Resource Connections at positions in the grid. These are divided into Sources, Sinks, and Storage. Every tick sources output a resource into the net, and sinks consume that resource. If there is more demand than supply, connections become starved and the block may stop functioning. Special types of sinks with the "CanPull" flag set can also draw from storages. A pump, for example, is implemented as a can-pull sink and a source, allow equipment connected to the output to receive resources stored in tanks they wouldn't be able to pull themselves.

New Beginnings

noreply@blogger.com (Unknown) — Tue, 28 Nov 2017 03:42:00 +0000

It's been more than four years since I've had a project worth posting about on here. Previously this blog was dedicated to progress on my own game engine. Game engines are cool, but I'm more interested in making games.

Over the past two months I've been laying the groundwork for a new game project, and I finally have some progress worth presenting. Most of that time has been spent creating extensible and generic components for building ships (compartments, machinery, exterior hull, etc) and an interface for putting them together.

So what do the first results look like?


Example Frigate Exterior

Interior Deck Layout

This game is a space strategy game with some twists. I grew up playing games like Homeworld, and I loved the real-time strategy combined with the three dimensional battlefield (and of course, the spaceships). But something has always bugged me about strategy games, and it is the fact that a gigantic space battlecruiser and an infantryman are treated exactly the same way: they are a singular unit which has x hitpoints before it dies.

I might be biased but ships are far, far more than a singular unit. They're complex machines operated by hundreds of people. In this game you can command your ship in a traditional RTS sense, but you can also go inside and give crewmembers orders to, for example, patch some damage or fight a fire. I want the player to be able to see the chaos inside of a heavily damaged ship, and try to task their (surviving) crewmembers with repairs to keep the ship fighting a few moments longer.

Ships are comprised of compartments which have equipment such as engines, pumps, or terminals inside them. This equipment is connected together with piping and wiring to form resource networks which allow them to function, such as providing power to blocks which need it. The exterior hull is built in a Space Engineers style around the interior.

Battles will take place between small numbers of ships (2-3 per player) due to their complexity, with long time-to-kill for an individual ship. As ships take damage, equipment will be damaged and resource connections broken necessitating repairs. Fires can also be started, and will spread if not fought quickly. If an exterior block has taken too much damage it can be destroyed completely, possibly opening a compartment to space.

One thing I am absolutely adamant about is that there will be no point where a ship loses all of its health and spontaneously ceases to exist. As long as there is a single living crewman and functional equipment on the ship, it can still be selected and given orders (whether it can carry out those orders is another matter).

So join me on this journey into making the most micro-manage-y spaceship RTS ever.

Let's Talk About Planets

noreply@blogger.com (Unknown) — Wed, 14 Aug 2013 00:16:00 +0000

It's been a while since I've posted anything, but I certainly have not been idle. In fact, the reason I haven't posted anything is because I have been so busy! Usually I get an hour or two every night when I'm back from work/gym to work on this project, and writing blog posts is time consuming. So usually I get coding instead of blogging, but I don't want to neglect this thing too much.

Sit back, this'll be a long one.

Up until recently, all of my terrestrial planets have been featureless, uniform spheres. You could land on them, but you couldn't really go sightseeing. Not so anymore.

I've always been a fan of building up concepts from the bottom, so if we're going to talk about planets the first thing we need to talk about is spherical quadtrees. Each planet has six faces, which we'll call 'front', 'back', 'left', 'right', 'up', and 'down'. Initially, each one of these faces is a flat grid of 32x32 vertices. But planets are not square, so by normalizing the position vector of each vertex we end up with a unit sphere. Moving these vertices along their normals by the equitorial radius gives us a sphere the size of the planet.

Each of these faces is the root node of a quad tree. Each quad tree is capable of dynamically subdiving to provide higher levels of detail. The reasons for this being necessary should be obvious, but I will state them anyway: it would require gigabytes of memory to store all of the vertices necessary to render a planet at a meaningful resolution (say, 5 meters between vertices). Also, the majority of this fidelity cannot be appreciated when it is on a distant mountain, or from a ship looking down from orbit. This method reduces the load on the GPU considerably, and consumes much less uncessary memory.

Every level down on the tree covers one quarter of the area of the parent, meaning we can represent more detail with the same group of 1024 vertices. These subdivision continues until we reach a desired level of fidelity (based on a certain distance between vertices), at which point the node becomes a leaf. Terrain leaves have collision meshes, and can be stood on. In order to minimize physics complexity, only active pages (with objects directly above them) and their immediate neighbors have collision meshes.

The SphericalQuadTree class features a series of utilities for finding neighboring tiles given a direction of movement. These utilities use a series of lookup tables to find the appropriate neighbor, and they even work across the "face" border. Constructing these lookup tables took a while, and in order to get it right I actually had to make a paper cube that represented the 6 faces of the planet and label it.

With that stuff out of the way, we can talk about terrain generation.

Every planet has a terrain type and a seed value. From there, we can generate the terrain for the entire planet. This is done with an interface called the Landscaper, which has several different subclasses for different terrain types. Every time a new vertex is created in a terrain page it calls a method on the Landscaper and then adds that to the equitorial radius, moving it up or pushing it down.

To do all of the generating I am using libnoise, an awesome open-source coherent noise generation library.

The first important thing to realize is that when I say "type" I don't mean things like plains and mountains. The terrain type defines what type of planet it is. Currently I am working on the simplest, called "Barren", to figure out what works and what doesn't. After that is done, I will implement the others using the techniques from Barren.

Here's an example of what I've got so far (with vertices colored based on altitude):

And here are the currently-planned terrain types:

Barren

These planets are geologically dead (if they were ever very active at all). Picture these planets looking a lot like the Moon. They'll usually have rough mountainous areas and relatively flat maria produced by lava flows. These types of planets will never have an atmosphere, and because of this will usually be heavily cratered.

Irregular

These aren't really planets so much as large captured asteroids. Mimas is an example of what I'm going for here: a large, oddly shaped ball of rock. Most of the geological features here will be cracks and craters in the surface.

Magmatic

"Lava" planets are generally young planets which haven't cooled down after their formation. The Earth was probably like this for the first few million years of its existence. The surface of these planets mostly appears to be "continents" of cooled magma seperated by gaping fissues of red. Glowing rivers of lava can be easily seen from orbit. These planets may or may not have an atmosphere, which would mostly be sulfur and other products of volcanic activity.

Ice

On the exact opposite end of the spectrum are ice planets. Enceladus and Europa are great examples of these types of planets. These planets will feature hilly white wastes, sprinkled with craters. Enceladus also has interesting fractures on the surface caused by tidal stresses from the primary. Some researchers suggest that Europa may have a sub-surface ocean. I'm not sure if I'll be able to do something like this, but it could theoretically be modeled with some kind of terrain shell (I will have to think about this). These planets may or may not have atmospheres.

Martian

I couldn't think of a great name for these, but basically they are relatively-habitable planets with terrain that was shaped by things like wind, dust storms, and glacier movement. Rivers may appear on these planets, though the liquid is long gone.

Terran

Finally, the gems of the galaxy. These are what the players are really hunting for if they want their best chance at survival. These planets are much like Earth, with diverse geological regions and liquid water. This will be the most difficult terrain generator to implement, and most likely the slowest because of the large number of noise modules needed to generate interesting terrain.

One of the things I want to add on to the basic terrain generation is the placement of monolothic features such as cataclysmic craters and giant mountains a la Olympus Mons. I'm not sure how I can integrate this with the noise modules, but I will probably have to end up extending libnoise in order to do it.

Also, I mentioned atmospheres in several posts above. I have a very rudimentary framework in place for atmospheres, but currently they are not actually implemented. In terms of their actual generation, I'll save that for another post when I actually have something concrete done for it.

Once the actual generation of the physical terrain is complete, I'll be moving on to coloring them. I have been thinking a lot about how to accomplish the texturing itself. The planet terrain has a unique vertex class and its own set of pixel and vertex shaders, so I have a lot of freedom to try any methods I want without altering how anything else in the engine is rendered.

One of the first ideas to cross my mind was to do it all procedurally on the GPU, but I quickly decided that it would be too difficult to produce realistic results with only the data available to the GPU.

The idea I am leaning most heavily towards involves several steps. I won't go into much detail until I actually have something implemented, but here is a rough overview. First, we take the output of the noise modules determining things like terrian type and "biome" type. Next, we also need to take into account the angle between the surface normal and the up-vector at that location on the planet (because this changes, the planet is round!) so that we don't get things like grass growing on the side of a cliff. Once we have some information about the type of ground this vertex represents, we can blend together a palette of available ground textures to get the desired result.

Hopefully soon I'll have some more progress pictures for the different planet types (without textures). Until then, onward and upward.

Starfield Builder (Iteration 2)

noreply@blogger.com (Unknown) — Wed, 27 Mar 2013 01:19:00 +0000

As part of the directx 11 port, I've finally revisited the starfield generator. There isn't much new in this version, as it was mostly just porting dx9 to 11, but it finally draws textures on the quads for the stars, and colorizes them to match the actual star color.

The colors are very subtle, but still noticeable. I'd rather have them that way, to be honest, instead of being obnoxiously in-your-face.

A simple re-write, but the results look much better!

Ring Systems (Part 1)

noreply@blogger.com (Unknown) — Fri, 15 Mar 2013 04:53:00 +0000

I think it's pretty safe to say that Saturn's rings are one of the coolest things in the solar system (or at least one of the prettiest). I've been wanting to give more love to rings for a while. When I originally implemented them I was having quite a bit of stenciling problems (zbuffering doesn't work at these scales), and dropped them after I got them barely rendering. Now that I've been slowly rebuilding every part of the engine to work with DirectX 11 I've come back around to gas giants. Instead of doing the jovian shader immediately, I decided I really wanted to get rings right first (rationalizing to myself that they applied to all types of planets, and was thus a bigger step than just one specific type).

The formation of ring systems isn't well understood, so I had to take a somewhat less-than-scientific approach to generating my own. To over-simplify it, rings are basically a collection of particles inside of a planet's Roche Limit, meaning that the gravity of the primary is too strong inside that limit to allow them to coalesce into a planet. I did a bit of reading on what we know about Saturn's rings and tried to nail down a way that they could be generated programmatically. For a first iteration, I'm pleased with the results.

Structure

The Voyager probes were the first to discover that Saturn's rings were more complex than just the two main rings we could make out at our distance. In reality, they are comprised of hundreds of thousands of tiny ringlets. It's generally theorized that the structure of ring systems is closely tied to the moons orbiting the planet that hosts the rings. The interaction of the gravity of the moons and planet with the ring particles creates "divisions" in the rings. Moons that produce this effect are called "shepherd moons".

To create the major structures I'm using a Weibull distribution modified by a portion of the number of moons the planet has. There is a minimum value, so there is still some variety even if the planet has no moons. "Major structures" includes rings and divisions. By taking the modulus of the iterator in each loop I can alternate between divisions and rings. An Inverse Gamma distribution is used to determine structure thickness, with the scale argument for divisions being smaller than rings. Each structure is then written to the texture, with the alpha value varied using Perlin Noise to keep them from appearing as one solid color.

Here are some examples (each ring is given a random color to make them distinct during development):


Rainbow Rings!

There will be more on composition in a minute, but for now just know that each ring will have a general color. To break up that homogeneity I added "minor structures", which are a randomly generated number of 1-texel wide rings roughly uniformly distributed throughout the major rings to add some flair. Right now they're just green to make them stand out:

Composition & Color

Saturn's rings are comprised primarily of water-ice, with fragments of rock, dust, and minerals providing most of the color. Right now all of the colors seen here are only for testing purposes. Even though they look awesome, I don't want clown planets sprinkled around the galaxy.

This won't be implemented until much later, but the appearance of rings will eventually be determined by the composition of the planet they orbit. The reason this feature is on hold for a while is because I have yet to figure out a good way to smear elements around the solar system with interesting distribution. Before I can determine which elements will be present in the rings (and thus, which colors) I will need to determine the composition of the planet.

In general, lighter elements tend to be pushed into the outer solar system during stellar ignition (which is why all our outer planets are gas giants). This is because when a star finally ignites the sudden burst of solar wind pushes the lighter elements away faster, leaving the silicates and heavy elements to form rocky planets.

Once I've finally managed to determine the composition of the planet I can take that and color the rings. Right now I'm thinking that the more abundant materials of the planet will form the major rings, and the rarer and often brighter elements will provide the hint of variety in the minor rings.

Other Cool Stuff (in the future)

Eventually, I'll need to give the rings some real mass so that when you fly through them you don't realize it's really just a textured triangle ring. Saturn's rings are made of particles ranging from a few centimeters to ten or more meters. In terms of thickness, they range from a few meters to almost a kilometer. In order to get this thickness, the shader will have to do a few things. The first will be to fade away the texture nearest to the camera so there is a hole (in much the same way that you can't see the fog closest to you). In order to fill that hole in the texture, I'll have to render dust specks in the field of view. For more substantial particles, I haven't made up my mind on how to implement those. Creating unique geometry on the fly for dozen or even hundreds of meter-sized asteroids seems like it would be a strain, even using geometry shaders. Voxels may be the answer here, but I haven't yet implemented a sparse oct-tree renderer as it would be quite a task.

But I can dream.

Upgrading to VS2012

noreply@blogger.com (Unknown) — Wed, 19 Dec 2012 02:02:00 +0000

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.

Landing On Planets

noreply@blogger.com (Unknown) — Tue, 11 Dec 2012 02:59:00 +0000

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!

System Map

noreply@blogger.com (Unknown) — Mon, 24 Sep 2012 02:10:00 +0000

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.

Flight HUD Mockup

noreply@blogger.com (Unknown) — Thu, 26 Jul 2012 03:06:00 +0000

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.

Interstellar Highways

noreply@blogger.com (Unknown) — Sun, 20 May 2012 06:42:00 +0000

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.

Starfield Builder

noreply@blogger.com (Unknown) — Wed, 02 May 2012 01:19:00 +0000

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

noreply@blogger.com (Unknown) — Tue, 01 May 2012 17:28:00 +0000

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.

System Generator - Iteration Two

noreply@blogger.com (Unknown) — Tue, 24 Apr 2012 04:14:00 +0000

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.

Bubbles Mk 2

noreply@blogger.com (Unknown) — Tue, 03 Apr 2012 03:23:00 +0000

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.

Student AI Trials

noreply@blogger.com (Unknown) — Wed, 28 Mar 2012 23:57:00 +0000

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

Maneuvering Thrusters

noreply@blogger.com (Unknown) — Mon, 26 Mar 2012 17:30:00 +0000

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.

Small Features

noreply@blogger.com (Unknown) — Thu, 22 Mar 2012 21:56:00 +0000

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.

Corona

noreply@blogger.com (Unknown) — Fri, 16 Mar 2012 14:43:00 +0000

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.

Star Coloring

noreply@blogger.com (Unknown) — Wed, 14 Mar 2012 04:58:00 +0000

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.

A Push Towards Hard Sci-Fi

noreply@blogger.com (Unknown) — Wed, 15 Feb 2012 05:45:00 +0000

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.