patch 0.6.3.00 next weekend

We are in the final stages of polish and debugging for the 0.6.3.00 patch, lets do a rundown of everything that's new because this patch is getting released in a week.

But first, look at this explosion!



You can see the new targeting UI and missile trails in this one.


Simply put the world looks a lot better now. We've removed the seams when travelling between sectors, and the backdrops have been overhauled.

The new backdrops don't just take advantage of the seamless nature of sessions, they also include all new art and new code designed to explode your mind with epic vistas of volmetric 3d clouds that process both reflected and transmitted light accurately in 3d.

They look like this.



It feels like a completely different game world now.


We've got some new gameplay mechanics in the form of new interactive modules.

Engineering rooms allow you to transfer power from the systems you don't care about to the systems you need most. They add a new layer of depth to ship customization hopefully without making ships too complex for the average gamer. The interface is simple and easy to use, but also unfinished because I added a new screen and now Jan has to design yet another UI. Oops. You can use them to transfer power from life support to weapons, in fact that's the only suggested use. They will make your guns reload and fire faster, and if you don't blow up the other guy you're just going to lose all that air anyways.

We have also added a new type of missiles, siege missiles, who's launchers are much larger and who's attacks can be devastating but hard to land. They are in the engine and have fancy new graphics but we are still tweaking their functions. Expect to see large ships lobbing unguided torpedos at eachother and pummeling eachother from long range with cruise missiles in the near future.


We finally created some content which has been planned forever and is long overdue: NPC missions. In economic sectors of space you can expect to sometimes find NPC characters in bars who want things from you. Talk to them to find out what they want.

These missions, in addition to fleshing out the content in the orange sectors, are aimed at helping the overall pacing of the game. There are two types and each solves an existing problem with the game that has been subject of much discussion in the forums.

The first type is Taxi missions, namely crew which will ask to be flown somewhere. These guys sometimes offer to unlock a new technology, and they are smart enough to not offer tech you already have unlocked. That means if you are hunting for that one last blueprint and all you ever find are duplicates, maybe try some taxi missions. Oh, and make sure your ship has a spare bedroom.

The other type of mission is going to be more exciting for people who play with mods, because one of the most requested features since we released flotillas was the ability to figure out where the heck those things have spawned. Well assasination missions will do just that, because usually (but not always) the people who need to be assasinated will be chosen from spawned flotillas. This system comes with a warning however...ships spawned from the workshop are not guaranteed to be a fair fight.


We've noticed that a lot of players want to just play around in the ship editor for shorter game sessions. We don't mind. Also, since we just overhauled session logic, suddenly it becomes very easy for us to produce new types of game mode which take advantage of custom session logic. Because it was so easy, we created a new one for this patch where you fight endless waves of ships of increasing difficulty inside a single smaller size sector. It doesn't offer much for story, but it is a great way to test your ship designs against real enemies without needing to spawn them yourself.

In other words it lets you take a ship design and jump directly into the action. We also fixed mastery points so they can be used outside of singleplayer. It was a needed architectural improvement that happens to benefit the test arena.


If you recall raging about how broken the "simple" feature of EVA remains after all this time, well then I sure hope you appreciate this update. Seriously, EVA is one of the most complex things in the game and we worked on it a lot this patch so we really hope it stops being broken once and for all...please? Anyhow in testing it seems to work without issue so I'll cross my fingers and hope that this one hasn't evaded me again.

We also added some other requested features, spawned ships now remember your previous weapon selection for instance. You all can thank the guy who sent me a screen shot of a ship with like 200 turrets on it for that one. I had no idea.

There's also lots of bug fixes and optimizations. The optimization pass was needed because the game now runs multiple session simulations at once and because one person sent me a save game where so much of the universe was explored that it actually began lagging the game. In the end I hope that the game will run even smoother than before even though we have technically increased the simulation complexity.

If it doesn't I'm going to ask why you are still running WTF on integrated graphics...that was never advised. go to the settings screen to see what GPU your OS has chosen for you, you might be surprised by the results!


Good news everyone: Jan has officially grown frustrated with making art for my crummy UI code and has started directly rewriting parts of the UI. The results are fantastic. He has stolen logic from his own mod tool (which we have linked on our workshop) and gone on a UI overhaul rampage. It's great.

Check out the new targeting GUI and the new conversation dialogue GUI for prime examples. Also we have better font rendering now. Though most of us engineer types will likely never notice I have been assured that the new text kerning is top notch and that all artist types with a sense of aesthetics will notice the improvement immediately.




I might have done some work on improved workshop support for adding locations and terrain and worldgen and...well all sorts of stuff. News of that later.

