X@COM

As we're all aware, atmosphere is an integral part of the X-COM experience, and an important element for building that atmosphere is sound. The sound of unfriendly footsteps echoing through the darkness; civilians screaming as the aliens find them before your squad does; hearing gunfire pierce the silence as unseen aliens fire on your position, but miss their mark so you still have no idea where they are. These add to the suspense, while also making the "hidden movement" phase that much more interesting (and informative).

This aspect of the game has been on the back burner for quite some time while we squared away the core mechanics, and with that done it's now time to decide what needs to be heard.

Items:

• Weapon fire / attacks
• Projectile impacts (projectile+material-dependent)
• Explosions 
• Throwing/landing (latter could be material-relative)
• Dropping (essentially same as landing)
• Picking up
• Melee swings / misses
• (Ammo loading/unloading probably unnecessary for now since only possible through inventory window, which has its own sounds)

Units

• Footsteps (usually terrain-based, but units may override that in special cases, such as flight or huge stompy aliens)
• Death

Terrain

• Footsteps (us. material-based)
• Door open/close
• Destruction (us. material-based)
• Falling prop impacts (unbroken, us. material-based)

Aside from the lists above, the sound system is already accessible through special abilities scripting, so sounds can be connected to just about any game element to create unique situational sounds like a terror unit roaring on spotting a target, or a chryssalid screaming on injecting a victim, etc.

Much of the functionality already exists, as particles and anything that uses them (attacks, explosions, throwing, melee...) are already capable of playing and controlling sounds (which is how the UI emits sound). We still need control for sounds related to non-particle objects, and to [elegantly] deal with various issues like the extreme cacophony that would result from huge explosions destroying wide areas of terrain, footsteps out of sight (it will slow down turns to always have NPC unit steps heard--not sure by how much), and many more I no doubt have yet discover.

After that it's mostly a question of putting together the assets, but I won't be doing all that now, just a core set used for testing/R9.

Fortunately I have handy a nice library of 157 footstep sounds I put together for an old game, so hopefully they'll work well for X@COM without too many adjustments (although I may have to edit them all--doh--to get them to work with the faster movement speed than the game they came from). Categories include dirt, grass, gravel, metal, mud, puddles, water, wood, rocky, snow, stone, and undergrowth. Because you need something other than my wall of text to look at, here's a color-inverted shot of one of the snow footsteps in Audacity (my primary sound editing tool):

*crunch*

Another issue at hand is to determine what level of control the player needs over sound. Besides the obvious option of muting the game entirely, will it be sufficient to split sound effect control into two categories, UI and game? That's what the plan is, in any case.

Other features under consideration (any opinions?):

• Dynamic sound effect volume based on the distance of the source from the nearest unit under the player's control
• Music isn't appropriate, but some kind of ambient drone or beat as heard in X-COM can help set the mood (as long as it's not too intrusive).
• [Unlikely:] Very subdued map-wide ambient/background sound effects, like distant shouts and screams in a densely populated urban map, wind through the trees in forests, etc.
• [Unlikely:] Environment sounds emitted by props, and heard only by the currently selected unit; examples would include fireplaces, gushing streams, machinery, alien facilities, etc.
• Radio chatter?

I'm not going to press forward on all this immediately. First there are a few little items sitting on the to-do list that need cleared away while awaiting any comments/input you guys have to offer.

The game has always been a bit demanding on older computers when sub-windows are open (it causes those funny graphical anomalies you see with the text and borders), and I figured now was a good time to deal with that.

Of course the first option that comes to mind is... hardware acceleration! So I spent the previous weekend attempting to integrate OpenGL into Rogue Engine X. It sure brought back memories of the times I used DX9 in years before, trying to figure out what the heck was going on in the background when all I wanted was some simple result. Several days later, after fiddling with OpenGL and pulling my hair out, I pulled the plug on that idea.

After all, this is a 2D game, so using the GPU shouldn't be entirely necessary.

Approaching the problem from a different angle, I decided to profile the game code itself and look for bottlenecks. (Bonus: I learned of an awesome application profiler called Very Sleepy--so easy to just attach it to a running program and go! And it should perhaps be called "Very Fast", because it really is. Before I was always copying the source over to my XP VM and testing it with a very old profiler.)

