DTA: Covert Revolt and C&C World-Altering Editor: A retrospective blog - Rampastring

With this year drawing to a close, I feel it's a good time to reflect on it. This year has been somewhat special. I released two gigantic, multi-year modding projects this year:

1) Covert Revolt campaign for DTA

2) C&C World-Altering Editor (WAE)

In case you are not familiar with them, the links above lead to the trailer for Covert Revolt and the GitHub homepage for the World-Altering Editor. As for Dawn of the Tiberium Age (DTA), it is a stand-alone mod for Tiberian Sun that combines and enhances Tiberian Dawn and Red Alert 1 under a single game.

This post will open the development process behind these two projects, especially Covert Revolt. How they came to be, and what lessons I learned: what worked well during their development processes, and what could have been done better. It is going to be a very long read, but I hope it will be interesting, and it can also be helpful for other modders and indie RTS game developers.

Note: This article will contain spoilers for Covert Revolt. If you haven't yet experienced the campaign and want to do so without spoilers, then you'll probably want to avoid reading this for now.

---

Around 2019 to 2020, I had, for some years, felt a desire to retire from active C&C modding. Modding wasn't giving me many new interesting experiences anymore. Typical of mod co-leaders, I had been involved in various tasks: programming, mission design, game design, balance tweaking, AI, building a community etc. I had fun playing the game, but managing it all was a time sink. Often it felt rewarding, but there were also many moments when it felt the opposite.

However, there was one thing I still felt I wanted to explore: creating a big singleplayer campaign. I had made a dozen stand-alone missions, a dozen co-op missions, and two smaller campaigns for DTA. In other words, I had a decent amount of mission design experience. But none of these rivaled a big, traditional RTS campaign. I wanted to challenge myself and see whether my experience was enough for creating a high-quality, large-scale singleplayer experience. But I knew that the workload was huge and so I was unsure whether I should really commit to it.

In June 2020, EA released the C&C Remastered Collection. The release was successful, sold well, and together with COVID-19 which forced people to stay at home, it revitalized the classic C&C community. I also had lots of fun playing through Red Alert 1 and Tiberian Dawn again. Following the success, like thousands of other fans, I was naively anticipating more official activity for C&C, including remasters. This meant that now was the best time to start working on a campaign if I ever created one.

---

Motivation for new map editor - WAE

I began by writing up notes for a story for the new campaign, as well as a general campaign plan/structure. My initial plan had around 15-20 missions split into three routes.

I then created the first mission of the campaign - CR#01 - as a concept in July 2020. I already knew that the old FinalSun map editor was inefficient, but while working on this mission, it really hit me that creating such a big campaign with FinalSun was not going to be possible with any reasonable amount of time. Having to manually place every single object, every single tree, having to manually scroll long lists with no search functionality, constantly open dropdowns to see options, use an early-2000s scripting UI with scripting elements separated into tabs... there was so incredibly much that could be done faster with a better editor. Creating even small maps with FinalSun took hours.

After concluding that I wouldn't be able to create my dream campaign with FinalSun, I let the whole campaign idea rest. Only for a single month, however.

As September came, EA released the source code for the Remastered Collection's new map editor. Maybe that could be a good base for creating a new Tiberian Sun map editor? I immediately checked it out. Found some dumb functionality (like pixel-based graphics that were designed for 4K and so were way too big for the 1080p monitor that I still used at the time) and fixed it, and otherwise hacked around with the application.

It quickly became clear that a lot of Petroglyph's code for the map editor was terrible. I am sure Petroglyph's senior programmers are better than this, so I guess they had delegated the editor to trainees or somesuch.

Meh. I published the improvements I made to the code on GitHub and abandoned the remasters' map editor after just a few days. At least my work didn't go to waste, as Nyerguds later picked up my source code and forked it for his much-improved Mobius Map Editor - be sure to check it out if you ever do mapping for TD or RA1.

If I wanted to have a good map editor for Tiberian Sun, I'd need to create it on my own. From scratch.

---

I have to mention that when I started working on WAE, there had been other efforts for a more modern editor. FA2sp was a project for enhancing FinalAlert 2 using DLL injection technology. They made impressive improvements, but progress was slow due to the developers having to reverse-engineer the closed-source FA2 code. It also wasn't compatible with FinalSun, the Tiberian Sun variant of FA2. There was a separate FinalSun version called FSP, but it constantly lagged the FA2 version in development. I figured it's better to start a new map editor project instead of contributing to these DLL injection projects. That way we wouldn't need to do time-consuming reverse-engineering, we would have a single unified codebase, and we could make use of more modern technologies than when hacking a 20-year-old application.

