Articles | The Real-Time Strategy (2015)

The Real Time Strategy
A look at player psychology and balance versus perception

I am IskatuMesk. I demand nothing but the best of the best from my entertainment to deliver to my niche audience. For the last decade and a half I have devoted myself to not simply creating mods, but understanding the inner mechanics of game design, player psychology, storytelling, and all the elements therein. My goal is to produce challenging and rewarding gameplay experiences for a subset of dedicated followers. I consider myself a Cave-styled developer, building on a continually evolving philosophy intended to break beyond the walls of its ancestors.

I use Starcraft's professional scene and history, and design theory from a variety of arcade and vintage titles, to build modern concepts. This article will touch on why and how the thought process of my RTS-oriented project design is structured.

I wrote an article in the past (the previous edition of this article) in 2009 that touched on Starcraft 2 versus Brood War. Today, in 2015, I have come to have a better understanding of the English language, Starcraft 2 has since come out, and I believe I can elaborate on many subjects much more fluently. I feel it is pointless to tackle the subject of RTS and Balance from subjective avenues, like potential new race and unit design, which can vary wildly between developer. I leave that to you. I'll instead discuss fundamental subjects and using existing titles for my examples. I'll also touch on two of my major experiments in proof of concepts - Armageddon Onslaught, a 7v1 survival tech demo, and ITAS, an evolving fleet concept that originated in 2001.

When I think of making a mod, I always look back to Brood War, regardless of genres. It's really easy to understand why once you understand Brood War as a design concept to build from.

In the past, a thread appeared on TL with the title along the lines of, "Why did other RTS' fail?"

Predictably, the majority of responses were along the lines of, "Because they weren't competitive enough, like Starcraft."

While most people will attribute the interactions of the player with the game as "competitive" or any other innumerable words, or attempt to describe a game's maturity or depth through broadly misunderstood terms like "meta", we can break down the RTS, and genres like it, into various elements as concepts. The concepts then become more malleable to us as a developer, and we can construct predictions and build a framework to address our design values with these elements in mind. Indeed, the genre of the game will apply little in the context of our observations here. However, they are written mostly in the context of the RTS and various dota clones (called Mobas by marketers) to spawn from them. We aren't concerned if a game is competitive or not. The same things that make a game competitive make a game enjoyable to begin with. Competition is merely fostered by the desire of individuals to improve their play and compare their improvements to others. It comes naturally of good design, regardless if it was the goal or not. Focusing on it exclusively is foolish.

I don't consider Starcraft art. I don't believe games can be art. I consider the gameplay of some of the players art. That the game allowed them to express themselves in an artistic fashion is enough for me.

What makes Starcraft a success, and other RTS' failures?

Tryanids

Zerg

Space Marine & Terran Marine

When Blizzard was refused a license to Warhammer 40k they made Warhammer 40k instead. Sc owes much of its success to using other people's ideas in much the sense that many older titles, especially many Japanese titles, used Geiger and Aliens almost 1:1 in many locations. However, Blizzard derived far more heavily than these counterparts. From graphics to concept, virtually nothing in Blizzard's games is original. Blizzard is a company that thrives at taking other people's work and ideas and putting it under their banner. They have extremely little competition that encourages them to do otherwise. Warhammer has yet to see a real RTS under its banner, only a bunch of crummy casual RTT's.

Many ignorant people will squarely point their crosshairs at Korea when questioned about Starcraft's success. Starcraft isn't just popular in Korea. Starcraft is a highly popular game around the world and represents the finest talents, both in terms of players and in terms of organizations, across games as a whole. Starcraft had a voice acted campaign set in a carbon copy of Warhammer 40k, and had very little contextual competition, featuring three unique races with exceptional audio and graphical assets for its time. Starcraft's terrain is more clean and appealing than other RTS' of its time. It had a Mature rating with multiple pre-rendered cinematics. This appeal and reasonably feature-filled product created the foundation for what it was to become. Starcraft is at the pinnacle of gaming and the pinnacle of professional E-sports. How did it reach this level of esteemed glory, and why?

Starcraft had help, of course. The likes of Kespa gave Korea the foundation it needed to seek greatness inside Brood War. But Kespa neither Korea made Brood War. They merely found Brood War to fit the criteria of what they, as a culture, thrived on. A means to cultivate and demonstrate personal skill, a means to deliver that skill to an audience, and a means to make a living out of those skills. Brood War is a deep and engaging game that catches people with its presentation then holds them with its depth, and it continues to survive its sequel and, to this day, still evolves professionally. Despite Blizzard's best efforts to kill off Brood War to make way for Starcraft 2 they have failed. This is testimony to the brilliance of the game. The best part is? Almost none of that brilliance was intentional or foreseen by the developers who created it. Starcraft, in its early days of development, was rightly criticized for being Warcraft in Space. Blizzard listened to the critique and improved it. They put effort into it despite their immense incompetence and inexperience as programmers. They wanted to make it all it could be despite their limits. They succeeded. This would be amongst the last times they ever responded positively to such criticism, however. The people who made Starcraft are long gone. While many have tried to follow in their footsteps the footsteps are just too big.

Instead, we have Starcraft 2. A game rife with problems all around the board. By attempting to break away from their WH40k roots they retconned and annihilated almost all of the original's writing, creating a mediocre and unengaging single player experience fitting more of a C-grade Hollywood bargain bin bootleg than anything fitting of its colossal budget. The multiplayer troubles are telling by how the company has been patching it.

In Legacy of the Void's beta, Blizzard proposed to entirely remove the early game in an effort to make gameplay faster and faster and to entirely eliminate early game cheesing. This, along with a string of like-minded changes at the heart of Starcraft 2's initial inception, hints at a lack of design direction, or perhaps a malicious one. Rather than address problem points at the root they seek to simplify the game to make it more "accessible", as their game is not compelling enough to hold professional interest and had already lost the market to dota clones who were both more accessible to casuals and more challenging for higher level players. Blizzard turned to catering to hipsters - people who want to identify as being a gamer without touching the scary and forbidding world of commitment. Blizzard favors this crowd above all else, as they have nurtured it since the conception of Diablo 2: Lord of Destruction, the first brick in what would be a long road to shaping the company's design goals for years to come. Starcraft 2, however, had much weight on its shoulders of being competitively successful, and so Blizzard had to try to cater to both audiences at once, leading to the rise of grindy "mechanics" to artificially elevate skill ceilings. Curiously enough their exclusively casual-centric games would proceed to compete with Starcraft 2's competitive presence later in life, such as Hearthstone. In many ways we can fault Starcraft 2, but we cannot deny it is exactly what they set out for it to be - a low-effort income boost. Starcraft 2 was successful despite its countless corners cut. Criticizing it offers us no chance to improve it, but it helps us understand how we can avoid similar troubles ourselves.

You Can't Make an E-sport

When Counterstrike, Quake, Halo, and Smash Brothers were first developed, "e-sports" didn't exist. Yet many of these titles to this date still see some level of competitive play, and have spawned an enormous amount of copycats attempting to ride the waves of their success. E-sports and the very concepts of them have become victim of gimmick buzzwords used by developers to masquerade juvenile and incomplete products as skill testing, hoping to ride the waves left behind by the success of Brood War and its ilk, and baiting people who are hoping for an evolving professional scene elsewhere in gaming. But when you design from the getgo hoping to be an "E-sport" you tend to immediately lose sight of how these games became E-sports in the first place. Calling something an E-sport doesn't make it an E-sport, even if you throw money incentive at it. Competition cannot thrive just because you ask it to.

Such was reflected in Sc2's community and general opinion and, after its release, in sc2's very own custom content community. Individuals looking for immediate benefits from the marketplace banded together under the sole desire to monetize maps, not make their projects. They could only see themselves making thousands of dollars off of cheaply made content and living off of it. Thankfully this never was possible, but the damage had been done. Sc2 had attracted almost exclusively people who wanted easy money and not people who wanted to make good projects. Blizzard compounded this problem by intentionally withholding their 3ds max export plugin for 4 years, driving away even the most patient of would-be original content creators. The scene has been stagnant ever since. This is how the metric of something can shift so wildly depending on how it is perceived and presented. It is as much about psychology as it is about content. In the end it did not matter what sc2 or its engine were like, how powerful or how well developed they were. The kind of people who were drawn to it are what defined its failure as a custom content foundation. In much the same sense, those people who designed exclusively for E-sports and competition as their sole goal often ran into significant balance and fundamental design issues down the line they didn't know how to deal with, because they weren't trying to make a game. A game. Think of this word for a moment.

Consider Hearthstone. MTG for jocks whose appeal is little more than pushing buttons for RNG and exploiting broken deck builds. While card games as a whole are their own infinitely deep bag of dicks, consider that Hearthstone is very commonly in the top three stream viewers. While hardly a statistic for competitive presence, it shows a general metric of player interest exceeding most other titles. It isn't farfetched to say most people watch streams for one of two things - personality and competition. If we consider that most of the top titles (LoL, Dota 2, Hearthstone, CS:GO, etc) have an averaged number of color casters, we can assume that the remaining numbers are there for the actual game. That is to say that, despite its comparatively microscopic budget and with virtually no effort, Hearthstone succeeded Starcraft 2 easily. Hearthstone may be many things, but it as its heart a casual game, and it attracted the casuals quite handily. Starcraft 2 tried to be both hyper-competitive through artificial means and casual at the same time. It tried to cater to everyone while not knowing how to cater to anyone. With Brood War it would certainly be hard to say it knew how to cater to anyone much less tried to, besides fans of Warcraft. Indeed, that very criticism is what caused it to reshape dramatically. Brood War is, as I would say, a fluke.

Cultures play a big role in this grand picture, especially when gaming first started taking shape on early consoles. In the West games are often viewed as toys. In Japan, where the average income for households was lower, Japanese children often times had little opportunity to sample so many games. Westerners often played only to see the end of games, while Japanese played to master them. It is easy to see how one of these avenues is more financially secure than the other, and why the West perpetuated the idea of splintering game experiences into DLC and micro transactions, and how many Japanese publishers and developers ended up taking up a Western philosophy in the end. You can't say that neither culture can't produce good games at any point in time, but you have to look into their goals as developers to see what it is they really want out of their project. This is the same question you should be asking yourself as a modder.

Japanese arcade developers were building projects for a niche fanbase of devotees. Recycling content was common, but a general theme almost always applied and their success depended on it - the products required greater skill. There would be no success for them if their title was not more challenging than their previous. The allure for the players was this increasing ladder of challenge, and the difficulty mechanics of these games often changed how the games actually played. Scoring mechanisms were widely varied and demanded precision and perfection to exploit.

While many arcade games can be played in co-op almost all of them are void of PvP. The competition is derived not so much from overcoming the other players directly, but performing better than them and attaining the highest score. This is something I have started to take greater note of as, after 2009, I decided I would stop creating multiplayer projects entirely. I would discover that even the most mundane of Japanese titles were mediocre at the worst, while Western ports of those games were commonly abhorrent, and Western equivalents of the mediocre easily reached into maliciousness. The cultural differences between the developers and the history of their content helps shape an understanding of the business practices behind those developers.

As a modder and a developer it helps to see both sides of the coin. Games who "by chance" ended up great, like Brood War, and games who tried to copy them and were objectively far inferior both as games and as spectator sports. In many cases it ends up as simply being the difference between honesty and putting effort into a project, or being dishonest and hoping to cash in through marketing. While both can be financially successful only one ends up being an enjoyable product for real gamers. As a niche developer financial success is rarely the majority driving element behind production. The E-sport argument is also a lost cause to modders - you won't be creating an E-sport. If, by chance, you end up like Icefrog, that will be merely by coincidence, much like Icefrog. It won't be just because you wanted it. Attempting to predict and rely on the popularity of a competitive game has been the death of more than a few companies. Nonetheless, the realm of E-sports is an excellent source to study subject matter related to your work.

Professional play is a critical learning tool for a modder looking to design and then balance a project. It's not just about the players, the scene, the "meta", it's about how the players perceive the game, and how the game presents itself to them. The best tool for learning anything about game design is brood war professional VOD's. Not even English casted ones. Just the game in general. Why do I recommend this?

Competition is a product of success.
 

The blending of Engine and Style

