Tick Tock - a suggestion for a more frequent patch cycle
GreenWarlock
Member Posts: 1,354
It is always dubious to comment on another developer's release cycle, as I have no insight into the company dynamic, and why the process that produces a release is the way it is. As a customer, I am not the only one frustrated with the slow, monolithic release cycle that BeamDog are using, so offer an observation from another company (in a different business) that I hope may inspire.
Intel for a long time had an effective monopoly in the CPU industry, and happily threw all their engineering into making the best chip they could, over and over, to stay ahead of the competition. At one point towards the end of the 90s though, AMD made huge progress, and there was a real danger that they may have been seen as the technical leader (in fact, the original 64-bit architecture of modern CPUs was inspired by the early AMD, rather than Intel, architecture).
Intel had to learn to innovate more rapidly and effectively to retain their lead, and came up with what is called the Tick Tock development model. They have two teams working on different developments, a Tick release focusses on the production process, reducing the size of logic gates etc. to make the CPU physically much more efficient, and allow the number of gates to increase with Moore's law. A Tock release focussed on a new design of the layout and code units, enhancing the instruction set and other capabilities of the processor. Splitting these into two separate (independent) focusses greatly simplifies the complexity of any one release - as complexity is the product and not the sum of the inputs, and has resulted in a very predictable effective cycle of processor releases for well over a decade now:
http://www.intel.com/content/www/us/en/silicon-innovations/intel-tick-tock-model-general.html
Now I am not suggesting BeamDog need to teams working independently on different patch cycles, that would not be an effective use of resources on a small team
However, the idea of splitting up into two patch streams the parts of a patch that have more local vs. global reach would greatly simplify integration and testing, and potentially allow for a faster release stream.
The majority of bug reports are associated with game data and very local scripts failing to fire or account for a specific variable correctly. The chance of a patch fixing such an issue to affect the rest of the game is not zero, but a much smaller risk than a patch to the game engine, adding a feature such as a class kit or the loot bar, or changing some part of the global system such as the fonts used.
If the new/global features were part of a separate patch cycle, which specifically did NOT try to address data/script issues, then a 'tick' release of quick (localized) patches could be validated and released much more quickly. By releasing such patches more frequently (monthly? quarterly?) then the number of fixes in any one release would be smaller, so the chance of any one fix derailing the whole patch goes down. It should also be easier to back out a single problematic fix without destabilizing the whole patch, if that is a quicker way to release.
The feature patch work would become a little trickier, as it would mean periodically rebasing that development branch off the latest released patch - but when the feature branch is getting ready for validation, then we stop making the many small fixes and focus on just testing and integrating a small number of features that widely affect the system and do require much deeper, more thorough testing of the whole game.
If such a system were in place - then we would not have been waiting a year to see a patch to complete the very first quest of the game. The BG2 crowd would be significantly happier by now, as there would have been a few releases addressing the most blatant encounter bugs. As a Mac user I would still be unhappy as all of those patches would be built on top of a 'global' patch fixing a memory leak that was never released to us, but at least there would be a sign of progress for the majority of customers, and a clear sign of what to expect in the future.
It is clearly to late to adopt something like this model for the 1.3 release cycle (even for BG2EE, as we hear that patch is well progressed in development) but might be something to think about in the 1.3 post-mortem review, when planning for the 1.4 cycle and later.
I don't expect this model would be perfect for BeamDog - there may well be reasons that this forked source-code model cannot work for BeamDog, there may be organizational reasons it could not work either, but as a customer desperate for a more frequent release cycle this is the best I can offer. Hopefully something in this might resonate or inspire in a helpful rather than critical way though, that can be adapted in a useful way.
Intel for a long time had an effective monopoly in the CPU industry, and happily threw all their engineering into making the best chip they could, over and over, to stay ahead of the competition. At one point towards the end of the 90s though, AMD made huge progress, and there was a real danger that they may have been seen as the technical leader (in fact, the original 64-bit architecture of modern CPUs was inspired by the early AMD, rather than Intel, architecture).
Intel had to learn to innovate more rapidly and effectively to retain their lead, and came up with what is called the Tick Tock development model. They have two teams working on different developments, a Tick release focusses on the production process, reducing the size of logic gates etc. to make the CPU physically much more efficient, and allow the number of gates to increase with Moore's law. A Tock release focussed on a new design of the layout and code units, enhancing the instruction set and other capabilities of the processor. Splitting these into two separate (independent) focusses greatly simplifies the complexity of any one release - as complexity is the product and not the sum of the inputs, and has resulted in a very predictable effective cycle of processor releases for well over a decade now:
http://www.intel.com/content/www/us/en/silicon-innovations/intel-tick-tock-model-general.html
Now I am not suggesting BeamDog need to teams working independently on different patch cycles, that would not be an effective use of resources on a small team
However, the idea of splitting up into two patch streams the parts of a patch that have more local vs. global reach would greatly simplify integration and testing, and potentially allow for a faster release stream.
The majority of bug reports are associated with game data and very local scripts failing to fire or account for a specific variable correctly. The chance of a patch fixing such an issue to affect the rest of the game is not zero, but a much smaller risk than a patch to the game engine, adding a feature such as a class kit or the loot bar, or changing some part of the global system such as the fonts used.
If the new/global features were part of a separate patch cycle, which specifically did NOT try to address data/script issues, then a 'tick' release of quick (localized) patches could be validated and released much more quickly. By releasing such patches more frequently (monthly? quarterly?) then the number of fixes in any one release would be smaller, so the chance of any one fix derailing the whole patch goes down. It should also be easier to back out a single problematic fix without destabilizing the whole patch, if that is a quicker way to release.
The feature patch work would become a little trickier, as it would mean periodically rebasing that development branch off the latest released patch - but when the feature branch is getting ready for validation, then we stop making the many small fixes and focus on just testing and integrating a small number of features that widely affect the system and do require much deeper, more thorough testing of the whole game.
If such a system were in place - then we would not have been waiting a year to see a patch to complete the very first quest of the game. The BG2 crowd would be significantly happier by now, as there would have been a few releases addressing the most blatant encounter bugs. As a Mac user I would still be unhappy as all of those patches would be built on top of a 'global' patch fixing a memory leak that was never released to us, but at least there would be a sign of progress for the majority of customers, and a clear sign of what to expect in the future.
It is clearly to late to adopt something like this model for the 1.3 release cycle (even for BG2EE, as we hear that patch is well progressed in development) but might be something to think about in the 1.3 post-mortem review, when planning for the 1.4 cycle and later.
I don't expect this model would be perfect for BeamDog - there may well be reasons that this forked source-code model cannot work for BeamDog, there may be organizational reasons it could not work either, but as a customer desperate for a more frequent release cycle this is the best I can offer. Hopefully something in this might resonate or inspire in a helpful rather than critical way though, that can be adapted in a useful way.
5
Comments