We will probably upload the patch right before the weekend.

patch 0.6.3.00 next weekend

We are in the final stages of polish and debugging for the 0.6.3.00 patch, lets do a rundown of everything that's new because this patch is getting released in a week.

But first, look at this explosion!



You can see the new targeting UI and missile trails in this one.


Simply put the world looks a lot better now. We've removed the seams when travelling between sectors, and the backdrops have been overhauled.

The new backdrops don't just take advantage of the seamless nature of sessions, they also include all new art and new code designed to explode your mind with epic vistas of volmetric 3d clouds that process both reflected and transmitted light accurately in 3d.

They look like this.



It feels like a completely different game world now.


We've got some new gameplay mechanics in the form of new interactive modules.

Engineering rooms allow you to transfer power from the systems you don't care about to the systems you need most. They add a new layer of depth to ship customization hopefully without making ships too complex for the average gamer. The interface is simple and easy to use, but also unfinished because I added a new screen and now Jan has to design yet another UI. Oops. You can use them to transfer power from life support to weapons, in fact that's the only suggested use. They will make your guns reload and fire faster, and if you don't blow up the other guy you're just going to lose all that air anyways.

We have also added a new type of missiles, siege missiles, who's launchers are much larger and who's attacks can be devastating but hard to land. They are in the engine and have fancy new graphics but we are still tweaking their functions. Expect to see large ships lobbing unguided torpedos at eachother and pummeling eachother from long range with cruise missiles in the near future.


We finally created some content which has been planned forever and is long overdue: NPC missions. In economic sectors of space you can expect to sometimes find NPC characters in bars who want things from you. Talk to them to find out what they want.

These missions, in addition to fleshing out the content in the orange sectors, are aimed at helping the overall pacing of the game. There are two types and each solves an existing problem with the game that has been subject of much discussion in the forums.

The first type is Taxi missions, namely crew which will ask to be flown somewhere. These guys sometimes offer to unlock a new technology, and they are smart enough to not offer tech you already have unlocked. That means if you are hunting for that one last blueprint and all you ever find are duplicates, maybe try some taxi missions. Oh, and make sure your ship has a spare bedroom.

The other type of mission is going to be more exciting for people who play with mods, because one of the most requested features since we released flotillas was the ability to figure out where the heck those things have spawned. Well assasination missions will do just that, because usually (but not always) the people who need to be assasinated will be chosen from spawned flotillas. This system comes with a warning however...ships spawned from the workshop are not guaranteed to be a fair fight.


We've noticed that a lot of players want to just play around in the ship editor for shorter game sessions. We don't mind. Also, since we just overhauled session logic, suddenly it becomes very easy for us to produce new types of game mode which take advantage of custom session logic. Because it was so easy, we created a new one for this patch where you fight endless waves of ships of increasing difficulty inside a single smaller size sector. It doesn't offer much for story, but it is a great way to test your ship designs against real enemies without needing to spawn them yourself.

In other words it lets you take a ship design and jump directly into the action. We also fixed mastery points so they can be used outside of singleplayer. It was a needed architectural improvement that happens to benefit the test arena.


If you recall raging about how broken the "simple" feature of EVA remains after all this time, well then I sure hope you appreciate this update. Seriously, EVA is one of the most complex things in the game and we worked on it a lot this patch so we really hope it stops being broken once and for all...please? Anyhow in testing it seems to work without issue so I'll cross my fingers and hope that this one hasn't evaded me again.

We also added some other requested features, spawned ships now remember your previous weapon selection for instance. You all can thank the guy who sent me a screen shot of a ship with like 200 turrets on it for that one. I had no idea.

There's also lots of bug fixes and optimizations. The optimization pass was needed because the game now runs multiple session simulations at once and because one person sent me a save game where so much of the universe was explored that it actually began lagging the game. In the end I hope that the game will run even smoother than before even though we have technically increased the simulation complexity.

If it doesn't I'm going to ask why you are still running WTF on integrated graphics...that was never advised. go to the settings screen to see what GPU your OS has chosen for you, you might be surprised by the results!


Good news everyone: Jan has officially grown frustrated with making art for my crummy UI code and has started directly rewriting parts of the UI. The results are fantastic. He has stolen logic from his own mod tool (which we have linked on our workshop) and gone on a UI overhaul rampage. It's great.

Check out the new targeting GUI and the new conversation dialogue GUI for prime examples. Also we have better font rendering now. Though most of us engineer types will likely never notice I have been assured that the new text kerning is top notch and that all artist types with a sense of aesthetics will notice the improvement immediately.




