Space exploration adventure RPG where you command a crew in a story driven sandbox universe. Work to destroy the sensor network and reach the heavily guarded planet before Shavala corporation goons hunt you down, or just go exploring.
User reviews:
Overall:
Mostly Positive (103 reviews) - 75% of the 103 user reviews for this game are positive.
Release Date: Feb 11, 2016

Sign in to add this item to your wishlist, follow it, or mark it as not interested

Early Access Game

Get instant access and start playing; get involved with this game as it develops.

Note: This Early Access game is not complete and may or may not change further. If you are not excited to play this game in its current state, then you should wait to see if the game progresses further in development. Learn more

What the developers have to say:

Why Early Access?

“We're a 3 person dev team with no publisher working on this project full time. Without the support of our community through Kickstarter and early access this game wouldn't exist at all. That essentially means people are paying us for an unfinished game because they like us and they believe we will make the game they want to play. We also want to play that game so we're doing everything we can to prove them right.”

Approximately how long will this game be in Early Access?

“The planned final version of this game is pretty ambitious and we expect to go through many iterations before completing the single player story and having the game world in a state we consider to be complete. We also want to be able to evolve the game over time in response to feedback so we are expecting early access will last more than a year.”

How is the full version planned to differ from the Early Access version?

“Expect massive changes on a regular basis as we add features and new types of depth to the engine and the game world.

Our initial early access release represents multiple years of work put into getting the bare minimum framework of the engine and persistent world working as intended. During early access we plan to have many iterations where game-wide features are added, and then content using those features can be integrated into the game world. That means major updates will contain game-changing features and new content such as new zones, new factions, new story arcs, new world generations, new item types, new interface elements, and new game mechanics.

An example of something we plan to add in the future is the ability for EVA activities which will allow entering and exiting ships without using an airlock. It should drastically change how salvaging activities play out and will probably change how you interact with the entire game world.”

What is the current state of the Early Access version?

“The game has an open persistent world with various space biomes for the player to explore. Each biome will have a different set of enemies and challenges in the form of enemy encounters, space-complexes to explore, and hidden treasures to unlock. The story driven elements are incomplete and more will be added with every patch, but for now the game is mostly a sandbox with some introductory story and setting lore.”

Will the game be priced differently during and after Early Access?

“The game might be slightly cheaper during early access. However if you want the best value for your money you are probably already avoiding early access games and we respect that.

We're here because we need income to continue development and if money were no object we would probably hide in our developer caves until the game was finished. The core benefit of buying into early access is participating in the development process and being part of the community that shapes the Zero Falls story and universe. This is not a "get the game for less money because it sucks" sort of deal, it is a "I think these guys deserve to feed themselves while developing their game" sort of deal, and we appreciate your support.”

How are you planning on involving the Community in your development process?

“We have open discussion on our forums and we respond very quickly to feedback and bug reports. I once found, fixed, and uploaded a patch for a bug before the end of a live streaming event where the bug was revealed. We have backers who are designing ships to be put into the single player campaign, and we have been discussing modding tools with the community from day 1. We also sometimes host community ship design tournaments in order to stir up conversations and feedback about balance and game mechanics.

The truth is we're making a big open sandbox game with enough space for a lot of unique game play ideas and elements, and we want to put in every type of kitchen sink. Our time is probably split evenly between 3 tasks:

1. core engine development
2. core story and content implementation
3. tweaks, edits, and additions in response to feedback”
Read more

Buy Wayward Terran Frontier: Zero Falls

 

Recent updates View all (43)

July 12

Upcoming feature: Seamless world

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.

Why sector boundaries

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.

Until now

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.

Other benefits

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.

Other things we're working on

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.
24 comments Read more

July 4

Upcoming feature: Power management

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?

Rejected candidates

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.

Power distribution in Zero Falls

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.

Under the hood

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.

When's it coming

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.
10 comments Read more
See all discussions

Report bugs and leave feedback for this game on the discussion boards

About This Game

Our goal was to make a game simulating space combat between large capital ships at extreme detail on the scale of individual crew members. We've spent multiple years building a custom in-house engine capable highly detailed ship interior simulations while still supporting real time combat between large numbers of ships in an open persistent world.

The result is a massive open world where any ship, station, asteroid, artifact, or wreckage can be entered by the player and controlled in real-time. Space battles are epic and immersive because there are no hit points, instead you have to try and survive as pieces of your ship are physically destroyed and ships can be cut in half or filled full of holes. Play as a renegade shooting up neutral supply convoys and scooping the cargo that falls out, or disable and board enemy ships to take back to your hideout. Research technology and upgrade designs to make your favorite ship into the ultimate war machine. The universe is full of loot and enemies and things to explore, and your character will have all the tools needed to design the ultimate ship and put together the ultimate crew.

We also look at progression from the perspective of RPG mechanics. Even though the game is a deep and detailed simulation, we want gameplay to have progression, customization, and specialization much like a character based roleplaying game. Instead of unlocking talent points you will find crew members that add unique utility to your ship as a whole, or you might find module blueprints that allow you to customize portions of your ship's design to suit your play style.

System Requirements

    Minimum:
    • OS: Windows Vista or later 64 bit os
    • Processor: Intel Core 2 Duo 2.60GHz
    • Memory: 3 GB RAM
    • Graphics: NVIDIA GeForce GTX 470 / AMD Radeon HD 7850
    • DirectX: Version 10
    • Storage: 700 MB available space
    • Sound Card: DirectX compatible on-board
    • Additional Notes: makes extensive use of multi-threading and 64 bit features
    Recommended:
    • OS: Microsoft Windows 7 x64
    • Processor: AMD Phenom II x6 or Intel i7
    • Memory: 4 GB RAM
    • Graphics: NVIDIA GeForce GTX 470 / AMD Radeon HD 7850
    • DirectX: Version 10
    • Storage: 1 GB available space
    • Sound Card: DirectX compatible on-board
    • Additional Notes: makes extensive use of multi-threading and 64 bit features

What Curators Say

1 Curator has reviewed this product. Click here to see them.
Customer reviews Learn More
Overall:
Mostly Positive (103 reviews)
Review Type


Purchase Type


Language


Display As:


(what is this?)
75 reviews match the filters above ( Mostly Positive)
There are no more reviews that match the filters set above
Adjust the filters above to see other reviews
Loading reviews...