There had also been some people hyping up their own map editor projects on C&C modding forums a few years earlier. None of them ever released anything publicly.

---

First steps

A single day after abandoning the remaster's map editor, I made my first commits for WAE, containing a .gitignore and basic classes. A couple of weeks later, I added support for loading a map, and rendering terrain using DirectX11 through MonoGame.

Above is the first screenshot of the application that eventually became WAE. This started an almost 4-year long journey.

---

Development process

Below is a timeline of development of WAE and Covert Revolt, with major milestones highlighted. You can click on it to open it as larger.

Now, because you have access to the above image, I won't be explaining the multi-year development process step-by-step.

This blog post is starting to be pretty lengthy already, so next we'll jump directly into lessons learned.

---

Lessons: what went well, what could have gone better? How can I replicate the success of Covert Revolt?

These lessons mostly concern Covert Revolt; WAE's development process was more straightforward as the "objective" of a map editor project is much simpler than Covert Revolt's objective as a huge and innovative singleplayer campaign. But some of them are also related to WAE.

I won't focus much on the creative aspects here, but rather the process of making a large-scale campaign. In other words, I won't tell you how to make a mission interesting. Instead, I'll try to tell you how to make 30 consistently high-quality missions in a reasonable timeframe, without getting burned out in the process.

1) Plan accordingly - at a high level

Before you embark on making a massive campaign, make sure you have an interesting plan for the campaign, containing elements like story, rough campaign progression, and mission concepts. Don't write down too many exact details, especially for later missions - you'll have time to design and tweak details as they get relevant. But you should have a decent high-level structure and interesting story planned. Changing it half-way is difficult.

With Covert Revolt I mostly succeeded in this. I made the original campaign plan in 2020, revisited it in early 2022, and tweaked it occassionally. But it stayed mostly consistent. Biggest change to my initial plan was that CR's original draft included about 20 missions instead of 31. I decided relatively early on - in autumn 2022, after creating like 5 missions - that the story that I want to tell needs additional missions to have good pacing, to avoid the feel that it'd be hastily jumping from one major event to another. This didn't result in re-designing the story or its elements, but just stretching out the existing story over a few more missions.

2) Make sure you have the right tools for the job

This point is more for game developers than regular modders, but also concerns modders who have programming abilities. As I stated earlier, Covert Revolt would have been impossible to create with FinalSun in a reasonable timeframe, unless I had made the maps much simpler and less detailed, which I didn't want to do as I was aiming for maximum quality.

If your current tools are inefficient, don't just start a massive project with them. Instead, create better tools first, or better yet, improve the tools as you work on the project. You'll save massive amounts of time in the long run. The thought of the workload can be scary, but think of it as an investment.

While WAE took me hundreds of hours to create, in skilled hands it is several times more efficient to work with than FinalSun, at least with CR's relatively natural environments, so I'm pretty sure it was beneficial considering total hours spent. As a bonus, it made the mapping work far more pleasant and less tedious - which is a great thing for mental health.

3) If you have a team, make sure your programmers also use the tools they develop as much as possible

This is related to the last point, but it sort of goes the other way. WAE and Covert Revolt development largely went hand-in-hand, at least until the latter half of 2023, when WAE shifted to focus more on TS and RA2. Whenever I needed WAE to have a specific feature while creating Covert Revolt missions or I thought of something that could speed up my work, I implemented it. This is largely why WAE is so efficient: it was created by a mapper, for mappers.

Many projects have too tight separation of roles between contributors, which leads into failures on which features to prioritize. I've seen this many times even within the small C&C modding community and continue seeing it often, for example programmers who believe a map editor should have feature X when no mappers are actually requesting such a workflow. Having programmers who actively use the tools they work on is very important - they can implement features and solve issues quickly as they bump into them by themselves and know what to prioritize for the biggest impact on productivity.

4) Do staggered testing

This one was more "accidental", but in retrospect, a great way to do testing. When originally planning Covert Revolt, I expected it to get only a single round of playtesting, or "occasional testing" by DTA staff members - that's how we had operated with earlier content.

But Covert Revolt was taking so long to create and was so large in scale that, mid-way in the development process (after Route A was complete), I felt I needed more testers than the core DTA staff had. This led me into making a public announcement call for testers in different C&C fandom Discord servers. Roughly 10 people contacted me, of whom I accepted 8 to become additional CR testers.