I might have done some work on improved workshop support for adding locations and terrain and worldgen and...well all sorts of stuff. News of that later.

We will probably upload the patch right before the weekend.

I am working on making the transition between different sectors of space completely seamless. It will be a work in progress for a while, but when finished we will have a shockingly large and awesome infinite seamless world.


Before talking about the process of stitching sectors together, I should probably explain why they were ever apart to begin with.

These big infinite space games always come into the problem of storing positions in floating point numbers because when your position vector gets too big (far from the center of the map) 32 bits stops being enough data to store where you are and movement gets jerky and twitchy. In Wayward Terran Frontier positions are stored as single precision (32 bit) because that's what the graphics API likes and at the scale we want even double precision isn't enough.

In order to make the universe infinite we created sectors with integer coordinates, and then the size of each sector is bounded by the limits of single precision floating point values. As is always the case, our infinite universe isn't actually truly infinite because it is bound by the limitations of signed integers multiplied by the limitations of single precision floating point numbers(arbitrarily chosen at +-100000.0)...a staggering size no doubt. Maybe some day I'll dedicate a tiny corner of the WTF universe to store a minecraft world or two.

Fun fact: a Minecraft block is 2 pixels wide in Wayward Terran Frontier and a Minecraft world would cover a square region 600 sectors tall.

Other fun fact: our universe map generates as images on the GPU in square regions which are 512x512 pixels tall, with each pixel ultimately turning into a sector. You'd need to generate 4 regions to fit a Minecraft world.

Final fun fact: space ships go a lot faster than a human can walk

Since of course we can't fit infinite sectors in memory we store sectors to disk when you aren't looking at them. This makes it hard to render them, but of course there's no point being able to see them since every item in that sector has the wrong position until you are in that sector, so why bother right? This issue extends to all things in a sector: since there is an entire coordinate space for objects inside every sector, it's hard for things like AI to search for enemies across sectors, or bullets to hit across sectors. Those items simply don't exist in the same reference frame.


I've just rewritten the session logic, world data structures, faction logic, and many other things to make session loading smoother. Before, crossing the boundary of a session would trigger a new session object to be constructed and the old session object to be deconstructed. Of course reading and writing from the hard disk was always done asynchronously, but to an intermediary format that wasn't a full session. There was a significant lag during the transition when the intermediary format was translated into a full session. All of this was to support the fact that only 1 session object could ever exist at once.

The primary change of the new system removes the restriction of having only a single session active at any one time, and makes creating the session just another asynchronous step to be taken in preparation of the player's movements. Now sectors near the player are loaded from the disk asynchronously, and sectors immediately adjacent to the player get turned into sessions asynchronously. When the player crosses that border, they simply swap one reference and there is zero lag.


The existence of other sectors in memory has other benefits as well like allowing us to render them, or giving us the power to properly simulate things the player isn't looking at. It is still an engineering challenge because everything you do across sectors needs to work in multiple coordinate systems at once.

Initially terrain, stations, and ships will be rendered across sector boundaries so you can see the rocks you might fly into before entering a session. In the future I may even try to get bullets and AI logic to work across boundaries, but not in the first release because that's going to be a hell of a challenge on its own. Yes I will simply accept that this is likely to cause lots of bug reports: "I saw a ship but it didn't see me!" and that sort of thing.

We can also now run full simulations of things when needed. I have all sorts of evil plans for that feature in the future. For example if I were to make wild speculative gestures (which should in no way be taken as an indication of planned content or future development goals) I'd say I could do something like having battle wreckage created the easy way (simulating actual battles), or allow AI to have more complex off-screen behaviors like mining or construction.

Note that the extent to which I will be able to render and update sectors other than the player's is going to weigh very heavily on machine performance. I may even need to set up some simulation complexity slider that lets you tune down the draw distance on a slow computer. Having more CPU cores and memory will actually make a pretty big difference for off-screen simulations since my framework allows literally all of it to be offloaded to another thread (or threads). Initially I suspect the default settings will try to be relatively tame, using as little extra resources as it can, but I chose PC as my platform because I wanted to abuse the best hardware available, and abuse it we shall.


Aside from this and power management systems we have a few other projects in the works.

• Jan is experimenting with some crazy unreasonably awesome looking secret backdrop eye candy project. (our hope is that in combination with seamless boarders the visuals should make your brain explode)
  
• I have made some upgrades to how the game handles missiles to support different sizes of missile, different types of ordinance, rendering missile magazines and launchers in a way that displays the ordinance type, etc.
  
