X@COM

There's finally something new worth a video: sound effects! Hear footsteps, guns firing, shooting through windows, blasting down walls, a stompy colossus wrecking houses, and finally the almighty blaster launcher.


The video doesn't include all the new sounds (by far)--for that you can play with the R9 sandbox (when it's available).

The weapons and explosions you hear are quick placeholders I put together for testing, but footsteps, destruction, and impacts are about where I want them to be besides still needing to be expanded. Right now there are 372 sound effects that fall under the above types, with still more categories to be added.

Sound effect volume is based on distance from the nearest unit under your control (and the inherent range of the sound itself), but most of the action takes place up close so you won't really notice it here.

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++.

Okay, so there's no swimming, we already have running (though X-COM soldier endurance leaves much to be desired), and we aren't going to have high-tech bikes.

Today we instead have climbing, jumping, and hurdling for you. (Maybe.)

Climbing:

This could open up a lot of new strategic options for movement. Terrain would have a "climbing difficulty" while units would have a new climbing skill that determines how easy it is to climb different terrain, if they can at all. Unless climbing something far beyond a unit's skill level, failure would usually just mean wasted time and stamina rather than outright falling to the ground.

You'd simply face the terrain you want to climb and use the standard upward movement commands (or let the pathfinder do it for you). You can change facing while climbing to look around, but must again face a surface in order to climb it. Reaction fire is also allowed while climbing, but only with one-handed weapons. If shot while climbing, there's a chance you'll fall. Upon reaching the top you'd climb up onto the roof or whatever flat surface is there. To climb down rather than jump down, you simple walk backwards (this would be a new command) over an edge.

Jumping:

The ability to leap across gaps would be nice, even better if jumping allowed you to fly off a roof and crash through a window in another building.

Hurdling:

It would be useful to quickly jump/slide over shorter movement-blocking terrain objects like bushes and tables, rather than going around them.


So... none of this is implemented yet, but I've been thinking about them for a while and still there are quite a few details to be ironed out before coding could begin. Because it may take some time, I've decided to put this up to a vote! Let's decide whether all this should wait until later (in the interest of actually making it to 1.0 this century), or go in now. Rather than using a poll, I ask that anyone with input leave thoughts in the comments section. There are certainly some gameplay implications to consider here, like the ability to climb trees to escape zombies (which would then attack the tree and bring it down?), and no doubt a lot more interesting aspects than that.

Keep in mind all of these features can/will be optional, and that even if not implemented in the current version they would still probably make it in one day, so even if you want to vote nay, feel free to bring up any relevant details I may want to consider when the time does come to add these features.

As cool/fun as these would be, I'm somewhat tending towards skipping them for now, even though I've already put a lot of thought into them. They're fairly complicated and there is a good bit to take into account and test so these systems work smoothly with everything else.

Anyway, I'll leave this topic in the incubator and work on the list of assorted loose ends and general improvements for now.


EDIT 2/1: Well, not as many opinions came in as expected based on the readership, but I think the general trend is apparent: Hold off on this until later (I am combining responses from here and Bay 12). So the parkour skill/actions have been pushed back to 1.0+ territory.

In the meantime I've heard that Linux/Wine and some Windows users have been unable to play the mods using the new standalone format. I've repackaged them all with a second batch file inside the actual game directory which should work in cases where the original/primary batch file does not.

Andrew has put together a well-written short about Victor Wade's dilemma in Rookie's Tale. You may have to play Rookie's Tale a few times before getting the underlying idea he's presented here. It's not something I'd considered when originally designing the scenario, but works well given the premise:


Kaol was sick and tired of the piss that passed for booze in this damn shack.
Taking another swig of the ruddy liquid, he longed for a glass of real alcohol. A beer would be amazing right now, and it would help take the edge off of the sword wound on his neck. Damn lucky, he was, that the goblin hadn't taken his head clean off; his last potion had stopped the worst of the bleeding after he had bashed the last of the bastards into paste, and after he had crawled his sorry ass back here a priest - the same man sitting across from him, actually - had stitched his flesh back together with a kind word to his deity.

Leaning back in the creaky three-and-a-half-legged chair, he spent a bit of time wondering where the nearest pub was before shrugging resignedly, realizing that he'd have to walk for a few days to get anywhere more civilized than the collection of huts the locals had dubbed a "town."

Kaol's pleasant thoughts were interrupted, however, as a stranger banged through the front door. The unshaven man stood a tad bit taller than he did, wearing the tattered purple scraps of an armor made from a metal Kaol didn't recognize. Some sort of weapon was slung over his shoulder. The man stumbled, catching his fall on a table nearby and leaning on it for support.

"No..." he croaked.

"Somethin' wrong?" the barkeep called from behind his counter; the newcomer waved at him dismissively, looking at Kaol's priest friend with strange, hungry eyes.

"This isn't right," he whispered. "Where... where's Zilith?"

"What the 'ell are you talkin' about?" Kaol asked. This fellow didn't seem drunk, or on anything Kaol had ever taken before; despite that, the strange man didn't quite seem there. Maybe he was mad.

"You... were there," the man muttered, ignoring Kaol's question. His eyes swept through the cramped room, taking in the dingy furniture, dying hearth and the wizard sitting silently at the far end near the embers. Despite his apparent attentiveness his eyes were glazed over, seeing something only he could see. Definitely mad.