This gave the first half of the campaign two testing passes: one by the DTA staff, and another by the new tester group later on. This allowed me to improve on the first iteration of the missions, and get the new iterations tested as well. Typically, people only mention the most glaring issues on the first round of testing, and focus more on details on the second round (when there's no glaring issues to report anymore), so by doing two rounds of testing, you get a good amount of feedback and get to fix even the slightest details or bugs, leading to a polished experience. In addition, you get useful feedback on the quality and fun-factor of your campaign in its state after the first round of polish.

Normally you only get one testing pass, as in a hobby project like DTA, people do what they find fun in doing. Playing a mission for the first time is fun and interesting (at least if your campaign is fun and interesting). Repeatedly testing it after each pass of fixes and changes quickly gets grindy and boring, so most voluntary testers simply don't do that: they only play your mission once. And even when they happen to play it twice, testers' previous experience from beating an earlier version of a mission will affect how they play on the second run. So, especially if you rely on non-paid testers, it might be a good idea to have a "first testing group" and a "second testing group".

The usefulness of multiple testing passes is further reinforced by that your ability to absorb feedback is limited. In other words, you can have too many testers doing testing at once. You can only keep so much stuff in mind and only have so many hours you can spend on improving a mission after people have tested it. If, instead of two smaller, phased testing groups, you only have one big group giving feedback, the amount of feedback you get at once might be overwhelming to the point you can lose focus on it. By splitting the feedback into two phases, you get the feedback in more suitable portions that makes it easier to keep track of what needs to be changed.

Now, here's a counterpoint: the second half of Covert Revolt (B and C routes) didn't get two testing rounds by separate groups, but they also got multiple passes to a more limited degree, simply because we had a lot of testers. Some played the missions right after announcement and others played them a few days later, which allowed me to adjust the missions after initial feedback for a more polished experience for the later testers. In addition, the later missions generally had fewer major issues to report on, because I grew more experienced as a mapper over time and was able to design and script the missions better right from the first iteration. Meaning, with a sufficiently high number of testers and confidence in your work, having tester groups might not be necessary. But I think it's still beneficial, especially due to the "too much feedback" effect I mentioned in the previous paragraph - I occasionally got "too much" feedback in a short timeframe during the development of routes B and C.

5) Organize your feedback channels

This one might feel obvious, but I've seen many projects do it wrong. Basically, I've been in some projects that only have "global" feedback channel for all missions. That's not the way to go about it. Your testers will give you feedback on several missions in the same channel, making it hard to keep track of and find the feedback for each individual mission when you need it. You want one channel per mission.

In Covert Revolt, I set up a Discord forum for testing, and created one topic for each mission, and aggressively monitored that people also mainly post to the topics. If people wrote mission-related feedback to other channels than the mission's own topic, I directed them to write to the topic instead. This way, feedback for each mission was contained in one place, making it easy to return to a mission and improve it based on feedback even months after the feedback was first given. In addition, because you can't open a topic accidentally, this avoided testers getting spoiled from the feedback given by other testers. Avoiding spoilers even for testers was especially important in a story-driven campaign like Covert Revolt.

6) Give yourself enough time

When we released the Covert Revolt Announcement Trailer in August 2022, it said "Coming in 2023". As you know, that didn't really happen.

When I first designed the campaign, it was meant to be about 20 missions long. When we released the trailer, I had 5 missions ready. I was creating about one mission in a month. Meaning it was theoretically doable to make 16 missions before the end of 2023 and get the campaign released.

However, even with the original plan, this timeline was overly positive. You should not assume equal process efficiency throughout. Creating missions can be stressful work at times, and sometimes you might need time to recover, even when it doesn't feel like that in the beginning. I took one longer break of 2-3 months and a couple shorter breaks from mapping during CR's development. These were necessary to avoid burning myself out. At the end of 2023, I had exactly 20 missions ready, with some of them having unaddressed feedback.

So, when thinking of a deadline or release date, be vague, and don't make it overly strict. Leave space for breaks, even when you don't anticipate needing one in the near future. Assigning too much time is better than assigning too little; it's usually just a positive for your players if you then manage to beat your original deadline, or you can use the extra time for extra polish. A tight deadline might be good for pushing yourself to work harder, but don't overdo it, and you don't necessarily need to announce it publicly.

Finally, take those breaks as needed, and remember to keep a good balance between work, your modding hobby, and the rest of life. You'll end up with worse quality in your campaign if you're overburdened; overstressed people make more mistakes.

7) Do multiple proofreading passes

This is kinda like the point with staggered testing, but for text. If your campaign relies on having a lot of text, like Covert Revolt does with its cutscenes and briefings leading the story, do multiple proofreading passes on it. Not only yourself, but with other people as well.

In Covert Revolt, I took feedback and addressed typos during campaign development. But to achieve maximal quality, we had a native American English speaker proofread all the text, from cutscenes to briefings to text triggers, and write suggestions on how to improve the flow of sentences. Nothing wrong with that - I went through the suggestions and applied most of them in the final two weeks before CR's release. That's it.

