What's going on?
Why the Media has Stopped & What We Do
To put it bluntly, we don't have any more media for you, and that sounds bad, but I can explain pretty well why that is. As I alluded to in the comments, development on this mod comes in spurts due to the activities of the modders involved. The core team, Jayden, AHadley, and myself are Australian, British, and American respectively. As such even the most normal and mundane of schedules on all our parts leave little room where we are all free. Add to that other projects and you can see how messy it can get. Now, I need you to understand that we are not doing nothing.
Jayden is our main artist and is responsible for much of the visuals you see on this page. He is also the texture artist for the Indie project Bionite: Origins, a student, has bad internet where he is, and from what I hear is head of his usual domicile. With his involvement in Bionite almost over, but personal issues and school work mounting, he has been far too busy to work on the mod. As I always tell him: family first, school and work second (including Bionite), modding 3rd.
AHadley's main responsibility is in fleshing out the story, establishing the characters, etc. He has recently been working on compiling all known BZ1 and BZ2 history, canon and not, and found some interesting things either forgotten for 10 years or never known by the community at large.
I, Nielk1, tend to stretch myself a little thin between a great many projects. It's a weakness of mine, but in this case, it has not yet become an issue. While AHadley works on the finer points of the story, I have developed the overall universe. Now, you might be saying "but this mod is an extension of what has already been done", and there you would be right, however the stock game and its mods leave tons of unanswered questions and we are working to solve as many as we can. I am also the resident programmer on the team and will be responsible for the mission scripts and utilities we use. With my primary interests being the story and the mechanics, I have been working on the story and race design.
Project Flow
Seeing as we are separated by both timezones and oceans, we do all our work through the internet. At this stage we utilize web software such as Google Docs for collaborative document writing in relation to the story and tech trees. While most mods for BZ2 are developed inefficiently with tech trees being created along side mission scripts and assets changing and breaking and so on, we are taking a different tact.
First, we established the universe and core story elements, the grand level "must happen" events. From there, we created the race design, how they would function, checking all the way to ensure the mission script would be capable of supporting the vast divergences from stock behavior we were making.
Then began the asset work, were Jayden created tile-sets and test maps, models, basic ODFs, and props, etc. These assets can be considered as contained units, specifically: Environments and Races and can be created without fear of major changes due to mission script upsets. During this time, we are also working on the finer points of the story, developing a cast of characters, their personality types, their history, their equipment. We are matching our characters up with personality types such as INTJ to ensure their interactions are realistic and don't take the player out of the story. This is the stage we are on now.
The next stage is to begin the mission scripts (that being the programming) and the maps along side final tweaks to the races. The first scripting to be created will be that which governs universally the operation of the races. At this point, balance testing will begin with real competitive games being played before the first mission is finished. In this way, by the time we are working to balance the missions the units and structures that are part of the acting races should no longer change, making mission development easy.
Risks and Issues and How?
AI Plans
The AI plans in BZ2 are pretty hard to use. While vast strides have been making in improving their usability and ability, basic limitations still exist. Classical AIPs exist for several states, such as early game, late game, and siege, and for every race combination (ii, if, fi, ff in stock). This would explode quite horrifically with multiple races added at once, however there are some solutions. Generic provide types in units and structures can vastly improve the conditionals in AIPs to the point that the plan only specify the race it controls rather than the one it targets (as what is built is stated directly by Object Definition Name). There is however still a massive issue with this. Attacker plans, at least last time I checked, must explicitly specify their target objects and cannot target based on provides. These are the plans that list what units to send out against other specific units.
We have several methods to get around this, but none are pretty. The first is to specify attack matches for every single race's units. Since the targeting uses base-names, only the base names must be used, however some Recycler Variants will use custom base-names so as to avoid conflicts (such as to avoid confusion between a heavy tank and a normal tank, where the heavy tank was newly added by the variant but the normal tank is also still available). In these cases, the un-targeted units would only receive resistance from attackers left over from other jobs or defensive units. The other two options are to replace the attack portion of the AIP, or the entire AIP, with mission script; or more specifically a custom type of script (not stock AIPs) run via the mission rather than the game engine. There is already a system in place in the 1.3 patch called the "Idle Dispatcher" which selects Idle units and sends them on the attack. A modified form of this in the mission script that reads a custom attack matching file might be the best solution.
Custom Information Between Client & Server
While the base game offers a quite robust set of tools, including custom interface elements of limited capacity, the interface between client and server is the biggest issue. The game works in a lock-step fashion, where all games must be doing the same thing at the same time less a "resync" occur. (Many RTS games use the same system, however, there is no "resync" in those cases and instead the game ends in error. BZ2 requires "resyncs" because of the inherent issues in FPS or direct player movement.) Because of this, certain actions, such as clicking buttons in an interface (or curiously using the 'I' key inspect feature) that are not translated across the network and can only be done on the local user are unusable.
We are looking into utilizing an extra data channel for information to solve this issue. While we can get around the issue by avoiding these functions, the interface for managing the more unusual races, as we have them designed, would be far too clunky to be fun or even reasonably usable. (We can trigger actions based on trigger items built from an invisible and invulnerable factory for example, giving us 100 "3 button press" no context actions, or 10 "2 button press" no context actions. By "no context" I mean that we are limited in methods of adding additional data such as targets, names, or numbers to these actions.) We are considering using an XAMPP based data queue. To best understand, we are considering dynamically creating a Jabber based chat-room for each game where the mission scripts share chunks of encoded information marked with the game turn that information becomes valid (when to act on it), an ascending message ID (based on a counter on each instance/client), and the client's unique ID (different for every joiner, different after rejoin). The combination of this information will create a unique sortable key for all messages ensuring that all clients may process them in the same exact order when their game turn is up. This will also allow for the data to be shared in game states for those joining the game after its start to have the information despite not having history of the 'chat log' while allowing other clients to throw out duplicate entries with the same key.
Why is it Just You Three?
Well, it is and it isn't. Others have contributed content, but none at the levels we would like. This project started several times and each time failed due to an overly high amount of community inclusion. Often, members without modding talent but still wanting to contribute (or worse, those who did have it and felt superior to the rest), would attempt to direct the story so strongly that it would become "their mod". In such cases, common sense decisions became nearly impossible due to their the irrational ignorant state of those involved. I am not putting anyone down with this statement, it is simply that many were ignorant as to the story of the stock game let alone the first CP which we build upon (which is no surprise, AHadley keeps digging up bits of 'lore' no one has known for years if ever). Often, the work done to merge all the disparate and nigh incompatible stories into one cohesive line was decried as making it "Story Developer A's Mod" or "Story Developer B's Mod" despite the strong lack of any of their original content. It was in this state that the CP2 died for what was probably the last time. Instead, some of us continued to develop the story, integrating and removing and re-integrating the story elements put forth b the community including even time-travel. Specifically, time travel was removed, added back, replaced with quirks of relativity, and finally removed again for the sake of comprehension (as a minor change to the story removed the need for it entirely).
Most mod developers in the BZ2 community are either absorbed in their own mods, left the community, or died off. We have even had one instance with the developer of a mod, one that is part of the story base of the CP2, going on a rant after a misunderstanding and demanding no one use his assets or story nor maintain his mod for later versions despite prior blanket permission otherwise. It is for this reason that our first mission is our first, and not our second, as the assets involved in what would have been the first are sourced from this mod. This also made us change some minor encounters in the early story to exclude this race and ultimately made us shift the entire timeline of the mod into the future. In the end, it made for a better story anyway, but it has trouble standing without the prior mod's story as the starting point for ours. (Hence it remains in the form of an intro.)
If anyone out there would like to contribute, please contact us, but be aware that we are pretty far from testing anything and currently development is sporadic. We are somewhat dubious of new members because of the issues that plagued prior attempts at this project and for this reason have created the distinction of the "core team" (Jayden, AHadley, and myself (Nielk1)) from any additional members.
Hopefully this will dispel any concerns you have had about this project and help you understand the nature of its development. We hope to have more to show you sometime but our latest area of great concentration is black print on white paper, and we want to save that for the actual enjoyment of play.