"You... Tsek... you were there, that's right..." the madman said, pointing to the robed figure; by the look of shock that flew across the wizard's face Kaol figured he didn't know the man. "And you... Kaol... you were there... but you weren't," he continued, pointing at the priest.

"Now jus ow in tha 'ell do ya know me?" Kaol asked, standing up and knocking his flimsy chair over. "Who tha 'ell are ya?"

"Victor," the madman said, nearly whispering. "Tsek is here... Kaol is here... where's Zilith?"

Kaol drew his mace from his belt. "Ya got one more chance, ya bastard. How in tha name a Belthas do ya know me?"

Victor's unfocused gaze sharpened, boring into Kaol's own. Despite himself the fighter stepped back; the ferocity behind those eyes scared him. "You were born in a town, a far distance away from here. Your father was a blacksmith, your mother died during childbirth. For your fourteenth birthday your father made you a sword; you lost it three years later to a dragon and you never forgave yourself for it. I can get it back for you." Kaol was struck by a wave of confusion, anger and a tinge of long-buried regret as those events flashed through his mind's eye. Was this Victor a psychic? An oracle? How did he know...

"And you," the madman said, turning to point at the mage - Tsek. "Your mother was a mage and raised you into the profession. You are ashamed that you can only cast a single spell and are hoping that adventuring will help you learn more to finally prove yourself to her. I can help you do that." The man in question just stared at Victor, shock written across his face. "But you... priest of Belthas... I don't know you... Zilith should be there... was there..."

The stranger slumped to the ground with a groan, leaning against the wall and holding his face in his hands. Kaol shared a look with his priest and the mage, and by silent agreement the priest stood and walked over to the madman.
"My name is Shentong," he said softly, crouching in front of Victor. "I am, as you guessed, a priest of Belthas." Victor looked up, tears streaming down his face. "What happened to you?"

"She died," the man whispered; Kaol struggled to hear him, even from a few feet away, and he struggled with the urge to creep closer. The priest might be able to strangle some sense out of the loon and figure out how the hell he knew so much... how he knew about Kaol. He didn't want to scare the man away, and kept his distance. "I... it's all so foggy, but... I remember her smile, her hair, her kindness... I remember her. And I let her die."

"What happened?" Shentong asked softly, concern and kindness etched across his face. "Do you remember?"

"I... there were monsters... no, aliens... they sent me here... I was, we were looking... I can't remember, it was something important..." Shentong met the barkeeper's eye, gesturing upstars; the barkeep responded with a nod. "Let's get you upstairs. See if some rest will help you remember."

Victor nodded wordlessly and allowed himself to be led upstars; as Kaol watched the two of them stumble out of sight, the mage approached him. "Do you know that man?"

"No," Kaol growled. "An' I'd guess ya don', either." The mage shook his head.
"I have no idea how he... found out..."

"Nor I." Kaol cracked his neck and rested a hand on his mace. "But I intend ta find out." With that, he followed the priest and his charge upstairs. No matter what this Shentong said, he wasn't going to let the madman rest until he had answers. With the mage trailing him, he stomped upstars to confront the madman.


You can read a couple more fan fiction stories on the forum here and here, though they appear in the members-only board for now. (We'll have a dedicated public fan fiction board later once the game gets bigger.)

"You are ashamed that you can only cast a single spell"... I love that line, so fitting.

Another memorable excerpt from one of Andrew's stories that I'm sure anyone can appreciate:

"It's a good plan and we're a lot better equipped than last time, so I think we can pull it off. What do you think, Kyzrati?"

The erratic mage hummed in thought for a moment. "I'd give it a good thirty-three percent chance that one of us, at least, will survive."

"Better than X-COM usually does," Victor muttered. "You guys ready?"


10101 has posted a screenshot showing what could be the "worst start ever" in Rookie's Tale.

Good luck, Victor.

Development on the game itself has been slow of late. The only new feature worthy of mention is the ability to show all destinations within range of a unit given its current TU/EN. This is a pretty much a standard feature for TBS games and has been on my to-do list for a while, so I threw it together a few days ago since I had recently added Dijkstra processing to the pathfinding class for other uses.



It's nice because it updates as you move, so you can see the area reduce in size as you take each step (most useful while using a keyboard). Another advantage is it's a way to easily see what spaces can and cannot be occupied. It has a couple of [unimportant] known issues, but should work fairly well.

Various News Items:

• There have been a few new unannounced minor updates to X@COM, and we're now at 8.5. The latest version of Rookie's Tale has been repackaged with the current version.
• A Rookie's Tale has been updated several times since it was first released, mostly minor fixes and improvements. If you're playing now and plan to create golems, I recommend the new version since I had apparently broken that spell before the original release. Thanks to 10101 for finding almost everything that needed fixing so far. There may be more silent updates in the future, if anything else is reported.
• "Aggression" the mod has been updated by 10101, who added a possible mage tower and burned mill to the map generator and gave the Elder an extra healing spell. (The mod's original author is Andrew Sundberg.) 
• By request, the blog has been reopened to anonymous comments for anyone who has something to say. I'd still prefer you leave some name that we can know you by (which you can do without logging in) in case you end up with multiple comments.

The next post will come fairly soon, as soon as I can organize my notes on potential new features to seek some feedback.