Site  •  Wiki  •  FAQ  •  Login

The Meskian Zen of Modding Starcraft

<<

IskatuMesk

User avatar

Posts: 153

Joined: June 6th, 2009, 8:59 pm

Post December 8th, 2009, 11:49 am

The Meskian Zen of Modding Starcraft

In this mega article I am going to explain from top to bottom my thought processes on modding. I will cover everything everything from balancing techniques, testing strategies, AI design, to organization, workflow, and keeping motivated. This will be an absolute guide on how I used to mod. It will be blunt, it will be rude, and you'll feel as though you've just ingested a can of bear semen once you're done.

The Meskian Zen of Modding

Understand the methods to the madness of my decade of modding. I treat modding as an expression of the mind, not as a simple gimmick to give some guys a nightly yuck or two. Unless you are prepared to make sacrifices for your dreams, your dreams will never breathe.

This is how I mod. This is how I treat modding. Other people have different approaches, sure, but this is what I think like, this is how I manage things, and it was worked flawlessly other than my own personal failures to which I can only blame myself of. I don't expect anyone to follow my methods to the letter, but rather for this guide to inspire thought and consideration of time-proven methods. Modding as a whole is in a great decline, and I feel it is because people approach modding from a totally wrong perspective and have very bad management and work ethics. I am totally retired, so I feel it's time to share this knowledge with people and let go of it at long last.

Conceptualization a Life of Modding

I didn't mod for a hobby. I didn't think of modding as "Oh, I'll just do this and worry about stuff later." If you treat modding as a hobby, or as some side project, here's a word of advice:

Stop. Just drop modding and never look back. All of those one-hit wonders who start a project and never complete it? That's you. Stop contributing to our pain.

The most important thing you can do to start your modding career is to treat it as a quest of the mind. It's not work; don't invest money into it. But it's not a hobby, either. It you treat it as some side dabble you will get nothing done and it will be totally pointless. If you have any hope of producing anything worthwhile or releasing public content, you have to be devoted and motivated. If you're just dabbling into modding for the lulz and not wanting to achieve anything, why are you reading this article? Also, don't treat modding as a gate to the industry. That won't work, either. Only in very rare circumstances will it get you into the industry, and unless you like your hopes and dreams to be repeatedly crushed, you're better off not even worrying about it.

I create Total Conversions. They require significantly more work than campaigns or minor modifications. To start a project of this scale, you need to prepare yourself in body and soul. This may sound cheesy, but being ill-prepared and not having a foundation to work with can utterly crush your project no matter how devoted you are.

Know thy limits

When I first started SC modding, I didn't know jack shit about computers or modding or whatever. I started modding AI simply to create an ultimate opponent, and once I discovered Stardraft, that drew me into actual modding. Mostly dat changes. Soon, I wanted custom graphics. That allured me into ICE.

For the longest time I used Arsenal2-3 and ICE. Even after I met HKS and we discovered that ICE and the Arsenals corrupted shit and broke it, I didn't want to use IceCC or Arsenal Zero because they weren't as simple to use. This unwillingness to adapt to better programs meant that most of my mods were corrupt and crashed a lot. Soon after that, I wanted my own graphics. So I had WarGiant teach me a bit of Rhino 3D. Let's face it, I'm a horrible modeler. Most of my early models were just glorified kitbashes of other models. They looked awful, but they were still a step ahead of traditional starcraft kitbashing. Then I wanted music, so I started learning Gigastudio and Cakewalk.

Ultimately most of my ventures, like music composition and 3d modeling, were utter failures. But through attempting to learn these skills, I instead learned valuable lessons and little tricks that helped me out anyway. I can't make a character in 3ds max, but I can use Afterburn to create some pretty nice looking effects. I'm totally fucking clueless in photoshop and paint shop pro, but I can masterfully process existing graphics and create totally new stuff out of them, or remaster graphics for usage in starcraft and improve color depth from the palette conversion. These skills allowed me to create some of the dazzling effects you see in Armageddon Onslaught, as well as edit some existing graphics to produce higher-quality graphics or alternate versions (Red Drake -> Ghost Dragon).

I started off fairly small, and worked my way up. From AI editing, to dat editing, to ICE, to evolving my skills and using IceCC. From MS Paint editing graphics to paint shop pro, I identified and used the best utilities available.

As Starcraft is now a very old game, it's very easy to establish the skills you need. Before starting a mod, you should recognize and acknowledge the skills that will be demanded of you. Never start a project expecting to rely on someone else for something, unless you know that someone very well. As a rule of thumb, never run a total conversion with a team larger than 3, including yourself. For Starcraft, it is vastly unnecessary to overcomplicate your work with so many unneeded people. Furthermore, these team members should exist only to create assets that you make use of. This brings us to the concept of outsourcing and team management, something I also go into detail in this article geared towards larger team management.

Starting your project - establishing yourself and your role

Never, under any circumstances, start a project you cannot see through to the end on your own. Every team member you add introduces barriers, complications, and hoops for you to jump through. Counter-strike was first developed by just two College students. Garry's Mod was essentially run by a single guy. You do not need a team. Know your abilities. If your abilities are largely insufficient to run the project on a one-man show, or you don't have the time, do yourself a favor and just don't start.

Ideally, if you have a few people you know very well and can trust to keep dedicated to your project, your team organization should look like this;

You: Everything modding-related.
Them: Asset creation or external file management.

Example: Mucky did the strings in MFTGATRL. ASofT created the Space Tileset for ITAS. poiuy_qwert renamed files and such for AO. I ran the show on my own. I kept everything under the hood to myself. I didn't discuss my plans. I just gave general updates as I did things and worked in total solitude.

I follow a simple concept of team management. Other than mods like MFTGATRL where HKS directly participated in mod creation, I consulted people on an as-needed basis. This allowed them to do whatever the hell they want with their lives but under the knowledge that you would eventually call upon them for assistance. They are not a part of your "team" - they don't have to hang around waiting for you to give them something to do. This is all outsourcing.

Often with outsourcing to other modders I operated on a simple work ethic. Traditionally, I don't allow anyone to use any of the content I have created in their mods - unless they do something significant for me. I would propose a trade for something significant. For example, when ASofT did my space terrain, I allowed him to use a variety of old ship graphics I had lying around for Temptation. It's nice to have people who will work for nothing, but don't become dependent on the concept. Think ahead; if you need graphics, but can't make graphics yourself, you're fucked.

Think about the people you know. Don't think about them as potential team members - humans by nature are extremely lazy. The prospect of someone saying, "Hey, a few days from now I might need you to make a short script to renumber some graphics" is a lot more inviting than "Hey, want to join my project and get a whole ton of work offloaded onto you?" Even if you mince words, that's ultimately what you're asking of them.

Establishing your abilities and goals

If you're breaking into modding and aren't very skilled, take the time to brush up on the tools and techniques before starting your mega conversion. With Armageddon Onslaught, despite my previous experience, I worked off a previous tech demo I had created for an ill-fated campaign, and established a proof of concept with the AI training heroes before actually lunging full speed into the gates of hell.

The most important part of a mod, especially Starcraft, lays in graphics. 99% of modders rely on poorly-made kitbashed graphics, often the same graphics used by every other like-minded mod. It's important to make your mod stand out and be unique, unless you like looking like everyone else and being passed over by players because your graphics suck. Even if your gameplay is awesome, most people, myself included, won't give your mod a second thought if you put no attention into the other aspects.

In a sprite-based game like Starcraft, it's perfectly acceptable to just rip graphics out of other sprite-based games. Even gifs off of websites can provide decent effects for you once processed properly. If you're looking into making a big mod, consult your memory of potential pools of resources. I have a 40gig SFX archive of games I have extracted sounds out of. Everything from lineage 2 to conquest: Frontier Wars. Whenever I encounter a game with good sounds, I spend some time researching how to get them out of it, and add them to my collection. As a result, I never need to look for sounds. Since I am skilled in sound editing, I can either opt to create sounds from scratch, edit existing sounds and make something new, or just pluck something straight out of my library.

In the unlikely event you are skilled in 3d graphics, you are in for a treat. Starcraft is very easy to produce graphics for. You don't need to worry about poly counts, just your textures and how the palette is going to thoroughly destroy them once you convert them.

Starcraft provides the opportunity to easily break into a number of important game creation fields, including voice acting, sound engineering, balance design, graphics, and AI. Starcraft is a very limited game, but because of the nature of its engine, it's very easy to put new content into it. Consider your first project the opportunity to learn a variety of skills that will serve you well in future endeavors, and don't be afraid to try something new like 3d graphics or iceCC scripting. You may find that you are very good at it. Laconius, who was petrified of IceCC, became rather skilled with it with just a few days of teaching on my behalf, and now he's one of the best scripters in the entire modding community, outperforming many of SEN's and CC's veterans. You can easily make such a transformation if you are willing to learn. Be prepared to dump a lot of time into this. It's an investment, just like anything else in life.

That said, some skills take time to master, and everyone is different. You must remain devoted and motivated, and that can be very hard. I know this well.

So much to take in! How do we even get started?!

Establishing your Mod Concept

I am of the belief that if you're going to make a mod, the only good mod you can make is something totally original and totally true to an original dream. That is to say, if you're going to invest time in a mod, you're better going all the way and making a Total Conversion. 99% of mods out there lack custom sounds or voice acting, but still have the gall to call themselves Total Conversions. In my eyes, they're not TCs unless they change the entire experience of the game. Sounds, music, graphics, gameplay and all. They are simply toying with the concept but not investing any effort into becoming truly significant mods.

Many people fall back on the concept that gameplay is everything and other stuff doesn't matter. If that was true, no one would care about Crysis or Half-life 2 or Doom. But people still play those, and it's because of the other elements they have. The truth is, sound is just as important as graphics, graphics are just as important as gameplay, and when making a new mod that presents a new universe, immersion, environment, and establishing your world is everything. Starcraft is the most popular RTS in the world despite being 640x480, being limited to 1650 or so units, and having only 8 players with no scripting engine. Why? Because it's easy to read. The voice acting and sound work are top notch and many recent titles don't touch them. It is a level of professionalism that fits so well together that it has endured over eleven years and STILL has more people playing it than any other RTS, and has also completely and totally dominated the E-sports scene.

You don't need super top of the line graphics and multi-million Disney voice actors to make your mod attractive and complete. But what you do need is for your elements to fit together. It has to play well, yes, but if it looks like ass or the voice acting is horrible, the mood will be quite sour. Project Revolution has great models and textures, but their animations are horrible - easily offsetting the years of work put into the other elements. Treat every element in your mod as an equal. I will talk about each element later on in the article.

Spend some time conceptualizing the world in your head. Maybe you're not a writer or a dreamer and you just want to make some cheesy Star Wars clone. Please, don't do that. They suck. Sniped_Ash made an incredible mod called Open Rebellion with some of the best graphics in the entire Blizzard fanbase, but it's not exactly hugely played. Why? It's just Star Wars. There's a billion star wars games out there. Star Wars is done to death. What would have happened if he devoted his energy to something a little less mainstream? Remember Gundam Century? That's still one of the most hugely popular mods out there because there isn't a plethora of Gundam games infesting America. The gameplay sucks, but the graphics are amazing. Unfortunately, it falls short of being a true TC, and is mostly popular as an entry mod for new players just breaking into the mod community.

When you build the design your mod in your head, start writing a document. This is called a Game Design document. Jot down your ideas, no matter how crude, that you feel are important to your mod. I do this for my absolute largest of projects, often on a forum for my fans to get an idea of what I'm doing. I typically only release info when I have significant work done, though; this falls into the "Public Image" category I'll talk about later.

Let's think about ITAS.

ITAS was a mod that started with a simple idea - expand my skills of Rhino 3d. I did not start the project with the intention of finishing it. I just wanted to build the concepts of my two major races in MFTG for fun. I also wanted to expand my skills in voice acting. But even though ITAS wasn't a serious mod, I put serious effort into designing the balance. I talk about Fleet Mods and ITAS design in this article.

With ITAS, I also established my first ever organization. Previous to 2004, I just threw shit where ever and went with it. But ITAS was going to have a ton of totally original content created for it. I am not exactly an organized person, and my methods are pretty sloppy, but they work and require virtually no effort on the end user to maintain. But it still keeps your mod folder clean and keeps stuff where you want it.

The Organization of ITAS files - Mesk Trainwreck Organization System version 1.0

With ITAS, I didn't want to put effort into major organization because I was a lazy unimaginative fuck.

Image

The primary ITAS folder contains a bunch of small folders with unprocessed data, such as portraits, 3d models, stuff like that. The RTS folder contains the actual mod data. The base RTS folder contains every piece of sound, music, and iceCC scripts named to a specific method.

"battleshipyes" ect sounds are for a Battleship unit, but since I haven't yet designated which unit will use them, they are just named battleship. Likewise, the explosion sound effects are unnamed from their original formats and just left there to rot until I eventually find a spot for them.

When I replace a unit and voice act it, I save the files in the directory according to the sounds they replace in Starcraft.

Image

For unit graphics, I stick them into their own folders. UD_Spirestorm is obviously the Undead Spirestorm. This entire process is designed to streamline work activity to minimize the amount of time required to move through folders or find shit. I've almost totally memorized all of the sound files - I know exactly which units they are for, so I don't need to rename anything between making and saving files and then importing them. The graphics are in easy to locate folders so I can just pop into them with PSP when running a script, control+A everything, and be on my merry way.

The iscript files are a bit more of a problem in ITAS. Because of the lack of an established naming convention, I opted just to name them inane shit. Incidentally, when I started the ITAS 3.0 update, it turned into a disaster and I didn't know where anything was. Some people edit the iscript in one big chunk - I edit it by-unit. It's just easier to organize and easier to sort through. Plus, merged locals can be annoying. Incidentally, my programs were still littered in random areas and this got annoying.

It's overdoing it to invest in some titanically complex way of organization, unless you're modding a game like supreme commander where you need 20 different files just to change one effect.

With Armageddon Onslaught, I invested into a little more efficient of a system.

The Organization of AO - Mesk Trainwreck Organization System 2.0

Image

AO was a tremendously large project. It used the entirety of the zerg race and virtually every single neutral, unused, and installation/platform related objects in the game. As a result, it possessed a tremendous quantity of files. I split the sound files - mod-ready content was in the base folder, unprocessed stuff in directories. Portraits got their own directories. Iscript files were now labeled as unit/id_aoversion or graphic label.


ESTABLISHING THY RESOURCES
Here I will list a quantity of resources for you! This is a MUST-READ section for any modder!

Starcraft is a complex game. Modding it requires a degree of wisdom on behalf of the developer. Not just in how to use tools and utilities and bring content to life, but how to make that content live and breathe. He also needs work ethics and resources. A good forum search can yield better answers then what old, senile cocksuckers like me would offer to you, especially if it's some question that's been asked to death.

Simple, common sense must be applied. Search forums before you ask. When asking a question, ask thoroughly and thoughtfully. Use proper English and grammar. If you type like a retard, people like me are inclined to just laugh at you or troll you. Modding for any game is a harsh, extremely competitive atmosphere and you will find few friends. But if you establish yourself as an intelligent, worthwhile individual, just maybe people will invest into you. It's just like an important job. If you're a very poor strip dancer, your makeup is horrible, and talk in a constant slur with no seduction at all, why would the strip bar hire you? You need to appeal to your seniors just as you need to appeal to an audience of horny 24 year old virgins. Consider this a good opportunity to prepare yourself for your Public Image and Hype Generation, which we'll talk about later.

Here I will unveil several of my resources in categories. These are websites I utilize for information

http://www.google.com

Google is your greatest ally. When you are uncertain about some general concept, like the appearance of something, google it. If you have a question about 3ds max or photoshop, google it. If anything, google may direct you to a useful website. Whatever you do, don't google "Hairy Goldfish".

Modding

http://www.campaigncreations.org <-- This is a "fairly" new forum, and doesn't contain a lot of SC stuff. Most of it is stuff I have created or answered over the years, including some of my game design articles and stuff. Feel free to ask questions if your searches have failed, though! There's still a few guys who can answer questions that post here.
http://www.samods.org <-- The site remains as dead as ever, and forum is very inactive, but there is a gold mine of old threads just waiting for you to unearth with the search function.
http://www.staredit.net <-- the most active of the modding sites, but has been abandoned by most veterans. Use the search function for massive returns. More oriented about beginner and intermediate modding.
http://www.staredit.net/maplantis <-- the Maplantis backup on SEN. Can't receive any new posts, but still serves as a repository
http://www.broodwarai.com <-- A site mostly geared to AI modding with a very mature and established, albeit small, userbase. Home of the PyMS modding suite and its creator. An excellent site.
http://corbobo.dyndns.org <-- Corbo's site contains a bunch of various resources and tutorials that you may find useful. Also a fair number of modders do lurk here.
http://www.modcrafters.com <-- A new site by Hercanic. Most of the veteran modders who still lurk forums go here, with the exception of myself. If you have an advanced or intermediate question, this is a good place to ask.

These websites represent the entire starcraft modding community. Treat them with respect, and it will be returned.

Game Design

Forget what you were taught in your run of the mill college game design class. The best way to learn how to expand the elements of Starcraft, or any RTS for that matter, and establish a new playstyle is to first learn how Starcraft itself plays. Starcraft is the most complex and skill-demanding RTS in existence with a huge amount of depth in every aspect of strategical and tactical play. But understanding Starcraft, especially a high level, is an investment all in itself. Luckily, there's a website that provides the means to do just that.

http://www.teamliquid.net - the premiere professional Starcraft coverage site outside of Korea. Maintained and run by many people who actually live in Korea and communicate with progamers themselves, Teamliquid is a colossal website with a massive community. The forums are an absolute endless gold sack of information just waiting for you to plunder.

http://www.teamliquid.net/tlpd/games/index.php?only_vods=on&no_spoiler=on&action=Update - Team Liquid's VOD (Video On Demand) database. This are full games of Starcraft played by professional players. You can learn a great deal just by studying these games, but there is also often English battle reports and stuff linked on player pages on the game sections. To watch a VOD, click on the + next to the date. Most of them come with the standard Korean commentaries, but some foreign commentators like Moletrap, Klazart, and others have created English commentaries on youtube for your viewing pleasure.

http://www.teamliquid.net/forum/viewmessage.php?topic_id=104154 - Day[9] Daily, run by Day[9]. This fellow produces extensive high-level commentaries of games on a regular basis and many are available on demand. This is an absolutely excellent and immediate resources for learning the advanced mechanics of starcraft and how map design effect it. As most modders underestimate the significance of maps in their game design, this is a great place to look to see how Starcraft functions and, thus, how they can change or evolve that concept.

I've also written a few game design articles. I'll get more into balancing and stuff in a later part of the article.

Graphics design

If you need inspiration for your graphics, you can either google stuff, or try various art websites. There's a bunch out there but I forget their names.

http://www.deviantart.com - the biggest collection of amateur and professional artists with the most readily accessible interface. Often I go onto Deviantart to look at their incredible work and sulk in my own ineptitude.

Voice acting

http://www.campaigncreations.org - We have a number of highly experienced actors and sound editors willing to answer your questions. Just post in the appropriate forum, please.
http://voiceactingalliance.com/board/ - VAA, a site Magic recommended me. Either if you're trying to just find voice actors (I found a wonderful mistress to voice act the Fallen Hero in AO with this site) or learn how to commit to the art yourself, this is a great place to go to. They are more fansub and anime related than gaming, though, so be sure to apply your inexorable charm to good use and provide ample details to get their attention.


Starting Your Mod

Once I have my tools where I want them, the resources at my fingertips, and an idea of where I want to go, I must decide how I am going to make this mod work.

All of my mods start with a concept, usually a story from one of my handful of universes. Most mods of mine are based on MFTG, a few on Loladins of Legend, and the very rare one on my largest universe, the Lour Saga AKA Throne of Armageddon. I have two different work ethics that I act upon depending on the universe.

If I'm making a humorous mod, like ITAS or MFTGATRL, I am not bound to finish it, nor am I bound to do my absolute best. The goal of the mod is simply fun, because that's what the worlds are about. Totally unrealistic, totally ridiculous bullshit.

But if I try to make a mod for the Lour Saga, I am bound to doing my absolute best and settling for nothing but perfection. My standards are far higher and these projects take much longer to conceptualize. No LS-related mod of mine has ever reached a reasonable degree of completion.

Once I have the story and setting I want, I work those factions into races. Zerg generally fits well with my evil races, like the Undead, because of creep. I can turn creep into the Scitor cellmesh crap, Undead/Armageddon magma, or, on another conceptual mod, mechanical circuitry sludge for a machine race. The Protoss would always fit the role of the most advanced race because of teleporting structures. In the case of ITAS, the least advanced race was given the Protoss slot and to justify the building concept, I just rolled over it with slave markets.

Think about how your races function, and work that into the gameplay. Zerg are a hive race, so they have lots of numbers. They also look and awful lot like Tyranids, because they are just ripped straight out of WH40k. So, may as well steal some more tyranid ideas while we're at it; Overlords, Cerebrates, ect. These work into gameplay; the overlords are supply depots, so on so forth.

The Undead use this race well. Larva become portals to the Abyss where ships pop out of, so on. Undead have a very simple and economic way of producing stuff, so their tech tree is very simple; split into 7 tiers.

You get the drill.

Unit Design & Balance

I am not sure if explaining the ideas behind my mods will help a lot, but shoot.

As I touched in the Fleet Mod article, unit design is very important. Avoid the concept of hard counters at all cost; they reduce the depth of gameplay dramatically and destroy your game.

In MFTGATRL, I was using races very similar to those in ITAS. The Pants Legion, the Undead, and the Gallantry Crew (Unrelated to Desler's work ofc), which were basically a band of vegabond perverts roaming the galaxy stealing pie and eating it.

The Pants Legion were a race that wore pants on their heads. Their units were very silly. They had tanks that fly, very cheap and readily available carriers, battle droids and dragoon-like units called Leggers. The Pants concept was very simple; Pants everyone until they are adequately pantsed. They were a race of reckless fanatics, just like Americans. So their units were typically very cheap, did a high amount of damage, and were quite mobile. Their main caster unit, the Hack-Controller, had a spell called Firestorm that utterly raped units and buildings when spammed. The Pants replaced the Protoss.

The GC were a race based around defense and tactics. They had very few basic AoE units and focused largely on ranged combat, similar to Terrans. GC were quite an infantry-heavy race, complete with terrorists that self-destructed and fearsome sniper units. Their vehicles were tactical, often able to attack both air and land. They had two fighters, one based on anti-ground, one based on anti-air. Nukes were also readily available and quite cheap. Unfortunately, their units were most often very squishy. They could produce a lot of firepower, but were very dependent on flanking and terrain control. This reflected upon their outlaw, guerrilla-like design.

The Undead followed the very typical Undead design. Mobile, high damage, lots of AoE, big superweapons. You get the idea.


With MFTGATRL, I aimed to create a sort of an alternate dimension to SC's existing gameplay, whereas traditionally my mods vary quite a bit. I wanted a more intense, faster paced game with more diverse unit selection and more bombastic battles. I ended up with a number of very powerful "super" units, including the Gelatinous Horror (I think that was the name, anyway), the Gunship Elite, the GC Battleship, and the Hack-Controller. These units underwent numerous balancing changes and I uncovered the secret to establishing a mod with a huge unit diversity but keeping everything unique and viable.

First off, infantry which were often relatively squishy, were very cheap. Just like fighters in ITAS, they benefited heavily from upgrades. Spider mines were turned into permanent gun turrets, like the gun traps in installation maps. These assisted the GC in holding territory, and could also be upgraded. With the GC, I wanted most of their basic units to feel frail, but not as expendable as Undead. This was an interesting crossroad, so Undead ended up becoming much more melee heavy in ground combat, making up with a very powerful air force. The GC relied heavily on ground troops for the majority of the game, while the Undead would gradually make a transition to air-oriented combat with ground thrown in. Which is unlike modern SC where TvZ, the zerg generally opt for an air opening (Muta harass) followed by a transition to ground (Lurker/defiler/ling).

In modern Starcraft, air power is only truly significant with standard gameplay in PvZ (Corsairs), PvT (Secret carriers, arbiters), TvZ (Vessels mostly, with the odd dropship and rare wratih rush... few times does the wraith rush work, though. There's also fantasy valks) and sometimes TvT (Dropships, wraith rushes, the odd time BC's ect) and absolutely fundamental in ZvZ. In MFTGATRL, I wanted air power to be fundamental all the time with Undead. They did have strong land units, including defilers that could utterly destroy small units and were permanently cloaked, but their true fighting power laid in air. This forced Undead to play in a reverse to Starcraft by investing either in a very strong early game force and teching very late, investing in battle collectors, Gelatinous Monstrosities and Elites with an eventual transition to air, or a more traditional tech to mutalisks (Warships) and later high-end stuff and sticking exclusively with air.

The other races also played a little different. The intended was to avoid alienating Starcraft players, allowing them to jump into MFTGATRL and maintain a very natural Starcraft feel but with a metagame that flowed quite differently. I didn't want any of those units that you never use, like Valkyries and Battlecruisers. I wanted those units to play a role. MFTGATRL was oriented for 4v4 games and FFA's, and wasn't strictly balanced for 1v1.

The Pants Legion generally got their carrier unit very quickly. This unit was relatively squishy but did a decent amount of damage. Their initial land units were not very strong, but they eventually got Siege Leggers which were quite formidable. Their air power was a mishmash of high attack power units, but they lacked true defining heavy air that could directly compete with Undead heavy air. Instead they relied on hit and run and flank tactics. The Pants Legion, as it is with most of my races that replace protoss, were the most unfinished race. They had a lot of high-range air units, including the Combat Copter that could spray an area with low-damage projectiles. A lot of those could be quite dangerous. These units were usually very cheap but very frail.

The GC were an interesting race to play. TvZ, bionic armies are typically very frail. They counter mutalisks, but mutalisks counter them as well; it depends on player skill and reaction. With the GC, it was even more paramount to invest into paying attention. The units did more damage, but were on average more frail. Allowing the Undead to close into melee was typically very bad. Bunkers and missile turrets were much stronger, though. GC were intended to be a turtle-friendly race, where you often fortified important locations with buildings to supplement your units. Eventually they did get access to some heavy units, however - especially air units. The Battleship is the strongest unit in MFTGATRL, and its highly expensive Gamma Ray can level chunks of a base or destroy an army. These units attacked very slowly, though, so you had to support them. They were also quite expensive.

GC allowed the player to employ hilarious nuke tactics. Since silos were no longer addons, you could nuke at will and very cheaply. The first renditions of the MFTGATRL AI built something like 26 silos and nuked you every 5-10 seconds. Despite the AI's stupidity in ghost management, often it was quite lethal. You also had access to other crazy spells; the irradiate replacement was Chemical Storm which did huge concussive AoE damage.

MFTGATRL wasn't my most well thought-out mod, but it was amongst my most complete and I liked the way it played.

Unit Design Rules of Thumb & Thoughts

Factor in the potential value of a unit's abilities over direct value. Siege tanks are fucking expensive and need siege mode upgrade to do real damage, but they are incredibly powerful. A Dragoon may destroy a siege tank once inside its minimum radius, but if that tank is protected by vultures, it could kill many dragoons. Vultures are relatively frail, but can destroy economy, and with an upgrade, can make the map a nightmare to traverse.

A unit that can kite another unit very easily should be more expensive than that unit, or cost gas when the other one doesn't. The Blood Moon is super cheap in ITAS despite its incredible 2k+ damage range, and that's because it has a super slow speed, slow firing rate, and massive minimum radius.

Consider what might happen with multiple units. A single corsair is little threat, but a critical mass of 5-6 corsairs can kill scourge before they get close, demolish groups of mutalisks in seconds, and totally disable land units. However, they can't attack ground, and they are fairly expensive. Additionally, if you repeatedly lose Corsairs in the early game where they are most pivotal, it will significantly put you behind. Even worse, if your corsair play fails and the zerg gains air superiority, you are fucked.

Consider the roles your unit will play. In PvZ, the corsair is important to slow down zerg's growth and maintain map control for potential DT or Reaver play. Maybe you just want the zerg to produce anti-air while you switch to a totally ground-based army.

What happens if we change the corsair? Let's say we just let him attack ground, too. What would happen?

Zerg would get raped. Oh so badly. Imagine something that can fly into your base, ignore your spore colonies, and pick off your overlords in seconds. Oh well, at least my economy is safe. Oh wait, no it isn't! The corsairs vaporize your drones along with your overlords. You are dead.

Be very careful with fast units in general. And a unit that can attack fast. The only really ideal way for the zerg to counter large numbers of Corsairs is either to hide his overlords somewhere or, if the protoss really has a lot of them, get the super-expensive Devourer. But the Zerg doesn't want to get devourers; they're so fucking slow in attacking, it's very hard to get the corsairs to stick and fight.

The natural playstyle of zerg is to just expand like crazy. If the protoss goes reaver/sair, it's probably going to be very hard for you to hold those expansions. Reavers absolutely rape ground units, especially with shuttle micro, but they're slow as fuck to kill buildings. The protoss player has to sit there with all his corsairs and shuttles while his reavers slowly pound away your hatchery. Meanwhile, your other expansions are coming up and you're building lots of sunkens and spores.

No one will argue when you claim the reaver is one of the most powerful units in the game. But it still has its drawbacks. Dud scarabs, slowness, vulnerability and limitations of its attack. It's a unit that requires a lot of skill and, more importantly, it requires synergy with the shuttle. PvP often drums down to reaver micro.

When you design your units, you want to consider what kind of a role they will play. It's easy to say that the Corsair with a land attack would totally fuck PvZ in the ass, but how would a similar change in a totally different conversion pan out? When I think about my ideas, I first start with a very basic concept.

I want the units to be fun. To have a fairly clear role and to adequately serve that role. Or, perhaps a multi-purpose unit with strange mechanics (XP Mothership in ITAS). But as I design my units for team games and FFA's, I also wanted units to have particular attributes or mechanics that functioned well across a very large map or added specific challenges. XP ships and KA ships in ITAS both had significantly long range with KA being the most superior, but Undead moved veery quickly. Since the mod was played exclusively on 256x256, the concept was to acquire intelligence and preferably vision of the enemy's fleet position so you could maneuver behind them to target their longest ranged ships, thereby eliminating their advantage. But what if they scouted you instead? It was a game of information warfare. This is exclusively from unit design - since ITAS is a fleet mod, terrain is not a factor.

If you start adding critical attacks and stuff to your units, you need to be careful with those as well. Assuming you aren't building an AO-styled mod, you probably want them to be fairly balanced. In VE II, Phoenixes were fairly weak on their own, but their Overload proc utterly raped air units. With just a few of them, they could completely obliterate a zerg air force of any size. This prompted a justified nerf. With these attacks you have the added bonus of being able to determine proc %. Do note though that SC's randomizer is VERY prone to predictable "proc streaks". A good example is Mal`Ash in AO chaining his ~3% Eclipse over and over and over again, killing everything on the map or never using it at all across the entire game.

Keep your unit design close to your race's concepts. Are they a brutal, reckless race? They'll probably sacrifice defenses for more attack power. Are they a conserved, goody-two-shoes bunch of treehugging faggots? They probably don't want to get an axe in their face and want to avoid causing mass destruction to the land they live on. Are they sinister, violent, hellbent on killing everyone? They'd probably invest into big, explosive weaponry with dramatic results. Racial diversity is rare in most RTS games and mods; follow SC's example and try to keep your gameplay for each race unique. With a big mod and perhaps the assistance of new plugin technology, you can even make custom economic or macro setups for each race, or perhaps custom spell systems. That's a pretty advanced topic and is outside of my capabilities, though.

Unit Cosmetics

Once you've decided how your unit wants to work, now you need to decide how that unit wants to look and sound like. With AO, I pictured the concept of units in my mind and then recalled from my resources what I had available to fit those roles.

I wanted a cheap, but dangerous unit with a high chance for criticals. The small defiler from Hellfire fit perfectly with this concept; he as very pointed, not particularly armored, and looked quite fast. For sounds, I opted for the Beholder sounds from NWN, because they were quite guttural and vicious sounding.

Although a unit may be very strong, if it doesn't feel, sound, or look strong, it will come off as weak or uninteresting. A high-end battlecruiser that just looks like a normal battlecruiser and shoots a handful of valkyrie rockets is uninspired and very boring. People will get very tired of your mod very fast if the units bring nothing new to their imaginations.

Sound Design

The Siege Tank produces a very satisfying THOOM when it fires. You know that's going to hurt. The Mutalisk's bouncing projectile produces a satisfying slicey noise and the Mutalisk itself produces an instantly recognizable and distinct noise when it attacks. Dragoon phase cannons, carrier interceptors, ect. they are all iconic sounds.

Your mod must have new sounds. I don't care if you've never touched sound editing before; it's very easy to learn. Even if you use piece of shit programs like Audacity, you need to learn the art of processing sound. I recommend Goldwave for starters. I personally use Adobe Audition 1.5; Audition is the successor to the old tried-and-true cooledit. Very powerful, very easy to use.

Get into the habit of listening to sounds in games. The Siege Tank's THOOM in sc1 has been replaced by a very unsatisfying and uninteresting UMPHSH in SC2; and people have been bitching about it left and right. There is important things to note when you listen to sounds in games.

And that's they're style.

Thing things attribute to style in sound effects;

Style itself, as in the prose of the sound effects. In a mod that uses sound effects largely from Lineage 2, for example (Like my Age of Wonders 2 mod) I generally want to keep sounds from other sources that sound relatively similar. In a mod where you use largely zappy-like noises for a race's weapons, it would sound odd to use a WW2 cannon shot for a similar weapon suddenly.

The sound effects should fit the event. A large-caliber weapon should produce a nice, beefy noise. A glock wouldn't produce a thunderous boom when fired. A massive beam weapon should be satisfyingly beamy and zappy. When establishing the sounds for races, I try to maintain a theme to each race. The GC in MFTGATRL used very generic modernized weapon sounds, but the Undead used largely hand-made sounds with a kind of a flangey vibe to them.

The Scitor in The Black Sun had this mechanical-sounding effect to many of their sounds, Anahn were all large-bore thunderous cannon shots and other heavy metal stuff, while Undead again reflected with liquidy-like demeanor on their pew pew.

There is also quality. Not just sound quality, but also the environment in which the sound was recorded in or produced with that changes how it sounds. Footsteps in Warrior Kings: Battles are considerably louder and more crunchy than those in Lineage 2; mixing them makes units sound strange when they move on after another, unless those fainter footsteps are used on a unit that is slighter of stature. For example, Orcs used the big, heavy footsteps from WKB, and Human/Elven females used the lighter stuff from L2.

Quality is a big factor in Gun sounds as well. This is most prominent in the various Counterstrike sound packs that exist. Many sounds are from actual firing ranges and include a long reverb. These are quite realistic, but you have to make note of SC's 8 channel limit for sounds. Also, they don't typically sound very beefy, so they are often unsuitable for vehicles or the like. If you stick to more traditional gunshot noises, you'll find a massive variety in them. It may be difficult for you to separate quality differences and environmental differences, but they do exist. Playing the sounds after each other in quick succession, or even mixing them together to produce a long rapid burst, is a good way to guess how it'll sound inside Starcraft.

Voice Acting

Voice Acting is a tough business. 99% of games that employ voice acting have bad actors. Out of the 1% that have good actors, many have terrible editing. I'm not going to teach you how to voice act, and Maglok has already made a topic for microphones, so I'll jump right to editing and decision-making.

Acting is very important, as is voice acting. Your flagship leading a fleet across the galaxy to squash those fracking toasters should probably be commanded by an experienced veteran Admiral who shows his years through his voice and speech. Voice acting and speech in units is a pivotal way to express your universe in a Total Conversion where you do not have a campaign to express it for you. Thus, a TC without any new sounds or voices is missing a massive portion of what makes a TC whole - immersion of character.

Each unit should have specific character to it. The Undead are all fucking psychos, but each unit has its own little specific taste of insanity.

Starcraft: ITAS Voice Acting Demonstration; The Undead

Most people would probably employ the "Weaker unit = less impressive voice" route with this kind of a race. With the Undead, all of them are basically demons that stab people. Instead of going with the weaker unit = less impressive voice, I opted to make the weaker units more insane, and the stronger units more sinister and calculated, thus implying a caste-like system where the weak are just too insane to do anything but fight, and the more intelligent and clever demons rise in power and rank.

When using editing, take special note of style once more. The style of your edits will be quite odd of the editing of one protoss sounds totally different from the other. Point in case - SC1 Protoss and SC2 protoss. All of my Undead use variations of the same flange setup with some chorus additions here and there, plus a specific set of reverbs.

In most MFTG non-Undead units, I gave each unit something specific to bitch about or be involved in doing. Be it pie, obnoxious alarms, complicated computers, or people sticking themselves into inappropriate locations, every Confed/GC unit allowed the player a fleeting yet terrifying glimpse of their world.

Hopefully that gives you some food for thought.

If there are any suggestions for topics to be added to the guide, let me know, as it's not quite "finished". For example, given the recent theft of graphics from AO, I feel inclined to write a portion about asking permission from authors and respecting people's work.
Image
<<

Hydrolisk

User avatar

Posts: 165

Joined: June 17th, 2009, 2:42 pm

Location: Peak of the spire.

Post December 9th, 2009, 10:26 pm

Re: The Meskian Zen of Modding Starcraft

If there are any suggestions for topics to be added to the guide, let me know, as it's not quite "finished".


You could include how you start off the project, i.e. which file types you start with, which files you begin modding after getting your plans done (or lack of plans?). I often start with the units.dat myself.
<<

IskatuMesk

User avatar

Posts: 153

Joined: June 6th, 2009, 8:59 pm

Post December 10th, 2009, 11:44 am

Re: The Meskian Zen of Modding Starcraft

Oh shit. I knew I forgot something!

I forgot to post the other half of the fucking guide!

Sigh.


Here it is.

Super Units

In many of mods, the races can employ large and very powerful units. You also have Armageddon Onslaught, where Armageddon can summon extremely powerful units that cause massive destruction.

Maybe you want your races to be able to create very powerful units, but want to avoid making them too powerful.

With ITAS, every race had upper tiers dedicated exclusively to the super units. Despite the power of these units and their relatively ease of access, they were quite balanced and I pride myself in the (albeit incomplete) circle of balance I had achieved. To best demonstrate my methods of balancing superships, I'll just write out their descriptions.

Undead:

The Undead superunits focused on exclusive key attributes or methods of attack. Undead units by nature are very simple and meant for specific tasks, and the superunits further entrenched this concept.

Spirestorm - This was the first super unit I put in ITAS. Its concept is very simple; it's big, slow, and hurts like hell. The Spirestorm is very durable and very short ranged, and has a chance to deal 4x damage on an already significantly damaging attack. It is great for sieges and works well to force enemies to move their units or get killed. It is a relatively cheap unit as well, so you can grab a few of them mid game to help protect your base.

Blood Moon - SENers loved to spam nothing but Blood Moons, a powerful artillery unit, without taking into consideration its major weaknesses. The Blood Moon is also quite slow, its damage is single-target, and it has a very large minimal radius. Although it is quite durable, it is virtually helpless to other ships, even small ones, in close combat.

Crusader - Crusaders are the frailest of Undead superships. However, they deal the most damage by a considerable amount in a single continual beam, they have scanner sweep, and are extremely fast. Crusaders are intended to flank enemy capitals and deal large damage to enemy superships.

Sorrow - The Sorrow Cruiser is a siege engine. It is very slow and quite durable, can cloak, and launches a very slow-moving projectile that deals significant AoE damage in ticks - and it has friendly fire. This weapon is most dangerous to units with low armor and without armor upgrades, and buildings. It's pretty easy to avoid the projectile, but the careless will be punished severely.

Xenon Project;

XP only had one usable Supership and another one about half-way finished but not implemented.

Omega: The Omega was basically a supersized variant of the Battleship. It fired in a much longer volley, where its major damage came at the end of the burst. It was critical to point the Omega at a target of importance; wasting its firepower on small units like fighters greatly devauled the unit as it was quite expensive to acquire. A large number of Omegas complemented each other nicely with fairly decently multi-purpose weaponry, but were vulnerable to units like the Blood Moon who would have a spotter.

Azaan: The Azaan was a conceptualized anti-fighter supership that fired multiple continual beams of energy that did nonstop AoE damage. It would fire wave-like beams in front of it, and it would be considerably less durable than the Omega. Obviously, dedicated anti-capitals would be very dangerous for this vessel.

Economy

It has become increasingly popular to seriously fuck with the Starcraft economy system. Which I feel is largely unnecessary, as most of the new economic systems fail to establish concepts already established by the existing one.

* Fun.

Is your economy system fun? Does it establish something new and interesting, or does it overcomplicate the gameplay? Players do not want to spend the entire game clicking through a billion different tech trees trying to figure out if their Anti-Matter generator costs too much Neutron emitters which you can't afford because the Proton emitters are on fire and producing at only 20% capacity because your Phase transistors had a critical meltdown when you built up too much energy.

Starcraft's system works. It has been proven time and time again when a slanty-eyed champion raises the next Golden Mouse and goes home with millions of won. Starcraft is, essentially, the perfect RTS, and the economic system plays a critical role into this. Before you start fucking with the economy, I highly advise you to read and watch into high-level starcraft play so you have a better understanding of what makes SC's economy what it is. Also, consider how tech and upgrades will factor into your economy.

I've considered several different economy systems for my mods but always decided against using them. Here's a few systems with my personal thoughts behind them.

Injection-based economy (waiting to acquire funds from provinces, for example, in a game like Diplomacy) is boring. The player is just spending half the time waiting for a timer. He is not directly interacting with the economy. This is also favors turtling. If you are building an extensive, 4X styled mod where you want the player to wait for injections, you need to make careful considerations of unit and building costs. It is much too easy to just sit back and wait for enough cash to buy Voltron and stomp over the other players who have feebly tried to penetrate your defenses with weaker units, and they have no way of achieving an economic advantage to compensate for your tech one.

Regional-based economy like that employed in STF will immediately demand your mod to be almost strictly ground-based. Regional control is best with clever and complicated map design; not the disastrous flat garbage seen in Dawn of War. Unit design in this will be even more critical and prone to tweaking. This means that you will have to invest in custom map design and carefully build the mod around these custom maps. Ideally you shouldn't make it too easy to defend or attack the buildings or whatever it is you are using to generate economy. This generally brings the game into more of a tactical standoff or harassment-based.

Control Point-based economy will turn Starcraft into an RTT and away from RTS completely. I would advise completely avoiding anything involving control points in a game as macro and combat intensive as Starcraft, especially when it's very hard to diverge from this gameplan in a mod. Dawn of War or Company of Heroes would be a better game to mod if you want this kind of a system.


Upgrades

Upgrades are very important. In my fleet combat article, I explained how upgrades change the gameplay considerably in both vanilla Starcraft and ITAS. With the advent of plugins, you can probably do a lot of crazy stuff with upgrades that was totally impossible during my days.

Upgrades are a way to evolve the gameplay. In ITAS, it was to turn fighters from scouts and harass units into high-DPS flanking swarms that rape capital ships.

With plugins, you could create upgrades that do neat stuff like firing rates. This adds a level of complication to balancing that I can't really foresee since I haven't ever been able to do that.

The best way to approach upgrades would be an approach accompanied with knowledge of the original game. Upgrades can dramatically change Starcraft gameplay; +1 for Zealots allow them to 2-shot zerglings instead of 3-shot. I think I heard that a certain number of upgrades (+2 I think) allow a Siege Tank to 2shot another tank in siege mode. Once you have an understanding of how upgrades can be applied, you can then employ a plan to your whim.

I usually made upgrades very significant in their bonuses, and more expensive than usual. This made taking upgrades become a significant choice instead of something to do when you have a little excess resources. Often taking upgrades would replace teching, since their bonuses made units (and defensive structures) considerably stronger. Some units would only achieve their full potential once upgraded.

Tech trees

I never delved much into tech trees, although in ITAS I wanted to totally revamp the two Confederate trees (Xenon Project and Kaloth Industries). In MFTGATRL I kept the tech trees very similar to existing ones with the addition of new units and new buildings and upgrades and stuff moved around a bit.

I really like the kind of tech business Bajadulce is doing in PEAI, though.

Production

Okay, now you've got an idea of my thought processes behind making units and races and stuff. Now I'm going to talk about actually making it happen. My work flow, ethics, what have you.

Building your mod: managing new additions

Okay, how do I start a mod, exactly? I have a concept, I know what it is I want to do, where do I begin?

I always begin with graphics. In AO's case, it was the Pit Lord tech demo from Sarenubus Kaladonmus. In ITAS' case, it was about a dozen or so models from rhino 3d. I always begin with graphics. Graphics represent the mod, and it's rewarding to see your new content in SC, even if it doesn't work fully.

If you're anything even remotely like me, you're going to be juggling a vicious ballet of motivation, focus, and dedication. Even though many of my mod's production lives were very short (ITAS 1.0 was produced in like 2 weeks), it is very easy to burn out. So I balance my work flow in a way that keeps me motivated and rewards me bit by bit as I move on.

The most rewarding thing to me is just setting my shit in motion. I smile when the Great Destroyer obliterates a fleet of carriers, I laugh when my cluster of Xenon Battleships obliterate some poor Modnighter's mass of Blood Moons. It's my worlds. I've brought them to life. That is the greatest reward. I don't care about publicity, I don't care about making release dates or whatever. I just want to see my shit kill other shit.

So, I always start with a random unit, a unit I think would be awesome. I make the graphic, then I make it functional. I call these barebones units. AO had a ton of barebones units it didn't built when it was first released; Duriel, Zeus, Mal`Ash, ect. They "worked", but they had no attacks or sounds or anything. The drive to finish the units is created when I see them in motion for the first time. It is then often critical that I do the work related to finishing them quickly.

My exact process for AO's units was as follows;

Determine unit specs. "I want the Gatekeeper of Chaos to have a flamethrower and a fireball attack with a DoT inferno that lasts forever."
Find graphic
Convert graphic frames to bmps
Send off bmps to p_q for renaming
Get bmps for weapons and effects
Determine what to replace in Starcraft, find ids
Start scripting weapons
Convert weapon graphics
Receive bmps from p_q
Process bmps from p_q
Send bmps to HKS to resize if necessary
Receive bmps from HKS resize if necessary
Finish scripting weapons, start scripting main unit
Create sounds
Finish scripting main unit to barebones format
Datedit the necessary unit specs
Spawn unit in map, check it out ingame, work out any frame call goofups I made (I often do that a lot since these units can have up to 2k frames)
Go back to main script, apply attacks and add sounds to weapons
Go into datedit and give appropriate stats
Test again, tweak to specifications
Apply full sounds
Apply cast effects
And lastly, do strings
Test with AI

I can't make wireframes or icons, so I didn't worry about those. I made some decent icons for ITAS in some method I can't recall, but wireframes have always been a dark art I've just ignored. I never considered wireframes necessary for a Total Conversion, if only because I had never found anyone who could make any and considered it impossible unless done by hand which would take way too long and I suck at drawing anyway.

In a multi-race mod like ITAS, I usually make one race have some base units, then make the other race have a few base units. I often end up bouncing between these two races adding units randomly. This is why the third race (most often protoss) ends up with so few units; I generally save up content for them to finish in the last stretch. Which I never make it to because I run out of motivation much too easily.

With AO, I focused on a more organized tier-to-tier setup. First I made tier 1 units, then tier 2, then tier 3. With every tier, I invisioned how much crazier I can make the next guys. Then, with that tier, I aimed to one-up myself in the next one. Then I ended up with units that teleport across the map and vaporized 400 units in a touch.

Usually I voice acted appropriate units on the spot, but sometimes I also waited and did a whole bunch at once. For mods like ITAS, I always saved requirement strings and stuff until the very end of production. Since none of the mods besides AO and MFTGATRL reached that stage, most of my mods had only unit names. I didn't consider this that critical because if I did them earlier I might end up having to redo them again because I changed the tech tree. I always knew the tech trees, anyway, as I only played by myself or with HKS and comps.

Which brings us to our next portion.

Public Image

There are three types of modders out there. And those three types can most often be associated with three behaviors as well.

- The first type builds his mod in secret and doesn't talk much about it. He releases it when it's finished. He often has a very high probability of finishing his project.
- The second type builds his mod and talks a bit about it but doesn't release it until it's finished. He acquires beta testers. There is a small chance that this project may actually be finished.
- The third type builds his mod totally under public scrutiny and makes regular public releases. Interest in his mod will usually die very fast and total completion is generally just a dream as motivation vanishes.

I'll say it right here.

Do not release demos of your project.

Demos kill projects. Previews kill projects. Demo videos, that's cool, just don't show everything. Video construction is something I'll talk about in a bit. But demos are like pulling a gun to your head. Your audience won't see the super amazing mod you've dreamed of, they'll see some half-finished buggy piece of shit and be thoroughly disappointed. It won't be up to spec with your standards, dur, it's incomplete. Under no circumstances should you ever make an unfinished project available to the public.

See my article about testers and leadership to learn more about picking out beta testers.

Ideally, you should be the guy that never says a word about his project to anyone until it's finished. You can make reasonable balance decisions just with knowledge about Starcraft and computer opponents. That's how I worked, and my mods have always been very balanced despite their incompletion. However, for six or so years I became enthralled in the prospect of building hype for my project.

The first rule about modding is you don't talk about your mod. You may give some ideas of features you'll present, but becoming engrossed in instilling a public image will force you into a mental obligation to work harder, to work to please your audience, and that will destroy you thoroughly. You'll find yourself making poor decisions on behalf of just trying to generate hype, you'll start cutting corners to make a release date, or in the absolute worst case scenario, you release a demo.

I've been down both roads. I've felt the burning euphoria of hype. But then I made the mistake of releasing early. My motivation plummeted, and while people would think this or that was cool, the ultimate goal of the mod wasn't reached. Interest is lost very easily. I grew too attached to what the public thought about me or my projects. That add more weight to my already heavily-burdened shoulders when I was working away on projects like MFTGATRL and UF. It is the single greatest mistake I have ever made.

I sometimes do get beta testers, though, such as for AO. In the article I linked above, I talk about keeping contact with your testers and so on. Now I'm gonna talk about providing for your testers.

Making for a Better Balance

Okay, so you've got a race and a bunch of units. You thought everything was pretty nice, but playtesters complain that X is too powerful and Y is totally fucking useless and they just wiped their ass with P because P doesn't even do anything useful.

What the fuck do we do?

Before you jump into your mod and start totally fucking with everything, here's a few observations I've made for you to consider.

Relic's games, when patched, often contain TREMENDOUS amounts of balance changes. Everything sees huge reductions or boosts.

World of Warcraft and Guild Wars follow the same way. Patches can change tons of skills and nerf the living shit out of things or massively boost others.

There's some key consistencies to note.

First off, these games have been patching forever. Yes, two of them are MMO's, but they often end up returning to the same skills and make reversed changes, sometimes in the totally opposite direction. The Relic games never achieve any kind of harmony and remain horribly badly balanced. Every review I see of Dawn of War 2 speaks about the awful balancing. "So, this patch is the Ork's time to rape everyone... oh, now it's the Elder's time."

There are few key reasons why these companies can bumble around fucking with things and fail to achieve anything useful.

First off, avoid making huge dramatic changes unless it's absolutely necessary. If your Elven Archer does 20 damage and you find she consistently kills Orcish Grunts a little too fast, you might be tempted to drop the damage down to 10. That is a huge drop. Try 15 instead. Make gentle, gradual changes, and test them thoroughly. If you follow the ethics of Relic and Blizzard and make gigantic swings through things, you'll not only come off as completely retarded to your testers who will just facepalm when you make half the units useless and the other half insanely strong. It's why Blizzard is having such a ridiculously hard time balancing WoW PvP (in addition to trying to cater to PvE content); huge changes completely gimp certain classes or overpower others.

Make gradual changes. When balancing AO's units, especially the AoE's, I had to be very careful. These units did a lot of damage, but not quite enough. So I very gently up the damages. Some of the damages ended up being double their original forms, anyway.

Obviously if the unit is totally harmless it will need dramatic changes, but when you are just dealing with specific units being a bit too strong, avoid big, dramatic changes.

Again, take into account the potential of the unit. It may not do a lot of damage just standing there, but if it can kite units, it can put out a lot more damage than its stats may lead you to believe.

Avoid making too many changes at once. If you end up completely overhauling the stats of an entire race, it will end up playing nothing like it did previously. Your efforts to rebalance them have suddenly made them completely different. Focus on problematic situations and then expand outwards from there. Also, consider unit synergies. Maybe my Orc Grunt can't kill the archer alone, but when my Orc Shaman spams Ensnare they are quite fucked. Ensnare, although rarely used, can be quite hilarious in TvZ when the ball of death tries to escape lurkers and just gets ensnared and dies instead.

Release Dates

Ignore them. No, don't ever set a release date. You won't make it. And if you did, you fucking cut corners. It'll be ready when it's ready. No sooner, no later. Period. Get the concept of a work place with schedules outside of your head. This isn't a hobby, but it isn't the office, either. Setting a deadline will hurt you more than you think. You're going to needlessly feel stress and worry about making it. You'll start to drop stuff or cut content or not devote enough time to testing.

Ignore the pitiful pleading of your sheep. The wait will make it all the sweeter; just don't blatantly hype up everything and then waste time like PR did and make everyone lose interest. Poor Heart of Storms.

Building Hype

Hype is a double-edged blade. Avoid wielding it too carelessly, or it will bite you in the ass.

When your mod has barely been started on, don't whisper a word about its existence. No one will care, anyway. I did the exact opposite with AO - I kept very public about it. But I also very carefully controlled information. Plus, I used it as a learning experience for other modders. I did a lot of things no one had even attempted, so I felt it was worth it to bite the bullet.

Information control. Keep those words in mind.

Hype is when you generate interest in your mod and receive the desire to play it from your audience. When you release information and you've got some attention, you might be tempted to release more and keep the excitement going. This is generally a very bad idea. For starters, it can backfire; you will suddenly run out of new stuff to show. Suddenly your mod isn't so new and exciting anymore. "Well, I already know the Klingons have 5 ships total. Great." You may also achieve what you wanted - even more hype, but this is also a bad thing. Hype has a habit of biting you in the ass when it spills over the pot. Think about SC2 - when it was first announced, everyone was super pumped. But then updates slowed and it has been delayed so much that almost all of the hype has burned out and left a lot of people bitter. Sure, they'll still probably enjoy SC2 when it's release, but that's not a mod. Mods do not have the same benefits as a full-fledged game with a 30-mission campaign featuring cinematics made by an incredibly impressive art division and a whole new engine/editor to play with and the future of Esports riding on its shoulders.

Once you have reached a reasonable state, release info very slowly. I like to use video media. A properly-made trailer can really generate the kind of hype you're looking for - the sense of desire to know more, the mystery, and the unveiled epic that awaits in the future. Building your trailer properly is hugely important.

Your Trailer

Look at that doofus, Cinicraft, that posted his PR campaign trailer in our forum a while ago. His campaign might be the most amazing thing since sliced bread, but his trailer is awful. It starts with a high-energy scene, then immediately drops out into a long and honestly very boring trek through installation effortlessly killing marines and scvs.

This is awful. And we can use it to pinpoint exactly why.

Consider movie trailers for a moment. The trailer generally starts off slow with a few words to accompany players to the main character or plot. Then you get glimpses of various scenes - this is called building energy. Energy is directly related to interest and excitement. Through emotional and stirring imagery, sounds, and content you must aim to captivate the audience. Then you present the goods. Action scenes, plot, what have you. No scene stays for too long, the video never stays on one part for very long.

Releasing the energy through action scenes or large events is what will really generate interest for your project. Through hopefully brief but fluent imagery you can portray some of your mechanics and units in action. AA's trailer starts with some big battles, and then drones out to a several-minute slowfest of dudes just flying around, then goes back into battles again. If he had reversed it, started with dudes flying around and some beauty shots, then moved into action, the effect would have been far more pronounced. Additionally, he showed way too much battle footage. AA's unit design is very weak, and the battles are very simple. This doesn't make for very great action footage. The trailer is almost 5 minutes long; a 1 minute trailer would have been less work to make and much more effective as a trailer. AA's focus is on economic gameplay and other mechanics than battles, so he should have demonstrated some of those first and finished off with a bit exploding finale.

Also, my AO release trailer was wretched. I had wanted to do a lot more with it, but eventually I ended up with a confusing and pointless show of spinning glowy that achieved nothing besides building up energy and then doing nothing with it.

There should always be structure to your video. It may just be a series of explosions and guys shooting each other, but it should flow some kind of hidden script.

There are robots.
*cue robot faces*
There are other robots.
*cue angry robot faces*
They fucking hate each other
*cue robot kung-foo*

Immersion is a key element provided by your trailer. Ideally, this trailer is the first time anyone will see your project in motion. You want the quality of the trailer to reflect the quality of your project. If the trailer is as half-assed as cinicraft's was, few people will find interest in it. They might like some the content, but the trailer will have ultimately failed to achieve what it set out to do. You will have fallen short of achieving the dramatic impact of "Wow, holy shit!" and are left with "that marine looks pretty cool" or "omg sc in 3d".

Only show fully completed stuff in your mod with your trailer. Unless it's something like my AO documentary demonstrations, it's usually unwise to show incomplete stuff. Just like with releasing a demo, you end up failing to reach the expectations raised through time or, in the case of a trailer, since when it started.

Study movie trailers intensely. Understand why they entrance you. Then watch horrible trailers, like those for Dragon Age. Why are they awful? Do they have a point to them? Is there any energy behind the events or is it just a mishmash of unrelated scenes?

Speaking of documentaries, they can be pretty cool. A commentated game by the author showing and playing his work and explaining it is extremely rare if not non-existent other than my AO videos. Baja produced some non-commentated demonstrations of his PEAI units; I think that if he commentated them they would be ten times as awesome. However, I kept my games few and far inbetween so major changes had taken place between videos, acting as a kind of a chronological boundary between versions. It's always fun to look at the old videos when you're done and think "holy shit, I didn't even have the Oblivion in when this was recorded!" It was exciting to watch my first AO gameplay video when I released version 3.0. This is mostly just for personal amusement, though. But a lot of people did like my gameplay videos, if only because I am hilarious.

Here are examples of what I feel to be a good trailer, made by Voyager. Unfortunately he didn't zoom into the footage to remove the console, so you can see he staged everything, but he did a pretty good job otherwise. It's simple, straight to the point, but effective.

Antithesis Rising Trailer: Three Days

Here's a trailer for Gundam Century. I like it; it's simple, to the point, shows off some of the Gundam units in action. It doesn't have much structure to it, but it doesn't stay at one spot and hangs around for you to get bored with it.

Gundam Century for Starcraft mod demo

Here's the very first AO trailer. It was the first mod trailer I had ever made.

Armageddon Onslaught - Pre-Alpha Teaser


Internal Testing

As we draw to the conclusion of this article, I'd like to talk a bit about my testing schemes. With AO especially, complicated units can be difficult to properly balance and test.

My greatest tool in testing is computers. There's no reason your mod should lack custom AI, so get into it early and it will provide you with endless hours of entertaining in your own mod. It's great for testing out unit combos, specific situations, ect. Obviously the computers can't micro, but you can, and this can help you exploit strong units and help determine how to balance them.

With AO, I had two testing phases.

My first phase involved the included Lewl map with command centers. A bunch of maps exist with every unit in the game placed on them, but since they don't have turrets or stuff placed on them they had little use to me. Plus, I was lazy and didn't make the neutral buildings/creeps/whatever functional after I hijacked their graphics slots, so they'd just crash.

Playing around with the unit is important. Interrupt it during attacks, during casting, spin it around wildly, attack and stop, you want to make absolutely sure your iscript threads don't cause problems during specific transitions - that's the easiest and sometimes most difficult to spot way of crashing with the iscript.

Once the unit functions to my specifications, I give it to the AI and I throw a big fucking showdown of ultimate destiny with 7 Armageddon in an FFA. I make the AI spam the unit like crazy in the beginning and watch the fireworks. Generally if it doesn't crash in 15 minutes I give the unit the go-ahead and work it into the AIscript normally.

Computer AI's are often more valuable than actual people. They're always there, they always do what you want (relatively speaking of course) and you can endure hours-long testing sessions without relent.

Plus, let's face it. The chances of you finding 7 dedicated players to test nightly with you are astronomically unlikely.

Post-production updates

Once you've made your final release, it's your duty to update any crashes to the mod. Even though I abandoned most of my mods after I released their incomplete forms, I always kept an eye out for any crash reports. Usually I didn't get any, though.

Minor imbalances or oddities can often be overlooked, but actual crashes should always be fixed.

Unfortunately the crashes in AO and ITAS 2.0 were unsolvable.
Image

Return to Discuss

Who is online

Users browsing this forum: No registered users and 1 guest

cron
phpBBST Software