That's after how many years though. It's not like the Campaign Series is recent. It's got to be close to or over 20 years old. It started with Talonsoft. Tiller must have kept some notes or documentation when the games were current. They had East Front, West Front, Rising Sun, East Front II and Divided Ground. Kind of hard to believe that he kept no notes or documentation during that whole period. Most likely he didn't have much to turn over to Matrix or to your team because of it being such an old game series. He moved on to creating other games and game systems. If bet you asked Norm Koger for notes and documentation on the original TOAW he probably no longer has much. Grigsby probably doesn't for some of his older SSI published games.
Let me ask you something. If Tiller kept poor notes then how are you able to scrap the old code in the Campaign Series and not come up with a jumbled mess. Even with all the code you changed the Matrix version of the Campaign Series for the most part still plays like the Talonsoft version. You guys added some nice features but for the most part both versions still play the same way. In other words if I played the Talonsoft version of a game like Divided Ground then picking up the Matrix version of CS Middle East and playing it is not that difficult. So if there wasn't much in the way of notes or documentation how did you do it? Reverse engineering? That's my point about half-finished games too. If you can do it with poor notes and poor documentation on a full game, why can't it be done with a game that's only half-finished?
With enough time and effort, anything can be achieved, I guess. It’s not that simple that you assume, though.
When you say "taking a half completed game", a lot depends on what you are "taking". I'm not that familiar with game development but for development in general. Are you taking\getting:
- source code?
Are you thinking of just this? It's essential but not enough. Is the code well designed, in a familiar language (both computer and human language)? Is it possible to derived the functionality of the code from the structure and comments?
- project plans?
What has been done, what needs to be done, what is unclear, where is there risk?
- design documents?
Essential to know what the software is intended to do, and even more important to know what it is assumed the software will never be asked to do. With just one developer (or few), then the design documents could just be thoughts in someone's head. Potentially this can point to problems, for example if you are used to one design approach and the existing work uses something different.
- test suites etc?
How do you know what exists already works? Can you tell that what parts of the product developed so far are complete, or is what has been done actually a work in progress itself?
- bug tracker?
What is positively known to not work in the current version? Are there fixes needed that mean the existing design documents (if any) are out of date?
Plus there are lots more things you want from the original developers:
- test tool required?
- what is the build process? software required for this?
- any user feedback?
- promises made in marketing?
For the benefit of others:
We started with pretty much the source code, or a set of source codes even, and built from there.
And as you point out, it's not “just” the programming part that’s important, the QA tool set is of equal importance. And the project plan, and documentation, and...
I'd like to share our approach to QA however. We have a very experienced programmer, and as part of the overall effort he built a complete bash based QA script library for the dev team to use in all aspects of QA processing.
As new features are added, this QA library is updated as well. The latest addition to this library is a script that checks our Lua CS Event Engine code for each scenario. It is not enough to check the Lua syntax, the CSEE functions and vars and use of thereof needs to be checked, too.
With this QA suite, we can now ensure the validity of each and all parameter files. Relevant parts of the QA set will also be included in the game, so any modder will be able to use them as well.
I am responsible for packaging, amng other things. We work at various locations and have a cloud to upload each our work. I have built an automated tool that picks all the necessary files for each game in the works (Middle East, Vietnam, East Front, ...), builds the install package, and then another QA script to further check all game exes, graphics, sound files are in place there.
Then, the game engine can also be run on a autotest mode, AI-vs-AI, over and over again. His mancave comes with a good few older PCs as well, and he has a few of those pretty much non-stop on autotest mode, running through the created scenarios over and over again, with latest builds. At key intervals, other dev team members harness our computers for autotest sessions too.
Test early, test often!
As for the development, Campaign Series (CS) at its heart is a tactical scale, action points based game, and we’ve taken great care to keep the spirit of the game the same, despite the complete overhaul.
CS has been around for a good while, we obviously love it to bits, but I was happy to note it still receives nice reviews . There was a lot of good there in the legacy design to begin with.
The bad and the ugly was mostly the aging UI, and how everything was hardcoded and not flexible in a manner that the more modern game engines are.
So we began the development based on a fully working but aging legacy game. The latest flashy Android and Apple phones can be said to be still fully based on top of the unix system developed by the Bell Laboratories in 1970s, so why not.
Campaign Series setup is a vast system, with a full set of game editors, a battle generator, a campaign generator, what not, on top of the actual scenario based core game there.
In our case, ”the source code” is several applications, it is quite a handful, we've got our hands full for quite some time still. But we’ve come a long way, too.
Here's a partial list of game aspects that have been completely reworked so far:
Instead of a separate code base for each game (the approach Talonsoft took), we have now a clean, streamlined, configurable CS Game Engine, both for Modern and WW2.
For the user interface we’ve added several new zoom options and have redone all the graphics while at it. Support to 4K monitors etc. Still work to be completed there, too.
No more hardcoding of parameters. The new game engine runs on top of a new ”Adaptive AI” database. Eras and nations can now be configured so each scenario at different era behaves fundamental to the battle portrayed. Scenario designer can even further tweak these default Adaptive AI values for the specific scenario, if needed.
A new Lua based CS Event Engine in place, providing event based triggers and rules for the game engine to take into account during game play. CS Event Engine can also be used to interact and alter the scenario specific Adaptive AI parameters, as part of how it interacts with units and formations in play in each scenario.
CS Event Engine also makes the AI far more unpredictable opponent. Scenarios can now be scripted, in a dynamic instead of static manner. For an example, a certain AI formation might have an initial order to attack "X" (or randomly, to choose between "X", "Y" or "Z"), but if "A" takes place or "B" rule holds true, it would instead go and reinforce another area.
It is all pretty neat, I really need to write a few blog posts about the CSEE.
It's not done yet, there's still a lot we want to add.
CS Game Engine and Event Engine both are still being developed, with vs-AI game play in particular the major effort under development for CS Vietnam that is in-the-works, per the survey we did as how you guys want to play the game and how you priorise things.
Finally, as everything is now game engine based, we will provide the latest CS Game Engine as a free update to previous games, so they are not left behind either.
A long post, sorry about that, but again, hopefully offers some insight to game development as it goes.