Game Breaking Release - Suggestions?

[crableybradtree]

I am a new developer, with one game in beta (Livingstone). I also took on a Bounty (19826) for a released game = Cribbage. This question is asking for suggestions on doing the release for that bounty.

The bounty involves adding 3 and 4 player capability, and adding teams, to Cribbage. I took the opportunity to autowire and JSON the game to bring it at least closer to the current framework, and remove some of the compile warnings. I am also hoping logic changes I made will help with some of the other old reported bugs.

Unfortunately, with all of these changes, if/when I release the update, it will break the 1900+ games, including the tournaments, in progress. With my meager programming talent, I couldn't figure out how to make these many measurable changes (e.g. multiple database changes) without making a game-in-progress breaking release.

I've been emailing Studio and Contact since late July asking for suggestions on doing the release, however I haven't received an answer.

Can someone with experience here give me some suggestions? Should I just roll out the release and deal with the screaming, or are there things I (or BGA admin) should do to lessen the pain?

[AxeCrazy]

Probably the db changes will break all, but you should be able to use the upgradeDB table function for that?
i used it once in an already released game (amazonas)

You can add the new db fields and fill them with default values.
If you really changed the complete database, perhaps you can build a way around it fo running games.

Or the game should be republished under a different name, but you need BGA for that..

Please ask in the discord channel, since response is probably quicker there.


function upgradeTableDb($from_version)
{
// $from_version is the current version of this game database, in numerical form.
// For example, if the game was running with a release of your game named "140430-1345",
// $from_version is equal to 1404301345



if ($from_version <= 2408292225) {
self::trace("ALTER DATABASE " . $from_version);
$sql = "ALTER TABLE `DBPREFIX_player` ADD `huts` smallint(5) DEFAULT 12;";
self::applyDbUpgradeToAllDB($sql);
$sql = "ALTER TABLE `DBPREFIX_player` ADD `extra_huts` smallint(5) DEFAULT 0;";
self::applyDbUpgradeToAllDB($sql);
}
}

[crableybradtree]

Thanks AxeCrazy for the quick reply. I did get a response back from Studio folks today with similar information about upgradeTableDb() and how to test a game by starting with the production version in Studio and then rolling to the latest Studio version (head) and running the database upgrade. The Studio folks also strongly encouraged me to do whatever was necessary to not have the release break games in progress. I guess they don't like to pause table creation for any game past Alpha stage.

It didn't take too many tests with the "start production version then load studio version" method before I got a game in progress to successfully complete. I just had to be more careful with the default settings of the new values.

Lesson learned: next time when making a major upgrade to a production version ... do it in little steps.

[oBsiDiaN]

You could try putting a branch immediately after game creation that sets new games to use the new code/db tables and lets existing games continue using the old.

Use the upgradeTableDB() function to set a value on all old games, then check that value in the first state and if not set (new games only) divert to your new code, you would need to create a distinct set of states that do not share id's with the original game states.

Maybe add a notice for players on the old code that things have been fixed for newly created games.