Updated interface for unit selection:

Most of the information and commands a player needs to manage units are located in the selection bar, located in the lower middle section of the screen. The panel on the right shows a list of icons representing all currently selected unit types and how many of each type are selected. This section also displays the total health and energy levels of all the selected units above. Clicking on one of the portrait icons here will deselect all other types within the current selection, which is designed to allow the player to easily select only certain unit types for special attacks.

Unit control GUI

The left panel contains the colored stance buttons along the top (aggressive, defensive, hold position, and hold fire) and automatically populates the lower section with all abilities available to units within the current selection, in this case some of the selected ships have a speed boost ability, which uses up energy.

Unit control GUI 2

Unit production:

GUI for Production Buildings

Unit production is handled similarly to regular unit control, but makes use of an extra panel on the left side of the screen. Note that the actual buttons for creating units are on the panel to the upper left, while the lower middle panel displays the next 5 units in production and the progress bar for the ship currently under construction. The upper panel also displays the total number of each type of unit in the production queue, since the player can queue up many more than 5 units at a time, however only the first 5 are shown in order. Units can be canceled by right clicking on the portrait in either location. Some of the changes to the production GUI are a result of switching to a pay as you go system for producing units, (like the one in C&C games) as opposed to the model where you have to pay all the resources up front to begin production (as seen in Starcraft.) This way, the player can queue up a very large number of units even with low resources, which should make macro management less stressful.

Finally, in addition to the GUI updates, I’ve made some changes to the graphics engine. Ships are now better lit and contrast better with the background space, plus I’ve added or increased a glowing outline effect to most units to help them stand out even more.

After a lot of testing, I decided a while ago to bring a two resource system back to the game. There are a few reasons for this change, and while I’m hesitant to add any more complexity to the game, some change was necessary. For one, I wanted to add a more gated resource to balance out the un-gated asteroid resource; asteroids are meant to be very common on most maps, which unfortunately also means that there would next to no limit to a player’s potential ore income. The maximum collection rate for the second resource is tied to the number of large planetary bodies, which limits the player’s ability to rapidly strip mine and spam units.

mining base and player owned moons

In summary, there are now 2 different game resources: ore and credits. Most units require a mixture of both ore (obtained from asteroids/scrap or planetary mines) and credits (obtained from scrap harvesting as well as from taxation and trade from planets.) Lower tech units as well as space station modules require primarily metal, while higher tech units and upgrades will require more credits.

scrap metal harvesting

Scrap metal deposits are placed in strategic locations on the map and are also spawned whenever space stations or ships that are frigate class or larger are destroyed.

asteroid mining

Asteroid fields can provide a plentiful source of ore throughout the game.


colony modules

The 4 types of available colony modules and their respective landing ships in the foreground. In addition to their specific roles, all colonies increase the planet or moon’s population over time, leading to a greater commerce rating and more income in credits to the player who owns the planet. These colonies have been in the game for a while, but I’ve recently revamped their appearance and changed a few of their functions.

  • Planetary Cannon: strong base defense (has a limited firing cone which changes direction as the planet rotates)
  • Trade Port: enables trade between planetary bodies (see picture below)
  • Atmosphere Factory: creates a breathable atmosphere if one doesn’t exist, increases population growth rate and grants bonus efficiency to all colonies
  • Mining Colony: provides a supplemental income of ore

trade routes

When the player controls more than one celestial body that has a trade port colony, a trade route is automatically created between them and trade ships are periodically spawned based on each planet’s commerce rating. Trade ships that make it from one planet to another will give the player a moderate sum of credits, however these ships are extremely vulnerable to harassment during transit.

What’s next? I’ve fallen a bit behind where I’d like to be with the game, but I’m still focused on making a playable demo and then going into a paid alpha. Going forward, I’ll be working a lot on improving the skirmish AI, and I intend to also post a smaller update as I finish updating the GUI and the last of the new space station models.

Engine Improvements:

Since the last update (formations and optimizations to unit movement) I’ve been working on optimizing and generally improving all other aspects of combat in the game. With the new projectile code, I’ve been able to drastically increase the number of projectiles the game can handle, leading to a re-design of several of the old units to take advantage of this. (including adding a rapid-fire Gatling laser cannon to one of the low level frigates) I’ve also been experimenting with dynamically adjusting graphics settings to turn off some of the more expensive graphical effects when especially large battles are being displayed.