But that's where I made a mistake. Or many, actually. I made a number of typos and other mistakes while applying suggestions from our proofreader! More than I make usually - I was overstressed from the crunch of the last two weeks prior to release - see the last paragraph in 6), when overstressed I made more mistakes even in something as trivial as writing basic English text.

And we didn't do another proofreading pass. Meaning those typos made their way into the release. Nothing critical, as we easily patched those out within the next month, but this was an avoidable mistake that probably made the campaign less appealing for some players.

8) Asset reuse is helpful - but do it smartly

Gamers often hate asset reuse. Often for a good reason - it's seen as lazy. That's what it is when done poorly.

But Covert Revolt features asset reuse, and no one has complained about it. Actually, players have thought it's cool!

I recycled maps. Some of the battlefields in Route A can be also seen in Route B and/or Route C, for example. This saved me a lot of development time - without it, creating the campaign would have taken probably 4-5 months longer. But it's not only about laziness or lack of resources: the stories of the different routes take place in the same locations, giving the asset reuse a logical reason.

Now, this could still hurt the campaign. Seeing the same map again can be cool, but it also gets old, especially if it's seen three times. How to keep reused maps fresh? The campaign is set in Karelia, a historical territory that belongs partially to Finland, partially to Russia. Like Finland, Karelia has 4 seasons. So, we can alter the appearance of the map based on the time when the mission takes place. When the map appears in Route A, it's a summer map. When it appears in Route B, it might be an autumn map. When it appears in Route C, it's a snow map. This keeps the maps looking fresh in each route while also keeping the time-saving benefits of map reuse.

To achieve efficient map reuse, I wrote custom C# scripts for WAE - see point 2) about effective tools - that convert a map from one season to another. Summer to snow, snow to summer, or summer to autumn - most of it could be automatized, and what couldn't, was quickly fixable.

Of course, along with visuals, the maps in the different routes feature different scripting due to different situations in the game world. But the layout and most terrain details could be reused.

9) Manage expectations

We didn't have an issue with this in Covert Revolt, so this is a point for WAE. Despite the work gone into WAE and all its efficient tools, many people in the Red Alert 2 mapping community still use FinalAlert 2. Even some Tiberian Sun mappers were strictly against WAE in the beginning. It can feel disappointing, but don't let it demotivate you if you know you can achieve a superior user experience.

I believe the reluctancy to adopt WAE is mainly due to three factors. First off, some people will just stick with older tools, no matter what you do and how much you improve your tools. They might be used to some very specific gimmick, whether functional or even visual, that they don't want to give up. It's probably best to ignore this group of people as you're unlikely to get much constructive feedback from them.

Secondly, because the old FS/FA2 editors are old, some mods have added custom hacks and features into them that WAE might not be compatible with.

Third, some people adopted WAE "too early", ran into bugs, went back to using FA2, and haven't given WAE another chance.

I don't think much can be done about the first one, unless maybe if you get some high-profile community members to accept and spread the word about your tool. The second one can be solved with cooperation with the mod's authors, but it might not always be worth it since some of the custom hacks can be difficult to port over. The third one is most interesting. Maybe stronger reinforcing of WAE being in beta, accepting feedback, and not "final" could have helped - telling people that the bugs will be fixed due time. But on the other hand, I've already done active bugfixing updates. And if the "beta" status is reinforced, it's possible those people might just wait until the final version, which will end up having the same bugs without their feedback. So I'm unsure whether this was truly avoidable either, aside from point 3) - having an actually active RA2/YR mapper make their maps with WAE. I've had a few RA2/YR programmers contribute to WAE, but they haven't been very active mappers themselves.

---

Phew. That was almost 30,000 characters of text. Looks like campaigns aren't the only thing where I enjoy writing.

I got the idea for writing a retrospective when some people said they'd enjoy reading one about WAE. This was not only about WAE, but also about Covert Revolt. It would be hard for me to write a retrospective solely about WAE, since its development is very interwined with CR's development in my mind. It is hard to separate them. If there's interest, I could write more about WAE another day. Although I did also thoroughly explain WAE's origins here. Maybe there'd still be some room for content when focusing on particular features, or my painful journey of learning HLSL for implementing proper depth buffering.

Anyway. Hope you enjoyed the read (if anyone of you got this far), hopefully it's useful to some of you modders and RTS campaign developers, and if you do mapping, hope you've enjoyed WAE, and if you want a great classic C&C campaign to play, go give Covert Revolt a try if you haven't beaten it yet. If nothing else, I know at least I will utilize this knowledge in the future, and when that happens, I might be glad I typed it all here.

Until next time!