• I have added some new missile types and missile related module types to the game engine.
  
• I have started initial work on a new top secret project relating to interesting things you might find when exploring taverns.
  
• I have drawn onto a napkin some designs which may allow future workshop mods to add stations into the single player game world similar to how flotillas work, but also with the power to place them manually into the world to be created as part of world generation.

I am working on making the transition between different sectors of space completely seamless. It will be a work in progress for a while, but when finished we will have a shockingly large and awesome infinite seamless world.


Before talking about the process of stitching sectors together, I should probably explain why they were ever apart to begin with.

These big infinite space games always come into the problem of storing positions in floating point numbers because when your position vector gets too big (far from the center of the map) 32 bits stops being enough data to store where you are and movement gets jerky and twitchy. In Wayward Terran Frontier positions are stored as single precision (32 bit) because that's what the graphics API likes and at the scale we want even double precision isn't enough.

In order to make the universe infinite we created sectors with integer coordinates, and then the size of each sector is bounded by the limits of single precision floating point values. As is always the case, our infinite universe isn't actually truly infinite because it is bound by the limitations of signed integers multiplied by the limitations of single precision floating point numbers(arbitrarily chosen at +-100000.0)...a staggering size no doubt. Maybe some day I'll dedicate a tiny corner of the WTF universe to store a minecraft world or two.

Fun fact: a Minecraft block is 2 pixels wide in Wayward Terran Frontier and a Minecraft world would cover a square region 600 sectors tall.

Other fun fact: our universe map generates as images on the GPU in square regions which are 512x512 pixels tall, with each pixel ultimately turning into a sector. You'd need to generate 4 regions to fit a Minecraft world.

Final fun fact: space ships go a lot faster than a human can walk

Since of course we can't fit infinite sectors in memory we store sectors to disk when you aren't looking at them. This makes it hard to render them, but of course there's no point being able to see them since every item in that sector has the wrong position until you are in that sector, so why bother right? This issue extends to all things in a sector: since there is an entire coordinate space for objects inside every sector, it's hard for things like AI to search for enemies across sectors, or bullets to hit across sectors. Those items simply don't exist in the same reference frame.


I've just rewritten the session logic, world data structures, faction logic, and many other things to make session loading smoother. Before, crossing the boundary of a session would trigger a new session object to be constructed and the old session object to be deconstructed. Of course reading and writing from the hard disk was always done asynchronously, but to an intermediary format that wasn't a full session. There was a significant lag during the transition when the intermediary format was translated into a full session. All of this was to support the fact that only 1 session object could ever exist at once.

The primary change of the new system removes the restriction of having only a single session active at any one time, and makes creating the session just another asynchronous step to be taken in preparation of the player's movements. Now sectors near the player are loaded from the disk asynchronously, and sectors immediately adjacent to the player get turned into sessions asynchronously. When the player crosses that border, they simply swap one reference and there is zero lag.


The existence of other sectors in memory has other benefits as well like allowing us to render them, or giving us the power to properly simulate things the player isn't looking at. It is still an engineering challenge because everything you do across sectors needs to work in multiple coordinate systems at once.

Initially terrain, stations, and ships will be rendered across sector boundaries so you can see the rocks you might fly into before entering a session. In the future I may even try to get bullets and AI logic to work across boundaries, but not in the first release because that's going to be a hell of a challenge on its own. Yes I will simply accept that this is likely to cause lots of bug reports: "I saw a ship but it didn't see me!" and that sort of thing.

We can also now run full simulations of things when needed. I have all sorts of evil plans for that feature in the future. For example if I were to make wild speculative gestures (which should in no way be taken as an indication of planned content or future development goals) I'd say I could do something like having battle wreckage created the easy way (simulating actual battles), or allow AI to have more complex off-screen behaviors like mining or construction.

Note that the extent to which I will be able to render and update sectors other than the player's is going to weigh very heavily on machine performance. I may even need to set up some simulation complexity slider that lets you tune down the draw distance on a slow computer. Having more CPU cores and memory will actually make a pretty big difference for off-screen simulations since my framework allows literally all of it to be offloaded to another thread (or threads). Initially I suspect the default settings will try to be relatively tame, using as little extra resources as it can, but I chose PC as my platform because I wanted to abuse the best hardware available, and abuse it we shall.


Aside from this and power management systems we have a few other projects in the works.

• Jan is experimenting with some crazy unreasonably awesome looking secret backdrop eye candy project. (our hope is that in combination with seamless boarders the visuals should make your brain explode)
  
• I have made some upgrades to how the game handles missiles to support different sizes of missile, different types of ordinance, rendering missile magazines and launchers in a way that displays the ordinance type, etc.
  
