Beam controllers now interact through a system call beam alchemy where having multiple controllers assigned to a single console will allow each controller to contribute attributes to a single beam type that will be emitted by the console
Added some new beam controller types
Added many new beam animation effects and types
Added a new interface to the ship designer for previewing the results of beam alchemy
Gave beam activation its own keybind and removed the system of toggling between fire modes
Beams now have a charge up period before they activate
AI is much better at using beam weapons now
Missiles and Drones:
added many missile warhead converter types
upgraded missiles to allow missiles without trails
fixed a bug where missiles could try to render trails when outside of the session causing a crash
drone bays now come into existence with their drones fully constructed
point defense AI now reacts to any nearby missile or drone instead of only standard missiles targeting their ship directly
ai has been taught how to use attack drone bays
fixed a bug where missiles were directly adding animations to the session which caused a crash if a missile was created by an animation during an animation update pass
Changed the default keybind for firing missiles to a mouse key.
added new animations and attack logic for bomber drones
added new animations and attack logic for projectile drones
The missile factory can now be unlocked
Siege missiles and the related tech can now be unlocked
bomber drones can now be unlocked
World and save format:
added texture compression to ship voxel data in the binary save format which means smoother sector transitions, faster loading and saving, and smaller save files
updated save file format with error correcting code to protect against poorly written quest logic because some idiot keeps writing it. In the past, broken quests could corrupt the entire save, now they can't even corrupt other quests
added a crash log and some fail safes for when the game crashes to hopefully help us find evidence of the few remaining causes of crashing
the game will now attempt to save progress when it encounters a crash before creating an error report. it will also try to exit to the menu instead of crashing entirely
upgraded the save format for crystal branches to allow future modifications to not bother save file disruption
added a synchronization point to guarantee that no threading stuff can interfere with a save game action
purged all old code relating to the farming screen as crystal farming has been integrated into the ship interior for a while now
Wrote a massive new framework to store player characters in a database instead of as part of the binary world data file. This changes all aspects of gameplay because it changes how save files work. More specifically, the game no longer has save files at all, it has worlds and characters. The characters are persistent and can move between worlds, and worlds now only advance forwards in time.
You can no longer save progress at a specific point in time and return to it later, as that makes no sense when characters are not part of the save data for the world
You can no longer load from a point in the past
You now have the power to choose if you will start a new game with a fresh character or with your existing character, retaining all progress and unlocks
characters are now no longer part of a save game, and can be moved between save games
characters no longer need to be saved, their data is effectively on disk as soon as it changes
all "progress" categories are now part of the character such as research, unlocks, credits, station capacity, and inventory
Quests now save progress when they change.
Biomes are a new addition to the level format and the binary data saved by the world. The concept of biomes was added in this patch and the first type of biome will now spawn in your world: the blue biome. The blue biome is the source of the monsters you find inside stations, however now there are added effects
Added biome spores which sometimes are spawned by asteroids infested by a biome. Blue spores will seek nearby ships and attempt to add a monster spawner inside them.
Research:
Removed the old research screen
Added tier info and category meta-data to most existing blueprints
Created an entirely new research screen
Added a system of research unlocks that happen after a certain amount of research is completed in each tier to grant the more boring blueprints such as hallways and doors
Overhauled the research progress binary data in a way that would have invalidated saves if we had not already nuked them
Added the concept of core nodes, which can be used from the design screen to unlock a module that you do not currently have the blueprint for. They are a very rare end-game currency item.
Reduced the research cost of the civilian vulture significantly
Slightly reduced the research cost of the pirate vulture
Story and quests:
Built a fancy new quest framework which will be used internally for us to design quests more easily in the future and maybe even allow for data-driven quests in the future. All quests and story content in this patch were built in the new framework.
Created an entirely new introduction sequence which is to enhance the existing tutorial for a much better early game learning experience. It gets the player into action earlier in the game and requires less reading.
Completely rewrote the quest to kill budd under the new quest framework
The quest to kill Budd now has a more informative tool tip, and a big green arrow which follows Budd around after he spawns
Added the next quest in the story arc after killing Budd which leads to the grey zone
Fixed a bugged dialogue step in the first trade quest
The first station exploration quest dialogue now starts sooner
Fixed a bug with a quest dialogue that didn't unpause the game properly
Fixed a bug with an early quest dialogue that prevented it from happening entirely
Fixed a dialogue which could be triggered by marv even if marv wasn't on the ship
Slightly improved some quest text from the first act
Adjusted the number of pirates involved in the SSC shipyard mission
Fixed a mismatched dialogue choice in the first conversion with the Anna agent
Fixed an issue with the idle conversation with the kyle agent where a dialogue step was skipped
Made a system that allows quest logic to properly track ships across the world map
The quest to kill budd now properly tracks the location of budd
Fixed an issue where the first combat introduction quest would not trigger if a mount on your ship existed which had no turret attached
The mostly non-functional quest which rewards the player for researching a certain number of research items has been removed. It's functionality has been replaced by the new research system
fixed a bug with the first trade quest where it could interfere with another quest's dialogue
fixed a bug with the first trade quest where the second dialogue could open in the wrong trade screen
fixed a bug with one of anna's introductory conversation arcs
fixed a bug with the surprise combat quest that allowed it to trigger from inside the home station
updated one of anna's conversations to now be guaranteed to give you a quest that you really should have picked up either way
the quest to explore a station looking for a cloning vat is now restricted so that it can only trigger within a radius of systems around the home base
fixed a bug that could prevent the first mastery point dialogue in some cases
lowered the entry requirement of pirate's cove in terms of crystals to be below the number you will typically get when exploring the initial dungeon event
fixed a bug where the initial trade tutorial quest could forget where to place the waypoint
changed some quest text to say "bureaucracy" instead of "beurocracy" without learning the proper way to spell bureaucracy
fixed a quest text in the tutorial which told you to go to the wrong airlock
fixed a quest text in the tutorial which told you the wrong keybinding
the step during the intro tutorial which requires scrapping a ship will now progress if you scrap any ship, or if you leave the station
added a number of new quests and prefab zones to the grey area of the map including new station prefabs, new NPC ships, and new battle encounters as well as the rewards for defeating these new enemies
Crew items:
Rebalanced all existing crew weaponry. If you have a flotilla which contains crew weaponry, it will still work but you should expect the stats of those existing items to be very different because our system will regenerate any existing guns to have new stats in order to fit under the new system
Added tier 2 crew weapons with new animations and new icon artwork
Added tier 2 crew armor with new icon artwork
did a pass over all existing item drop loot tables to rebalance how crew items drop
Damage values and damage stat progression has been significantly improved for all crew item types
Monster health values have changed, monsters now take slightly longer to kill on average
changed nano aura tooltips to better explain how they work, replaced "armor" with "exterior" to indicate that it is the top layer of ships that will be repaired, not armor tiles (which are technically systems)
buffed nano aura output a lot
Design screen:
Complete rewrite of most design screen functions and rendering
Design screen now supports zoom
Conduit pathing drastically improved, you can now draw conduits end to end in addition to tile by tile
Added a ton of stats to the design screen so you can asses your ship design numerically
New animated overlays for power networks so you can see what is connected to what
Animations for turret arcs make turret track placement much more intuitive
A color picker lets you pick your module brush by clicking on it
A list of recent module brushes
Multi-selection with copy paste
Optimized layout gives you more screen space to work with
Faster rendering and optimized deletion and placement of modules
A gui element to indicate how consoles are wired and which modules are wired to which console
The ability to switch between schematic and realistic rendering modes
A query tool allows you to get information about modules by clicking on them in the design screen
Quality of life improvements:
civilian ships no longer have a chance to fail being captured
made docking tolerances slightly less strict
SSC ships no longer have a chance to fail being captured
you can now right click exotic matter to instantly gain the credits value
added a safety control protocol which will prevent your ship from leaving higgs drive while inside terrain
added more enterances to pirate's cove and updated the entry quest trigger to match
re-added mouse world position debugging text to the world map screen
all reactors now experience a tiny amount of passive heat dissopation so they can never be stuck producing zero power forever
terrain now has an icon when zoomed out
viewing of terrain in other sectors becomes more seamless as terrain icons now render independent of sector
the icon for random abandoned stations now updates to indicate that the player has visited them
it has come to our attention that some of you are trying to dock with only keyboard controls. We had never anticipated such a thing would ever be attempted and we are very upset about it. As such I have added a mind control subroutine to the code which will magically make everyone who plays Zero Falls more skilled at docking. We hope that this routine will end the unwanted behavior, however in cases where it does not, players will find that they are at least more skilled at docking ships the wrong way. Note that there are some side effects, for instance in some cases these patch notes has been known to force the reader to start manually controllinmg their breathing.
Significant bugs and optimizations:
fixed a bug that was improperly testing if the player could see nearby sectors causing them to render when they were off screen
fixed a bug where some movement logic was being called twice in a single update leading to ship components animating in the wrong locations
fixed a bug that could cause the game to crash during the loading screen due to thread synchronization of map region generation which needs to use the GPU
found and fixed a bug in our core terrain engine that was causing a lot of extra work to be done every time we accessed terrain for collision or rendering. Hopefully one of our few remaining uber-bugs. The impact on frame rates should be pretty huge.
fixed a bug where turrets fired in other sectors were placing their bullets into the player's current sector
fixed a bug where turret sounds could play from ships in other sectors
fixed a bug where cargo pods dropped by ships in any sector were being added to the player's sector
fixed a bug where turrets were playing animations in the current sector when firing in other sectors
fixed a bug where crew that got spaced always spaced into the player's current sector
fixed a bug where ship engine audio was playing regardless of what sector the ships were in
drastically reduced the max range at which engine sounds will play in order to reduce the overall number of audio sources playing in a session at once
fixed a bug where damage that destroyed the player's bridge console and ejected the player from their ship on the same animation frame would transition to the EVA screen before transitioning to the ship interior screen, leading to the player being on the wrong screen
Misc:
added a particle emitting tile for decorating ships with
fixed a bug with airlocks where breaking them due to flying the ship while airlocks are attached would improperly apply the damage with unpredictable results
optimized console activations in a way which might reduce the chance of getting stuck on the wrong screen due to a bridge blowing up while you try to use it
AI ships no longer magically slide away from other ships. It was a cheap hack to try and fix something that needs to be addressed by AI logic
cargo scoop mode on a ship will now scoop to the player's inventory if you do not have a cargo bay or if your cargo bays are all full
passenger AI crew should now have a special faction flag that will prevent Marv from murdering them
fixed a bug that could cause a potential crash if collision checks are processed in a session on the very first update step processsed
removed the old quest log which although it had been made invisible was still updating in the background
added a new framework for drawing screen space and world space animations outside of the game simulation so that we can add help text overlays to anything we want
slightly optimized interior rendering by removing an unnecessary draw call
slightly optimized session missile handling be removing 2 sources of redundant data
changed the size of crystal branches, this modifies the save format in a destructive way and requires starting a new save, we did this because we are also making other changes to save formats
monster attack sounds now only play inside the player's ship
crew gun attack sounds now only play inside the player's ship
friendly pirate crew inside friendly pirate stations will no longer shoot the player
stations inside pirate's cove now have crew wandering around inside them, who also won't attack the player
added an event triggered when ships dock. The delegate type for use in the code, not something that happens ingame
added an event triggered when crew use items. The delegate type for use in the code, not something that happens ingame
added an event triggered when ships die. The delegate type for use in the code, not something that happens ingame
added an event triggered when ships fire turrets. The delegate type for use in the code, not something that happens ingame
AI will now point weapons towards the front of their ship when they don't have anything better to aim at
fixed a bug which was making ship interiors forget the amount of air stored inside a ship more often than they were meant to
ship reactors now cool down at their normal rate inside ships that have no crew
fixed some errors with the art asset for friend-ship
fixed a bug where ships that were manually destroyed (such as being scrapped at the home base) were not cleaning up properly meaning the crew inside never officially died, but instead disappeared to memory leak purgatory
abandoned stations that look like asteroid mines now have crystals growing in them
harvesting crystals now has a small chance to give you a crystal spore for growing your own crystals
increased the amount of time it takes credits to animate to match the database delay for writing to disk
enhanced the logic that updates animations so they now fail better and will be less likely to crash the game
fixed a bug that caused reactors to explode on portions of ships which were seperated by damage
fixed a typo "leared"
removed some placeholder agents which have been replaced with actual characters
implemented the ability for different conduits to have different transfer rates
implemented T3 conduits
the transfer rate of all conduits was increased from 6 per update to 10 per update
fixed a bug where crystal genomes were updating in inverted order
trade ships now search for trade routes to do based on a budget constraint imposed on their purchases
pirate ships which spawn to ambush your ship will now continue ambushing if you switch ships...cheater
fixed a potential race condition which in theory might lead to a ship interior behaving problematically even though I can't verify that I ever saw this result in a reported crash
ship sounds now stop playing if and when a ship is disposed, not only when ships are manually removed or destroyed
all ships now spawn with random rotation instead of zero rotation
added a way to spawn random SSC stations for use in SSC facilities
added 2 new beam ships and 1 new missile cruiser to the SSC lineup
the skill to plant a crystal now consumes 1 crystal spore from your inventory instead of 1 (held item) and it also checks to make sure your held item is a crystal spore before consuming it
made a crew pathfinding function a little more secure to prevent cases where pathfinding could cause an unhandled exception
added a catch to the ship interior screen which forces you to the EVA screen when your corpse is detected floating outside of the ship
Q and E are now lateral thrust (strafing) keys in the default keybindings. Missile launching and beam firing has moved to the mouse buttons 4 and 5 by default
fixed a visual artifact that sometimes happened on the EVA screen
added a new music track to the orange zone
A number of additional SSC ship designs will now be found patrolling around the world
Monsters now make a sound when killed
Honestly probably some other stuff that we've forgotten. If I think of it I will add it to the next announcement.
0.8.0.00 Thursday evening
Short update here, just giving you the official date/time. I am going to be making the 0.8.0.00 update live late on thursday (july 12) evening pacific standard time. For many of you this will be early friday some time.
It is almost ready now, but we found enough debugging to do that I wanted to push it back a few days for additional testing.
0.8.00 coming soon
Since the big steam sale is happening right now, I thought it would be fun to make a big list of all the changes coming in the next update. I'm also going to formally announce that the release is already in internal testing, and should probably be out for you to play with in close to 2 weeks from today. All the new features are in and we are furiously play-testing the bugs out right now. Here's the mega list of new things that are coming.
Overhauled the research screen
Added progress tracking to research unlocks which grants hallways and structure
Overhauled the design screen visually and unified the two versions between the main menu and singleplayer
Added new tools and optimizations to the design screen such as copy paste, color picking, better conduit drawing and more
Rewrote save files to function out of a database and be more secure against corruption
Added player profile selection to the main menu
Added the concept of biomes which infest space terrain and spread across the world map
Overhauled crew weapons and added a new tier of crew equipment with new sprites
Rewrote the game's introduction to be faster, easier, and more fun
Streamlined early game quests and rewards to get the player into action a lot faster
Made docking easier by increasing the thresholds for movement and relative orientation
Revised most red zone content to fix bugs, improve flow, and solve other issues
Added a new secret boss battle that can be found in the red zone which introduces a new currency
Introduced the concept of core nodes, a currency which allows you to unlock a module from the design screen
Added a series of new dialogues and missions which will advance the story into a new zone
Added some new characters to banter with an eventually explode
Many new ship hulls and ship designs added to the game world for capturing and fighting
Added attack drone module unlocks, AI for attack drones, and drone carrying enemy ships to the game
Rewrote the system governing how beam weapons interact with ship design: beam alchemy, and added many new types of beam
Added beam module unlocks, AI for using beams, and many beam oriented enemy ships were added to the map
Populated the green zone of space with very advanced ships using the best of tier 2 technology
Introduced the concepts of tier 2 armor and tier 3 conduits to the game engine
Remapped many station interiors with new art assets for station interiors
Huge rendering and logic update optimizations which will drastically increase framerate on most computers
An innumerable number of small changes to the user interface, GUI, and graphics
Research, Optimizations, Stability
Similar to our last blog update, this isn't an announcement for the next patch's release date. However I will admit we just released that one to our internal tester group. We're here to talk about more upcoming quality of life changes, this time with regards to research and frame rates.
Research changes
One of the biggest and most consistent complaints we have heard on the forums has been the RNG grind of trying to unlock all of the little uninteresting research items such as minor hallway connections and other things such as doors. Who doesn't want to grind for days trying to unlock a door? Well it turns out most of you don't. Fine, so we've got a new idea in the works.
The new thing is that we've gathered up all the less interesting research items including the tiny hallway pieces and the doors and the bendy hallway bits and everything between, and now we give them all to you once you've unlocked a certain number of items from a specific research tier. There is even a fancy looking progress bar that shows you how close you are to a milestone and what you will get when you reach the milestone. Research tier 1 items to fill the tier 1 bar, and once you've completed enough items you will unlock all of the tier 1 filler pieces and you can call yourself a tier 1 research master...or whatever.
This feature is part of our new research screen overhaul, and it looks something like this.
Optimizations
There were some serious optimization issues fixed recently which make the game feel like a completely different game.
Terrain is one of the systems that takes a lot of resources. Our engine allows per-pixel collision with a map of terrain objects that is honestly enormous. We have really large sectors and in addition to filling those sectors with really big lists of terrain items, we also render terrain items from other nearby sectors. We allow both AI and bullets to interact with those terrain entities on a per-pixel basis, and so we need to poll the list of terrain items many many times per update. As you can imagine, that means we need to have a really fast way to access terrain from a specific area without touching every terrain item in the list.
As it turns out our system was broken at its core and the system we used to reduce the number of terrain items accessed each time we were checking was actually increasing the number and referencing duplicates. The result was that every call to check collision in a small region that should have contained at most one or two items, was often checking tens to hundreds of items, and rendering all items on screen when there were hundreds of items in view was actually rendering multiple thousands of items. Our system was returning duplicate entries with every call. The result of this fix has changed the number of items rendered in the best case from something like 1300 down to something like 10, and in the worst case we were rendering around 5000-7000 items when we should have been rendering 300-500. Suffice to say, this is a massive fix for frame rate and overall feel of the game, and it will hit hardest on any graphics card that was having trouble running the game due to overdraw issues. It will also fix numerous AI related fps drops that happened when there was a gunfight near some terrain.
In addition, sounds and animations were playing for ships and crew in other sectors. Many people don't realize that sound can be a serious source of slow-down, but playing audio represents a significant source of data that needs to be moved around in memory. By fixing obvious issues of extra sounds and animations we have further increased the framerate and made audio work slightly better overall. The game really does play like a different game, and in play-testing I have found the experience overall much more pleasant.
Stability
We have crash logs now.
However it isn't just crash logs that we've added. The same system that makes crash logs, also tries to recover your game and save progress. In most cases, we have found that bugs which once crashed the game, will now remember your progress up to the exact moment of the crash. Maybe loading back into the save will revisit the crash again, however the addition of a crash log means that now we can actually hunt down the source of the crash and fix it, allowing you to pick up your progress exactly where you left off once a patch is released. We have the game in closed testing right now, and we are already seeing the benefits of this system.
In addition, all character progress is written when your character changes, and all quest progress is written when quests change. This makes it much more difficult to lose progress from bugs or from smashing your computer into bits during a game session. Maybe it will also open up a world of new bugs which arise from crashing the game in creative and uniquely abusive ways however overall the new save philosophy is designed to write more important stuff more often, which always makes recovery easier.
With framerate stability, crash recovery, and less grindy research, this patch is taking many of the unpleasant edges off of gameplay.
Design screen overhaul
This is not the blog post you were hoping it would be. That one is coming soon. The patch should go out to testing very early this week, with many bugs that will need to be squashed before it can be pushed for general consumption.
Speaking of testing, one of the things that needs immediate testing, and which we hope you guys will help with repeatedly breaking, is our new ship design screen. We have completely overhauled, polished, upgraded, twisted, bopped, and shaken the design screen. Lets endure a blog post about what new features are coming.
Zoom!
That's not just me making space ship noises in my head, you can actually zoom in and out on the design screen now. It was one of the more frequently requested features, and now it's here. It also fully supports all the other features I'm about to list, which is nice.
Circuit inspector
Hovering your mouse over any power circuit now highlights all connected modules. From any given reactor to any given power using module you can see at a glance if your power network will reach. This should also help with teaching the player how power traverses different types of connections.
Also hover over bridge modules to see which devices are wired to that bridge.
Conduit improvements
Drawing conduits sucks 250% less now as you can get end-to-end connections without having to carefully move your mouse over every tile and constantly fix missed tiles. The new system does end to end path-finding to draw the entire route at once, and it has a fancy animation so you know what you're going to get. Shift click to draw routes.
On top of that, we've also added the ability for more than one type of conduit to exist. You know what that means, some day there might be an improved version of conduits to unlock via research.
Global ship stats
A number of useful statistics for your ship are now summarized in the top right where we used to only show ship mass and crew count.
Color picker tool
Just like in an image editor, we now have a color picker tool. It allows you to select a tile on your design and immediately set your brush to the color under the cursor...except instead of a color your brush is actually a module...which in our code is actually a color since your design is an image...Yay color picker!
Selection tool
Ever wanted to select a group of modules and copy paste them? It even works with mirroring.
Beam alchemy overview
More
Lighting mode toggle for design rendering, support for the new feature: Core Nodes, a codex with helpful explanations of some confusing mechanics, history of placed modules, and overall beter visual presentation of all aspects are the remaining items on the list that I could remember when writing this. There's even more than that probably!
Save format rewrite
In the game development industry, it is essentially guaranteed that at some point in your project you will look at the entire thing and realize that one of the most core components, central to the entire design, has simply been done wrong from the beginning. Depending on budget, or more often leadership and partner deadlines, it often then becomes a choice for the development team: Do we put an ugly bandaid on this feature and release it as-is, knowing that it is wrong? Or do we invest a significant amount of time and effort to drastically change the direction of development at such a late stage?
Conveniently, our team is tiny we have no release date and nobody can force us to release anything we don't want to, so we have the luxury of doing things the right way, even if it means spending extra time rewriting something that has already been written. I suspect many other gamedev teams are jealous.
The issue I have been working on lately is one that we really need to get right before release: the issue of save formats.
The philosophy of a save
What data goes on disk, and what gets forgotten really is a sort of arbitrary thing once you distill away all of your preconceptions about the subject. As it turns out, there does not exist any universal thing which encompasses the idea of saving a game. When we first built the engine, I approached the idea of game saving from a perspective that was familiar to me and which seemed to work at the time, without really considering the big picture. As a result, some problems started to pile up.
I am sick to death of broken save files so for the next update I've decided to confront the philosophical problem of game saving head on. I didn't invent the idea of saving game progress. When I make designs, my brain tends towards familiar tropes and patterns I've seen so many times before, and I think I used the wrong one when I initially wrote progress saving in Zero Falls. So now I'm taking a step back, deciding how saves would function in an ideal world, and making steps to move it there with this update.
The linear story save
The save format philosophy we have right now is one that follows a perspective of the story being a linear sort of thing, and the character existing inside that story. Every second of gameplay is just an advancement of the narrative of character and world together, and when you press "save" you are freezing the game at a moment of time to resereve the option of returning.
It makes a lot of sense because we have linear quests and dialogues. If you talk to someone, and they give you an item, you should be able to reload the game at a time before you talked to them and you will expect to no longer have that item. You've gone back in time, so to speak.
It really is a classical formula, and it has worked in so many story driven open world games before that it was the natural thing to design if I was going to make a design without thinking ahead...but it has issues.
Here's a list of issues (because I gotta have at least one list)
You simply can't make an ideal solution for persistent unlocks that live outside the save file
It makes a very fragile data format that allows the entire game state to be corrupted by a single missing bit
Being able to go back in time means making a copy of the world, and our world format is huge
You have to write scripts to upgrade the entire save file when a story element changes in part of the world which was already recorded
Most importantly: character progress is always tied to world progress.
That last point is the big one, and it's kinda the same point as the first one. Our game world is the same thing as our character, and yet there's reason to think it shouldn't be. In a game about exploring and collecting unlocks, some people will want to ditch their world after a long play session but keep their unlocks, and others will want to start fresh with every world. How can we as developers give them that choice?
I think we need to look at saves from a different perspective.
The world and the character
In hindsight, this format seems more common among modern open world games, and after reinventing the wheel myself I think I can see why.
The idea is, character and world are separate entities. Character moves freely between worlds, and neither world nor character ever makes an explicit copy of itself in the form of a traditional save file. Instead, both make progress in only the forward direction, and if the player wishes to return to an earlier state of progress it is possible to create a new world or a new character or both.
This format gives up time travel in favor of granting the player absolute power over which progress to keep, and when to experience something from a fresh start. It allows both characters and worlds to serve as trophies and momentos of past acomplishments, while removing the hesitation of starting over again. More importantly, it solves all of the problems I listed above and empowers me to make future changes that might be fun.
I also realize that while I never adopted this save format, over the course of development the game has always evolved towards a feature set similar to other games that use the same save philosophy. You don't lose any progress on death in Zero Falls, a featue which rarely coexists with the ability to load the game to a previous point in time. Also the procedural nature of our universe, popping into existance the first time you look at it is a concept which creates fundamental architectural problems when you allow time travel. You may recall a bug where stations were duplicating themselves? This is only a symptom of the bigger issue at hand: how does a procedurally generated world return to a state before it generated without creating a mess? The answer is with endless hours of debugging and frustration, as well as very long loading screens and very large world save files.
I think the final game needs to adopt this save philosophy, even if it is a little painful to transition, and as such I am making the change right now.
What's changing
I'm gutting the save format. Your existing saves will be useless after the update and you'll have to start fresh. Sorry about that.
I've build the new character progress system around an SQL database. It's lightning fast, and your data is always on disk so it will be very hard to lose character progress. Even if the game crashes, you will find your inventory and credits and research is all up to date when you get back into the world. What's better is that data saves when it changes with zero lag, so no more waiting for long auto saves after every time you dock, and no more worrying that your progress is safe.
As for world crashing, being able to completely remove all binary data relating to characters frees up a lot of room to make world data more durable. We can regenerate sectors if they have a really bad issues, and we can throw out a quest if it is causing problems, all while leaving the world intact and the game running. This means absolute worst case is you lose the ability to complete a quest, but remember you will also have the option of taking your existing character to another game world and attempting the quest again.
Overall I recognize this will be an awkward transition for some, but this is early access after all. I plan to leave in the code that handles traditional saving (the time travel type) however I will be discontinuing support for that functionality and probably hiding it behind the debugging mode.
It will be nice not having to worry about time travel paradoxes when writing quest logic.
Living world - biomes
The two most complained about things in the previous version seem to be the lame tutorial, the difficulty of learning the controls, and the fact that it is hard to get crystals during the mid-game when the story tells you to go talk to the pirates. Addressing these complaints have been the primary focus of my most recent development work.
New intro sequence
I've modernized our intro sequence and made the flight tutorial just...better. This one drops you into the action faster and doesn't ask you to sit around reading for a long time immediately after starting singleplayer. The old story elements are still there, but the irritating bits have been slimmed down a little and polished up some.
Also, as a side note, the creation of this intro sequence was the first test of a new quest framework upgrade I've been working on which will make it easier to write quests in the future. Since the intro sequence seems to work quite well, I'd say the new framework is a success.
My current project is using that framework to create the next stage of story content, but I wanna talk about the other project which is already in the engine, since that one is more or less working and ready to go.
Biomes
This one was inspired by the lack of crystals. When trying to decide how to solve the fact that the player can't get crystals easily in the early game, I realized that crystals should ideally tie into asteroid mining. I needed both a way for crystals to get into asteroids, as well as a reason for the player to plant crystals in asteroids. I was also reminded of an old project I always wanted to work on which was lurking at the back of my mind forever: Asteroids should be a habitat for living stuff.
Thus, with much arms being thrown into the air I said "to hell with it" and sat down to program a feature I've been wanting for a while. Living biomes that exist as part of the world map and the space terrain.
There are now color coded factions which can inhabit asteroids and stations on their exterior. These factions, initially, are...
the monsters faction
a faction of native (hostile) crystal fauna
a faction of domesticated crystal fauna
They will spread in real time across the world map, infesting asteroids and creating hazards for the player. As an example, the blue faction, which spawns in the player's starting region, represents the space monsters sometimes found on stations. This biome will release spores which will roam space looking to colonize more asteroids, however the spores can also target the player. If they hit you, they will place a monster spawner inside your ship somewhere.
These spores can and will also target any NPC, so if you find an abandoned lifeless ship floating in space full of monsters, that's not a bug, that's emergent content. However the AI should already be smart enough to try and defend themselves.
The friendly domesticated crystal fauna will be unlocked in the green zone of the map which we are working on for the next update, and it will spawn wherever the player plants crystals inside a station. This biome will suppress other biomes and its spores will have beneficial and protective effects.
More importantly, when mining an asteroid with a drillbore, the contents of the asteroid interior will be affected by the status of current biome infestation. Containing ore, monsters, crystals, or maybe even other things depending on what has been growing on the outside of the asteroids.
However the most important of all reasons for adding the biomes is because it allows interactions with terrain that aren't interior based. We designed the game with space combat in mind, and the bulk of the simulation complexity is built around the ship exterior aspect of the game, yet we felt like too much time was spent in the interior. Biomes is another step in the right direction because they can grant resources like crystals through ship piloting activities, which will reduce the need for the player to spend so much time in their station.
Also biomes make the world feel more alive.
Beam Alchemy
A wise person once said, "There's weed killer in our corn!" but I digress. Today I'm here to talk about shiny beam shaped explosions of fun.
Have you ever thought to yourself "man, these beam weapons are totally cool and no development ever needs to be done to improve them!?" Well that's the exact opposite of what we've been thinking lately. I mean, the next update is supposed to fill out the remainder of the tech 2 tree, and I've already revealed that that means missiles, beams, and drones. So lets talk about beams right?
Philosophy of a beam ship
The idea behind beam weapons is that you have emitters, and you have controllers.
The emitters do the real work, taking energy off the power grid, storing it, and using it to provide various arcs that your beam can fire across. They are like the turret mount of the beam world. More of them means your beams recharge faster, sustain for longer, and can handle firing more powerful beam types. I consider emitters to be feature complete, and also cool looking.
Controllers on the other hand.... Well, lets just say Jan has interesting plans for those. If emitters are the "mount" then I guess controllers are the gun right? Seems like it takes the analogy too far. Anyhow, point is that a controller determines the property of a beam weapon, but there's only like...3 of them! You need a new module for each one and making new modules is hard so...
Beam alchemy
So I guess we needed a way to make beam controllers more interesting from a ship design perspective, and as a result we created beam alchemy. It solves so many problems in such a neat way.
Beam alchemy! That sounds like crazy talk.
Yup. The idea is that beam controllers no longer provide multiple beam types to choose from. Instead, they blend their properties together to produce a unique new beam type depending on which controllers you have used.
It even handles more than one of the same controller, increasing output for each additional controller with diminishing returns of course.
New stats and effects
With the new blending mechanic, we need to really nail down all of the functions and attributes for blending purposes. As such, we have done a lot of work to make sure that beam controllers have interesting stats to blend with other beam controllers such as:
damage rate
energy use rate
range
(new)charge duration
(new)...other effects
Other effects are the coolest part! Did you ever want a beam that slows your target by increasing their mass?
What about a beam that fires lightning?
How about whatever this thing is?
Our goal is that each beam controller will bring unique properties, unique animations, and unique effects, and that you will have the control to combine them into your own combinations to make the beam weapon that suits your ship best.
We're also going to put new types of beams onto AI ships so they can ruin your day in interesting and unique ways.
Missile converters and future updates
Good news! We're still working on cool stuff and I'm here to show off some of our progress. Remember, our goal is to finish up the core story elements so a full play-through is possible. Then after that we will be looking to flesh out content and polish the user experience.
Next large content patch
As in, the one after the one we are working on right now, will take the player into the grey zone of space to go head to head with the full might of the SSC navy. So what are we working on in this patch? Well the loot that's going to drop of course.
The SSC navy and the grey zone of space represents a new challenge because it is where the tech tree really starts to open up to the player. We are introducing a new never-seen weapon system: drone bays, we are completely overhauling an existing weapon system to prepare it for upcoming loot drops: beam emitters, and we have been fine-tuning and polishing an existing weapon system with new puzzle pieces that the player will get in the grey zone to complete their set: missile systems.
Missile systems
We already have missiles in the game, however without access to a missile factory they may have been more of a secondary system that you wouldn't have focused a ship design around. We intentionally witheld that module because missiles weren't complete without first solving an important problem: ordinance selection.
The unique aspect of missiles is that a missile launcher, and a missile magazine, can hold more than 1 type of missile. Specialized missiles for specialized combat roles. However this poses a problem for the developers: how the hell do you choose your ordinance type?
Do you have to carry missiles around in cargo?
Do you choose from new screen?
Do we have to redesign logistics?
After much thought, we concluded that the best solution was the simplest. Both simplest from our side, and from yours: a new module type. This fits with our policy of putting all of the complexity into the ship designer, and then making the ship designer optional for enjoying gameplay.
We do this because we know some of you are engineers, and some of you just want to explore what the engineers have created.
Missile warhead converters
Missile warhead converters are modules which operate on any nearby magazine or missile factory. Their function is to instantly convert the type of ordinance contained or produced inside the that of the converter. They are an activated module, which means that if you have more than one you can use them to swap ordinance on the fly by connecting them to your bridge. However they are also automatic meaning that placing one of them on your ship triggers their activation by default and you can effectively choose the missile type used during the ship design phase.
This also means that in-game ships created by the developers, as well as custom ships in flotillas, can be designed to fire new types of missiles without the need for special scripting or quest logic.
Seen above, in order, are armor penetrating missiles with offset damage that is very effective at hitting the interior of ship systems, and graviton missiles which apply a slowing debuff to the ships they hit, effectively increasing their mass to prevent manuevers. The system allows us to make new missile types very easily.
0.7.1.01 - 0.7.1.02 patch notes
0.7.1.01
fixed a bug with the new scrolling menus which prevented clicking
set default UI scale to 1 instead of 2
0.7.1.02
fixed a bug with the procedural taxi quest which prevented it from finding your passenger after loading a game
fixed a bug which prevented Anna from searching your ship for food when you delivered it to her
budd will now spawn in the player's current session if the pirate home sector grid location was never assigned for any reason
budd will now patrol to the player's location after spawning (where the player is when he spawns)
fixed a bug with the kill budd quest which MIGHT have lead to the dialogue happening before Budd actually spawned in some cases depending on the order that things were done in
fixed a quest which was failing to load leading to the game saying saves were corrupt. This also gives me an idea for how in the future I might make saves handle quests better