devtrackers.gg
User-generated content (UGC) is one of several pillars we view as essential to creating the next great RTS game. We hope the breadth of this topic inspires discussion from a wide range of perspectives. Please feel free to offer your thoughts and opinions on any or all of the discussion areas below. While things like YouTube tutorials and community-organized events could be considered UGC, for the purposes of this discussion we’re focusing on player-created maps, mods, and custom games.
Legacy & Community
Desert Strike, Aeon of Strife, Defense of the Ancients, Cat vs. Mouse, Diplomacy, Micro/Macro, Mini-Game Party, Mafia, Castle Fight, Phantom, Bounds, Risk II, Bunker Wars, Nexus Wars, Golems, 4v4 Micro Jungle, Hamsters vs. Space Vacuums . . . we could go on and on. Players have now been creating and enjoying custom RTS game experiences across four different decades!
The legacy of UGC in RTS games is beyond comparison. Entire game genres, such as MOBAs and Tower Defense, trace their origins to custom games. Many of us at Frost Giant have backgrounds as modders or mappers in Blizzard games, and like many of you, we have fond memories of playing and creating custom maps and mods.
UGC plays an important role in attracting and entertaining players looking for a change of pace, as well as creatives who enjoy building new experiences. UGC also contributes to competitive play by often contributing the latest and greatest competitive maps, something we discussed in more detail in Competitive Map Design and Our Thoughts on Competitive Map Design. Across these different spheres of play, UGC fills a critical role by providing a sustained source of new and exciting content, created by and for the game’s community. Passionate UGC communities like SC2Mapster.com, Hiveworkshop.com, and Staredit.net have remained strong years after their respective games have ceased development.
Editor - Overview
The significance of a healthy UGC community can’t be understated, which is why ensuring our game has a powerful and accessible editor is one of our top development priorities.
Editor strengths and weaknesses have varied across different RTS titles. The Galaxy Editor released with StarCraft II was extremely powerful, allowing for complete overhauls of the game, but in some ways was less accessible than older RTS editors. In StarCraft: Brood War’s case, the UGC community has long used ScmDraft 2, a third-party editor that was endorsed by Blizzard during the release of StarCraft: Remastered.
We want our editor to be a polished and accessible tool that empowers as many people as possible to be a part of building a future filled with fun new game experiences.
Our decision to build our upcoming RTS in Unreal Engine 5 naturally raised questions within the UGC community about what modding in our game might look like. We’ll tackle a few of those questions here, as well as some we expect might arise based on our answers.
Q: Will modders use Unreal to create content for our game?
A: We considered a lot of options for how to approach mod support using UE5, and have decided on building an in-game editor that doesn’t require users to download Unreal. There may be opportunities for very advanced modders to use Unreal to do things that might not otherwise be possible via the editor, but our aim is for our editor to be more than capable of creating the vast majority of RTS UGC you see today.
RTS modding has a legacy of accessibility that we aim to continue. We can’t wait for our players to go into editor mode, start drawing terrain, place their first units and doodads, and create the triggers that led many of us down the path towards game development.
Q: What will the editor support?
A: Our intention is to support most of the functionality available in existing RTS editors. It’ll feature three core modules: Terrain, Scripting, and Data. These will work much as you might expect, with improvements based on everything we’ve learned over the years.
Q: Will the editor be available at launch?
A: We are still early in development, so this is not something we can answer definitively, but work on the editor is currently underway and we plan for our own designers to use the editor to build the majority of our maps and gameplay content. We hope that this will help ensure the tool we have at the end of our development process is robust and ready for public use. Our designers will also be doing some work in Unreal directly, but this will be more the exception than the rule.
Q: How will map sharing/publishing/downloading work?
A: We are still discussing the right approach for us as a game and a team. The two primary options are publishing a map to a live service, as in StarCraft II, or sharing maps directly from player to player via lobbies, as in StarCraft: Brood War or Warcraft III. Both systems have advantages and disadvantages, and we haven’t decided on one or the other yet. This is one area in particular where we want to hear from you. To be clear, regardless of where our players download maps, we plan to present custom maps as a list of available lobbies to ensure that any map can gain visibility. We touch on this more below.
Q: Will we support custom campaigns?
A: This is also difficult to confirm at this stage of development, but we believe custom campaigns are incredibly important, and many of the people on our team put in significant effort to provide this functionality in StarCraft II’s 10th Anniversary update. Hopefully, by planning for them early in development, it will be easier to have this feature ready for public use in our new game.
Q: Will we be able to import custom assets?
A: We fully intend to support this, but how exactly is still unclear.
Whew! We still don’t have all the answers, but that should give you a sense of what we’re thinking.
We’d now like to share more specifics about our vision for the editor. This topic is a great opportunity for us to delve into more detail about one part of our development plans, as unlike some of the more common questions we get (“What’s the setting going to be!?”), we don’t need to spoil anything we’re saving for future game announcements.
Please bear in mind that none of this is completely set in stone, and things will likely change over the course of development. We say this for two reasons: to set appropriate expectations and to emphasize that feedback on this topic is incredibly valuable to us, as we’re constantly reevaluating our approach.
Editor - Terrain Module
We’re approaching the terrain in a familiar way. You’ll be able to raise and lower cliff levels, paint textures, place doodads, adjust pathing, and define points and regions. The standard for terrain editing is well established and an overall good experience, so we don’t intend to make significant changes here. We would love to hear your thoughts on terrain editors, what you loved, what you didn't love, what you think can be improved, and how you would improve it.
Editor - Script Module
Our aim for scripting is to provide both accessibility and flexibility. We want less advanced users to easily understand what they are creating, but also provide the means for advanced users to be quick and efficient. To accomplish this, we’re creating a visual scripting language that highlights the flow of execution. You will set up “triggers” with events, conditions, and actions (including custom functions) – just as you may have experienced in other RTS editors. The main difference is information will be presented as a visual chain instead of a wall of text. In designing this visual scripting language, we’ve taken inspiration from Unreal’s Blueprint, Unity’s Bolt, MIT’s Scratch, Google’s Blockly, as well as StarCraft II and Warcraft III triggers.
Behind the scenes, this visual scripting will also be generating a text script language that advanced users may write directly in, if they so choose. We’ve deliberately designed the visual scripting language in a way we hope will enable us to show you the text script being generated. This is useful for many reasons, but perhaps most so because it makes script mergeable and allows multiple designers to work simultaneously.
We considered numerous potential languages for this script, including C#, TypeScript, JavaScript, Lua, and Rust, but in the end decided on AssemblyScript–“A TypeScript-like language for WebAssembly.” We chose this because we plan for whatever scripting language we use to compile down to WebAssembly, and AssemblyScript is built to do this very well. It has syntax similar to C++ and Java/TypeScript, which makes it easy for us to transition into as we develop the game.
What is WebAssembly? WebAssembly is a widely supported, standard platform-agnostic, low-level language. You won’t need to worry about this even as an advanced modder, but it’s essentially a language we’re using to help turn script and code into binary to be as efficient as possible. All of the script in our project eventually becomes WebAssembly. Many programming languages compile to WebAssembly, and our game can support all of them as a result. This is great because it allows third parties to create content development tools for our game, bypassing our own editor if desired. It also makes it easy for us to pivot away from AssemblyScript if we see a reason to do so during development.
Editor - Data Module
For the data module, we’d like to improve on what many of us experienced as modders in StarCraft II. We’d like to capture the accessibility of the Warcraft III data editor, along with the power and flexibility of the StarCraft II data editor, for those who need to tap into it.
Achieving this balance is tricky, but the approach we’re following is to tackle the three things in particular that made the StarCraft II data system challenging to work with, particularly when just getting started:
- The ability to copy/paste existing data.
- The volume of catalog types and understanding their relationships.
- The volume of fields in the property grid.
These three things combined make it difficult to understand what’s happening in the StarCraft II data editor. For example, the Marine “Unit” catalog entry alone has 198 fields (everything from hit points to occlusion height), and 73 other associated catalog entries for things like death models and sound effects, each of which have their own fields. This overwhelming amount of information can make it difficult to understand where to even start to make the changes you're after. Similarly, when you copy/paste a data entry, it’s difficult to know what’s going to happen to that entry’s relationship with the 73 other pieces of data. Will they also be duplicated? If you make a new Marine, is it going to create a copy of its Gauss Rifle data as well? Or will it just keep referencing the original data?
We’re planning to help make data more understandable and manageable. One of the ways we’re doing this is by creating a simplified interface for data, where only fields flagged as important will show up by default. Data like how much health a unit has, how fast it moves, and what abilities it has will be marked as important. When you go to edit a unit’s data in the editor, you’ll see these primary fields, and others will be hidden behind an advanced editing mode that more experienced modders will be more comfortable with.
We’re also working to make it as easy as possible for users to group and modify existing data. This will make cloning existing data to create new modified versions of it easier, as well as allow us to create better data visualization tools than those available in other RTS editors. We will share more details about data grouping as we iterate on various solutions.
Just like with StarCraft II, all of the data will also be available in a text format. Unlike StarCraft II, we have decided to go with JSON as our data format instead of XML.
Lobby & Game Browsing
But what good is a great editor if people can’t find and play the UGC you’ve spent countless hours creating? One of the most important lessons we learned about UGC from StarCraft II is the importance of the open lobby list. When StarCraft II first released, there wasn’t a way to see available lobbies for different custom games. Instead, players were given a list of the games themselves, which consolidated all associated lobbies behind a single title. When a player clicked to join a game, the system selected a lobby and placed the player into it. On top of that, the hosted game list was buried in submenus under the custom game section, so players had to actively look for it. When players first entered the custom game section, the first thing they saw was the most popular games on the Arcade service.
All together, this system created a “rich get richer” UGC environment. The more popular the game, the more visibility it had and the more popular it became. Eventually, some games had so much momentum they stifled the visibility of everything else, making it virtually impossible for new content to gain traction.
To amend this, the team brought back the open lobby list players were familiar with from StarCraft: Brood War, Warcraft III, and most other games from that era. The open lobby list was also made front and center when entering the custom games section. We think these changes significantly improved StarCraft II’s UGC ecosystem overall.
For this reason, we plan to have an open lobby list easily accessed by UGC players in our game. But what other changes would you make to how players browse for lobbies and custom games? What should we keep from previous systems and what needs improving?
Custom Art
Our commitment to UGC has also steered other development decisions, such as the way we’re creating art for our game. This is one of the main reasons we’re using Blender as our primary 3D content creation software. As a free tool, Blender is an accessible way for UGC developers to create and implement art into their content. We’re also planning on distributing other tools we’ve developed to allow UGC creators to take advantage of the same art pipeline we’re using to create the core game. This is a significant undertaking, but we’ve already made some great progress. Do you have experience creating custom art for mod content? What aspects of that user experience need improving?
Monetization & Rewards
Monetization of UGC is a controversial, but important topic. Many UGC creators invest thousands of hours in their projects, typically without any hopes of compensation. If they’re lucky, they might leverage the experience to get hired at a game company, or successfully spin off their project into an independent game. We’d like to foster an ecosystem where the most successful content is able to generate some level of income for their developers, without compromising the traditionally accessible nature of RTS UGC. We’d love to hear both player and creator perspectives on how monetization and rewards for UGC developers could be implemented in a healthy way.
Tools & Statistics for Creators
If we opt for a distribution model where creators publish maps to our game service to be downloaded from a dedicated interface, similar to StarCraft II, we’ll have more opportunities to provide tools and statistics for UGC creators surrounding player engagement with their content. What features and information about how players engage with your maps/mods would be particularly useful to you? What features to help market your maps/mods would be useful to you? How would you envision a map/mod “homepage” to look and function?
Final Thoughts
We are committed to fostering a healthy UGC environment in our upcoming game. We know this will create a stronger overall ecosystem surrounding our game, and that it’s important to future players. We anticipate many of you have thoughts, ideas, and experiences to share associated with what we’ve discussed above and what we may have missed, so we won’t ask anymore specific questions this time around.
As always, thank you for participating in our journey!
-The Frost Giant Team
External link →