Unlike Warcraft 3, Starcraft's graphics have aged extremely well. They are amongst the highest quality "pixel art" you can find for its generation and country. SC's resolution is an offensively miniscule 640x480 and it doesn't represent the strongest technology of 1998, but it looks good and it's believable. It remains easy to read, but is sufficiently flashy to convey key actions. Much like Metal Slug and many similar Japanese arcade titles, Starcraft looks competitive compared to today's modern 3d titles. 3d is in itself a gimmick rarely explored by even by titles released in 2015 as any more than a distraction from comparatively shallow game design. The average modern game is a focus marketed intern prototype hoping to cash in on careless casuals looking for nothing more than 5 hours of distraction from life. Consider this when choosing the engine and assets for your project. 3d is very rarely worth the trouble of investing into. If nearly none of the multi-billion dollar big businesses can do it right, how would you tackle the problem? It's not impossible. It's all about perspective. In most cases you'll never need or be able to make use of 3d. If you want to, you should first figure out all you can about 2d.

Another thing about Starcraft is that it's responsive. It feels smooth, it looks smooth, and it's responsive. Starcraft is generally played through a latency-free third party service. Starcraft has many issues with pathing and unit AI, however, but we'll touch on that in a bit. It is the RTS equivalent of Castlevania. Blizzard has done one thing right in their games consistently, and that is controls. Often times the controls can be the deciding factor when comparing their titles to ripoffs, particularly World of Warcraft and its many, many, many clones.

The system behind the graphics is as important as the graphics. The graphics, the audio and the "engine" are the first things you experience and act as your way of communicating with the gameplay. As much as kids like to constantly abuse the over-used line, "Graphics don't matter, only gameplay does!" they fail to realize that it's the graphics that convey the gameplay in the first place. When neglected they become stale and lack sufficient strength to hold your attention enough to really focus on the gameplay. Worse yet are games who use graphics to hide gameplay. Many modern games attempt to hide their lack of gameplay by distracting the player.

Also seen extensively in modern cinema, rather than attempting to address critical issues elsewhere attempts are made to hide them instead. Camera shaking, abusive post-processing, the Loudness War et all are all signs of a developer trying to ride the name of a franchise on a swath of shilling and focus marketing. These games are not built by gamers and so they will always take the lowest hanging fruit when it comes to grabbing buyers. This sort of media design was popularized in the late 90's and really spearheaded into the games industry in 2000-2001. When games became increasingly popular and the entry level skills required to publish them lowered focus marketing became the leading design theory, and gamers were met with a rapidly dying industry. Even the most mediocre of old console titles still required marginally more skill to develop than modern titles which are all but a collection of third party assets and code haphazardly slapped together. Again, this is Blizzard's calling card - they slap other people's work together, and they do it better than others. Unfortunately they tend to introduce arbitrary rubbish along the way that detracts from the experience.

Starcraft 2 has a responsive engine. It does what you ask it to, and when you ask it to, but only on a local game, and not through battle.net. At the heart of what could be a competitive mecca is an arbitrary delay on every action made by the user. Many games feature this to varying degrees either because of technical limits or, more frequently offered as an excuse, "to create equal playing ground between potential 56k users and everyone else." Consider from the start if you plan to introduce such arbitrary delays and how severely they will affect your design goals. If your goal is to have something that fosters player interaction, you want as little between the player and that interaction as possible. There are real, physical limits to hardware, but you should never be finding yourself constrained by those.

Reads

Starcraft 2 was heavily criticized for readability immediately from its alpha announce. This is because it is a 2d game using lazy 3d visuals. Air units intersect and clip rather than overlap, the graphics are all washed out and lack definition, the specularity is too fine and produces sharp, confusing highlights, the terrain is extremely blurry and lacks definition, and the particles all depend on the same textures and last too long. Terran sounds dominate the audio channels with their high compression, clipping, and long tails, not to mention they reuse the same sounds constantly for impacts and explosions, like the tank hits, missile turret hits, and building explosions. Meanwhile, the Zerg are all using nearly identical sounds, most of which are inaudible. Starcraft 2's audio is best described as schizophrenic. It was clear they did not hire audio engineers for this title much less ones versed in the concept of readability.

Indeed, readability is as much about audio as it is about graphics. Coming from a modding perspective it is likely you are well aware of the concepts of readability. Consider that many players register audio cues before graphical ones. Now consider the difference in sound effects from Brood War to Starcraft 2. In brood war, every sound is distinct, even though half of them are from commercial cds. In Starcraft 2 only a handful of sounds are not straight ripped from a CD and those are the few distinct ones that exist. All of these problems are easily solved by the modder and most of them are pretty trivial fixes.

Be very careful with Specularity. Sharp highlights most often look unrealistic and "wet" unless the material fits the bill and, especially at a distance, add a huge amount to visual noise. These Goliaths and Vultures look like glossy plastic and clash heavily with the blurry, flatly-lit terrain. Use a cubemap to give them some minor metallic reflectivity and have broader, shallower highlights. Increase the tile rate on terrain textures to fix the blurring.

Groups of air units easily stack and mesh into an incomprehensible mess in Starcraft 2, especially when you start using larger numbers of units or larger models. On the flip side, the tanks are easily distinguished by the increased collision sizes I gave them to fight clipping. 3D is not your enemy if you know how to work around its many pitfalls. I wanted to try giving all air units slight height offsets on creation and see how that handled the clipping issues.

Particles and special effects are a big deal. Western games often seem confused by particles and how to make them. Evidently, a lot of particles can obscure the scene. But if you don't have enough effects the game is bland and readability is actually hurt. Effects are reads whether you intend for them to be or not. When considering particles I look to the likes of Anime and Asian games, especially Lineage 2 and Tera. Asians have mastered the art of highly attractive, shiny effects that are colorful and appealing but very concise. Using unique effects for every weapon ensures that players have something they can identify as well. I think of the overview of an RTS as nothing different than the overview of R-Type 3. The same concepts should apply - you shouldn't need to focus on one thing. Indeed, you should be watching the screen as a whole, and the game should enable this. That anime and Asian games both use similar types of effects hints at how they treat reads - flashy openers and concise finishers are usually the primary style. They announce their presence and then quickly make way for further content.

In Armageddon Onslaught I tried to give each unit unique sounds and effects so, despite the vast amount of visual and auditory noise going on, you could make out distinct reads.

Next to effects we have style. I don't think styles should be abused. Cartoons don't fit in 3d, especially like how wc3 did it. These graphics do not age well and are too difficult to attain conventionally. Starcraft's style wasn't so ridiculous, but it wasn't a full attempt at realism, either. And, face it - SC still looks good. Another game that looks good to date is Earth 2150. An extremely early adopter of 3d, Earth 2150 is rough around the edges but attains a good balance of style. I managed to run it on an M Cyrix II with 4 megs of built-in video memory.

There are some anime-styled games that look reasonable out there now; consider they avoided the pit of using cell-shading, and you might be able to avoid the trainwreck that was borderlands. Critically, more reliance on mesh detail over texture noise seems to be a factor. It would help to study anime itself if this is to be your goal, but consider that reads will be harder to deliver in a cartoon environment which is deceptively high in visual noise.

Starcraft 2, however, was wrongly criticized during its development. It has issues with readability, but many players were judging the readability through low-resolution youtube videos. Youtube re-encodes videos to a very low quality resulting in significant blurring and artifacting. For any game this is bad, but for a game with a lot of small things moving around that have high contrast from the specularity bad encodes are particularly brutal. Not to mention that most videos at the time were not even any better than 720p, most of the time significantly lower. Knowing how people perceive things helps you understand why they are seeing them as they are, and can help you decide whether or not to disregard their words.

Between graphical and audio reads, a player is looking for cues from the game to understand what is going on. As a player becomes more skilled things become more and more predictable to them. They can play the game without needing to actually see or hear what is going on, but only so long as it remains in their control. Elements that take away control, like squads and automation, detract from the player's experience by depriving them of the responsibility for their own gameplay. Lack of control means reads have less value. Evidently, problems compound each other very easily. For casuals and hipsters this may be a blessing in disguise, because the lack of control means they can't blame themselves for their failures and never need seek improvement. In this hand we see the evils of not holding individuals accountable for their own failures. We accept in a world where everyone can be successful and no one can truly fail. Clearly, this is something we should do all we can to avoid.

Control as a Concept

Dawn of War relied on squads for most of its gameplay, already a significant red flag to anyone looking for an RTS. The squad AI in these games is horrendous, commonly splitting up on map objects and becoming nearly impossible to control. The behavior of individual units is denoted to a cheap waypoint system where you as the player only get to waypoint invisible captain units around that then delegate their orders.

Let me spell it out for you: Squads do not belong in an RTS. Period. There is a variety of reasons for this, but for the moment, I'll stick to control.

Squads remove control from the hands of the player and, graphically, can get very confusing. Control often became infuriating in Relic RTT's, especially on a map any more complicated than a giant flat square (which was hard to find, mind you). This difficulty in control pulls you away from the gameplay and more into a symphony of smashing your face into your keyboard. Dawn of War has virtually no room for gameplay because there are only so many things you can do. By appealing to a playerbase who are not gamers, Dawn of War resists gamers by taking away much of the control over how the game actually functions. Without WH40k's setting as a selling point you are left with a slapstick mess. It did have one thing, though: decent audio. The setting and audio were enough to carry casual interest, allowing sequels to be budgeted. Company of Heroes had more success than they did, but could never leave the shadow of its chains. People starting pinning the blame on franchise name power (Blizzard vs nonames), which isn't wrong, but it's only half the story. Like many similar stories, some neat ideas swamped in focus marketing-driven swill. None of these titles are honest so it's no surprise they didn't compete with one that was.

Do not fight the player's will to be in control just because you yourself cannot play at that level.

A player will feel more accomplished and more involved when it is he himself in command of the elements. A game is more than a toy. It is a manner through which an individual can express himself.

This is much the case with mechanics-based games, like Shmups. With pixel-perfect and frame-perfect controls at their disposal the skill ceiling rapidly climbs, and the drive of players to improve themselves becomes the lifeblood of the game. Players enjoy expressing themselves, their creativity, their ability to improve. By dissolving elements that enable this behavior you drive away gamers and invite in people who want to be identified as gamers by playing a game, but you will never encourage them to be players since you are now distracting them from the game and offering them the instant gratification of being part of a crowd you are no longer serving content to. This was much the case with western arcades, who were more intent to line their pockets than develop the scene as a body. Either they created extremely unfair games to milk cash (midway), or ramped the difficulty unnecessarily on imports. They had no intention of fostering a real playerbase, only milking the ignorant. As a result, arcades died in the west.

As a modder you may intend only to bring a specific dream or vision to life. Many of my projects are built exclusively to give life to a part of my writing. But this doesn't mean the game has to be mundane. Making a meaningful experience out of such selfish ventures is actually a lot easier than devoting years into building a would-be E-sport. All you really need is a few observations to guide your hand. Games thrive on being challenging and rewarding to play, not effortless and droning or unfair and frustrating. As a modder, this is critical to understand immediately, regardless of the genre, project, or lifespan you hope your project to have. Learning to spot the differences between what is a feature and what is a byproduct of carelessness or malice is the first step to objectively reviewing media, including your own work.

Critical fundamentals to live or die by -

• - A game should always respond when the player wants it to. Frame-perfect reactions should always be a thing. If the game resists the player's input for whatever reason including enforced latency, vain attempts to be "real", or other rubbish, it will always frustrate the player. Remember that in modern technology it is always possible to have realistic, flowing animations built into snappy responsiveness. Just because a Western developer doesn't know how to do it doesn't mean it is impossible. See: Castlevania: Symphony of the Night, R-Type 3, DMC3-4

• - If you feel inclined to automate a feature because the feature feels tedious your feature is not a feature, it is grind. If you reach this stage in development it may be a good idea to start over or quit entirely. (re: macro mechanics in sc2 added to invent artificial mechanics ceiling.)

• - Study the professional play of a game if you are intending to make something similar to it. Understand if or why a scene exists, and the elements that lead to its survival or death. Be prepared to make objective judgements and deprive yourself of subjective opinions. The lessons learned therein will be beneficial to understanding how you can evolve your own designs.

• - Understand that raw numbers don't determine balance.

Balancing - The pitfalls of the RTS

Balance is a big subject but it's really not that complicated. If we look at Brood War we see one of the few examples of a nearly perfect game. Another example is R-type 3. I've seen many people walk into a project with a bucket of excel sheets under their arm. I feel this is the wrong way to approach this. Evidently, Blizzard did as well, because Brood War is pretty wacky at times. Brood War has a ton of different elements we can dissect piece by piece, like terrain value, but I think most of that is pretty obvious to someone reading this by now. Again, I prefer to approach these subjects as concepts.

