Monday, June 09, 2014

My Corona

Wow! That's by far the longest absence I've had from this blog. Apologies! I've never really had a schedule, but this is the first time I've actually skipped a month.

My tardiness is almost completely due to one single reason: I made another Shadowrun campaign. Yeah, I know, I'm pretty surprised too. After the second one was finished, my feelings were pretty much, "That was a lot of fun, but far too much effort for the result." It took me a long time to get back at it again. I suspect that, like many life activities, it's mostly the result of our memories of pain fading and memories of the good parts growing. And, honestly, it's also been really gratifying to see the slow but consistent growth in popularity of my first two entries. They've never topped the charts or anything, but I really appreciate the kind reception they've received from people who have played them.


After putting Eclipse to bed, I'd vaguely thought that I might wait until Dragonfall (the first official expansion from Harebrained Schemes) came out, and then decide whether to turn my two games into a trilogy. Dragonfall arrived in February. I played it, it was fantastic, heads and shoulders above Dead Man's Switch in gameplay, story, and characters. I did feel a slightly bittersweet twinge that what I had done in my first two mods was no longer unique, but mostly happy to see that the direction of the series seemed to be shifting a bit more in the direction towards classic party-based CRPGs, a shift that I have been delighted to champion.

But, as far as my own work... not so much. I'd had a couple of ideas that I'd run across while doing research for Eclipse, and some vague ideas of where the story might continue from there, but also didn't feel a burning need to extend it. I've always deliberately given my missions (hopefully) satisfying conclusions, wrapping up the main plot points and eschewing cliffhangers. There are always a few threads that could be followed forwards, but nothing that needs an answer.

And, even if I were to make another mission, it doesn't automatically follow that it would be a sequel. I've been consciously following the modern BioWare model in my games, where you can import a character from the previous entry, or create a new character who receives a default world state from the earlier game. That's theoretically a good way to structure it: you will hopefully get a solid majority of fans from the first game, and some new fans jumping right into the second game, so with luck you can grow your audience over time. However, the way Shadowrun Returns structures its UGC (User Generated Content/Campaigns), players must install all earlier (dependent) modules before your later ones. As a result, when chaining multiple entries together, your later games will always necessarily have fewer subscribers than your earlier ones. With that in mind, it would make much more sense to start an entirely new story.

Like I said, I didn't immediately catch the itch to crack open the editor again, so I continued to ignore it. Over time, though, ideas began percolating. Some were CalFree-related lore than I had researched before; some were game concepts and mechanics that I had enjoyed in Dragonfall; and some were from the mass of Obsidian RPGs I've been playing lately (Neverwinter Nights 2, Mask of the Betrayer, Fallout New Vegas). I decided to figure out whether I could cobble all this stuff together into something fun.

I've never been a professional game developer, but from what I understand, AAA game companies tend to operate in cycles that go through three phases. First comes the design phase: before any code is written or assets are produced, a small team will spend a fairly long amount of time defining the vision for the game. This will include things like making concept art; determining the overall plot and main story beats; picking the main features to include in the game, etc. For me, my "design phase" occurs entirely in Google Docs. I hesitate to call my main document a Design Document - actual design docs are meant to be shared with a team and have a high level of polish, while mine was intended just for myself and consisted of monologues, bullet points, and a metric ton of question marks - but it served the invaluable purpose of helping me understand just what would go into this campaign and how it would all hold together. It started out as primarily a brainstorming document, and evolved over time into an 18-page-long summary of what I would end up creating. It included things like the major NPCs in the game: party members, merchants, allies, and adversaries, including a mix of new and returning characters; descriptions of the set of maps I intended to create and re-use; a description of the scenes that would make up the game, how the player would progress through them, and what story beats they would encounter in each.

As time went on, I began to figure out how the major mechanics in the campaign would work. I began crunching some numbers within the design doc, leaving them recorded for posterity. I'm a big fan of the "choice and consequences" school of classic RPG design, so I started to figure out what the major choices would be that the player would logically make during the course of the campaign (through dialogue, action, or a combination), and how those outcomes would affect the endgame. Looking back, if this campaign was any larger or more complex it would probably have been a good idea to split the mechanics stuff out from the lore; in my case, though, it was all very manageable, and did let me easily link things together by quickly jotting notes down.

The story went through some evolution along the way. I had to abandon my initial vision for a climactic battle on top of a mountain - I had loved that idea, but it just wouldn't work well in an isometric engine like Shadowrun Returns. Similarly, I had initially planned to have major stretches of the game take place in the wilderness. My initial contact with the Shadowrun universe was from the 1990s 16-bit video games, and so to me settings like the Salish-Shidhe Wilderness are just as much a part of Shadowrun as the Barrens. But, while Dragonfall has some very welcome additions like green grass, it still doesn't have the rivers and varieties of trees and shrubs that I would need, so I made further adjustments to my planned maps and missions.

This should be clear by now, but I am very dependent upon HBS and similarly talented folks for their production of fantastic artwork in the form of terrain tiles, NPC portraits, and 3D models. There's no way I would even dream of making these things if I couldn't call upon those resources. I'm aware that other UGC creators are accomplished artists in their own right and able to produce their own assets when they need them; that's wonderful! As for me, I've found it much easier to stick with the tools I have.

Finally, I had locked down the overall arc of the game and its component parts. The scope of the game had grown somewhat during my "design phase." Back when I was "pitching" it to myself, I was trying to convince myself that it wouldn't really be that much work. One introductory scene, one hub map, then three Dragonfall-style missions that could be done in any order, of two scenes each, and finally a concluding scene. I reasoned that I could reuse up to three of my San Francisco maps from Eclipse without it feeling too cheap, and figured that it wouldn't be too painful to make the new ones. Map-making has always been the slowest and most painful part of the process for me, so that was a big deal in psyching myself up to take this on.

But, what would those maps be? I had four potential missions in my initial brainstorm, and I'd figured that I would take the three best and discard the worst. As I started fleshing them out, though, I came to realize that I really liked all of them. They illustrated different aspects of the main plot I was driving towards, covered unique geographies, and had distinct tones that kept me from easily identifying one as redundant. I reluctantly decided to accept the effort involved in bringing them all to fruition, with the additional complication that, like in Dragonfall, I would allow the player to skip a mission of their choice if they wished. Furthermore, with my mountaintop scheme eliminated, I realized I would need to move through two different scenes to pull off the conclusion that I had planned; it would eventually grow into three, although the third was a fairly simple rump scene.

While the scope had grown, it remained a defined scope, which was critically important. The single most important difference between Chris the 2010s Wannabe Game Developer and Chris the 1990s Wannabe Game Developer is probably not my better-honed coding skills, my broader base of experience, or the superior tools available. It's the fact that I've come to realize how incredibly important it is for me to define a vision at the start of a project, and then work towards that vision until it is realized. Back in the day when I was messing around with BASIC and C++, I would invariably get more and more excited as I worked on a project, tossing one brilliant idea after another onto the pile, until it had exponentially exceeded my capabilities, let alone my attention span. I've come to realize that there's no substitute for actually finishing something, and all the time I spend in defining my goals is time well spent.

(Not to say that everything is locked in stone before I start coding, of course. Sometimes I realize that something isn't working and need to make changes, or think of something cool that I can drop in with very little effort. But, having a document that I can point myself towards does wonders for staving off the desire to push the finish line out even farther.)

So... I'm currently trying to reconstruct my timeline on this project, mostly for my own curiosity. Looking at the revision history in Google Docs, it looks like I actually started work on the "design doc" back in January, but that would have just been jotting down potential plot points (many of which were later abandoned or substantially changed). I started building out the doc in earnest around mid-March. A few weeks later I started my second major Google Doc, which would eventually hold all the major dialogue in the game. I started by writing down the conversations the introduce the plot of the game and some of the conversations with party members and allies that takes place in your hub: this helped me start to get a feel for the voices and personalities of the new characters, which in turn helped me figure out the roles they would play in the overall plot.

By the end of April, I had largely finished a first draft of the design doc, and commenced work in earnest on the game. In AAA game design, this is known as the "Production" phase. For professionals, this includes activities like creating levels, building 3D models, recording dialogue, doing motion-capture, etc. For me, it consists of the following tasks, which I follow in a rigid order. More details on each phase below.
  • Writing dialogue. I like to do this all up front, before any of the other tasks start; if there are problems in the story, they'll generally become apparent in the dialogue, and it's way easier to fix them there than after I've built a game around them.
  • Designing maps. I'm not very good at this!
  • Creating the NPCs present in each scene.
  • Building any minor, incidental dialogue that wasn't done previously (typically for puzzles or waypointing).
  • Programming the triggers, events, and logic that drives the actual gameplay.
  • Validating the game by running through it ("alpha testing").
  • "Decorating" each map with additional cosmetic props.
  • Providing lighting and special effects on each map.
  • Choosing and adding music.
  • Creating loading screens.
  • Writing copy for the campaign (description, FAQ, etc.)
  • Publishing to Steam!
Writing dialogue takes a while. In my case, it took me from April 29th until May 11th, and my main doc reached 65 pages. Of course, writing dialogue for a game is different from writing for a book: conversations can branch in multiple directions, can loop back on itself, certain avenues might open or close based on actions a player has or has not taken. So, while I'm writing, I'm focusing on the tone of the speaker, but also the structure of the content and how it will be represented in the game. I've developed an odd shorthand that I use in this document that I can refer to later to determine how lines are related to one another, and when they depend on or impact content in the game itself.

This sometimes seems tedious while I'm writing it, and always seems tedious weeks later when I'm copy-and-pasting 65 pages worth of text into tiny little paragraphs in the Shadowrun Returns conversation editor. Why not just write it in there to begin with? Great question! It would certainly save time, and would eliminate the need for external notations of things that need to be set in the editor. In my personal case, though, I've learned from experience that, for whatever bizarre reason, the creative part of my mind shuts down when I'm looking at an IDE, and works fine when I'm in Google Docs. If I write a line of dialogue in the editor, I might stare at a blank line for five minutes trying to think of the response. In Google Docs, I don't even think, I just write it. It's weird, but there it is. (And, I have to say, I have total sympathy for, say, any writers who can only work on MS-DOS machines running WordStar 4.0.)

I've followed a similar structure in Eclipse of splitting out my dialogue doc from my design doc. For the new game (which at the time I was calling "A3" and would eventually become "Antumbra 3 - Corona"; more details on the name later), one of my major ambitions was to create a banter system for party members, similar to that used in Baldur's Gate and most later BioWare games. The banters were purely cosmetic: each player would only see a fraction of them on their play-through, and they wouldn't have any in-game repercussions. They were different enough that I created a separate doc just for these. I wrote them over a period of three weeks, often switching between the banters and the "normal" dialogue depending on my attitude at the time. The banters were creatively freer, since they didn't need to tie in to the main plot, and usually structurally similar: many were just discussions between two party members, which might or might not give you an opportunity to interject. But, since I couldn't use the overarching plot as a crutch, I had to dig in and understand the characters, to figure out what they would want to talk about, and how they would react to one another. This was challenging, but incredibly fun. I don't fool myself - I play tons of BioWare and Obsidian games and am perfectly aware that the bar for writing an NPC is extremely high - but it was some of the most fun I've had in a while.

Wrapping up the dialogue gave me some good momentum and also a sense of commitment heading into my least-favorite part of the process: creating maps. I should note that HBS has been really great about encouraging people to build re-usable maps and share them within the community, and people have built great mods using such pieces. I'm honestly not sure why I haven't taken advantage of it. It might be a rare instance of masochism, or a need to control crucial details of my scenes (I know from other experiences that editing something can sometimes end up taking more time than making it from scratch), or because my maps always follow story and not vice versa, or a desire for ownership. (For the record, I'd be happy to collaborate with someone on building things like this, but I feel weird taking someone else's completed work and incorporating it into something they hadn't planned.)

However, this time around was actually by far the smoothest map-making experience I had. I think that it's largely a result of me figuring out from my previous missions what's easy and what's hard, and planning ahead of time to get the best bang for my buck. In the transition from Antumbra to Eclipse (henceforth A1 to A2), that was mostly true for lighting: I'd figured out what kinds of lights to put in my maps that would let me light them in minutes instead of in hours. From A2 to A3, I'd started figuring out what was hard for me. Cities are time-consuming; fortunately, A3 mostly takes place in rural areas and small towns, so a lack of skyscrapers doesn't hurt anything. Grids of rooms are ugly and hard to navigate: for A3, I adopted a more sprawling design that let each room stand on its own instead of butting up against its neighbors. Decorating the area surrounding an outside map region can take longer than decorating the area within that map: for A3, I started making liberal use of Solid Invisible Props which neatly blocked off such areas from view and saved me untold hours of tedious, unrewarding work.

I ended up creating six new maps for A3, and updated another four (!) from A2. In A2 I'd already become comfortable with the idea of recycling maps. Yeah, I know it sounds bad - I hated it in DA2 as much as you did - but for me, it means the difference between having two scenes and having just one scene. I've found that, with generous attention paid to ambient lighting, region definition, flow, and dialogue, you can remove much of the stigma that could be associated with a repeat. Plus, twice in the course of a single game is not a bad record. (At least, I keep telling myself that!) Anyways! I was able to use two of the maps in two different scenes each; the third map was a hub, which I'll talk about later; and the final three were unique ones that only appeared once each. There were no city maps, but otherwise I'm pretty happy with their variety: they cover several different settings, and each lends itself well to different styles of combat and puzzles.

So, my process: I always start out by (badly) free-handing a map on paper with a pencil. This lets me define entry and exit points, figure out where chokepoints will be, and start planning the locations for any encounters (combat or otherwise). It's often in this phase that I'll plan any puzzles for the map. My general rule of thumb for a given scene is to provide at least three distinct combat encounters and at least one non-combat obstacle to overcome. Sometimes this might be a mechanical puzzle, sometimes a fetch quest, sometimes a set of dialogue to traverse; often it will be some combination of these, where a player will be able to use their unique skills to find an appropriate solution. Anyways, I like my puzzles to flow out of the environment, so while I will usually have a general idea of the type of obstacle to face there, by the time I've wrapped up the map I've defined it much better.

At this point, the map is functional, but definitely not pretty. In editor terms, I've defined the walls and floors. I might have added a few props intended for use as cover in firefights, but most of the map is bare. This gets it to a state where I can start actually developing the gameplay that will take place on the map. In later phases, I might come to realize that there are some problems with the geometry, which will lead to (painful!) tweaks. The more "finished" a map has become, the harder those tweaks get, so I like to keep it in its simple form for now.

One the bones of the map are in place, I'll start creating the NPCs for the map. In some cases, these are friendly or neutral characters. The first time I've met a particular one, I'll spend the time to design their concept and pick an appropriate portrait to represent them. This is incredibly important for the feel of the mod, but has traditionally been a fairly tedious process: often I'll find a portrait I really like that conveys the personality I want, but then I'll need to manually figure out how to most accurately represent their body using the engine's prefabricated models, outfits, and portrait codes. Fortunately, this process has gotten much easier since the last mod I made, primarily thanks to Brain Morph's model browser and other useful visual tools that let me short-circuit the compile/run/debug cycle I had used previously.

My approach for enemy NPCs also changed. In the first two mods, I spent a lot of time hand-tuning each individual enemy: picking out their outfits, selecting weapons and spells, adjusting skills. I knew that this wouldn't be a possibility this time around, though. For starters, it would be far too time-consuming. Beyond that, though, since I was allowing players to walk through the content at their own pace and under their own direction, I would need to be able to dynamically adapt enemy difficulty based on the character's progress. Fortunately, the latest upgrade to Shadowrun Returns added the ability to do exactly this. Known as "Scaling characters", it lets you use predefined character "sheets" of stats and weapons, and then at runtime it will select the corresponding sheets for each enemy. It took a bit of trial and error to get this right, mostly due to dumb bugs involving mixed-case filenames, but once it was in place, I was able to generate enemies much more quickly than before: just drag out the appropriate Lone Star / Thug / Whatever templates, update the name and prefab to match the actual enemy desired, then tick the "Scale Character Sheet" checkbox. Done!

Once I had this under control, I took a similar approach towards creating my companion runner characters. This is something that's always been really important to me. Back in the 1.0.0 version of Shadowrun Returns, there wasn't any way to get a uniquely identifiable runner from the hiring screen, so all of my runs included potential companions as normal civilians who you could recruit through dialogue. After they joined your team, they would continue with you through the remaining maps; this (along with extensive abuse of global variables) let me implement crude versions of banters and reactive dialogues. Fortunately, things have improved greatly with Dragonfall and version 1.2.0, so now I was able to have multiple unique runners at once and acquire them through the hiring screen and have them scale up in power as the story progressed.

I had recently completed the exercise of updating my first two mods with a better flow of combat. In my earlier attempts, I generally put the enemies on the map from the start, and had players move through the whole map in turn-based mode. However, while playing Dragonfall, I had come to really appreciate the way it moved players in and out of combat over the course of a map, which noticeably improved the pacing and made exploration more fun, at the cost of some loss of tactical planning. With that in mind, here I would either place enemies on the map while on the Civilians team, then switch them over to enemies on a trigger (generally when they spotted the heroes); or keep them off the map and teleport them in to simulate an ambush; or actually activate the actor spawners at the appropriate time (which can lead to engine stuttering, but also is necessary for the really cool visual effects you get when creating elementals and matrix IC). I've gotten in the habit of tagging each enemy with the name of its squad, which in turn has let me write more powerful triggers that let each "cell" of enemies act more intelligently.

With the place and people ready, it would now be time for the action. In Shadowrun Returns, almost everything in the game other than movement and combat is the result of triggers, sort of a simple programming language. I use triggers to start conversations, to move characters around, to give orders to NPCs, to detonate explosions, to make dance parties, to move characters up staircases and elevators, to put on disguises, pretty much anything. By this point, I would have a clear idea of what was happening in a scene, so writing the triggers usually ends up being the fastest part for me, and one of the most fun.

While triggers are primarily oriented around gameplay, I also use them to help establish mood. In Corona, I was more confident about using them to create cutscene-style moments, where characters will move around on their own and undertake actions. The Berlin campaign also added a much more accessible way of accessing previously-hidden animations, and I took advantage of that, showing characters dancing, kneeling, casting fireballs, or whatever else was needed. And, while music itself would wait until later, this was a perfect time to start adding sound effects. I've found that sound is incredibly useful for selling the action in a 2D isometric game like this: a character moving its arm around doesn't convey much by itself, but adding the sound of a whooshing blade and a grunt of pain will convey the action much better than a bit of text would.

The scene is now alive, and it's time for me to start testing. My initial passes will usually be done by debugging with a single ultra-powerful character (like a Level 6 Troll Samurai) and at 250% speed. This lets me quickly run through each encounter and puzzle. There will be bugs! I will fix the bugs and repeat, and keep on doing this until it's basically working.

There's a wide gap between "basically working" and done, of course. Most scenes will feature multiple routes to completion, which might vary based on your own skills and the companions you have brought with you. Once the most glaring bugs have been snipped out, I'll start moving through the more nuanced routes. This used to be a pretty tedious process, but has gotten much better lately. First, since I've already defined templates for my NPCs, I can easily drop a needed character on the map if I need to test their participation in something. I also adopted a new technique this time around of creating a "Debug" trigger on each scene that fires when the map starts and does any arbitrary setup necessary for testing. This could be used to, for example, advance me automatically past a well-tested part of the map and into a buggier one, or to set some flags on the scene to simulate a new set of conditions. Best of all, when I'm ready to release, I can just uncheck all of my Debug triggers to deactivate them, instead of needing to peer through each individual map to see whether I still have any testing stuff in there.

Up until now, I've been testing each scene or encounter individually ("unit testing"). Once that's all done, it's time to do my first complete end-to-end run through the game. That's a wonderful feeling! It also leads to many more bugs! I'll realize where I've made assumptions about what a player has done previously, or failed to set up the rewards that carry from one mission to the next, etc. This process takes quite a bit longer, in large part because I can't use the quick-and-dirty debugging capabilities of the editor, and instead must rebuild and restart the scene with each change. Fortunately, by this point all the stupidest bugs have been eliminated, so the bugs that I'm tackling at this point feel worthwhile.

After I've finished beating my own game for the first time, I give myself a little congratulations. I also acknowledge that there's still a long way to go. At this point the process becomes somewhat parallelizable. I hand a build off to my saintly alpha tester, and head back to the editor to create the atmosphere and polish that will make the mod actually seem like a game. And, as my tester finds bugs, I'll fix them and roll out new builds that show my progress. I get a lot more momentum at this point, now that there are more eyes on the content. I like using Steam to distribute testing builds, although it (Steam) can be very buggy. Whenever I publish or republish the UGC, I go to the page and change the mod's visibility from "Public" to "Friends Only", which ensures that the world at large won't stumble across it before it's ready. In theory, Steam should be able to automatically push out new builds to my tester as I make them. In practice, it does this maybe 60% of the time; 30% of the time it requires some asinine process of quitting and restarting various programs; and 10% of the time it refuses to deliver anything and requires me to unpublish and republish the entire mod. Fortunately, nobody but the two of us are inconvenienced by this process. I was very thankful to see that they have apparently finally fixed the timeout issues that made creating UGC almost unbearable in the early days.

On the polishing phase, my first task is to "decorate" each scene. That's a bit like map-building, but these activities won't affect the overall flow of the gameplay. Instead, these are visual items that provide atmosphere and character to a scene. A dungeon might include chains, torture devices, and steel bars. A city park might include shrubs, benches, and trash bins. A corporate office might include copying machines, posters, and stacks of paper. I don't think I'm particularly skilled at this, but it is a bit fun... it reminds me of playing with Legos.

After every map is decorated, I then loop back around and start lighting each one. The overall mood of a scene is defined through its ambient and directional light, which might suggest environments like a night with a crescent moon, a badly polluted freeway, a chilly fluorescent hospital, etc. Within the scene, individual points of interest are lit using "point lights". I've come to appreciate the value of simplicity here: rather than spend hours of time and a dozen tiny lights to try and accurately light a single control panel, I'll use more general approaches to lighting key points of interest. An alarm panel might generally radiate red in the area around it; a bubbling font of energy might cast a purple tinge; an important NPC or item might be lit with a subtle white. I've found that the results are nearly as good and infinitely less frustrating than my prior perfectionist attempts.


While point lighting has gotten easier, special effects remain simpler still. These are the things that really turn a map alive, and a good amount ship with the editor. You can add things like buzzing swarms of flies, dangling electrical cords that shoot off sparks, ominously oozing green acid, blazing fires, flocks of crows, and more. This stuff is absurdly easy: just drag and drop it to the place you want!

I'll test these changes too, though it's a different type of testing. In my debug trigger, I'll generally kill off everyone else in the map and open any locked doors, then just wander around and look at stuff. Items in the game don't always match what's depicted in the editor, and I'll iterate frequently, nudging items and FX and props around. This is the point where it starts to actually look like a game.

By now, I'm coming into the home stretch. I've saved one of my favorite and easiest tasks for last: music! There are several dozen tracks of music available across the Seattle and Berlin campaigns, each with a distinct sound and evoking a different mood. I start by listing all of the slots I have available for music. In the first two mods, this usually just meant one combat and one non-combat track for each map, with perhaps a matrix track as well. In Corona, I mixed it up a little: I wanted to have two distinct themes available for two significant NPCs, which would play when each appeared. I also used music more to convey shifts in mood throughout a scene: when you enter one scene, you're fighting a disciplined and militant opponent, and the combat music sounds appropriately martial; later, a new enemy sweeps onto the scene, and the music changes into a more chaotic tune that depicts the increasingly frenetic battle. After the slots are defined, I'll go through and listen to every track available, and decide where to slot each one. I avoid any duplication of music, while also trying to pick the most appropriate item for each one. This is a really fun process: I would probably be helpless if I were to try to describe the music I wanted to a composer, but when I have a fixed set of options to choose from, I can figure out how the tone of each one best suits a given moment in the game.

By this point, the game is essentially done. Bugfixing has never stopped, but by now the critical game-breaking bugs have been identified and resolved. My main task now is adding the final layer of polish that will hopefully differentiate my mod and show that I've put some effort into it; these finishing touches communicate that this is a Serious Mod (TM) worth checking out and not some random drek that a kid uploaded on a whim. The most time-consuming part of this process is creating the loading screens that display before each scene. I follow the technique that Harebrained Schemes uses for their own missions, where the loading screen shows a section of the scene using in-game assets. This means playing through the scene again, trying to find parts that "photograph" well, and then taking screenshots. I've gratefully adopted Brain Morph's Photoshop template for converting these screenshots into loading screens, which can then be dropped into my mod.

That's pretty much the end of writing the mod! The very last thing to do is write the copy for my Steam page. Much like an article needs a catchy headline and photo to be noticed, mods need good descriptions that sound interesting and set expectations. I write brief descriptions of a paragraph or two that are bundled with the mod, and then prepare some longer text for the actual Steam page that provides feature sets, links to the earlier mods, a status description, and a separate FAQ page. I've also gotten in the habit of creating a separate bug thread for Steam; I find that this helps me avoid clutter and keeps the main discussion thread available for actual, uh, discussion about the mod.

Finally, I double-check everything, make sure my debug triggers are disabled, pick an appropriate version number, and hit that big "Republish" button one more time, leaving it on public visibility. And... that's it! If previous mods are any guidance, it will see very low traffic for the first week or so, then get featured in the top slot and receive a flood of new subscribers. From there on out, it'll mostly be word of mouth that determines how many people find and play it.

Of course, it isn't ever completely done. Like a AAA software title, I've now merely moved on to the "Maintenance" phase. This has its own set of tasks and procedures. My main goal is to fix any bugs, with particular priority given to those that cause a player to get stuck. Again, if the prior missions are an indication, I'll probably find and fix almost all of these in the first week or so. Going forward, I should only see major bugs when Harebrained Schemes releases a new version of Shadowrun Returns that breaks existing content. Even in the absence of bugs, though, there's still more to do. The biggest and probably most difficult task is to balance the combat, so I'll carefully monitor any feedback people leave about what areas they found particularly easy or challenging. I try to resist tweaking things based on a single report, and instead wait to see a consensus on needed changes. I'll continue polishing and updating the game indefinitely: rewriting dialogue that doesn't sound right to me, smoothing over jagged gameplay mechanics, improving enemy AI during encounters, and so on.

Still, this is as good a place as any to say "It's done." And I'm glad that it is! Writing a mod is incredibly fun, but it's also a very consuming activity, again as illustrated by my lack of updates here. It's not just that I've been too busy writing the mod to write blog posts: it's that I've pretty much stopped watching movies, playing games, or doing any of the other things that I tend to blog about in the first place. I'm really looking forward to having some purely recreational free time back again.

I was going to write some about the actual content of my game and the creative (as opposed to technical) process, but this post is already excessively long so I'll leave that for a future one. Hey, at the very least, it will bring my number of posts for the year slightly back up!

1 comment:

  1. " I hand a build off to my saintly alpha tester,"

    Thus being the only time ever that I am given that particular adjective. :)

    ReplyDelete