• I have added some new missile types and missile related module types to the game engine.
  
• I have started initial work on a new top secret project relating to interesting things you might find when exploring taverns.
  
• I have drawn onto a napkin some designs which may allow future workshop mods to add stations into the single player game world similar to how flotillas work, but also with the power to place them manually into the world to be created as part of world generation.

Part of the fantasy of owning a big space ship, having a crew, and going on space adventures, is periodically yelling to your engineering team "More power to engines!" or "divert power from life support to shields!" because yelling these things is most of what the captain does during space battles on tv.

Whatever you're using it for, power redistribution has been a staple of space flight simulators since the original X-Wing games. It adds a layer of tactical strategy to space combat beyond turning and shooting. Since you play the role of captain in Zero Falls, the game would feel incomplete without some way to reroute power during combat, wouldn't it?


Of course we've already got a few layers of depth beyond turning and shooting so simply adding a triangle toggle for power distribution isn't such a simple prospect in Zero Falls. In fact, it introduces a problem of complexity. When captain Kirk yells at Scotty for more speed, the audience is right there with the Captain and all of the pipes and science and engineering behind actually generating the speed isn't their concern. However in Zero Falls we actually simulate all that science, so you might be worried that you will find yourself in the position of scotty yelling back "I cannae break the laws of physics cap'n!" because you will be forced to deal with the reality of how ships work in order to make them go.

Clearly power distribution systems in Zero Falls need to be a compromise between deep engineering, and ease of use. It wasn't an easy compromise to make.

Many candidate ideas got thrown out for one reason or another. I considered power conduits that could be toggled on and off, modules which beamed energy wirelessly, giving the player color coded conduits to design power groups with, modules which used energy to increase the transfer rate of conduits, and all manner of interactive screens which might configure them during flight. None of the ideas was perfect, and all of the above got rejected because they didn't reach all of my design goals, however I am pretty happy with the one I've settled on.


My design goals for power distribution were as follows:

1. Good power management use should improve the performance of even an optimally designed ship
   
2. it should be optional, yet desired to have power management abilities.
   
3. it should make use of the engineering room, since we have assets for one and honestly...gotta have an engineering room
   
4. it should improve the depth of interaction with your ship so you feel like you are learning your ships quirks and anticipating its weaknesses and getting better at flying it
   
5. bonus points for how the system might interact with various other top secret future projects
   
6. it should do all of the above without being terrifyingly complex and scaring off new players

My solution was the concept of routes. What's a route you say?

"Transfer power from life support to the aft weapons array" <- that's a route.

How do you use a route?

Simple, every ship has 1 route active at any given time. Route 0 is normal power functionality. If you have additional routes available you will see toggle buttons which you can click or activate with a hotkey to change your active route. You will know what each one does, because you will create it before you can activate it.

How do you create a route?

Walk into your engineering room. You will bring up a new screen which is a diagram of your ship. Clicking modules rotates them in and out of 3 different categories:

• Power destination
  
• Power source
  
• Disabled

The functionality of which hopefully is intuitive to most players. A power destination will receive more power than normal, and may have increased output. A power source offers its power to be stolen by destinations. Finally, a disabled module doesn't take any power and thus saves your energy for more important things.

What's the catch?

You can only save one configuration per route and to get more routes you need either more engineering rooms or better engineering rooms. A very simple ship setup might only offer a single route, forcing the captain to choose ahead of time where emergency power can be routed during combat. Does your ship benefit from a burst of speed? or do you anticipate needing extra shields? Maybe you have a missile ship and you just want the option to toggle missile factories on and off. Each of these ideas would constitute a "route" and each would be represented by a single toggle on your navigation screen.

the goal of course is to make engineering rooms matter, and to make them serve a purpose. We're not trying to make the player pay attention to more stuff all the time. As such, the game will remember the routes you create for each ship design, so every time you use the same ship it will have the same routes.


This sort of technical junk is extremely valuable to certain subset of our users so I like to add it to my blog posts. Here's what I've done on the technical side of things:

Every power update has been divided into 2 phases. Previously, a single power update phase allowed all of the power using modules to take power across the power grid from modules that provide power such as reactors and capacitors. Within the confines of a single update, conduit use was recorded so that overall power transmission would be limited by the maximum transfer rate of each individual conduit. Once some module had put 6 energy through a conduit segment, that conduit was capped out for the rest of the update cycle and no other modules could draw power through it.