Balance is obviously one of the most important aspects of an RTS, if not the most important. Even an RTS that is technically fun to play is totally ruined by balance problems, and single player experiences can be trivialized or rendered frustrating by balancing oversights. I created a private dota clone for Warcraft 3, and was beset by a weird conundrum right off the bat. I had staff helping me with the project, but one member continually introduced heroes or abilities that were not adhering any set of guidelines. On paper, their abilities did not seem terrifically overpowered or generic, but in practice they lead to extremely unenjoyable gameplay. It was a wakeup call on how easy it is to introduce such things, even unintentionally, especially when working with other people. A lot of the issues boiled down to the hero designs being built to counter specific things or behaviors.

The largest, biggest, most obvious pitfall in terms of balancing is Hard Counters. Hard Counters are systems like that employed in Dawn of War, also known as Rock Paper Scissors. Hard Counters destroy competitive gaming in every sense of the term by removing the skill factor, removing the strategic factor, removing the tactical factor, and replacing them with predictable, stale garbage. Hard counters can exist as mechanics and interactions enabled by player skill rather than numbers telling of bonuses, too. Consider, for a moment, if only certain pieces in Chess could kill other pieces. The diversify of the game would quickly narrow down into very specific strategies. Hard Counters are comparable to QTE's; a poor man's adaptation of Simon Says.

Someone might get the bright idea to argue, "Well, SC has hard counters, too! For example, vultures can't do damage to dragoons!"

Starcraft's damage system seems to resemble a hard counter system, but evidently, abilities make the difference. Ghosts, vultures, and the like are the primary candidates of showing off that even if they can't directly fight certain units, giving hint to a rock paper scissors kind of gameplay, they can, and will, still win those fights. Keep in mind shields in Brood War still take full damage from all weapon types, too. Ghosts, incidentally, have lockdown. Vultures have spider mines. Personally, I prefer not to lump the utility power of units like these into point and click spells, but that is what Brood War does in this example. Utility is something we'll touch on in a moment, because utility is a huuuge subject.

Although counters are not necessarily a complete paragon of evil they must be used in moderation - very careful moderation - to promote creative and imaginative gameplay. As Blizzard themselves said, they did not expect SC to become such a huge success. The challenge is now to recreate that balance of strategy, discipline, and unit flexibility.

By forcing specific activities, like how Dawn of War did by giving half of the units very small hard caps and rigidly defining damage systems, and like how C&C always does with its damage system, these games cause gameplay to become exceptionally stale very quickly. Supreme Commander steps outside the box by instead using a very rigid tier system and funnels its balancing into economy, promoting a unique but still plain and overall repetitive method of balancing that has little replay value. Unit damage is very plain in Supreme Commander, but control is slow and there is much to be desired in the pathing engine. Most high level play is, in essence, players waypointing each other's base, spamming units mindlessly, and occasionally sniping a valuable building. On the flip side, Supreme Commander's macro-oriented gameplay and artillery/experiments can lead to interesting FFA's when they progress into the late game. However, the further Supreme Commander diverges from the highly homogenized base units the more imbalanced it becomes. If I was to name an RTS with an interesting take on economics that diverge from Starcraft it would be Supreme Commander. But we'll touch on that in a bit.

Something hard counters and extreme maneuverability also discredit is terrain value. In starcraft 2, currently the races are so mobile that terrain has lost its value to a degree. In warcraft 3 terrain means virtually nothing. In Dawn of war there is no terrain to speak of, as evidently the developers realized their squads can't handle it. You can't factor cover areas into this, because cover areas are also rigid and for the most part play extremely little if any role in the grand scheme of the game and are more or less gimmicks rather than worthy features. With this in mind, consider that the more "features" you add the harder time you will have justifying their existence. Dawn of War would play identically with or without its existing cover system. It's meaningless. Starcraft 2 further discredited terrain with the advent of the E-sport Tower, a structure that hands a nearby unit immense vision radius, allowing lazy players to still maintain eye over significant portions of maps.

In short, Hard Counters hurt the player badly. Not just the hardcore player, but the casual player. If the game is always going to play out the same way, or if you're simply playing a glorified version of Simon Says, what is the goddamn point? The game essentially becomes a quick time event, and we all know how uninteresting those are. Even a game that is clever, visually and aesthetically appealing can murder itself viciously if its developers turn it into a series of QTE's. This seems to be a theme common in college-level design design classes, because Indie developers flock to it like moths to an open flame. Don't be That Guy. Figure things out yourself.

What offered games like Company of Heroes uniqueness over competitors was their vehicular combat. While they lack the finesse of Starcraft's controls, they instead offer a more positioning-oriented balancing scheme by offloading offense and defense power into various quadrants of armor thickness and tuning the unit movement into more realistic levels. For example, some tanks may have heavier armor in the front and weaker armor in the back, forcing you to bring shots to their rear to do damage. On paper the system both makes sense and exposes some more potential balancing avenues, but in practice the unit AI is often so abhorrent and unresponsive that the system can become more frustrating than involving. Nonetheless, even from examples we might otherwise dismiss as noise in the riffraff, there are still often times neat ideas or observations that can be gleamed.

Mechanics > Numbers

I'm going to give you a huge tip right off the bat. Just the tip. That is: don't worry about numbers. Not initially. Sure, keep things in moderation, but at the design stage putting ideas in practice and putting concepts to the test means more than balancing them right off the bat. Consign to the knowledge that, initially, your project is going to be grossly imbalanced. Address this calmly. Dawn of War had the chance to be balanced and enjoyable many times, but you continually saw enormous patches changing everything about the game at once. As a result the game was never balanced. In Warcraft 3 only two races are competitively viable, and Night Elf dominated the entire scene. Two extremes of the dice. Focus too much on numbers and you will lose your way. Don't pay attention and the meta could grab you by the balls. But focus on the fundamentals first. One of those fundamentals is terrain, because terrain is enormous in many of these games and worthless in others.

In Starcraft the terrain ultimately determines the gameflow, the metagame, and the overall strategy the players will undertake. Even minor changes in seemingly similar maps can bring out entirely different gameflow, and significantly different maps, say Othello and Plasma, will have entirely different games and ultimately keep the matches fresh and interesting, even if they are in a Bo5 mirror matchup between equally skilled Terran players. To reach the stage where we can even gauge changes being as a result merely of the terrain or of an underlying problem we already have to be extremely confident about our gameplay, however. To this day arguments rage on about race balances in certain maps for Brood War but, universally, the statistics remain fairly favorable on most competitively accepted content. Terrain is a tough subject, so if you're really interested in getting deep into that, I recommend finding those discussions on team liquid. It is also possible some English commentaries may cover those subjects (especially Day[9]'s earlier casts).

We touched on automation for a moment and I figure this a good place to wrap it up.

During Starcraft 2's alpha people were very scared about Multi Building Select, MBS for short. They compared it to Warcraft 3, and used Warcraft 3's evident lack of macro as an example to illustrate how badly MBS would hurt sc2's skill cap. Even if MBS was to be faulted for a part of Starcraft 2's casual-oriented design, you can't use Warcraft 3 as a basis for that argument. Even though Starcraft 2 fields less units than Brood War, it is still much higher in unit count than Warcraft 3. A better example would be Armies of Exigo.

Of all the many attempts to approach Starcraft, Armies of Exigo is the most impressive I have seen to date. Artistically superior to every other attempt to copy warcraft 2's art in 3d and yet graphically more advanced than many titles of a comparable era, Armies of Exigo's many unfortunate downfalls are all entirely accountable to having EA's logo on its box. Incidentally, the exact same story would happen with Heroes of Might and Magic 6. Why would you go from EA to Ubisoft? I guess some people never learn.

The argument of user interface advancements over artificial skill ceilings became a common theme in these discussions. Another point often attacked was the higher unit selection possible in Starcraft 2. Starcraft 2's pathing and low unit collision makes for bulbous, "death ball" gameplay, so using one control group for every unit is very often a good way to get your casters and other valuable units killed. In this way the high unit selection serves more as a noob trap than anything. I can't fault Starcraft 2 for either MBS or high unit selection, because I think if it was as good as a game as Brood War and had those features no one would have ever cared. What was more likely the case was that people didn't like the game and tried to find ways to pin blame on it without knowing how to describe their feelings as a body.

Starcraft 2 uses automining to homogenize the reflexes between professional players and window lickers. This is a bad user interface advancement. However, it was made necessary because of the severe performance issues sc2 has with streaming in assets, resulting in jumps when the game loads, and because the game "immediately starts", which may not be at a predictable period for the players, given the inaccuracy of the load screen. I feel like this could have been designed around rather than bandaided by forcing everyone on the same level. The same can be said about forced latency to make 56k players feel like they're on the same level. By forcing everyone to play at reduced input responsiveness you degrade the play experience of everyone to satisfy an extremely small niche of casuals who aren't likely to be playing for very long. That would be something only to momentarily consider if the game had direct connect or LAN. But it doesn't since Blizzard is so scared of China.

Indeed, some games are built exclusively for niche audiences and have huge entry barriers. I am personally more in favor of this kind of design, but if this is your goal, you are probably already set on a user interface concept. Personally, I'm in favor of giving the player an intelligent UI that empowers them to make decisions rather than making decisions for them. Avoiding popups, prompts, helpers, quest indicators, glowing objects, automation, and nags are critical for my philosophy of the user interface. I make my games intended for a highly skilled audience but from the start I offer a ladder for new or low skill players to start ascending to respectable heights. I use ingame elements to introduce the game, especially character dialogue. It is up to them at that stage if they want to put in the effort. I don't care about people who aren't willing to improve.

Making something niche for the sake of committing to a specific goal is admirable. In pursuing perfection of that goal and caring nothing for the mainstream you are far more likely to be successful. Working for yourself first is a critical aspect in all walks of life. When a developer doesn't care about what he's producing, what he produces tends to be garbage. It is natural for humans to activate a fight or flight reflex when confronted with something they are afraid of, like effort, but encouraging them to fight this is beneficial to all of us. Giving them an avenue to stoop back into regressing to the mean is something we should always avoid.

Games that try to resist player expression breed casuals who become resistant to challenge, resistant to diversity and expression. Development ethics that resist developer accountability lead to skirting around the issue of making a quality product. They are one in the same. It is a self-serving, culturally neutering environment. One that developers are inclined to feed because it trivializes marketing and sales. As a modder you rarely are ever in any kind of situation to be pressured by such things, so it's a great opportunity to step back and observe both ends of the fences.

These subjects may seem far-fetched from the concept of design and balance, but really, they're not. It builds into player feedback and counterplay. The perception of a player's gameplay to him is often as important as the gameplay itself is to you, and how you perceive your own game must be objectively addressed at every point. After all, you are presenting your gameplay to a third party, and what they see will be different than what you see. When a player feels like he can do nothing to avoid inevitable fates it leads to just as much frustration as such events really would. This is why clear and accurate representation of the gameworld is such a big deal, why readability in graphics and audio feeding the player precise information is such a big deal. Starcraft 2 may have been the first actuation of this concept for many would-be mappers and players, but such concepts have been a huge deal in games for a very long time, all the way back to Japan's earliest console games.

Maybe the player had the opportunity to defeat the Dragoons with his Ghosts. But if he couldn't figure out what was going on, and the fight ended before he could assess the situation, what then?

The Developer's Cello Duet

Immediately into development you must come to accept people aren't going to be happy with your project, your design, and your balance. You must accept immediately that you will never, ever please everyone. Accept this evil and move on. Do not attempt to cater to everyone or you'll slip right into that culturally neutered environment you're trying to drive your players away from. The idea that a game must be for everyone is the tip of a truly long and hard shaft, one you should avoid at all costs. Determine your target audience and tunnel into that audience exclusively be it casual or gamer. Determine your genre and stick to it.

There will come times where events should happen that won't happen because the player did not respond appropriately, did not act within an applicable time frame, did not understand the elements, or was simply misplaying. These events are what you should seek to understand the psychological mechanics of before you start worrying about numbers. How the player perceives and interacts with the game environment, the value he places in various elements, and how he computes those elements is the bigger contributor to balance. Hard counters blanket over this by removing this element as much as possible - the player's conceptions and skills mean far less when the game tells you exactly how to play it, and resists any effort to work outside that script.