As suspected, the engine code handling preparation of the screen data to be sent to the renderer was eating up a majority of the processing time. It was using a method I called "drill blitting", checking for all screen objects positioned over a single cell and blending them together to create the screen's final appearance at that location. It was the easy way to write the code back when the engine was first created, but the game has become more complex since then with lots more objects to handle. So I completely re-thought the way the screen is drawn and switched from cell-wise to layer-wise blitting, merging one horizontal layer at a time rather than doing it cell by cell.

Hell yeah!

This was tested on a full-sized, fully-revealed Rookie's Tale map using the default font, the first time with just the default map view open, and the second with a simple inventory open on top of that.

As you can see, the more window objects on the screen the bigger the savings, so opening the inventory and other sub-windows won't cause as big a hit to the FPS as it used to. FPS used to take a 23% hit while the inventory was open; now reduced to only 3%! (We're definitely going to need this boost, because the new UI will have a lot more little windows and interactive parts.)

Obviously your actual FPS will likely be lower unless you've got one of these wicked core i7 chips (or whatever better stuff has come out since). I captured those shots from my title bar FPS readout (F5), but you won't see values this high unless you uncap your FPS (Ctrl-F5).

I'm guessing it's possible to improve on this even more with some tricky OpenGL shaders, but that's beyond me--we'll be sticking with software rendering for the foreseeable future.

As there always is with any rendering WIP, there were several blooper-worthy screenshots (from the OpenGL attempts).

Rookie's Tale intro, as written in alienscript.

Complete mess.

More alienscript.

Inversion of foreground and background colors.

These were the fun ones. The most annoying, and prevalent, screen was the seizure-inducing flashy yellow one. Ouch my eyes!

X@COM started back in 2011 with a single text file, a quick brainstorm listing essential features and examining the feasibility of such a project given the technical challenges. Among other topics, it touched on 3D, unit facing, and extant/previously attempted X-COM and 3D roguelikes.

After that came a rather short file considering what the underlying architecture of the program and its data should look like. Do we want component-based objects? Inheritance? State machines?

Both files were quickly tossed to the wayside when coding actually began and a pair of somewhat organized files took over:

"Program notes" covered implementation details but grew excessively long when its "to-do" section began including things that could be quite a ways off, or may never even come to be, so aside from its "known issues" section to which I occasionally tacked on new items as they appeared, I retired that file.

"Design overview" was a design doc in the traditional sense, summarizing the game's appeal, gameplay, GUI, etc., and it was onto that file that I started pasting more and more "ideas" that will become the future of X@COM.

All that information became fairly useless, though, since it was just one massive list. Seeing as how we've come to a rather big milestone, with the Battlescape very playable and many of the core mechanics not only complete but fleshed out, this was a good opportunity to organize that information so it can be useful today (or one day). "Fortunately," X@COM's scope has grown beyond what can be efficiently handled by a normal text file :)

Ever since the good old days of DOS edit, I've been using .txt files to keep notes. I still have thick binders of game rules printed out from the DOS edit days (as much as I'd like to have them, the floppies have all disappeared). Even a more recent game I worked on was documented through dozens of text files, some containing dozens of pages themselves, mostly written in... Notepad.

Switching from this familiar medium is going to take a bit of getting used to, but I'm testing the waters with some new software. After a day searching around for what's out there, I found a few of the better programs more suited to my needs, and settled on a program called CintaNotes. *All* of the X@COM notes have now been migrated a local database file and organized with tags (this alone took a couple days):



I'm not really used to the idea of tagging things, but we'll see how it goes. In any case, I still prefer and will continue to use text files, at least in spurts, after which their content will be integrated with the note database.

The database is for storing mostly long-term ideas that are still way out there. For near-term work I keep a separate to-do list at the top of the internal changelog, and for exploring the details of whatever I'm currently working on, nothing beats pen and paper, which I use most frequently.

Below are some sketches from Rookie's Tale design (colors inverted because they look better that way). The final blueprints didn't necessarily adhere to these; their purpose was to get an idea of the general layout, flow of movement, and choke points.

The Warlord's Keep.

The huge crypt housing the Greater Lich and full of nasty traps.

Garrison under siege by the Half-Orc mage and his followers.

When working on any major new feature set, there's an interesting nested development process where feature/element 1a ends up requiring element 1b and 1c, which then perhaps require even more elements, or even feature 2, and each of these has a piece of paper (or two or three), and they get stacked on top of each other and/or spread out until the pile/surface area begins to get a little daunting. As with coding any program, they just have to be tackled one at a time, piece by piece, and they *will* eventually make their way to the recycle bin. Always quite relieving to finally reach that "oh, so that's what my desk looks like" moment, as I did recently. A temporary state, of course, as we prepare for the next major step.


R8.7 Already?

Well damn, R8.6 had a pretty serious regression due to not fully testing code handling the new burst-fire mechanics that allow for alternate rates of fire: unlimited-ammo weapons were allowing an endless barrage of fire. That means we've already got an R8.7, and anyone playing R8.6, who I would assume are likely to have already encountered this bug, should definitely update. (Save games are compatible if you have a game in progress, by the way--just copy over the save file.) Both Rookie's Tale and Aggression have also been repackaged with R8.7.

This update also comes with another modification to pathfinding: You don't have to change your map level to move to a location on the ground, such as when descending slopes or the Skyranger ramp--just click in the air and the unit will move to the ground below that (obviously this doesn't work for flying units, which can just fly to the above-ground position itself). Not a big deal to seasoned players, but newcomers are often confused by the multi-level map and become frustrated from the very beginning (despite the basic tutorial mentioning it explicitly), so maybe now the demo will scare away fewer potential players.

The people have spoken! Truthfully, not a whole lot of them, but the handful of voices heard make it fairly obvious that overall you guys would prefer to avoid too many intentional roadblocks (a.k.a. feature creep) on the way to 1.0. Probably a smart move.

So as discussed in the previous post, I've postponed parkour and plowed through a series of quick features while clearing up the near-term to-do list in preparation for the Next Big Thing.

While these new features come with R8.6, uploaded today, some of them consist of engine support for future content and mods, not something you'll immediately have access to in the game. Nonetheless, I'll mention them here so that you know what's going on, and so I have an excuse to put up some related screenshots :)

Hand-held light-emitting items will now illuminate the nearby environment (I'm talking mechanics here, not some new visual style). This means little to X-COM right now since their own unit-based light is equivalent to that given off by an electro-flare, but it could have some interesting implications for mods where you might not have so much light available and have to carry a source of light (which may not last forever, like a lit torch). Varying amounts of light may also be emitted by armor itself.

Pathfinding has been slightly modified. I believe most players will prefer the more predictable direct route when allowing the game to take you to a chosen destination (as in X-COM), even though that route generally costs a tad more TU due to extra turning costs. I could add an option to disallow this behavior, but if you're in a tight situation where a few TU will really matter, you can always move in shorter sprints (which you should probably be doing, anyway) or use the keyboard. Do note that if the direct path (meaning a straight line towards the destination) is blocked, the normal pathfinding calculations will take over and will always take the cheapest path, which is not straight.

Burst fire weapons now support numbers of projectiles other than three, so some weapon could theoretically go full auto on a target with six shots, or more. For even scarier stopping power, burst mode supports a "salvo" setting that fires *all* those projectiles at once. Of course, my first inclination was to make a launcher that fires 12 large rockets simultaneously. Just a test, mind you ;p

X-COM sends primitive village back to the stone age?

When first testing I had all the rockets moving at insane speeds, and blew a path of destruction right through the Exodus city map (it looked even cooler when animated):

Hope there aren't any civilians in those buildings...

The aftermath. This is what 12 rockets can do for YOU!

Finally got around to adding ammo counters to the inventory window. This was postponed a looooong time ago when the original inventory window didn't have much room because it used the full-width font. Now you can actually identify at a glance what weapons are loaded with how much ammo, and the amount remaining in each clip in your inventory without having to remember / check all these values manually. Always one step ahead of the aliens, we are! (I also went ahead and made the HUD prioritize the display of remaining ammo, even though we'll be getting a new HUD in a few versions.)

News:

• Rookie's Tale has been updated with a few fixes and a new sword (Vampiric Blade).
• 10101 has again updated the Aggression mod, this time with a huge garrison. Woe to the orc raiding party that runs into that thing (10% chance; you'll know at the beginning there's one nearby because you'll hear the commander's call to arms at the end of your first turn--keep retrying with F10 until you get it if you've played before and are just interested in the garrison).

Around the corner: A bit of optimization, and sound++.