Testing out a fix for a map generation crash, that should hopefully tone down the Danger Rangers/Bruce Li crashes among other ones from generating a lot of rooms. This also contains some changes to the end fight, now featuring snow plows.

5/5 EDIT: This is now up for the release version of the game.

-----------------

INSTRUCTIONS

IMPORTANT NOTE: The testing branch and the retail version usually use different save files! Testing Branch saves also get cleared out on occasion.

HOW TO INSTALL: Right click Death Road to Canada on Steam. Go to Properties. Go to Betas. Select Testbranch, no password necessary.

CHANGES

- Crash fix for a crash that could happen when an empty room was generated.

Ending Spoilers :mountie:

:mountie::mountie::mountie: Canada Crossing Changes :mountie::mountie::mountie:

- Snow plows added as border gates.
- The former back line of Mounties that didn't attack/blocked your way are now above the snow plows.
- If the game detects you've never won, a Mountie now gives you a message of hope as you're running to the border gate. This text event stops showing once you beat the game in any mode.
- If you're playing on one of the "Easier Bandit" difficulties (Normal, Rare, Familiar, Long Road, Short Road), the ending zombies will stop attacking you right before THE BIG REINFORCEMENT arrives. This is mostly to stop beginning players from dying in a hilarious way.

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.


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 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.


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.


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.

Torps are best fired in rapid succession and we've fired another into the hull of the v2.2.x family of features with Update #58. Bringing custom keybindings online, we've knocked off the last feature of the family. With all of the major feature work finished, we'll be working quickly to wrap up the next era while the engineering team gets a head start on the v2.3.x features! Check out the full EA Dev Roadmap for details on all the areas we are working on, but we've included the tattered remains of the v2.2.x family below.



When offered the option to Surrender in advance of a ship combat, the prompt title and the description now give some advance warning as to what you can expect. This is based on the captain type, Faction, their Rep, your Rank and all the other factors taken into account -- but you can see when you are likely to be just searched, looted, thrown in prison or even executed.

From the main menu, pop open the keybindings screen to modify the game's keybindings. There are two sets -- common/map and combat. So you can bind the same keys to different functions between these two screens (space to navigate but also to end turn in combat, as an example). Adding custom keybindings has prompted us to add a few more hotkeys but we are aware of a few places were more will be helpful and we will keep working to add more and of course will include them here for customization. Thanks to everyone posting requests for these!



Contact offering military and specialist gear now offer a 3rd tier of gear in their service ladder. Each offer 4 new types of gear for purchase. You can see these new offerings without reaching the tier's requirements, so take a look! Some exciting and very different items are included.

There will be on-going work to keep balancing out crew combat for many more updates, especially as we add new Jobs and Talents. With Update #58, we've adjusted a rule about low Piercing versus higher Deflection. If the target's Deflection is twice the Piercing value, an extra 25% chance to avoid Piercing hit is added. This helps to level out weapons like blades and pistols that do not have the best piercing value and requires more active buffing to punch through armor unless you have a weapon like a Sniper, Snubber or HMG built for it.

For the Merchants and Smugglers alike -- the demand set for Electronic Components has been expanding to include more zone types. Check Resource Types on the wiki for more quick details!

- Added Custom Keybinding support for all screens and combat
- Ship Combat 'Surrender' option now includes intel about what enemy Captain will do (Search, Loot, Imprison)
- Contacts now offer a 3rd service tier for gear
- Added 8 new types of level 3 gear for officers and captain
- Arbiter immediately converts to UC Faction (no delay for later stage games)
- Crew combat balance shift -- if Deflection is more than twice Piercing, reduced change to Pierce by 25%
- Fixed repeat damage from relanding with Gravity Sickness and Worldsick Trait
- New Crew barks for Worldsick and Gravity Sickness
- Rebalanced Supply and Demand curves for 'Electronic Components' trade resource
- Fixed range change issues in ship combat and successful use of Blood Game cancels Escape
- Fixed issue in crew combat where viewing crew member status removed Move / Refocus / Default Attack Talents
- Fixed issues in Ship Combat victory -- dumping cargo miscounts, sorting in conscription
- Fixed up pager in crew combat Talents list
- Fixed bug where Init penalty was carrying over between completely separate crew combats