optimized fighter groups
(better game engine = more ships and more lasers)

These improvements are especially important because, in Empyrean Frontier, the combat system is mostly based on projectile attacks with realistic ballistic physics. There are no traditional damage types or armor types, instead the size, accuracy, rate of fire, base damage, and number of ships in a group determines which units are able to counter which other units.

There are a few interesting side effects that come from this kind of projectile based system. The main reason why I like it is that it provides a natural incentive to spread out your ships and surround the enemy forces, rather than vice versa. Projectiles that miss their intended targets are still very likely to hit nearby units when they are tightly packed and there are overlapping lines of fire, whereas projectiles are likely to miss entirely if the units are spread out. The army with the better positioning tends to have a massive advantage, so the tactical aspect of RTS army control will be extremely important in the finished game.

At the most basic visual level, it’s important that weapons tend to act as you’d expect; high rate of fire weapons are good against many small units, while a large single projectile like a tank shell is more efficient against larger ships. To improve readability and decrease the learning curve, weapons are also being color-coded according to their rate of fire and damage output.

Color Coding:
Green = anti-fighter
Red = anti-frigate
Yellow = area of effect damage

Unit Improvements:

In addition to the back-end optimizations, I’ve also been working on updating the unit models for all of the ships. At the moment, there are 8 different kinds of combat ship: 2 fighters, 5 frigates, and 1 cruiser. Progress has been slower than I’d like, but as I still want to release an alpha and demo as soon as possible, it was important that the ship models were updated to be more professional looking. Apart from looking nice, which hopefully they do, each kind of ship needed to have a distinct style in order to easily distinguish between different types. Therefore, each type of ship has a fairly unique shape and groups of ships also display a semi-transparent symbol specific to that type of unit, so that even at a great distance, the player can tell what kinds of ships are active.

I’ve also been finalizing the unit roles and balance of the different unit types. Each ship has a specific combat role and is strong against some compositions, but weak against others. The basic idea behind most of the units should be pretty familiar to RTS players. Fighters are generally light harassment units, like very fast infantry, Sentinel frigates are made to counter fighters, Destroyers are the main tanks, and so on. One of the more unusual units (see video above) is the Flying Saucer, which is now armed with a medium strength laser and a tractor beam that can push or pull enemy units. My goal with this ship is to emulate the “pikemen” style of units you tend to see in medieval or ancient RTS games; the flying saucer can play a support role and pull in and focus down individual units, but its greatest strength is its ability to counter high damage, close range units like bomb frigates, by simply pushing them away and preventing them from getting in range. The full list of current units (and I do plan on adding more in the future) is presented below, with basic data on each unit’s strengths.

optimized fighter groups

The first improvement in this update is the addition of geometry instancing to the main draw methods. This optimization has greatly increased performance by drawing all units of the same type together, rather than calling each one as if it were a different model. This change is most noticeable when there are a large number of fighter groups, since there can easily be hundreds of individual fighters on screen in a normal game.

optimized fighter groups

I’ve also added exhaust trails behind ships in order to better convey movement and direction of ships. (Plus it frankly makes the game look a lot more interesting.) In addition, thanks to some rewritten movement methods, fighter groups are now able to circle in place when not moving, which is also mainly a visual change.

In the backend, units will now move with more efficient collision avoidance algorithms, again reducing lag without sacrificing precise movement. I’ve also written some simple flocking behaviors, so large groups of units will move together efficiently. For the most part, unit movement is now pretty much on par with what you’d expect from a modern RTS; the player can also queue up multiple move or attack orders by holding the shift key, and even large clusters of units are able to follow any waypoint path with reasonable accuracy, intelligently altering their courses based on other nearby units.

flocking behavior

Formation Drawing:

Finally, I’ve implemented a new formation drawing system, one that is much more customizable and all around better than the old one, which had only a few preset formation shapes. With the new system, when the player has a group of units selected he can hold down the formation hotkey (which for now is the Alt key) and by right clicking and dragging, draw a line of any shape in order to create a formation move order. Drawing a simple concave formation facing an enemy position is probably the best example of how the formation drawing system enables the player to very easily perform a useful task that would normally require many actions in other RTS games, but it allows for many other tactics as well. You can even scatter or split the selected units into multiple groups for a flank attack by releasing the right mouse button during the movement and drawing another separate line. In the same manner, the player can create formations several lines of units deep or add higher concentrations of units at certain areas on the line.

Ultimately, I think this system should elevate the level of gameplay for players of all skill levels, by providing a more intuitive control scheme for complicated tasks involving unit formations, especially considering that the largely projectile-based combat system in Empyrean Frontier heavily incentivizes good positioning. The formation drawing tool doesn’t automate any of the strategic or tactical decision making, it simply enables the player to give detailed orders with significantly fewer mouse clicks.

See also:


Lately I’ve been working mostly on improving the interface. GUI design is definitely one of my least favorite parts of game development, but at least the game looks more polished now. Here’s what’s new since the last update:
shipyard under construction
Improved GUI:

Since the last update, I’ve primarily been working on updating the user interface in the game and replacing the old placeholder graphics. At this point, most of the in-game GUI has been updated to a more acceptable quality and in some cases, redesigned to improve readability on lower resolution displays. The major interface elements are all focused around my implementation of the fairly common bottom bar design. The metallic panel on the left displays the player’s resources, as well as providing commonly used formation and basic unit control toggle buttons, while the right panel houses the minimap and system data for multi-system maps. An additional popup panel on the left houses production menus when the Command Center or any shipyard is selected, and the digital panels in the center of the screen display information on currently selected units.


Research System:

Tech trees and the ability for players to research or otherwise unlock more advanced and more devastating weapons are an essential part of any RTS. The following is an early look at how these mechanics will be implemented in Empyrean Frontier.

In the current design of Empyrean Frontier, all of the research and unlocking of new technologies will be handled directly from the Command Center. Command Centers will share the same tech database, but multiple Command Centers will be able to research separate techs simultaneously, adding an additional incentive to expand to more than one base. Command Centers currently serve as the hub of each of the player’s space stations, and are also responsible for constructing new building modules, so giving them the role of researching as well seemed fitting. Additionally, this simplified design eliminates the need for separate tech buildings and lets the player see all available techs in a single screen, which should make the game easier to understand without really losing strategic depth (as well as making it easier for me to finish it.)
shipyard under construction
At this point, most of the actual techs are not implemented or even fully designed, however the goal is to include many fairly standard kinds of tech including weapon, armor, and engine upgrades, plus certain unlock-able units and abilities. Currently, the only fully implemented techs are the three upgrades to higher tech levels, which serve as bottlenecks in the tech tree, with each tech level unlocking the ability to purchase all buildings and techs available in that level.

When a player upgrades the Command Center, it undergoes a visual transformation, becoming larger and more elaborate with each tech level. These visual changes are important from a gameplay standpoint in order to allow for some way to scout the enemy’s current technological progress.
shipyard under construction
See also:


I’m back with a newly updated website/blog, and some updated models from the game. Since the last update I’ve been working on improving the visual appearance of a lot of the models in the game, as well as making some big design changes.

First and foremost, I’ve been creating new models for each of the available station modules (buildings) that the player can construct. These new station modules can now take up more than one node in the hex grid, for instance the reactor takes up only a single node, while the much larger cruiser shipyard’s layout occupies a total of 13 nodes. Each module can be rotated and placed in any position so long as it is connected to at least one existing module. By giving buildings different sizes and shapes as well as more distinct designs players should be able to more easily distinguish between different types of modules.

Many of the new models also have some kind of animation or light effect when in use. Apart from being more interesting aesthetically, these effects are meant to better convey the function of the structure. Shipyards show partially built ships being warped in, and the core of the command center shows similar effects, as its intended function is to remotely warp in other building modules.

shipyard under construction

building a cruiser

In addition, several of the old building designs have been modified or completely removed. The main design change is that there will no longer be any dedicated “tech buildings,” instead upgrades and unit unlocking will be handled directly from a research tab in the command center. (I’ll have more details on this subject and a number of other design changes I’ve been working on in future updates.)

See also: