DEV STATUS UPDATE Q3/20
OK - I don't even know where to begin with this without writing a massive blog. So I'm just going to try to keep it short and simple.
As you all know, the Battlecruiser and Universal Combat games spawned from them are a labor of love and which I have worked on for almost three decades now. With various games in the series being derived from a previous game version while using engines and features, over the years code bloat (if it ain't broke, don't touch it!) accumulated to an unmanageable degree. Over the years, I replaced or upgraded most of the legacy code - to the extent that as of this writing, very little of the original Battlecruiser game code exists. In fact, all of the original legacy code written in TASM and MASM have since been replaced with C/C++ versions. This has been an on-going process each time I dare look at this code base with more than a passing glance.
Here comes the fun part.
So few years back when I decided to do another game in the BC/UC series, I knew that starting from scratch simply wasn't in the cards because, financials aside, it would be an insurmountable task for the most part. That aside from the fact that I was overseeing the development of Alganon (which my team had taken over) as well as my next big - and what I believe to be my final - game Line Of Defense.
The decision to branch UCCE 2.0 to create a 3.0 derivative was so that I didn't have to start from scratch. I felt that the best path forward was to use the underlying suite of game engines, while updating those with improvements, adding new content etc. And so with that plan I released that first 3.0 version in June 2015. Since that time, while cleaning up and removing legacy code, I was also improving on the engines which would later complete this version.
As this effort continued, the act of removing deprecated code - while breaking most everything that worked before - forced me to not only branch (see Public Test Builds) the code, but I also had to freeze certain updates in order to complete other critical work. For one thing, the graphics engine was still based on DirectX9 (which Microsoft deprecated years ago in tool builds). So in order to continue working on 3.0 in a WIN 10 world, I had to not only maintain a separate set of DX9 dev tools (DLLs etc), but I also had to fight back the urge to upgrade from Visual Studio 2010 on which the most recent versions were based. Trust me, developing a videogame in a VM environment isn't fun. Like at all.
One fateful morning last year after a particularly nightmarish debugging session, I made the decision to not only migrate to DX10, but also to move my platform dev for the game to VS 2017 (I recently moved to VS 2019). And just like that, the planned branch of 3.00.20.05 (which was to be released in March 2019) came to a grinding halt.
While all that was going on, a different dev fiasco which was playing out over at the LoD dev cabal, came to a head and created a massive distraction.
As time went on and my focus shifted between UCCE 3.0, LoD, Alganon, and life itself, I found myself spending less time on 3.0 because of the sheer amount of work that needed to be done - and which was the only way forward. Sure I could have branched that DX10 build, gone back to the last VM aware build and continued. But I didn't do that because I had a specific plan in mind - and I was determined to complete it as there was NO incentive or reason to go back. Why? Because I had vowed to never - ever - make another game as complex as the BC/UC series again. I'm approaching 60 and I would very much like to enjoy my looming retirement on smaller things after spending half a lifetime in game dev.
Also, a BIG part of this grand 3.0 update plan was to one day bring back multiplayer (as DLC) as seen in the dev Trello board. And in order to do that, I would have to go back in and enable, then backport the last multiplayer kernel last seen in...checks notes...UCCE released in 2007 (!). Funny thing is that the multiplayer kernel/engine in the All Aspect Warfare and Angle Of Attack games were based on improved versions of that multiplayer kernel/engine.
So, uhm, yeah.
At the end of the day, when I finally finish the 3.0 suite of engines, and then start adding in the new content (models, terrain etc) which have been piling up after being created, it would be a massive benefit to the game in terms of visuals, performance, tech updates etc. And while the planned multiplayer is still going to be session based (but with a persistent server version like AAW/AOA games) and not an MMO, even at 64 players, I believe the effort would have been well worth it.
In conclusion, as I've said before, I simply don't yet have any hard dates for releasing a new 3.0x build. But it will be soon-ish. For those of you who have bought my games since the original 1996 Battlecruiser and followed my career, the mantra "It's ready when it's right. And right now it ain't ready" remains as it was back in the day.
Thanks for being patient. And don't worry, it's going to be worth the wait.
As you all know, the Battlecruiser and Universal Combat games spawned from them are a labor of love and which I have worked on for almost three decades now. With various games in the series being derived from a previous game version while using engines and features, over the years code bloat (if it ain't broke, don't touch it!) accumulated to an unmanageable degree. Over the years, I replaced or upgraded most of the legacy code - to the extent that as of this writing, very little of the original Battlecruiser game code exists. In fact, all of the original legacy code written in TASM and MASM have since been replaced with C/C++ versions. This has been an on-going process each time I dare look at this code base with more than a passing glance.
Here comes the fun part.
So few years back when I decided to do another game in the BC/UC series, I knew that starting from scratch simply wasn't in the cards because, financials aside, it would be an insurmountable task for the most part. That aside from the fact that I was overseeing the development of Alganon (which my team had taken over) as well as my next big - and what I believe to be my final - game Line Of Defense.
The decision to branch UCCE 2.0 to create a 3.0 derivative was so that I didn't have to start from scratch. I felt that the best path forward was to use the underlying suite of game engines, while updating those with improvements, adding new content etc. And so with that plan I released that first 3.0 version in June 2015. Since that time, while cleaning up and removing legacy code, I was also improving on the engines which would later complete this version.
As this effort continued, the act of removing deprecated code - while breaking most everything that worked before - forced me to not only branch (see Public Test Builds) the code, but I also had to freeze certain updates in order to complete other critical work. For one thing, the graphics engine was still based on DirectX9 (which Microsoft deprecated years ago in tool builds). So in order to continue working on 3.0 in a WIN 10 world, I had to not only maintain a separate set of DX9 dev tools (DLLs etc), but I also had to fight back the urge to upgrade from Visual Studio 2010 on which the most recent versions were based. Trust me, developing a videogame in a VM environment isn't fun. Like at all.
One fateful morning last year after a particularly nightmarish debugging session, I made the decision to not only migrate to DX10, but also to move my platform dev for the game to VS 2017 (I recently moved to VS 2019). And just like that, the planned branch of 3.00.20.05 (which was to be released in March 2019) came to a grinding halt.
While all that was going on, a different dev fiasco which was playing out over at the LoD dev cabal, came to a head and created a massive distraction.
As time went on and my focus shifted between UCCE 3.0, LoD, Alganon, and life itself, I found myself spending less time on 3.0 because of the sheer amount of work that needed to be done - and which was the only way forward. Sure I could have branched that DX10 build, gone back to the last VM aware build and continued. But I didn't do that because I had a specific plan in mind - and I was determined to complete it as there was NO incentive or reason to go back. Why? Because I had vowed to never - ever - make another game as complex as the BC/UC series again. I'm approaching 60 and I would very much like to enjoy my looming retirement on smaller things after spending half a lifetime in game dev.
Also, a BIG part of this grand 3.0 update plan was to one day bring back multiplayer (as DLC) as seen in the dev Trello board. And in order to do that, I would have to go back in and enable, then backport the last multiplayer kernel last seen in...checks notes...UCCE released in 2007 (!). Funny thing is that the multiplayer kernel/engine in the All Aspect Warfare and Angle Of Attack games were based on improved versions of that multiplayer kernel/engine.
So, uhm, yeah.
At the end of the day, when I finally finish the 3.0 suite of engines, and then start adding in the new content (models, terrain etc) which have been piling up after being created, it would be a massive benefit to the game in terms of visuals, performance, tech updates etc. And while the planned multiplayer is still going to be session based (but with a persistent server version like AAW/AOA games) and not an MMO, even at 64 players, I believe the effort would have been well worth it.
In conclusion, as I've said before, I simply don't yet have any hard dates for releasing a new 3.0x build. But it will be soon-ish. For those of you who have bought my games since the original 1996 Battlecruiser and followed my career, the mantra "It's ready when it's right. And right now it ain't ready" remains as it was back in the day.
Thanks for being patient. And don't worry, it's going to be worth the wait.