This game version addressed a HUGE bug in "Part II: Die" in which the monster wouldn't spawn. It also made the camera system a bit more intuitive. Thank you for checking out this game! We are 12k downloads and 122k views deep!

.

Hello Everyone!

Today we released Game Server Toolbox v.03. In this version we added a new feature called the Dependency Manager. This will allow you to download and install common dependencies that some game servers require like Visual C++. We will be adding others to the list in the coming week likes DirectX.

In addition, we added a new tab in the Dashboard called Tools! This is where you can find the Dependency Manager. We will be releasing new tools in this tab in the future that will help you take more control of your game server.

The new server creation tool in the coming months will work hand and hand with the Dependency Manager. It will automatic install them for you to make the server creation process even simpler. We will release the new server creation tool in stages to make sure everything goes as smooth as possible.

We hope you enjoy the update and please let us know if you have any issues or feedback!

Hello dear friends!

1.1 Update is now released and should be available for download (if not promptly restart Steam and it should start its download). This update is small (hence why it shows as 1.1 instead of 2.0).

• Increased players stamina
  
• Improved A.I. behavoir (detection & chase range)
  
• Minor improvements and bug fixes (player/world)
  
• Added additional achievements
  
• Censor control (.ini)

For all issues and general feedback please refer to our discussion forums. Bigger update is on it's way and should be available soon!

Today we have enabled cards for Grisaia Phantom Trigger Vol.3.
Thank you for your patience and have fun!

Hey all,

A quick mini update for everyone.

We have deployed a number of fixes for the latest version of the game.

We fixed:

• The tentacles in Blast Pit not responding to explosives
  
• Problems with CSM on lower settings and improved CSM performance
  
• Humvee using experimental texture that caused FPS drops
  
• Invalidated old saves as we forgot to set that with the first deployment. Sorry if that inconvenienced anyone.

We are currently troubleshooting

• Flashlight not working on some machines with dedicated video cards
  
• Game not launching on some machines
  
• Black screen on Linux when launching

We also found a nasty bug on our Linux servers. We are working on getting that sorted as soon as possible. For the time being our MP servers are down. Once we have them up, we will plan a play date so we can REALLY test the servers and blow off some steam with everyone!

Thank you to everyone who reported bugs and helped the community fix problems.

We've been wrestling with some technical debt and old code that has been plaguing performance and making it difficult to add new contributors to our team. Today's patch successfuly resolves many of these issues!


+Some parts of the game have been slightly rolled back so that maintenance and upgrades can be made. Please be patient as we update lighting, NPCs, and other content.
+New map shows off terrain streaming tech.
+Fog, the camera, and other perspective settings are being adjusted to accommodate streaming terrains.
+Don't forget to try different graphic settings, as well as grass and tree options! These can have a major impact on FPS and visual presentation

As we update and rework parts of Dragon we've been constantly toying with the right balance of open-world vs modular zone design. Because Dragon has the unique character of being both a flight simulator and action-rpg - two vastly different kinds of games - we must find approaches that scale well.

To this end, we think we've found the right balance. Moving forward, we'll be using "zones" or "regions", bounded spaces that are composed of many streaming terrains. The game manages the streaming terrains for a (generally) seamless experience. This approach keeps the vast open-world experience while leveraging the reduced development and performance overhead which comes with bounded spaces.

This patch is just the tip of the iceberg! Thanks for being patient as we clean house and get Dragon in to shape.

The Issue: Mappers currently take a shotgun approach to resource layouts. They try to put resourcing locations in strategic places, and try to define resourcing amounts that will work for for most, if not all games using the spring engine. Unfortunately, that approach will generally work well for one game, and be fairly mediocre for others.

Read More...

If you like my updates, consider subscribing so that you can get updates sent to your email!