A player building an understanding and improving that understanding of the game creates opportunities for him to benefit from that improvement. Learning fosters a sense of accomplishment when seeing that improvement by overcoming challenges. Multiplayer games are the roughest to design around in that respect, because it's too easy to funnel "improvement" design into "do this better/faster" design, which can quickly lead into garbage like sc2's macro mechanics, which are arbitrary and offer little to the game in terms of creativity but are necessary due to their impact in numbers. For this reason, amongst others, testing and challenging your concepts as a design from the getgo is extremely important. Unit testing is a tremendous deal in game design. Each element should be critiqued as an individual and you should be asking yourself not simply if it feels balanced in numbers, but if it feels balanced and enjoyable as a concept.

Although vultures may die to dragoons in a fight, it may not necessarily always end that way depending on what you choose to do with them. Spider mines, synergies, or avoiding the Dragoons entirely by using the Vulture's superior speed. The Vultures often have options in what to do, options the player must decide to use or not. This level of control places you directly on the battlefield and directly responsible for what happens. It's not a clickfest. It's a game of logic. I had less than a third of the APM of a professional player but my micro was still enough to keep me competitive. Today my skills aren't noteworthy in this crowd. They are just expected of someone who is or was a gamer. Sometimes they work, sometimes they don't, but my failures are my own and not because the game restricted me. Even professional players can make errors. This is what allows the players to thrive, as it continually drives them to better themselves. People are attracted to people like that. Competition drives communion, and communion attracts attention. People enjoy watching other people thrive in games of skill, because the tension and excitement of the moment lends to those who they themselves may not be all that great at or interested in becoming a part of the game. I found myself fascinated by the professional gameplay of Blazblue and Shmup players while not necessarily being heavily invested into their genres, because the high skills of the players and the evident high skill ceilings of the game gave much room for a spectator to break into and experience their displays. These players can form their own stories surrounding their experiences with their games, creating rivalries and building competitive scenes on their exploits alone. Some people regard these players as superhuman, or just "Korean". They've already missed the point the developers set out to make.

As a modder I cannot tell you how your project can foster this kind of interaction. I can only tell you how I try to do it. It is an art entirely lost in the modern Western market and slowly slipping away from the Japanese. It is not financially sound. But it's how good games were made.

High risk, high reward

If you're a starcraft player you know the Reaver is amongst the most dangerous and awe-inspiring units in the game. Its concept isn't new or original; goes without saying. It's fat, slow, squishy, and hits really fucking hard. Combine a Reaver with a shuttle and you have the recipe for some truly epic gameplay.

In professional Starcraft the Reaver makes or breaks a good protoss and provides some of the most exciting moments for players and the easiest opportunity for the trio of commentators to go completely berserk. A type of gameplay design, called High Risk High Reward, can be directly related to this mechanical slug and its chirpy companion. If the scarab gets stuck on something it may explode and do no damage, or if misused or outplayed it may waste its lengthy cooldown on an undesirable or suboptimal target.. If you position the Reaver right and get a good shot off you may devastate your opponent's economy or military and potentially win the game. There is a degree of tension that builds with the deployment of the Reaver because it could mean anything, and that anything will be impactful. It is a costly investment and has little utility on its own.

In sc2 the Reaver was replaced with the Colossus, whose damage doesn't even follow the projectile's graphic, is big, beefy, and can walk over cliffs. A simple, uninspired, unintuitive unit with a very blatant and cliche role that has exceptionally high utility. It is more powerful than the reaver, and its reliability makes it very hard to squander its cost-effectiveness. This is an example of destroying a mechanic and simplifying the game to appeal to an audience that lacks the skills to play the first RTS but, most importantly, lacks the desire to improve. Make no mistake, new players and Korean superstars alike could use a Reaver to great extent. But the skill ceiling with its positioning, timing, and placement in the game was tremendous. Blizzard didn't like that such skill gaps could exist because it discouraged their hipster audience from trying to play, as there was a significant learning curve that only practice could conquer. Instead they have steadily introduced more "buttons to push" to "increase skill cap". This brings me back to the QTE analogue...

I point out these examples to make a point. Although something may not be very original or have a spell that involves all sorts of mathematics and interlocking synergies to determine if it's more effective at X or Y than another spell, passionate and instinctual use of this unit will prove more entertaining, more challenging, and more rewarding both ingame and as a hobby or as a sport than a set of mechanics that will always play out the same way. The simplicity of an element can be built around its deployments and its effects can be rather mundane, but so long as it remains free of the arbitrary, it has flexibility.  When flexibility exists in many elements, responsibility imparts onto the players to make the most of their own abilities and limitations, and it becomes more about the players and their own accomplishments rather than prefabricated computations determining the game's outcome. A game should allow a player to express themselves as boundlessly as possible. The Reaver, a simple unit in all concepts considered, exists in a world where high damage splash abilities are rare, but economy is slower and more painful to rebuild than sc2. Comparatively speaking, the Reaver inside sc2 would have much less impact because the game is far less accepting of the concept of high risk and high reward, economy is easier to rebuild with mules, larva inject et all, and the higher mobility and longer range of units overlap more aggressively on the Reaver's weaknesses. In order for a Reaver to exist in sc2, sc2 must first be able to receive it in a manner that makes it meaningful. Blizzard was just fine when they weren't trying so hard to make all the money and appeal to every demographic. See: d2 classic, warcraft 2. Sure, they had a lot of problems. But they remained enjoyable and players generally had room to grow over lengthy periods.

Scarab Duds

However, a point must be made regarding the Reaver. The Reaver's scarab commonly falls victim to the pathing engine. It may get hinged on something, especially minerals, and die when its timer runs out, exploding but doing no damage despite being within perfectly reasonable attack range. These "duds" make for dramatic moments on the stage but in reality they are a negative connotation. They are a bug derived from the pathing engine and are not at all intentional.

The bug plays into risk and reward. There is a risk your scarab may not even do anything. Players try to position the Reaver in a manner to avoid the problem, but it's a bug, and it's unintentional. Dragoon pathing is screwy as hell, too. We should ask ourselves, "what makes a feature, and what makes a bug?" If we were to fix the scarab, what implications would it have? This is a tougher question than you might think.

If the scarab had 100% reliability it makes the Reaver far stronger. But it also means the control is back in the hands of the player. It makes sense to fix the scarab, but one should always be aware of the consequences in doing so. Bugs that affect the power of units are just as important as features. Fixing them, or leaving them alone, has tremendous implications because to the player experience it is still an element that defines that unit. Fixing the Reaver could easily make it overpowered. It would certainly make many problematic drop locations viable.

Brood War's balance is tenuous, defined by high highs and low lows. Spells that deal 300 unavoidable damage when activated, units that can instantly kill one another, and stuns that last an eternity. It is built on an "unbalanced balance" concept, even if Blizzard never envisioned it that way. It was the fact they didn't envision it this way, didn't try to build it to be an E-sport, but rather a set of opposing, wild swings, that rendered it what it is today. Nudging Brood War at a conceptual level could throw it all into the lardery. It is these "wild swings", these huge "unbalanced" characteristics, that give the races their identity. Between lurkers and bio, tanks and templar, the variables become less about x spell doing 10 more points of damage, but rather that, at the fundamental level, the elements are "overpowered". They balance each other off and hand the responsibility of managing that balance to the players. The huge, normal damage splash of Lurkers, the overkill of multiple tank shots, Scourge requiring manual splitting, Mutalisk dancing. A vast amount of factors the developers may never have considered and likely remain ignorant of to this day developed and shaped the game in a series of abusive tactics that lead into the evolution of counterplay rather than counterbalance. In some respects it can be said that it would have been virtually impossible for the developers to foresee even half the things that had defined Starcraft by the time Bisu appeared. But there's no excuse for ignoring it all in any title to be published afterwards.

Yin yang, unbalanced balance

This is what separates Starcraft from nearly every other RTS in existence and what defines it as the RTS. An RTS hands players a variety of tools to use in whatever manner they can think of within the limits of their own talents and reflexes. The tools work within a set of limits defined by their characteristics and ability to be exploited rather than raw numbers determining how they interact. Automation is kept to a minimum to allow players to explore flexibility within themselves and the game rather than pushing buttons and waiting for results. Brood War is one of the only games on the PC to make it close to the elusive "sandbox" genre and actually playing the part by allowing expression on the per-unit level as fluently as it does. There is room for improvement here, but we're not likely to see it in our lifetime. It is for this reason I ceased building RTS conversion projects and moved to campaigns instead. I know I cannot best Brood War.

Armies of Exigo is one of the games to attempt to mimic Starcraft in some ways. Armies of Exigo was very much intended to be a clone of Starcraft. However, it also introduced some elements from Warcraft 3. Bigger numbers, variable numbers, and similar resource systems. Armies of Exigo also had MBS and several other UI advancements, like being able to select buildings that had been placed but had yet to be started on. The combat was slower but still had a distinct characteristic about it. I felt that the higher unit count lended well to the wc3 stats, as it enabled battles to have their own dynamic, independent from Starcraft and Warcraft, despite the many similarities. It would be my second RTS recommendation to investigate.

Familiarize yourself with Brood War professional gaming. Regardless if you're making an FPS or an RPG you should know how and why Starcraft became what it is. I cannot express this enough.

Time is the True Test

Meta. You've heard of this word everywhere. Perhaps because Riot, a developer of a dota clone, enforces a specific Meta, and people complain about it.

