Staging is Important.

Bug fixing data-driven gameplay can be challenging, and Chris and I have put a lot of time towards developing a process for the many stages that are needed to test before pushing to the world. To make things more complicated, Bold Moves will pull data from one of two servers depending on the kind of build that the game is published on.

For a while, our pipeline consisted of DEV, TEST, and PROD. The problem that arose from this is that we didn't have a safe environment to test data on the production server before releasing to the world. Each of these stages have their own manifest file, and without STAGING we had to test pre-live builds by manipulating the actual data that consumers were using in a way that also wouldn't disturb them. 

Very bad practice. 

At the time, TEST was pulling double-duty: it was for testing data in preparation for consumers as well as new features and back-end functionality. It was an appropriate test environment; TEST data rarely changed compared to DEV, and it was mostly the features that were intended to become live. The biggest problem with this is that TEST is on a different server from PROD altogether. We couldn't guarantee that all the necessary assets were in place before the new data hit live.

We've built in a few compatibility checks to the data that prevents the game from downloading out-of-date data, which allowed us to get around the problem for a while by preparing builds that were on a different version number on PROD. Ideally, Bold Moves development will reach a state where we rarely push new updates and deliver content entirely through server-side data. Without a change in code, we would have been unable to test new data on the Production server without consumers also seeing this data.