With routes, we perform a second power update in addition to the first one. After all modules have taken the power they want, modules designated as power destinations are given a 2nd chance to take power from the grid using the same conduits, but with added conduit capacity which depends on the quality of the engineering room assigned the route. The catch is that they aren't allowed to take from reactors in this 2nd phase, because the reactors have already done their duty so to speak. Instead, a new list of power sources is provided in the form of the source modules designated by the route.

Since the engineering room effectively doubles the number of power update cycles (to a degree depending on the extra flow capacity) it can be very effective at increasing the output of energy craving modules. It also has an added effect of triggering an overpower mode on some modules which allow them to use energy faster for higher output. That effect will vary on a module by module basis, but a good example is engines which will try to operate above 100% output providing more thrust for more energy in exactly the opposite way as they do when providing less thrust in response to having less energy.

Routes also follow slightly different rules because you manually assign power sources. Namely, you can take power from any power using module. This allows you to do creative things like direct energy to move directly from one module to another to power one of them even when the entire tree is disconnected from the main grid, or so that you can daisy chain modules to a certain degree.

My hope is that the system will be both simple and powerful, with lots of emergent utility that even I have not thought of yet. I'm currently working on getting all the modules upgraded to handle the extra power gracefully but I'm sure I'll miss some and they will be added in the future.


I'm working remotely from a boat right now and won't be publishing anything until I'm back. Also this new patch will contain core engine content that's going to need lots of testing. Expect a patch in around a month maybe.

Power distribution isn't the only thing I'm working on. I also got the logistics screen to remember your turret assignments and am starting a new project as well.

Part of the fantasy of owning a big space ship, having a crew, and going on space adventures, is periodically yelling to your engineering team "More power to engines!" or "divert power from life support to shields!" because yelling these things is most of what the captain does during space battles on tv.

Whatever you're using it for, power redistribution has been a staple of space flight simulators since the original X-Wing games. It adds a layer of tactical strategy to space combat beyond turning and shooting. Since you play the role of captain in Zero Falls, the game would feel incomplete without some way to reroute power during combat, wouldn't it?


Of course we've already got a few layers of depth beyond turning and shooting so simply adding a triangle toggle for power distribution isn't such a simple prospect in Zero Falls. In fact, it introduces a problem of complexity. When captain Kirk yells at Scotty for more speed, the audience is right there with the Captain and all of the pipes and science and engineering behind actually generating the speed isn't their concern. However in Zero Falls we actually simulate all that science, so you might be worried that you will find yourself in the position of scotty yelling back "I cannae break the laws of physics cap'n!" because you will be forced to deal with the reality of how ships work in order to make them go.

Clearly power distribution systems in Zero Falls need to be a compromise between deep engineering, and ease of use. It wasn't an easy compromise to make.

Many candidate ideas got thrown out for one reason or another. I considered power conduits that could be toggled on and off, modules which beamed energy wirelessly, giving the player color coded conduits to design power groups with, modules which used energy to increase the transfer rate of conduits, and all manner of interactive screens which might configure them during flight. None of the ideas was perfect, and all of the above got rejected because they didn't reach all of my design goals, however I am pretty happy with the one I've settled on.


My design goals for power distribution were as follows:

1. Good power management use should improve the performance of even an optimally designed ship
   
2. it should be optional, yet desired to have power management abilities.
   
3. it should make use of the engineering room, since we have assets for one and honestly...gotta have an engineering room
   
4. it should improve the depth of interaction with your ship so you feel like you are learning your ships quirks and anticipating its weaknesses and getting better at flying it
   
5. bonus points for how the system might interact with various other top secret future projects
   
6. it should do all of the above without being terrifyingly complex and scaring off new players

My solution was the concept of routes. What's a route you say?

"Transfer power from life support to the aft weapons array" <- that's a route.

How do you use a route?

Simple, every ship has 1 route active at any given time. Route 0 is normal power functionality. If you have additional routes available you will see toggle buttons which you can click or activate with a hotkey to change your active route. You will know what each one does, because you will create it before you can activate it.

How do you create a route?

Walk into your engineering room. You will bring up a new screen which is a diagram of your ship. Clicking modules rotates them in and out of 3 different categories:

• Power destination
  
• Power source
  
• Disabled

The functionality of which hopefully is intuitive to most players. A power destination will receive more power than normal, and may have increased output. A power source offers its power to be stolen by destinations. Finally, a disabled module doesn't take any power and thus saves your energy for more important things.

What's the catch?

You can only save one configuration per route and to get more routes you need either more engineering rooms or better engineering rooms. A very simple ship setup might only offer a single route, forcing the captain to choose ahead of time where emergency power can be routed during combat. Does your ship benefit from a burst of speed? or do you anticipate needing extra shields? Maybe you have a missile ship and you just want the option to toggle missile factories on and off. Each of these ideas would constitute a "route" and each would be represented by a single toggle on your navigation screen.

the goal of course is to make engineering rooms matter, and to make them serve a purpose. We're not trying to make the player pay attention to more stuff all the time. As such, the game will remember the routes you create for each ship design, so every time you use the same ship it will have the same routes.


This sort of technical junk is extremely valuable to certain subset of our users so I like to add it to my blog posts. Here's what I've done on the technical side of things:

Every power update has been divided into 2 phases. Previously, a single power update phase allowed all of the power using modules to take power across the power grid from modules that provide power such as reactors and capacitors. Within the confines of a single update, conduit use was recorded so that overall power transmission would be limited by the maximum transfer rate of each individual conduit. Once some module had put 6 energy through a conduit segment, that conduit was capped out for the rest of the update cycle and no other modules could draw power through it.

With routes, we perform a second power update in addition to the first one. After all modules have taken the power they want, modules designated as power destinations are given a 2nd chance to take power from the grid using the same conduits, but with added conduit capacity which depends on the quality of the engineering room assigned the route. The catch is that they aren't allowed to take from reactors in this 2nd phase, because the reactors have already done their duty so to speak. Instead, a new list of power sources is provided in the form of the source modules designated by the route.

Since the engineering room effectively doubles the number of power update cycles (to a degree depending on the extra flow capacity) it can be very effective at increasing the output of energy craving modules. It also has an added effect of triggering an overpower mode on some modules which allow them to use energy faster for higher output. That effect will vary on a module by module basis, but a good example is engines which will try to operate above 100% output providing more thrust for more energy in exactly the opposite way as they do when providing less thrust in response to having less energy.

Routes also follow slightly different rules because you manually assign power sources. Namely, you can take power from any power using module. This allows you to do creative things like direct energy to move directly from one module to another to power one of them even when the entire tree is disconnected from the main grid, or so that you can daisy chain modules to a certain degree.

My hope is that the system will be both simple and powerful, with lots of emergent utility that even I have not thought of yet. I'm currently working on getting all the modules upgraded to handle the extra power gracefully but I'm sure I'll miss some and they will be added in the future.


I'm working remotely from a boat right now and won't be publishing anything until I'm back. Also this new patch will contain core engine content that's going to need lots of testing. Expect a patch in around a month maybe.

Power distribution isn't the only thing I'm working on. I also got the logistics screen to remember your turret assignments and am starting a new project as well.

We are opening the steam workshop to the public today.

This patch includes 1 significant bug fix, however it is primarily a release of the new features necessary for interaction with the steam workshop. You will notice that we have added a mod upload option to your main menu.

If you have no interest in creating or uploading custom content, you should ignore the new button and instead check out the newly opened...

Wayward Terran Frontier Workshop

You can use the steam workshop to import custom ship hulls made by other users into your single player game world for added variety and customization. You will still need to find these ships, and they might be rare, but you can subscribe to as many as you like for potentially unlimited ship diversity.

Also I created a comprehensive guide on how to use the workshop features, and how to make custom ship hulls here:

Guide - Creating and sharing custom ships

...And if that wasn't enough, Jan has been working tirelessly to create a image editing tool that honestly should not be given away for free because it is so freggin good. The tool is specially designed to help make really great looking custom ships for our rendering engine, and preview them without having them in game. You can find the tool inside my steam guide, or just download it here:

Jan's mod tool

This represents the first time we, as developers, might find a really cool space ship in our game that we didn't expect to see, so that's pretty exciting for us.

Enjoy!

We are opening the steam workshop to the public today.

This patch includes 1 significant bug fix, however it is primarily a release of the new features necessary for interaction with the steam workshop. You will notice that we have added a mod upload option to your main menu.

If you have no interest in creating or uploading custom content, you should ignore the new button and instead check out the newly opened...

Wayward Terran Frontier Workshop

You can use the steam workshop to import custom ship hulls made by other users into your single player game world for added variety and customization. You will still need to find these ships, and they might be rare, but you can subscribe to as many as you like for potentially unlimited ship diversity.

Also I created a comprehensive guide on how to use the workshop features, and how to make custom ship hulls here:

Guide - Creating and sharing custom ships

...And if that wasn't enough, Jan has been working tirelessly to create a image editing tool that honestly should not be given away for free because it is so freggin good. The tool is specially designed to help make really great looking custom ships for our rendering engine, and preview them without having them in game. You can find the tool inside my steam guide, or just download it here:

Jan's mod tool

This represents the first time we, as developers, might find a really cool space ship in our game that we didn't expect to see, so that's pretty exciting for us.

Enjoy!

This is a provisional going-live event. I'm currently very heavily distracted by the health of a family member, however 0.6.1.00 has been ready for testing and I want people to try it out so it is going live. If there are troubles I may revert, however I suspect this will simply work.

Chanes are as follows:


This is bonus contents i guess, we upgraded to monogame 3.6 by accident when I ran the installer not realizing it would replace my binaries.

Monogame 3.6 brings more efficient sprite drawing and some low level fixes to sound stuff as well as various small framework things here and there. In theory this should simply make everything a little faster and smoother...in practice it means you can't resize the screen by window dragging anymore.

Mono 3.6 integration is also helpful for the other 6.1 additions.


The big addition you will notice is the new debugging tools. To activate them get into the test arena and press Delete when piloting your ship. You can spawn any of your profiles via drag+drop controls and use the faction settings tool to make any battle scenario you like.

This video shows off the new tool


Flotillas are fully 100% supported in this update. They allow a custom ship to be assigned a faction and added into the general population of a single player game world. Having flotilla files working is the first step to getting mod support working.


We integrated the steam API and this version is technically compatible with the steam workshop. Currently there is a small group of testers who are using the provisional version of the workshop to test integration. If you would really like to try out the new features talk to Red in the community forums about joining the tester group.

The workshop lets you simply subscribe to flotillas à la carte to customize your single player world with custom ships.

• fixed a station texture that was the wrong size
  
• profiles will no longer crash if there is no .tac file or if the .tac file is corrupt or invalid
  
• reduced TOBI output to be in line with the new movement system
  
• conduit glow now decays over 1 second causing less seizure inducing visuals and it does so in a way that is actually a slight optimization to all conduits
  
• added a screen that allows uploading to the workshop. It is still in testing and disabled by default, but it is in there.
  
• design debugging is now enabled for those in the steam tester group for use in testing flotillas
  
• fixed a crash when a ship without an emission layer breaks into shards
  
• profiles that fail to load now explain why they failed to load via the loading screen progress log
  
• fixed a crash caused by ships without turrets
  
• there is now a maximum target lock duration that will be used even if your ship has no sensors so small fighters can use missiles again
  
• added the ability to toggle floating combat text in the options menu

This is a provisional going-live event. I'm currently very heavily distracted by the health of a family member, however 0.6.1.00 has been ready for testing and I want people to try it out so it is going live. If there are troubles I may revert, however I suspect this will simply work.

Chanes are as follows:


This is bonus contents i guess, we upgraded to monogame 3.6 by accident when I ran the installer not realizing it would replace my binaries.

Monogame 3.6 brings more efficient sprite drawing and some low level fixes to sound stuff as well as various small framework things here and there. In theory this should simply make everything a little faster and smoother...in practice it means you can't resize the screen by window dragging anymore.

Mono 3.6 integration is also helpful for the other 6.1 additions.


The big addition you will notice is the new debugging tools. To activate them get into the test arena and press Delete when piloting your ship. You can spawn any of your profiles via drag+drop controls and use the faction settings tool to make any battle scenario you like.

This video shows off the new tool


Flotillas are fully 100% supported in this update. They allow a custom ship to be assigned a faction and added into the general population of a single player game world. Having flotilla files working is the first step to getting mod support working.


We integrated the steam API and this version is technically compatible with the steam workshop. Currently there is a small group of testers who are using the provisional version of the workshop to test integration. If you would really like to try out the new features talk to Red in the community forums about joining the tester group.

The workshop lets you simply subscribe to flotillas à la carte to customize your single player world with custom ships.

• fixed a station texture that was the wrong size
  
• profiles will no longer crash if there is no .tac file or if the .tac file is corrupt or invalid
  
• reduced TOBI output to be in line with the new movement system
  
• conduit glow now decays over 1 second causing less seizure inducing visuals and it does so in a way that is actually a slight optimization to all conduits
  
• added a screen that allows uploading to the workshop. It is still in testing and disabled by default, but it is in there.
  
• design debugging is now enabled for those in the steam tester group for use in testing flotillas
  
• fixed a crash when a ship without an emission layer breaks into shards
  
• profiles that fail to load now explain why they failed to load via the loading screen progress log
  
• fixed a crash caused by ships without turrets
  
• there is now a maximum target lock duration that will be used even if your ship has no sensors so small fighters can use missiles again
  
• added the ability to toggle floating combat text in the options menu