Meta refers to gameplay characteristics adopted by players because of perceived efficiency or effectiveness. It is a widespread habitual series of actions or elements adopted by players for whatever reason - either because the balance allows for it to exist (World of Warcraft and optimal talent/glyph builds) or because of perceived effectiveness (units/builds being avoided because professional players aren't using them, seen very often in dota clones) despite the fact they may be objectively overpowered.

The subjective opinion of things leads to a warped understanding which can lead to a warped meta. As a developer you should understand that meta is a thing regardless of single player or multiplayer and it happens because of interaction between players, viewers, and general public opinion, and it also happens because of habits that develop over time and therefore has both local and communal presence. It may be small, like preference of certain items or spells because of minor perks, or it may be huge, like lane swapping, team vs team psychology derived from repeated scrims and expected behavioral patterns, or it may be game-defining, like the limited number of effective champions in League of Legends professional gameplay because of compounding player playstyles that exclude otherwise powerful champions from becoming conceptually viable in their composition.

"Upsetting the Meta", a common theme in Starcraft 2's repeated attempts to shake the coils of its suffocatingly bland unit design, may be an attempt made by a developer to unhinge the perceived style of gameplay their playerbase has adopted. For example, a meta in BW Protoss gameplay versus Zerg was the Bisu Build, a fast expand forge soon accompanied by early corsairs for overlord hunting and, eventually, Reaver dropping or dark templar. Zerg came to expect the slow start and corsairs and built around it. Players adapted over time to this build, players of all skill levels, and counters were eventually devised.

Attempts to upset the meta by introducing massive, sweeping changes to render certain behavior unviable are often considered negative, as games with deep enough gameplay may present the power for players to eventually make their own adaptations. Brood War is, again, one of the only games to convey a Meta that has continually shifted by the will of its players alone. Units once considered unviable or inefficient slip into gameplay once more, the balance of perceived racial power shifts, and new strategies continue to crop up - all without the developer ever touching it, not even so much as to fix Reaver scarabs or make otherwise inefficient units like the Scout more viable.

Often times the best decision is to wait and see and try to harbor an understanding for why players are doing things a certain way. Here, time is the true test. Some play patterns may be undesirable because they lead to stale or unenjoyable counterplay, like certain point and click champions in League of Legends being instant picks because of inescapable, reliable CC or nukes. Comparatively, in an RTS, point and click "I win" abilities and units tend to be big friends for meta shifting into lazier and mindless builds and solutions escaping otherwise uncertain variables in gameplay that rely on player versus player interaction. This is why, from the start, your design should avoid such things.

Meta is very much a thing in campaigns as well. High utility units and abilities that serve as jacks of all trades can easily trump most campaign mission designs in any given game, because campaigns rarely have computer AI and tend to rely on timed waves (see: Starcraft 2 and marine/medic). Having a functional AI is critical for a campaign to begin with, but doubly critical to help combat potential meta developments trivializing mission design.

Utility and Utility Creep

A common theme in dota clones and RTS alike is utility creep. It is an opposing pitfall in player control designs that can lead developers to introducing units who are capable of serving multiple tasks with relative efficiency.

A great example of a unit with extreme utility creep is the Marauder from Starcraft 2. It has nearly as much health as a Siege Tank, is ranged, has stim packs, can be healed, and slows enemies it hits. it also deals a whopping 20 damage to armored from the getgo. The only real solution to Marauders is heavy-handed hard counters or air. The Marauder forms an unholy trinity with the Roach, who has similar health and damage values, and the Immortal, who, again, excels at anti-ground combat and has extremely high defense and offense.

When we look at the damage values in Starcraft 2 compared to Starcraft 1 we see an enormous escalation of speed, range, and damage values. The obsession with making Starcraft 2 "faster, more intense!" has robbed it of much diversity in unit design and backed Blizzard into a corner with balancing. Many units become homogenous in attributes like speed and range, depriving them of the potential to make otherwise bland characteristics accented by unique strengths and weaknesses.

Across the pond, League of Legends has made a habit of ensuring almost every Champion has some kind of CC and mobility ability as well as a % health damage ability. One of their "designers" in particular has ensured virtually every champion he's had a part of has a proc based on 3 AA hits. All the champions who yet lack these broad and easily accessed power budgets become less and less viable as the utility arms race between new champions continues to escalate, Riot continually seeking to "outdo" themselves with each successive design. This reached a pinnacle with champions like Thresh who have a multitude of extremely versatile CC abilities applicable to nearly any situation and became mandatory bans or picks from their release onwards.

This is an extremely easy trap to fall into. Once you recognize you want players to express themselves you can become trapped in the circle of wanting to give units enough flexibility and power for players to exploit. Crowd control and mobility are low-hanging fruit, intrinsically laden with the melee versus ranged kitefest and nuke-heavy design that all similar games have. The common issue with such titles is the mismanagement of power budget in ranged units, balancing based on numbers rather than potential strength of the ranged unit. Riot manages to flip this in the opposite direction by handing tanks extreme survivability and means to ignore distances or CC their target to death. Ranged DPS classes, especially AD Carries, are relegated to support roles, as their damage-dealing ability is directly correlated to their team's ability to CC the enemy team to death first. Forgoing elements regarding positional plays and picks, league enters a vicious cycle of gnawing off and then adding power back to either end of the spectrum, failing to find viable balance for years on end. The issue becomes more and more apparent the more champions are added or revised, as every addition and revision tends to raise or contribute to the bar that utility is power.

Utility is a means of describing something that has multi-purpose uses. A marine, for example, has utility in that it is ranged. 10 marines will put down far more damage than 10 zerglings on a single target, can engage earlier, can engage faster, and can engage from a distance. Marines can also attack air, and have stimpacks. Zerglings may be faster, but it's insinuated zerglings will take damage or start to die before they begin to pay for their cost. Zergling budget is weighted entirely into speed and damage. Their utility mostly comes into play by being comparatively cheap and faster to produce, but is limited by your inability to heal them, offset exclusively by dark swarm.

Units like the Colossus who are comparatively cheap and can "do everything" short of attacking air skew budget values and have exceptional utility creep, making them useful in many situations regardless of how they are used. There are very few weaknesses to the Colossus, mostly in its vulnerability to AA-only units, which is easily played around, and their vulnerability to anti-armor hard counters. But their effectiveness in general combat, speed and flexibility makes them one of the most powerful and least interesting units in the game. An even worse offender is the Sentry, whose Force Field that prevents movement has colossal game-deciding implications at nearly every turn. Such a simple spell, yet its utility is truly immense as it dictates where enemy units can be, if not outright paralyze them, allowing units like the Colossus to vaporize entire armies in half a second with their splash damage. While comical to watch it is unhealthy and frustrating to play against. Since then Blizzard has allowed some units to crush barriers, I believe, but the spell really should just have been redesigned from the start.

It is not that super powerful spells like the Sentry's Force Field should be entirely avoided, but rather that, if you're going to add them, ensure they have some nature of counterplay available, and that they do not, with the press of a single button, trivialize a ton of gameplay content. Homogenization occurs when all units have comparable utility or overlapping utility and function that discredits individuality, and hard counters occur when utility and interaction between units becomes overly lopsided and dictates forced responses. Starcraft 2 has a mix of new, high-utility and high-counter oriented units on top of a bunch of units based on their Starcraft 1 counterparts with comparably tame foundations. These design mixmatches are what lead, in part, to its balance troubles. The unbalanced balance concept has a much harder time trying to breathe in this environment because of the mismatched paradigm in design theory.

Utility can be expressed in many ways. Not just how fast a unit responds but how it responds. Stutter-stepping in Starcraft 2, which is the sloppier cousin of patrol micro in Starcraft 1, can enable units to fire while moving because their damage point is immediate on the animation. As a result balancing units like this can be tackled in manners other than changing health and damage values. Indeed, the problematic colossus could retain its attributes but have other weaknesses that help identify it, like how the weapon travels (making it travel at all), how fast it turns, so on so forth. All of its elements compound one another - instant aoe damage, high mobility, high responsiveness, high health, and long range. In a similar respect, Mutalisks, although numerically similar in sc2 to sc1, are comparatively far less effective than their sc1 counterparts due to the differences in how the engines handle air units.

Again, if we are considering balance in the concept of unbalanced sides balancing on another, high utility can easily defeat this by handing something an option that has broad reaching applications that then, in most instances, force multiple responses from an opposing side to equalize. If we accept that we can never achieve true equalization then high utility has even less of a place, as it will encourage builds and stratagems to be built around the one element instead of being free-moving. And, again, this element isn't necessarily a negative connotation in itself. Marines, comparatively high utility units, lack true individual strength in any region and depend on Medics to be truly potent. Moderation is the control rod that determines the true effective power of otherwise high utility units, further reinforcing that we should avoid things like hard crowd control because of their flat effectiveness at all levels of perceivable power. This goes for all games - loss of control is one of the single most powerful ways utility can be exposed. See - ARPG's and hit recovery.

Armageddon Onslaught

A Proof of Concept and Technical Demonstration

Armageddon Onslaught derives from several core fundamentals, then expands outwards into creating a unique experience in a genre that is otherwise extremely overpopulated with comparatively diminutive ventures. AO is not my largest undertaking, but it has been my most successful within Brood War. In this article I will touch on the thought processes involved in its creation, AO's origins, and some of the story concept.

Picture back when you were young, impulsive, easily influenced. Horror movies still gave you nightmares, the boogey-man was still real, and games held a degree of immersion. When I was young, and Starcraft was just released, I could live it. The fog of war and the unknown nature of the zerg to a mind completely unfettered by literature like Lovecraft and Warhammer allowed me to embrace the Starcraft world as a mysterious and hostile place. Then the campaigns ruined it. Then I started reading and, well, I never looked at Blizzard games in a positive light again. But when I didn't know anything none of that really mattered. Being young has the innumerable benefits of ignorance.

Diablo was much the same way. The thought of struggling for survival in a world where everything and anything can hurt you appealed to me. The challenge to rise in power but end up reaching deeper into that well of darkness that inspires terror and mystery. I wanted to mimic this environment. This hostile world where every step into the darkness feels as though you are discovering something new and potentially deadly. Where no matter how many times you traveled down this road every time was different. As I matured and grew to despise many Western attempts of such environments I often pursued means to twist those interpretations at the conceptual level, and tried to understand why they lost their value merely because I knew they were creatively bankrupt. Indeed, it comes down to less about the originality of the subject matter but more about the execution.

When someone sees a beast or a demon they feel threatened because they are alien. This feeling is best emphasized by a careful mix of knowledge and mystery. You may only know of this creature in passing, enough to know it's powerful. Yet you don't know what its full capabilities are. This is what Armageddon Onslaught establishes from the start. In the game you can select the unit and know its name and base damage (some don't even display damage because of lolhardcode), but you have no idea what it's going to do until you actually face it in combat. Small, fragile units like the Damnation and Oblivion can actually turn out to be extremely devastating if not dealt with appropriately. You won't know that until you face them in actual combat. There are no handlebars, no warning indicators, no helpers. Just you, what you're familiar with, and then the enemy, which you are not. Creating that barrier between familiar and unfamiliar was the staging point of AO's unit design.

Conceptually, Armageddon Onslaught's "Fear of Threat" comes from the deadliness of its units and not necessarily their appearance. It relies less on grimdark and more on the proposed danger that the actual elements provide, a total opposite of modern "horror" games who rely on cheap movie tactics to try to surprise the player or hope to obscure their elements through post processing. I want the player to feel like he is still in control of himself, but that the world around him is very much alive - and against him. Interacting with the elements that are dangerous to you makes them more real and believable, rather than just trying to tell you "ok be scared of this just because xD". Knowing and sensing an enemy is making a legitimate attempt on your life is a far more real experience than a lense flare and color tone filter.

Armageddon itself is derived of these feelings. The feelings of mystery and fear. I give players something they're comfortable with - the default races - and I set them up against something they know little about. After that, it comes down to instinct. You know how to play. You know how to win. But do you know how to fight against an opponent such as this? Building the concept of the demon race into a means of interaction rather than just a name was the burden of the unit design.

Too often writing will humanify demons and beasts to reduce their presentation down to that of 80's cartoons (Zerg in brood war, Xel`Naga in sc2, orcs, Undead, etc. in wc3) and give them mundane one-liners to spew alongside uncreative social structure that downplays their threat (Covenant in Halo) with the goal of making their inner structure less alien and less difficult for casuals to absorb. With Armageddon I wanted their initial presentation to lack all elements of structure other than that the longer they were present on your world the stronger they became. Only with their God, The Great Destroyer, did their presentation start to manifest.

The Great Destroyer and the Will of Armageddon

When I played Guild Wars: Eye of the North and constantly heard of the title "The Great Destroyer" I had always imagined him to be bigger. Bolder. More intelligent. A sinister evil but a terrible evil. Instead you got this kind of a chicken-like thing that wasn't terribly difficult to cheese your way into killing. While the Destroyers in Guild Wars had an interesting and alien enough presentation, how you ultimately destroyed them was as lackluster and anticlimactic as a game could get. They never really were a prominent threat in the campaign, even though the campaign did much to talk them up at points. They never felt threatening because the execution of their design was abhorrent. They had all the assets they needed. They didn't use them. I didn't want to repeat this mistake, despite AO as a project being a mere tech demo.

With Armageddon, I wanted to create a name that players could instantly recognize. Instead I ended up with the title "The Great Destroyer". I thought, "Well, it fits, so let's keep it." Ultimately, The Great Destroyer acquired a real name - Alkhazir.

The Great Destroyer is essentially the Devil. The incarnation of evil and the will of evil. He exists for one purpose - to sow the seeds of pain and despair. To burn and destroy, to consume and corrupt. He is the very enemy of the Gods and mortalkind. His dialogue hints at his history - alluding to Roman Gods, some of which are his twisted servants to be seen shortly before his appearance.

The Great Destroyer's design changed a great deal when he was translated into the various Apex concepts, but during the creation of the original Brood War project, I had no such intentions of diversifying his history. After all, I couldn't present writing in Brood War. I could only present that emotion and sense of personality through the unit and the unit alone. Limitations can be seen in a negative light in many respects, but they are also often the single most powerful forms of creative inspiration.

Bringing Armageddon to life

The concept of a demon race is not something new or original. Indeed, by using the Terran and Protoss races as our protagonists, I surrender any form of truly original basis. Yet, I had the opportunity to provide a unique experience for players and for spectators while at the same time challenging a variety of old questions regarding the possibilities of Starcraft modding. The question was, how would I turn these visions into reality? Although AO was damned to be little more than a tech demo, I was not content to leave it at that. I wanted to make it all it could be.

The wave-based Tier idea plays upon the designs of old UMS maps that gave players hero units with the mission to survive increasingly difficult waves of zerg units. Instead of heroes and crappy terrain, though, we now have our own races and whatever map we want to play on. To produce something that could challenge a team of skilled players or beefed up computers, I had to reach back into time and pull out all of my shelved concepts from mods ranging from 2008 to 1999. I reached back into the very humble beginnings of my Starcraft modding and looked for my old ideas.

The biggest motivation behind this project was access to Diablo 1 graphics, courtesy of Nottingham Systems, and infinity-engine graphics, courtesy of a bit of grunt work and some logistic support by poiuy_qwert. Once I had these graphics I simply reached upwards into my anus and conjured ideas for them.

The Pit Lord was the first unit to be born, but only because it existed as a part of my Sarenubus Kaladonmus tech demo. SK was intended to be a 10-12 mission long campaign featuring the Zelconian in a sidestory involving Sarenubus' struggle against the Anahn within TOA, my major writing world. As things tend to go SK was never started on and the tech demo was forgotten for quite some time. The Pit Lord, though, was the first unit to be added into AO and helped set the bar for future units. It literally told me, "Dudes should be at least this insane to be added".

The humble beginnings of what would eventually consume nearly half of brood war's tilesets and doodads, the Zerg race, and almost all unused slots available. AO required a sprite limit expander to even function playably in the first place. It redefined what people expected out of the game's engine.

Shortly after, I got a hold of Belhifet's graphic which I soon used for the Madness Titan. The Madness Titan is a truly fearsome opponent and it was with his creation that I really set in motion the mod's unit list. I had a lot of ideas for units but most of them turned out to be impossible with Starcraft's limitations. For example the Fallen Hero was supposed to fire a volley of projectiles that would randomly explode mid-flight. That was not possible. Also, the Damnation's projectiles were supposed to have random speeds in addition to random damage - also impossible. Brood War's projectiles seem to be loosely derived from their unit systems but most iscript opcodes related to to air unit movement and other such "specialized" behavior do not do anything or just crash for them. Had I been a programmer I could have reverse engineered the game and made my own plugins to fill the holes. Ideally I would have been able to rewrite a lot of things that caused me headache, but I am no artist and I am no programmer.

While I was introduced to porting in AO's era my skills had not yet matured well enough to port 3d models to older sprite games in a cohesive manner. It took a tremendous amount of work, and a little help from SgtHK, to port this one WoW drake. With it, though, I was able to create several variants, including the phantasmal Ghost Dragon, which many other modders thought was impossible due to the way transparent palettes work with units.

The Fallen Hero, voiced by Snowfender who has since quit voice acting, was intended to have a far more diverse weapon set than the Plasma Glaives she uses for her base attack. Alas, she was one of the units left unfinished by AO's release.

The unit that gave me the most trouble overall was the Great Destroyer himself, and he's still not perfect. I had planned to add a ton of overlay effects to him but as my motivation continued to plummet I realized I'd never get around to it. The biggest problem with TGD was the fact that he'd randomly lock out commands until you pressed "stop", something the AI can't do even with sigorder. I discovered that this was because of the game not running the "walk" animation thread in some rare instances when the unit wanted to move, and TGD needs that sequence to initiate his teleportation code. You see this problem a great deal in Starcraft professional play, in fact - control grouped Mutalisks flapping wings slower, wraith engine graphics not appearing, all of these are from the same bug. I tried to make workarounds for this but the AI still sometimes gets him locked out, usually over water, for some indiscernable reason. AO's troubles continued with my attempts at Starcraft 2's iteration of the project, with its performance making any project even remotely in the scale of a melee replacement entirely impossible.

SC is not a fun game to mod when you are trying to force your way through its many hardcoded problems. It reminds me a lot of trying to make my campaigns in warcraft 3 and running into problem after problem with the AI or pathing. It would be a premonition of future roadblocks as well, notably with Sins of a Solar Empire and Starcraft 2. All of these games are extremely heavily dependent on hardcode and hacks to bypass otherwise easily avoided problems, and for a modder this will always serve to be an annoyance at the very least. Neither Warcraft 3 nor Starcraft 2 could handle unit counts comparable to Brood War, and that's before you threw computer AI into the mix. As a standalone game Starcraft 2's AI easily cripples even top of the line computers 5 years after it came out. Hardly suitable grounds for any mod. That's notwithstanding the censorship and size limits sc2 enforces on all custom content. AO, as a sc1 mod, already skirts dangerously close to sc2's space limits. Imagine a real project!


Things would have looked promising for AO2 by 2012 with my newfound ability to model mechanical environments and maturing port skills, but Brood War was the last game engine to be seen that could support even a shadow of the concept until Unreal 4. Unfortunately, big dreams often crash small and very quickly.

For sounds I mostly used a bunch of sounds directly ripped from infinity-engine games. I had a few voice actors assist me in voicing a few of the Legendaries, but not all of them got voiced like I had hoped for. I also did not completely finish the work on setting the units up for samples, such as for the Lord of Terror, who plays his sounds far too often. During AO2's concept I was practicing a much more involved take on the sound assets, and planned to voice many of the mobs myself. I was also going to redo all of Starcraft 2's vanilla sound effects and totally revise the existing races, a common theme in all of my Starcraft 2 project concepts. Unfortunately, the other common theme was that my testing always yielded the AI and performance to render such projects impossible, even though many extremely promising data, tactical AI and graphics concepts had been developed throughout the years for my designs. AO2 taught me an important thing even if it never left prototyping phases, however - I wasn't really interested in the project as a design anymore.

As a representation of an RTS project AO was merely a revised embodiment of existing survival maps. It was the first iteration of those maps in a mod environment, unless you could my original AI projects predating AO's inception, such as Scorpy's AI and ZONS. Indeed, it was these AI projects that eventually lead to AO's inception. However, as a proof of concept, AO rendered many problems evident from the start.

•  Without micro the AI's reliance on proc-based abilities made combat unpredictable and unreliable. This lent to challenge in some respects but would lead to frustration in others, particularly when very strong abilities, like Zeus' lightning storm and Mal`Ash's shockwave, would come at entirely unpredictable moments and easily cost you the game. I didn't want to build warning marker telegraphs into any abilities, because that's retarded, but I did want there to be a logic in which the units used them, so the players could conjure counterplay. The hardcode regarding AI was the single most damaging element of the design, and without full, total control of how the AI behaved, AO would never be balanced and never truly fun to play. This, of course, was one of the few things that Starcraft 2 had going for it - tactical AI would have been a huge boon to the project. Alas, this was the sole thing sc2's AI had in its favor. The AI simply wasn't capable of doing the other things Brood War's AI did nearly as well as Brood War did them.

•  Armageddon's base was either too easy to destroy or too difficult to destroy. Without proper defense logic the AI could easily be cheesed or rendered nearly unkillable. There was no real middleground that could be achieved. The starcraft 2 version was going to centralize gameplay around destroying Alkhazir in his sleeping state or after he awoke, so defense rules and gimmicks could be centralized around that single unit.

•  Mods that depend on a player having friends are stupid because 99% of mods are played solo in all but rare circumstances. AO's balance could wildly swing depending on the numbers of human players present, because human players knew how to abuse things your AI allies couldn't abuse as much even though they cheated like hell. I created AO under the presumption that the player experience would be solo, but in playtests with other people balance problems were greatly pronounced in nearly unpredictable ways. This helped to expose the underlying issues with balancing based on numbers and procs. It was, however, a critical part to understanding why those systems were flawed. This plays heavily into the AI element of the design and further highlights why functional AI is so critical to a mod. The AI must be able to perform as well as a player in any circumstance.

•  The original writing was horrible.

While I built AO from the ground up to be a barebones experience, once I first explored the concepts of the Great Destroyer and his related history with my first campaign scripts in sc2 I met a variety of logistical problems that came as a direct result of that heritage. Ultimately I ended up entirely rewriting everything related to Armageddon's concept for Apex C, and much of the original theatrics and hotblooded concept have been reimagined for the purpose of bringing Armageddon into the Realm circle for Apex's core concept.

The evolution of Armageddon taught me many things, and that is that the simplistic manner of Armageddon's original design and designs like it cannot be elaborated on if they are to survive logically. In much the same sense as how Kerrigan ruined the Zerg, growing outwards from The Great Destroyer's design and bringing Roman history into the concept seemed like a good idea, but it also diminished the original image and served only to cheapen the original intent of Armageddon's presentation. By needlessly building out in unnecessary angles Armageddon's concept was destroyed as a byproduct of its own growth.

Indeed, this falls back to my reviews regarding games like Symphony of the Night, who survive almost exclusively on presentation with very little world building between them. The original Castlevanias had some dialogue and some history, but relied very heavily on presentation and execution to fill the game world. They worked brilliantly in much the same sense as how Armageddon's original concept would have worked brilliantly had it been completed correctly.

Such concepts cannot exist if they have to grow, however. You risk diminishing the prose and presentation enormously by adding things on top of what relies on the prose and presentation to exist at all. By trying to humanize the zerg and add Kerrigan as a face to them Blizzard ruined all elements that gave the zerg their mystery, their threat, and their wild nature. They no longer appeared as hostile and dangerous creatures from beyond, they were simply toys for some creatively bankrupt comic book villain who existed exclusively as a love interest for the protagonist.

The Great Destroyer had even less than that for him as a character but, like Dracula ruling over a castle that changes every time you step into it, he did not need much more beyond the few lines of dialogue he was first presented with. Even the title The Great Destroyer scarcely survived the rewrite, as it no longer fit the context of the character. At this stage the retcons were as enormous as Blizzard's own, and Armageddon as a name did not survive the rewrite, left to exist only in the context of the Brood War tech demo. Here, in the walls of a confined and very limited presentation, the design lived and died as a proof of concept that never quite proved anything.

Armageddon Onslaught was a miserable failure.

Armageddon Onslaught, as an experiment, was a total failure. As a tech demo it proved many theories of mine were entirely impossible, while some others proved interesting enough to show off. It brought talent from all corners of the dead community together and condensed them into a spastic mess. As a concept it did not survive beyond this, as a mod it is virtually unplayable, and as a proof of concept it proved the concept cannot be done in almost every game engine to the date of 2015 in the scale it was attempted in Brood War. If I was to become a programmer then I could probably achieve it in either Unreal 4 or by rewriting large portions of Brood War itself.

ITAS

My third TC project, back in year 2000, was a Fleet Mod. Along with Dominion War by Jstek, I produced amongst the first ever Fleet Combat Simulation mods. But the concept didn't really kick off until 2004 with the production of In The Admiral's Service, although many of my viewers felt that 2003's UF was superior. UF, however, was more a dabble, and while it saw extensive content created for it, ITAS was the edition to stand the test of time.

ITAS was created not to establish a concept of Fleet Combat, but to exercise modeling techniques in Rhino. However, once it appeared at Staredit.net and Maplantis, it became wildly popular - enough to spark a number of modders to try their own hand at creating Fleet Mods, including Ad Astras and Temptation. I later intended to finish ITAS but lack of motivation and crashes from the limit expander cut the project short.

ITAS was still played significantly more despite its incompletion and lack of strings, and ultimately, I felt its design withstood the competition until the end of modding's days. They're good mods, but in my eyes ITAS' fundamentals were left unchallenged by all derivatives.

Why?

First we must understand the basics of the Fleet Mod and the foundations that ITAS was built upon.

The Basics

A fleet mod entails that all units must be air units. This immediately removes the concept of terrain value and largely decentralizes the gameplay from map control and strategic movement. With ITAS I danced around with the idea of anti-matter ribbons and other terrain obstacles, but never had the opportunity to attempt such a massive terrain overhaul. To gain back elements lost by removing terrain equations you had to play with vision, ranges, and per-unit interactions on a more macro scale than you might normally. This lead to the rise of the high tier tech trees and, in the case of many derivatives, attempts to change starcraft's economy system. Either because of lack of commitment to revising unit concepts to major stages or because of different design paradigms, most other creators opted for economy-related changes.

Although Fleet Mods are total conversions, like all mods they should follow several key gameplay elements presented by Starcraft. Although mods aim to change the gameplay, often significantly, one would be wise to pay attention to the fundamentals that make Starcraft so popular. All of the lessons we have learned from our observations of professional play will tell us that changing fundamental mechanics requires, at the very least, a great deal of research into the implications of our changes, much less asking why we are changing them at all - such as the damage system and the economy system.

Most fleet mods orient around the combat of capital ships, using fighters primarily as support. This is the biggest limitation of the fleet mod concept - it is very, very hard to balance strike craft against capitals. Stat-wise, capitals will always be stronger and you can encourage turtling too much by poor strike craft design. As strike craft that are too expensive and too frail will mean that the only easy and fast way to access the enemy player is defeated because the defense will always be superior to the offense. This will encourage players just to take up a position on the map and hold out until they get the biggest, baddest ships and can confidently and slowly roll across the map, killing everything in sight.

With ITAS, I went with two totally different race designs. The Undead focus on frontal weaponry and have a very basic tier-based system. Their ships tend to specialize in specific tasks; the Shadow Dancer is a debuffer, the Dragon is a light artillery, and the Blood Moon is a support artillery. Meanwhile, the Xenon Project had a wide variety of tiers based on ascending classifications.

Generally, you shouldn't touch Starcraft's economy system.

Until the derivatives from ITAS began to appear, however, economy was often left largely untouched, particularly because anyone who wanted major changes needed considerable ASM skill, and that simply wasn't a talent that existed in the survivors of modding except for a small resurgence of tool developers that showed up at this time. It was around now that we really began to see attempts to radically alter the game's economy fundamentals. The best example I have on mind is Temptation, which gives gas to you in the form of resource injections (or, on the map I played, whoever holds the center gets the only gas geyser on the map). Injections in general lead to a whole host of problems, but with a "fleet" mod in particular, the problem is compounded two-fold.

Because every unit is an air unit they are much more mobile than in vanilla Starcraft. Even if they are really slow, they can cross the map at will and aren't restricted by cliffs or choke points. This will naturally discourage players from taking map control. Even though ITAS was played largely on money maps, every base only had one gas, and units became very, very expensive as time goes on. This is an extension of the concept of vanilla starcraft; A five-base zerg can readily go Ultralisks, but a two-base zerg will be gas starved and kind of screwed. The idea is that as the game progresses, players take more and more map control to exponentially increase the resource income. Since it's difficult to turtle in ITAS because strike craft are very fast and if you ignore expansions you're going to get boned, you are always macroing and in a state of production or upgrading. The more expansions you have, the more affordable the late tiers become. You can hole up in one base and try to rush for blood moons or battlecruisers, but that's just the same as trying to 1-base battlecruiser rush in starcraft, except much more time consuming.

The starcraft economy system is simple but it works perfectly. There is absolutely no reason to diverge from it. It's a simple concept and when you start monkeying with it you run into difficult balancing challenges. Using Temptation as an example once again, resource injections make it extremely difficult to reach the high-tier ships. This encourages players to turtle and wait for injections so they can build the big, bad megaships which typically utterly destroy the weak ones. This is further compounded by the rule that defense is stronger than offense; if a player loses his investment, he can't make it up by having more bases or factories because his resources are linear. The exception is of course when a player rushes to the gas geyser and turtles around it. Every tick of the gas geyser creates a void between the two players, a void which is virtually impossible to recover - even if the geyser is lost and taken by the other player - because intelligent investment of those resources can be immediately applied at that time. An injection is an indirect way of applying direct power that is extremely hard to rebalance once actuated into functional budget. Consider the special resources in Heroes of Might and Magic, and the units that depend on those, and the power they possess if one player possesses x more than the other. Consider then when a player can control those resources very easily with dimension door or similar spells. The system invests heavily into snowballing and allows players to easily decide the fate of the game, given they are of comparable skill level, within the first few injections.

While a custom economy system can be created and tweaked to perfection, this is rarely the case and it takes much more than just a few months of testing with a handful of guys to perfect something as wildly different as resource injections or regional control bonuses. Most of the mods I've seen to date, with the exception being STF, that implement such an insanely new system end up coming out really bad. The concept is there but actuation renders the troubles not worth the reward. Changing something just to change it does not mean you are improving the equation. You are only moving pieces around until you re-align them into a cohesive shape. High-mobility unit mechanics oriented around time-constrained resources creates an opposite of design schemes.

The metrics helped determine the development.

Something that really bothered me about the SEN community is a comment someone made during my time there. Something along the lines of, "Modders are all terrible melee players". From my experience this tends to be a correct assertion; there are decent players in the community but those are not the mod designers. Another common problem that is notorious with other modders tends to be extremely bad balancing. Now, I'm not exactly IdrA's rival, destroying foreigners left and right, but out of the games I played with modnighters I was often struck with how terrible they played. It wasn't that they were stupid people or anything, it was that they didn't understand the basic concepts of Starcraft gameplay. Almost every mod is simply an extension or mutation of this gameplay, so this terribleness ends up extending to the modplay as well.

One has to wonder, then, that if they don't understand Starcraft that well, how can they design a hugely different economy system that no one has done before and hope for it to work as fluidly and balanced as the original? Why would they choose to tackle such a colossal, fundamental system if not only to reduce the skill cap so they themselves can reach it?

A player doesn't need to be an excellent player to understand a game. Consider the role of technical commentators - individuals who analyze the game and get into the minds of the players. In order to understand their job and present their roles fluently they must have a virtually unequaled understanding of the game. Otherwise no sensible outfit would hire them to do their analytical casting, right? In many cases these casters are players who otherwise are not good enough at the game to be considered professional, or are only good enough to understand the game at a casting level. During my time with Brood War I became much like that - I had a strong understanding of the game, but I couldn't play at the level of my knowledge. Indeed, analytical processes became more part of my time with the title than actually playing it. I believe this is a sentiment shared by virtually no other developer who had put major work into Starcraft custom content, although it was shared by a few of the players. This hurt those who sought to tackle Starcraft's biggest systems.

That isn't to say that mods like Temptation are failures. But the very thing they aimed to make their mods unique - their economy systems - end up working against them. Not necessarily because they're complex or simplified, but because they detract from the gameplay experience by changing an aspect of the game that doesn't need to be changed and taking away from the game key elements established in Starcraft's lengthy lifetime. In much the same sense we don't change the armor types or how we deal damage just for the sake of changing them, we shouldn't change the resource harvesting system "just to be different". That is because if we are going to change them, we need to have an extremely well-educated foundation to support those changes. These mods wanted the player to pay more attention to their economy, which, while a noble intention, often ended up equating to just waiting for the economy instead of interacting with it. STF's regional control is something much more interesting, because that is interactive and plays into map control. STF isn't a fleet mod, though, and a fleet mod utilizing a similar system would be easy to turn into a mess.

Think about Command & Conquer. A game series whose economy often degrades into injections. Oil Derricks, Hackers, supply drops ect. These aren't intuitive. They're boring. They add nothing to the gameplay experience. The games drag on and turn into turtlefests. There's a reason why C&C's many installations never approached Starcraft, and we can attribute that almost exclusively to the gameplay. We should figure out why that is the case before adopting mechanics and ideas from objectively inferior titles. Isolating why those systems didn't promote more meaningful play from those titles, either because the titles and their content were misinterpreted or because those systems were bad designs, will help us decide whether or not we should even bothering entering the arena of changing fundamentals in the first place. Or, we can decide to forgo this analysis, and instead make comparisons to draw alternate conclusions in their stead.

Indeed, if we are considering the context of a niche audience, we can throw out the comparison of titular successes as a body. Then, instead, we can look to the objective level of interaction and consider how our players are dealing with the systems as individual bodies. An injection based system promotes an amount of effort to secure the maximum possible injections and then periods of null-interaction before actuating on acquired resources. If the injections are drawn from map elements and not structures (Dawn of War vs Supreme Commander) then the potential skill cap and mechanical depth surrounding the systems becomes directly correlated to the map design and depth. A system built around actively acquiring resources to then actuate promotes a continual span of attention to not only secure a relatively unscalable amount of resources but to also ensure the resources continue to flow. This flow is continually actuated upon and resists bad play by encouraging continued efforts to defeat float and maximize efficiency, where otherwise injections, once acquired, no longer have active value until they are again acquired, opening a void of non-interaction. Additionally, active resource allocation promotes more map diversity and offers more flexible means to balance said maps, as otherwise individual perpetual elements leave little room to diversify. See: Mineral-only expansions. Worker units, as opposed to invisible money appearing in your bank, is also another element for both the owner and opponent to make plays upon, creating further opportunity for interaction and potential mechanics.

If we consider that a resource injection is a non-interactive element because it removes active player involvement in its acquisition, and distill the injection to its root concept; resources being handed to the player, much becomes clear to us in our comparison.

A non-interactive element need not exist in an RTS. Hard counters and their ilk are non-interactive elements, voiding player creativity and relying exclusively on number interactions that occur under the hood regardless of user intervention. Again, this rolls back into the QTE argument, where preset arguments determine the equation in a weighted manner regardless of player skill level so they can nullify player expression. In an absolute perfect environment, which may well be impossible to achieve, numbers are merely metrics determined by player motions rather than mechanics entirely. But an RTS depends on numbers to facilitate strategic diversity to some extent, so it is an evil we must bathe our feces in regardless, if not without due moderation. Were we to become too accustomed to the taste of feces we may yet find ourselves in the Stallman's closet building Diablo 3.

In the same manner, individual harvesters returning resources are considered injections, and the applied comparison of higher worker counts over individual worker counts brings us instead to the concepts of map control and ground control-styled control points serving as injection nodes. Again, the snowball gameplay is heavily biased towards early birds getting the worm, as displayed by Dawn of War and the suffocation of critical units requiring specific points and snowbally map control to attain. Dawn of War is the perfect example of how not to make an RTS or an RTT in virtually every respect.

Supreme Commander's resource system is sort of a mix between the concepts of harvesters (mass extractors) and the concepts of injections (mass fabs and power generators). Because resources are also spent in a continual manner as opposed to lump sums, it becomes a game of balancing net income over net loss, all the while still avoiding float. The manner to acquire injections relies on two resource structures, both of which are often volatile and vulnerable, and compound each other for cost effective bonuses. This also then depends on more active map control (extractors being the most efficient mass income, but need nodes to construct), and although supreme commander's maps are just bland heightmaps, this is certainly the seeds of an injection based system done right. However, without major reverse engineering, this system is entirely impossible to create inside Brood War. This system, however, only truly shows its value in early to mid game, and by late game becomes of little consequence to lose attention on.

Supreme Commander would have benefited from map design. It's because of the presence of terrain complexity, elevation, choke points and logistics that economic macroplay begins to get interesting. It's why Heartbreak Ridge is so much of a different gameplay experience than say Python or Andromeda. Their economic setup is totally different from each other even though they are both using the same system, which is resource harvesting. Dawn of War had ground-only design for the longest time, but it had no map design whatsoever, which heavily contributed to its bland gameplay. Of course, with counter-based squads being the centric of unit design, map design would have offered little for tactical exploration anyways.

ITAS and my horrendously badly terrained maps were an extension of map control concepts on paper, but on the flip side, with air-only units the design can only extend so far through implications. I tried to build into the concept of vision forming your map control rather than the direct position of your units relative to cliffs and chokes. By placing expansions at key locations, generally in a non-symmetrical pattern, each location of the map held different value. In a mod like ITAS where you have extremely fast strike craft capable of doing a lot of damage, the position of your main fleet is important. Despite strong defensive structures defense isn't always strongest in ITAS. Usually it's very, very bad to find an enemy fleet near your base, where they can destroy expensive structures in the blink of an eye. This plays in a different part of Fleet Mods, one that is very difficult in my opinion to get right because of the traditional limitations of SC.

Intelligence and the Information War

Scouting is a huge thing in Starcraft. Denying the enemy's SCV from seeing your hydra den and only your spire, or tricking him into thinking you're going for mutalisks by allowing him to see your spire, stuff like that can often be big and even game deciding. In ITAS, not necessarily all Fleet mods because each developer designs their races different, scouting your opponent's base isn't really that big of a deal because build orders aren't extravagant. It's more important to know how many bases they have. It's important to know their upgrade level - upgrades are huge in ITAS - but most importantly, the position of their fleet is most important. In vanilla SC, deceiving your opponent that your army is moving across the northern valley in Heartbreak Ridge can be deadly if in fact you're moving along the south ridge and flank him. In ITAS, the majority of ships are capital ships and, especially for Undead facing Xenon Project fleets, knowing where that big ball of death is can make a huge difference. Likewise, since the Undead possess two extremely long-range artillery ships, the XP must know where they are at any time.

This isn't a concept I was able to expand upon very much. In SC2, the sensor tower and its map blips are something I would have loved to have in vanilla SC - to implement the concept of space probes and "pinging". As it is, both races have access to scanner sweep (Peeky station and the Crusader supership) which is a little too powerful for my liking. If I know that the Undead fleet has a bunch of Blood Moons trailing behind it I can easily swoop around them and get into their blind spot.

ITAS was originally designed to be played on 512x512 and 1024x1024 maps. The project was discontinued when this was discovered to be impossible to achieve, presumably because of some limitation with the minimap (SCMDraft can make these big maps, but sc won't work with them). This made fighters a little bit too powerful. Okay, they can't fight a battleship head-on unless they have some serious upgrades, but they are really, REALLY fast. Ideally, I'd loved to have given fighters and stuff some kind of dodge ability to avoid heavy guns, or better yet, give capital ships special weapons which could ONLY target fighters and vis versa. But such is the stuff of dreams. Fighters end up being great for scouting because they're cheap and fast, which isn't the role I intended for them. In the perfect world fighters would all be carrier based.

I think that an aspiring modder looking to make a fleet mod could possibly do something really cool with plugins in terms of the information war. A lot could be done to improve the depth of tactical decision making based on guesswork and pieces of information rather than either knowing where the enemy fleet is or having not a damn clue. This to me is the realm for exploration, and not necessarily the economy system.

Unit design

ITAS had 3 races conceptualized - Kaloth Industries, Xenon Project, and the Undead. Each had dramatically different unit designs, a little similar to SC's unit designs. None of the races in ITAS were ever finished; the biggest drawback of the mod by far, and probably the biggest reason why other developers chose to take a hand at the concept themselves. But the two races were quite playable.

Kaloth Industries has big, beefy ships with high cooldown, high damage, and high range. But they were expensive, they turned and accelerated slowly, and they didn't have a lot of flexibility. They relied most on the Information War concept; they needed spotters for their big guns and generally wanted to avoid being caught up in a melee. In the newest version of the mod they have a handful of example units and a REALLY retarded AI courtesy of a modified Ashara $P.

Xenon Project is a jack of all trades race, the easiest to play for new players and the easiest to understand. Their ship tiers are divided into specific classes; Missile ships, direct-damage ships (Laser corvettes, Quantum Frigates, ect.), but they also had really big, beefy ships that could fight a number of enemy vessels of varying classes. An Enforcer's damage is wasted on a fighter, but a Battleship could damage a cluster of fighters or duke it out with an enemy battleship. The key with Xenon Project is map control and upgrades. All of their big guns do incremental damage which suffer from multiple armor calculations; upgrades are essential. And because upgrades are ridiculously expensive, a good economy is essential. They are the easiest race to play but the hardest race to control. Modnighters underestimated the power of the Xenon Project and considered the race underpowered until I showed them otherwise by demolishing multiple Undead players who spammed specific superships, often Blood Moons, with basic battleships and frigates.

The Undead are fast-moving, hard-hitting psychotic demons from the pits of microsoft. Their ships are more frail than those of Kaloth or Xenon, typically don't do AoE damage, and tend to fit very specific roles. The ultra-slow Spirestorm is designed to force enemies to move or die, and does massive single-target damage. The Blood Moon is a huge artillery piece that also does huge single-target damage but has a massive blind spot and a large cooldown. You can't get away with spamming only two kinds of ships with the Undead; you need a big, varied fleet. Modnighters had a very hard time understanding this and were soundly squashed by myself and the computers as a result.

Turning Starcraft into a game about air units alone seems like a complete turnaround from the lessons I learned and elaborated on earlier. However, it was through experiments like the Fleet Mod concept that I learned how and why ideas have merit or don't. I wasn't afraid to try something different for the sake of being different even knowing it was probably not going to turn out that great. That's a part of learning, and you shouldn't be worried about not making some grand achievement.

The unit design in ITAS was the thing I paid attention to the most again. I wanted Undead to be the guys who swarm dudes and then come out with exotic super weapons. I wanted Xenon Project to be the race where it was key to position your ships properly and set up a system of crossfire to wear down the enemy. I wanted Kaloth Industries to involve big, bursty damage and tactical movement. Each race was catered to a different style of play, and this had to reflect on their impressive number of units.

Undead were split into around 7 tiers. Each tier unlocked a set of ships, with the final tiers unlocking the Superships and eventually the conceptualized 500x500 Megaship class. Superships ranged from the ultra-cheap Blood Moon to the highly tactile Sorrow siege cruiser. Undead needed a big economy because, unlike in Starcraft, it was difficult to cap out your supply in ITAS until you reached the upper tiers. This meant that if you were power-teching away aiming to rush someone with a big ship, they could have a huge quantity of smaller ships in the same time. Incidentally, it's also easier to replace small ships than it is big ones.

Xenon Project functioned very similar to the terrans in starcraft, but with a bit more of a complicated tech tree. My laziness with strings ended up making this race more difficult to play than it really was, which is probably why players favored the Undead the most. XP had a number of production buildings that specialized in specific classes of ships, although they direly needed a new production center and some organization. Getting into the sweet spot of capital ship production was an expensive prospect and demanded the player to establish a strong degree of map control. Against the extremely passive modnight players this was very easy. although in one game I was rushed by a decent Undead player who used a Sorrow cruiser and a bunch of smaller ships to destroy many of my expansions before I was able to out-micro him with frigates and kill him.

While these two races appear deceptively simple, the real magic behind them is really only unveiled to players who already have established Starcraft mechanics and understanding. This leads to the concept of unit design and one of my biggest gripes with mods and games made by other people.

Particularly involving big ships.

Most often mods have a big ship that fires a single gun or does very little damage and is underwhelming. The focus of the Fleet Mod is fun. A masterfully balanced re-imagination of starcraft is really not going to happen here. We should consider the original title, and consider we're not going to best it with something like this. Because of the limitations of Starcraft and modding you can't really do a whole lot with mods and that's why people fuck with economics; they're trying something new, even if it eventually shoots them in the foot. But what they often neglect is something that's sitting right in front of them - exciting unit design.

Undead are a very violent, brutal race, and their units do a lot of damage very quickly. But they need to be used carefully. A careless Undead player will lose everything, but a skilled Undead player who relies on the strengths of his units will be rewarded greatly. XP is a little more lax in this sense, but proper unit placement, separation, and targeting goes a long way to directing that focused firepower of your fleet and getting the most out of it. The fundamentals of the unit design complement the race's gameplay style. Everything is grounded into how the units interact with the player.

The big beefy battleships of the Xenon Project are a key unit and great to use an example for my unit design philosophy.

"If it's big, pointy, and has a lot of guns, it should feel big, pointy, and show that it has a lot of guns."

Fleet Mods are about being fast and furious. The all-air design will contribute to this regardless of what you do next. The Xenon Battleship is the perfect example of embracing this concept. When it shoots, it sprays dozens of projectiles in quick succession and deals a significant amount of damage. In terms of balance, this is a tough unit to balance; the first incarnation of the Battleship did over 3x its current damage. It was nerfed, but then the upgrades were boosted when the concept of upgrades was established. ITAS has a maximum upgrade level of 15 - at around upgrade level 7-8, most fighters have their damage doubled or more, and incremental damage like that of the battleship benefit greatly. So when you first acquire a Battleship in the beginning of the game it may not seem so great. But as time passes and combat becomes faster, more frantic, and more bursty, the Battleship scales upwards and becomes very fearsome.

In starcraft upgrades are critical. The most basic example is the Zealot; upgraded, he kills a zergling in 2 hits. unupgraded, it takes 3. This is the stage where we step beyond unit concepts and start looking at actual number balance. Upgrades can and will easily throw a dick into the woodworks if you haven't prepared for them by now.

Xenon Project's damage is largely based on incremental damage except for units like the Laser Corvette and other major single-target units. Incremental damage is when a unit fires multiple times and deals damage multiple times; thus, armor is calculated for every hit. A Zealot does incremental damage, for example, as does the Firebat. ITAS takes these examples to extremes to help balance its big units, much like AO. Against a unit like the Blood Moon who has a serious amount of armor, an unupgraded battleship is greatly outmatched. This is how it should be - a Blood Moon is much harder to obtain than a battleship. But as the game progresses and the XP player upgrades to +7 and higher, suddenly Battleships are doing huge amounts of damage to small ships and can tear down a Blood Moon in small numbers.

Unfortunately, unlike vanilla starcraft, armor upgrades are almost worthless. This is because the damage ranges in ITAS get absurd pretty quickly, and even maxed out armor (+15) isn't going to really do a lot, except on ships like the Blood Moon who already have a lot of armor. Again, the lack of control here means this was a balancing blackhole I wasn't really able to pull the project out of. AO did a better job because the damage values are far more tame. In an ideal world I could axe a 0 off of ITAS' health and damage values and probably get away with it.

To make up for the weakness of fighters defensively (If they were more defensively strong ie more durable, they'd be too powerful and ships like the Battleship would be helpless against them let alone single-target ships), I gave their upgrade bonuses a massive increase. This meant that as the game progressed, and bigger and badder ships appeared, fighters scaled in that they could do huge amounts of damage to ships if they flanked them during a battle. This is largely what makes the computer AI so deadly, especially for Undead - their big masses of upgraded little ships can easily tear down lone capitals.

I'd have loved for a subsystem kind of thing like in homeworld 2 to give fighters some more tactical options than just bumrushing an unsuspecting and vulnerable capital. Alas. The limitations of the system prohibited my exploration of potential avenues for fighters. Such was my single greatest regret for the design as a whole.

Unit roles

Incremental damage, artillery, ships speeds and everything are attributes. Unlike vanilla Starcraft, where everything is generally the same speed except for units like vultures, speed shuttles, ect., in a fleet mod you have the opportunity to make some pretty strange and unique units. After all, once terrain value is diminished, it comes down almost precisely to how units control.

The Blood Moon is like a glorified, heavily-armored siege tank. But it doesn't splash, so it has to be targeted manually in a big brawl. The Battleship is your all-around attack ship, but it's small splash radius means that when surrounded it's much more vulnerable. The Hydra is super fast and has crit, but it's very vulnerable; like vultures, it's a dangerous flanking unit or great when used as a meat shield. The fighters for Kaloth Industries take forever to turn around and are very slow to accelerate, but have great standing strength, so it's best to try to outmaneuver them.

One of the units I really like in ITAS is the XP's Enforcer II. It fires three times in a quick burst, producing a small beam. It's great against small ships and big ships alike, but its role changes with its targets. Against small ships it's best to aim at stacks of them so it hits them in a cluster. Against big ships, you want to point it at enemy battleships and other heavy-hitters because of the front-loaded damage it does, which is hard to get in the upper tiers of XP ships. You also have the DensuKii II Omega-class - basically a gigantic version of the Battleship. It deals its damage across a lengthy volley and its biggest shots come last, so it's ideal to target ships with a lot of health so its shots and cooldown aren't wasted. A missed shot with an Omega can have serious consequences while Undead Alrashann's beat down on you with their 6x100 damage shots; much more front-loaded damage than the Xenon equivalent.

The roles of the units start to mold into the player's head as he plays. Most mods I see just have generic units. Your artillery, your infantry, your tank, ect. And at first glance, ITAS' unit roles are pretty basic as well. But being a Fleet Mod, those unit roles have different impacts than on the ground. Never treat a fleet mod like you treat a generic ground and air mod; unit roles are much more flexible. Blood Moons can be surprisingly dangerous as general combat units - if they're spread out and separated to avoid clustering. This plays into a concept I established for modders looking for balance advice some time ago; when making the attributes and cost for your unit, factor in the potential power of the unit. Units should be an investment, an option that the player is choosing to take. With ITAS I never delved into complex tech trees because I wasn't motivated at the time to make a huge system like that, but if I were to go back and make the mod again, that's exactly what I would do.

The concept of a fleet mod seems silly in hindsight, but many people took to it as designers and as players. It was interesting to see how pet projects of mine eventually lead to a variety of different takes on the subject, even if, in the end, I felt many of those takes were somewhat misguided. But it is not my place to tell them what they should make. They clearly had a goal or objective they wanted to build, and by paving the way to that action, I find substance no less. I can only hope that the resulting observations and critique from therein can lead to a deeper understanding for all creators to follow in our footsteps.

Conclusion

The Real-time strategy is a means of a player expressing themselves through a series of accented tools a developer has handed them, preferably with as little between them and those tools as possible. As a means of competitive expression it is hard to call any game post Brood War objectively "good", although many titles have attempted newer ideas and produced more modern representations of ideas Brood War has. Even so, Brood War maintains the most vast resource available for learning how a good RTS functions and how players functioned through it. Indeed, learning the psychology of player interaction with the elements can be a more telling experience and more insightful than skimming a list of health and damage values. This then opens the eye of the beholder to the many broad elements that determine balance, including responsiveness and utility through actuation rather than how many buttons there are to push.

The lessons learned therein have been integral to my project design for years and formed the core philosophy of my various RPG designs, including the Apex H Living World concept, and it is through these elements that a critical portion of my review philosophy is formed.

May these observations be of some benefit to those seeking to follow in the footsteps of a modder.

<