X@COM

As part of the beginning of the UI update, the latest additions have been about getting more info on the battlescape map.

Holding different number keys will identify visible objects by name. Here you can see labels popping up for enemies, then soldiers (much more fun with sound):

Your soldier names can also be color-coded by their remaining health.

Enemies are also identified this way when first spotted, as are all of those in line of sight at the beginning of each turn.

Also use labels to quickly check what items your soldiers are currently holding, and those that are lying on the ground (for stacks of items, it will cycle through them as you hold down the key):

Your soldiers' armament is also color-coded by percentage ammo remaining, where applicable.

Any number of types of labels can be displayed simultaneously, depending on how many keys you want to hold down.

Explosives will be (somewhat) safer to use, now that you can see their area of effect without resorting to square counting. It works for both firing explosive projectiles and throwing primed explosives, and uses brighter colors for higher damage--the blaster launcher calculation looks like... a super nova :) Here's a small rocket:

The animation will properly predict explosion dampening by various obstructions based on their material.

There's also a new (proper) grenade priming interface that replaces the old (okay, ancient) placeholder input method.


Since there's rarely reason to prime a timer to anything but 0, that will be the default behavior (skipping the window entirely) unless you press an extra key to manually open the priming interface.

Props and items can now be animated, though I don't plan to go crazy with the feature myself, as it could get distracting. UFO power sources do have a gradual glowing effect now, and explosive devices primed by your soldiers and thrown or left lying in the open will glow, too.

More than 750 sound effects later, I'm done (for now).

This phase of development only goes as far as implementation of the core sound system, and inclusion of a majority of the "generic" sound effects that we know we need:

• bullets/projectiles colliding with different materials
• spent shells hitting the ground (again, material based)
• item throwing and colliding/landing/falling/dropping (not all the same thing)
• melee swings and strikes (dependent on object struck--and whatever is swung, but for now that's mostly the same metallic objects)
• door manipulation
• grunts/screams from injury (pretty limited for now, esp. on the alien side)

So nearly none of the "unique" content you see in the demo scenarios has sound, instead all I've done so far are the parts that are sure to go into the final game. Obviously as you heard in the recent video there are sounds for the core weapons and explosions, for testing and, of course, fun :)

As for ambient sounds, while I had previously labeled them "unlikely", they are just so easy and beneficial to the atmosphere that I had to implement them, too. So now your soldiers can hear the pulsing hum of the UFO power core, beeping of terminals, wind in the trees, and fire. More will come later with the actual game content, although yesterday I couldn't help myself and added an event-based sound that plays on mission start if you have a Skyranger: the sound of the craft bay doors opening and lowering the ramp. Ambient sounds are heard by the currently selected unit, if any, and fade in slowly when selecting a new unit so as not to get too annoying while cycling through many units.

Check out this debug shot visualizing the volume of ambient sounds heard around a UFO:

Obviously you have the UFO power generating the strongest source of source in there (though it falls off quickly), with the terminals on the left chiming in. Outside is a tree, and if you're not too far away from it you'll hear a gentle breeze occasionally blowing through the leaves.

As mentioned before, sound volume is distance based, so the amount of control the engine now provides over falloff rates (attenuation) is useful for making different kinds of ambient sounds more realistic and changes in distance sound less harsh as units move nearer/further. The engine supports linear, logarithmic, reverse log, and inverse rates (you can read about them and see their graphs here). They don't work absolutely seamlessly, this being a grid world with discrete positioning rather than one with the more fine-grained resolution you'd see in a normal 3D game, but they get the job done well enough.

As with everything else, the entire sound system is controlled through text files. You just drop files in the audio directory, add their path to the sound definitions (along with their ranges and falloff model), and use them wherever in the data. The engine also supports the creation of sound channel groups for more precise control through particle script commands.

For the player, sound control is divided into three groups, UI, game, and ambient, which you'll be able to toggle and set volume for individually, though for now I'm not going to include commands for that since it will be handled through an options menu.

With this R9 is pretty much done, though I'm thinking of creating a quick mod that can better showcase the sound system, as all these cool new sound effects will be deactivated in the normal demo scenarios (you can manually activate them, but the overall experience will be inconsistent).

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.

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!

R8 just got a little update, mostly just bugfixes for new features the modders are using, along with a slew of internal tweaks to help them improve existing mods and bring you even better ones.

Of course there is one big change for players: Armor is now an item that can be removed, as described in the previous post. Ctrl-r is the key to both equip and remove armor, which requires two free hands. These actions can also be performed by mouse through the inventory screen. Most of the regular armors are not removable, but for now it'll at least be of some help in Cataclysm since you can pick up bulletproof vests and the like off dead policemen and unique units.

You'll need to grab the new version to play future mod releases, and I updated Cataclysm+ to v3--it's now compatible with 8.1.

It's national Adopt an Alien Pet Day!

The psi-amp is ready. I.e., you'll now be able to mind control aliens if you're good enough. The AI will not yet use the the psi-amp on you, as it would be incredibly unfair given your limited resources in the demo missions. I did, however, throw in a psi-amp... "somewhere" in Area 51 and Cataclysm. Of course, it wouldn't be much use without some skill, and there's no base for training yet, so all your units start with a random psi-skill of 2.5~5.0x their base value.




As planned, the psi-amp fit right into the special abilities system, which just needed a menu to enable selection from multiple abilities on the same object, as seen above, though the system is capable of handling much, much more than that. For example:


Yes, those are actual scripted abilities I was playing with to test the system, and they do exactly what they look like they do. (Adding each one only takes a single line of script that sets about ten variables.) So now the engine does intrinsic abilities, and X-COM agents could theoretically one day be learning all manner of psionic skills like firestarting, telekinesis, teleportation, unaided mind control, and MIND BULLETS! Well, whatever you can think of, really.

With the psi-amp done, where mechanics are concerned the X@COM battlescape is now capable of everything seen in the original! (Not to mention all the other features I've added.)

I decided against releasing another R7 update and instead pushed the previously mentioned modding features back to a modest R8, which is on the horizon and closing fast.

The mind probe is now ready for your perusal of brains everywhere!


Actually, it would be fun (useful, even) to later use this or other similar devices to actually get some insights into what a sentient being is thinking (AI hints, flavor text, etc).



The window is nicely animated, but again I'll save the video for a UI compilation that I'll put out with R7, which is scheduled for ARRP 2012.

Of course the same screen is also used to examine your own unit stats, so the long list of extraneous stats has been removed from the HUD since they can be accessed here:


I may at some point add the ability to choose a stat and compare its value across all your squad members, if anyone would find that useful. Also, I'd like to limit the mind probe to sentient units only (which could be easily scripted through the text files using the new object traits system combined with effect conditions), but right now it's like the original X-COM: any target goes. A separate device could be designed for analyzing mechanical targets.

You'll notice that I've resurrected the melee stat which was included in the original X-COM code but not actually used in the game. If you weren't following early development or haven't tried the demo yet, you may not know that pretty much *any* item can be used for a melee attack.

The default data I'm using right now (not necessarily balanced properly) has most items with 100% base accuracy (note that by X-COM rules that doesn't mean you always hit) and take 30 TU (unique melee items and terror unit melee attacks are different, of course). It only works if you are adjacent to the enemy, duh. The damage done by the default melee attacks depends on the attacker's strength, though again this can be overridden for special items. I also added some common damage types (bludgeoning/slashing/piercing) that can be used to define melee attacks.

Melee is generally not as deadly as actually shooting a weapon, of course, but it allows for lots of fun new mechanics, like dedicated melee weapons (e.g. knives, light sabres, etc.) and bashing down weak terrain (or even sturdy terrain like walls using a sledge hammer!). Melee attacks can also cause knockback on the target if your strength is greater than theirs, and if your strength is also great enough to smash through whatever is behind the defender, then you'll smash them right through it. So you can, for example, whack an alien with a baseball bat and send him flying out a third-story window so he hopefully falls to his death from impact damage. In fact, if you had superhuman strength, you could theoretically smash aliens right through walls, and if it collapsed part of the structure the debris would even fall on them, which would be pretty funny... Of course, you have to watch out for powerful aliens doing the same things to you.

Now that the mind probe is done, that leaves only one item from the original X-COM yet to be implemented: the psi-amp. The effects are already possible through the current system, all that's missing is a menu to select from a list of usable abilities when an item has more than one. I'll save that for R8, though, since I need to get to adding new items and content for the next scenario.


Warning: Wall of semi-technical text follows.

In other news, a couple days ago I also finally added particle templating! Meta-programming (or in this case "meta-scripting") is incredibly useful for rapid development, enabling easy creation of multiple variations on a concept. In this case, the engine can now read in particle template data from the text files and, while parsing particle definitions, automatically generates all necessary variations of a given particle to meet template specifications.

While quite simple to implement, it becomes a huge time saver during the content design process, making it possible to more easily create multiple particle variations by detaching design from general behavior (i.e., great for lots of different effects with minor changes from a base design). In practice, it's mostly useful for recoloring, but can be used in other creative ways. This got me really excited--doing things like this always seems to tickle my geeky side (perhaps my biggest side).

I'd been thinking about adding this feature for a while, but it hadn't really become necessary yet. However, with the numerous colors you see in the profile window, templates make a lot of sense: What would've taken almost 200 particles to implement ended up taking only 8 (!) with templates.

This reminds me of back when I was rushing to finish Cogmind for 7DRL 2012 and had to quickly recolor a bunch of X@COM particle effects to match the many types of weapons available in Cogmind--lots and lots of copy and paste, which could've been avoided completely had particle templates been ready back then!

So I've also gone back and rewritten other X@COM particle systems to use templates as well--just the blip particles used in the motion scanner were collapsed from their original 42 long lines of particle parameters to 6 long ones and 8 short ones (the latter a tiny chart used in combination with the six template particles to generate a full set); the text typing effect originally required six lines for every new color, but now it's six lines to define the behavior, and one for each additional color! Yay!

Here's the entirety of the script lines needed to animate the typing as it's currently done in the game (the red template chart defines the colors):

Templates also make for better design by allowing you to concentrate on what's different about the particles, instead of wading through endless rows and columns of data looking for those specific little differences.

Face it: If you were on the front line against a frightening alien menace, you'd probably prefer to be shot up with chemicals most of the time, too!

The oh-so-indispensable Medi-Kit is ready to patch up and treat your panicking, bleeding and otherwise not-so-happy-to-be-dying-to-WTF-WAS-THAT soldiers. It'll be much better than what you've had to face so far: Seeing critical wounds as more or less an unavoidable doom counter.

I'd like the UI to be a bit more flashy, but for now I'm sticking to a more utilitarian design and simple color scheme so these elements are at least available in game. So this is what you get:


I would have gone for a slightly more visual representation of the target's body, but the interface needs to be compatible with any kind of anatomy that could potentially be created through the dynamic body part system, so critical wounds are just shown through a list of parts. The window is animated and I added a new sound, too, but I'll save the video for a UI compilation once there's more to show.

In related news: The Special Ability Framework is COMPLETE! That pretty much explains where I've disappeared to these past weeks, and I'm sure one day it'll have been worth it--because for now it was definitely overkill for implementing just the standard X-COM content, e.g. chryssalids, silacoids, motion scanners, medi-kits, etc., which all could've been hard-coded in no time.

The framework doesn't yet include absolutely every trigger and effect that might eventually find its way in there, but 41 triggers, 47 conditions, and 30 different effects is already enough to create a mind-boggling amount of Fun Stuff. Some of said Fun Stuff you will see in R7.

As I've described before, it's a very flexible framework that allows modders to mix and match triggers and effects complete with text messages, particle effects, sounds, and of course effects on game objects. In fact, while testing the medi-kit I was able to pretty easily (took less than a minute...) add some extra functions for fun: a "poison" function that instantly kills the patient, and a "zombify" function that mutates the patient into a mindless zombie. The medi-kit interface dynamically builds itself based on what abilities the text files give the medi-kit (or, actually, any item with the "open medi-kit" trigger, since you could technically create other items that have medi-kit-like functionality), so the functions I added appeared as new buttons that I could use to kill or zombify targets... Much more useful functions could be created using the MOD_ENT ("modify entity") effect, which has 19 sub-effects for modifying unit stats on the fly.

Other things I played with to test the system:

• phase-shifting aliens
• amorphous aliens that divide in two when shot
• aliens that emit a deadly toxin which kills any humans who get too close
• aliens that trigger periodic cyclones which pick up small objects and fling them around (oops, did you throw that grenade over here? hah!)
• alien gun that shoots out smaller aliens (here, have a facehugger!)
• controlled teleports
• items that can transform into other items
• potion of strength (quaff it, really)
• staff of destruction (disintegrates everything within a certain radius of target position)
• a med station that heals user when "manipulated" (<--a new command that allows units to "use" terrain objects--could be used for computer terminals or whatever)
• (approx. 30 more test abilities...)

Next I'll be working on the mind probe interface (which won't take very long) and a few random other housekeeping tasks before putting the next scenario to code. Actually, before that the HUD needs a temporary mini-log so you don't always have to open the full combat log to see what's going on, since the new ability system means you'll occasionally need more detail about what's going on than what you can see on the map.

Okay, maybe not the silacoids. Who really cares about them? They're fun and all, but certainly not dangerous.

Chryssalids are of course a completely different story. These bad boys are now out there seeking panicking civilians to zombify. Then there's the zombie spawn out for some fresh soldier meat. You'll be up against the undead hordes in a new scenario planned for the next release (which is still quite a ways off, btw). Bring your Molotovs!

Here are some log excerpts from one of my tests. Louis spots a zombie shambling toward him and uses his quick soldier reflexes to try and mow it down before it can get in close. Unfortunately Igor decides to join in with his rocket launcher and while he does manage to blast the zombie, he also takes out his nearby squadmate in the process. Of course there's now a chryssalid on the lose. Good luck guys.


Then Paul shows up and, apparently having forgotten to prime his alien grenade, uses it instead to bash the chryssalid in the face. Not smart Paul.


You'll make a good zombie, Paul--they don't need brains.

Note that because the silacoid ability is set to deal incendiary damage, as it moves it naturally sets flammable terrain on fire, instead of just burning that area of the ground. I can't recall whether they actually set fire to the ground in the original (I don't think they did), but it would be a simple change in the ability script to turn that off. I rather like it.

Speaking of the ability scripts, here's a shot of the new specialabilities.xt file as it appears in notepad++ (click for full size):

As for modifying the silacoid's abilities as mentioned above, all you'd have to do change the "IN" (incendiary) in the "DMG_TYPE=IN" effect data string to some other kind of damage that wouldn't cause fires, like "PL" (plasma).

The Unstable Compound ability on the list was something I was using to test volatile items. Now if only Paul had smashed the chryssalid with *that* he could've at least gone out like a man! (Volatile items explode pretty easily, including when smashed against something. Oh man this game's gonna be fun once I actually get to designing the content...)

The chryssalid zombify effect was somewhat annoying because it's not supposed to take effect immediately, only on the target's death or once the chryssalid stops attacking it, so it didn't fit very well into the system and ended up requiring a "special case" MUTATE_DELAYED effect. Makes sense from a gameplay perspective, though, since that would mean a group of armored troops would be less likely to fall as quickly to a chryssalid as unarmored troops would (especially since chryssalids zombify their target even if their melee attack *misses*, and the special effect completely disregards the defender's armor!).

About the implementation, I spent a lot of time hesitating over details, trying to design the system so that it's flexible yet not prone to errors and overcomplication, but complex systems have a natural tendency to defy being forced into a simple design...

After days of bouncing back and forth between a smaller and larger scope for the special abilities, I settled on a system somewhere in the middle. In hindsight, there really should've been a lot more planning and testing before putting it to code, but the lack of concrete progress started getting to me after a few days of nothing but brainstorming and taking notes. Besides, no matter how robust it may seem, I'm sure creative modders will be able to break it. I'll just have to resolve to fix issues as they pop up, since I'd probably drive myself insane before managing to account for all the emergent possibilities. The engine does perform a lot of data checks on startup to make sure the abilities don't include any combinations that don't fit internal parameter restrictions, so we can hope the number of problems should be minimal.

Now that it works, I'll continue expanding the number of supported keywords before moving on to special items like the motion scanner. Much later on there will still be some kind of separate map-centric trigger system for terrain- and mission-related scripting; this one was focused on the game's more dynamic objects, especially entities (units).

For you, not me, that is.

The game is starting to get rather complex, and that complexity will jump yet again in the near future with the addition of more special items and their UI elements, so I decided to go ahead and add context help before going any further.

The first time a new help topic is available (one that hasn't already been seen before), the game will pop up some text to give an overview of how to use a particular function or window. Here's what you'd see when opening the inventory window for the first time (click for full-size image):


The entire system is very dynamic and ready to simply drop in new text (it comes from an external file) and give it a target area or console. That said, the help I've got in there now is limited mostly to UI elements, not gameplay. Eventually there should be more tutorial-style help as well to help new players understand the X-COM mechanics, but for now the majority of players probably know what they're getting into, so I'm holding off on that.

Hitting F1 or '?' on any window will also bring up the list of commands associated with that window. Here's the command list for the map/HUD screen:


A command list screen did exist before, but it was a temporary solution hacked together for the first release as part of last year's ARRP. Now it's mouse accessible, is properly animated, and has been integrated into the primary UI control system. The inventory and log windows have their own command list, as will all future windows. (For now mouse access for the main command list is through a tiny button found near the bottom-right corner of the HUD, since the that part of the UI has yet to be designed.)

So with another good chunk of the [somewhat boring yet essential] internal stuff behind me, up next are probably special items and Chryssalids/spawning. As with the other mechanics, the latter will be implemented using a pretty dynamic overarching system that will enable creative modding while still being capable of modeling the original X-COM mechanics. Weapon attacks (e.g., Chryssalid bite) will become capable of special effects on the target, one of which will be to cause the target to die and spawn another unit (e.g., zombie) of a specified faction. A greater variety of spawning will also be possible, so instead of just spawning a single unit, you could have the effect be to spawn multiple units nearby (xenojelly/ooze?), or even have a unit that naturally spawns duplicates of itself, or some other specified unit, at certain intervals. Think of all the possibilities! (No, really, think of possibilities you might like to see and tell me about them, so I can make sure they'll be supported.)

Morale is in, and works how you remember/expect it to. So now you can shoot your friend in the foot when he (and you) least expect it!

Check out the results of a total berserk rage as described in the log:

There you can also get a glimpse of the log coloring (which is available in the current release, R6, but I never put up a screenshot showing how it looks, for those of you who aren't downloading the intermittent dev builds).

Despite the thoroughness of UFOpaedia.org, some questions remain as to how the system works, which I resolved using what I guess are the most likely and appropriate methods:

• How much morale is lost by an individual unit when it is only injured? (I have it set to use half the value of an ally death.)
• How do non-X-COM, non-alien factions (e.g. civilians) fit in? (I have this handled on a per-faction basis, whereby it affects only the individual shooter, and X-COM soldiers lose morale for killing civilians, while aliens gain it. This behavior is easily moddable, of course.)
• What are the precise alien equivalents for the human ranks where morale calculation purposes are concerned? (The data I've got now sets alien "leaders" equivalent to colonel, and "commanders" equivalent to X-COM commanders, and all the remaining applicable aliens are squaddies, except where N/A.)
• How much stamina is drained for fleeing units, if any? (I left it as normal, though I believe the original doesn't actually deduct TU/stamina for panic movement.)
• Do fleeing units trigger reaction fire before they reach their destination?
• Exactly how many TUs do berserking soldiers get? (I've got it set at 125% their normal TU, which makes some sense--UFOPaedia says they get an absolute 255, but that can't be right since it would enable units to fire a ridiculous number shots..., and no one has confirmed that value for certain. From what I remember, I think they are only restored to full (100%) TU before berserking, but I would have to go back and play the game [yet] again to confirm it. Still have yet to do that, but I'll definitely need to set aside some time for it eventually to make sure I get everything right.)

Some of the strangeness in the original has not been carried over, of course:

• Fleeing units will not always head southeast
• Fleeing units behave according to normal movement blocking rules (i.e., no walking through other units)

I'm not going to put these extended options in the game yet, but some ideas for the future of panicking:

• Out of ammo? Charge up to an alien and repeatedly bash it in the face with a rifle butt. That would be great...
• Could also have different actions based on varying degree of panic
• Civilians jumping out of high windows to escape aliens (not unlikely), most likely plummeting to their death (for anyone who didn't already know, units jumping through windows and other fragile terrain has been possible for a while now, but civilians won't normally do it yet)

Morale effects are optional and can be turned off, like just about everything else. By necessity/extension, unit rank was also coded and actually means something now.

Below are a few more log screenshots of a game played in Area 51. Nothing exceptional, really, and these excerpts don't show much of the possible unique text and interesting events, but I haven't had enough time to gather a collection of fun logs yet.

Rogue Engine X, which was originally blazing fast, just got a little slower***, but it's going to be worth it!

Several months back I was fretting over what to do about the low readability of square fonts when you have long text strings or even a paragraph to read. After all, it's hard for the eyes to quickly parse that kind of unusual arrangement of characters--too much empty space. Eventually I threw out the idea of multiple fonts as not necessarily worth dirtying up the elegant and extremely efficient console-handling code in the engine.

Then a little while back jday brought it up again over on #rgrd and reminded me how important the text is in X-COM, so I started to think about it again, and realized that if it's not done now, it ain't gonna happen. Well... it's already happened, so I don't have to worry about that anymore!

Seeing as how it's going to revolutionize the upcoming UI, I had to fit it in now or the entire layout would have to be redesigned in the future. And revolutionary it is... think about all that extra info which can fit in there! The HUD will be twice as informative; the in-game log will be easier to scan; reading descriptions and stories won't torture your eyes; map overlay text will be a lot more readable, and more readily distinguishable from the map ASCII... the list goes on.

In order to keep the speed reasonably fast, the engine restricts the narrow text font width to exactly half that of the square glyphs so it lines up nicely for the rendering system--a bit limiting, but it still works out. Compare the appearance of these windows:

The command list. Though this particular window eventually won't exist in this form, it's a good example of how much easier it is to scan a list written using a narrower font.

The inventory screen.
...is now...
The log window. You guys haven't even seen this one yet! Text message work is still ongoing, and I haven't chosen colors yet, but this is a prime example of how reading a bunch of wide text would be quite annoying. In case you're wondering what the hell is going on, this is an X-COM rookie deathmatch in the sandbox =P
...is now...

Note that the specific fonts shown here are of course just something thrown together for testing.

One advantage of the new system is that the game now supports an unlimited number of fonts, which the engine organizes into sets that can be easily modded in through a configuration file. So the UI will now be able to introduce different individual fonts for different purposes, wherever it happens to work well aesthetically.

Look for a modest R6 soon.

In other news, I see that Xenonauts is kicking butt on Kickstarter after only the first couple days. Makes me jealous, and has also gotten me fantasizing about doing something similar with X@COM one day. Thinking realistically, there's not quite the same potential fan base for a non-graphical remake, but it doesn't hurt to dream! It'd be pretty amazing to attract enough money to develop X@COM full-time for a bit. Of course, to get on Kickstarter I'd have to rebrand the game (and perhaps instead tack on the original X-COM content later on as an unofficial "mod"). Not really a big deal, since it's just a bit of text, and my ultimate goal is to take this far beyond the original anyway. Meh, who knows.

***Okay, maybe not just a little slower... The required changes ended up dropping the REX rendering loop to something like 40% of its original speed. Sheesh...

...and eventually, Bang!

The UI for the next version has been audible for a while now--at least parts of it have. So be prepared for a bleeping good time next release! I'll be adding UI sound effects incrementally over many versions as new interface features are completed. The final map and HUD have yet to be developed, so I'm not bothering to give them sounds just yet. Weapon/movement/etc sound assets won't be added until much later, but the functionality is already there.

I replaced the inventory system from R5 with a new system that comes with greater versatility at the price of slightly higher complexity. Body parts, rather than inventory slots, are now the fundamental unit for creating an entity (unit). "Body parts" (which each have their own set of properties) can be grouped together to define a certain "anatomy" that applies to one or more races. Body parts and armor each come with their own inventory slots, so combining the two can result in different inventory layouts. Here's a shot of the relationship as commented in the source:
The original system was sufficient to model the X-COM rules, but not good enough for expanded applications like dynamic loss of limbs and the resulting effect on inventory space and item interaction. With the new system, races with entirely new and unique body parts and possibilities for interaction can be created by modding the text files.

Most X@COM engine mechanics are a superset of the original game rules, so there will be much more flexibility when expanding or modding the game. Almost everything will be exposed in text files (including mechanics, not just data).

There's also a brand new (and completely externalized) message system, including a combat log which records unit actions/events. The goal of this initial implementation is to simply provide a place where you can read what just happened, or scroll back through the log in case you missed a piece of the action. Eventually, at the end of each mission I'd like to have the game analyze the entire log, and create a summary of the action which is output to a file and could hopefully be an entertaining recap of a mission. The log is rather unexciting in its current state, so I'll save the visuals for a later video that includes more unique windows that will be appearing soon.

Thanks to everyone who showed their support in the Roguelike of the Year competition! We did fairly well--12th out of 185--considering X@COM is just an early alpha game. Next year once the game is a lot more playable I'm sure performance will be even better.

It's been a surprisingly long time since the last post. Sorry about that. Not that nothing's been happening over here, but I prefer having something concrete to show with every post. I'm still chipping away at the todo list, but the current stage of development involves spreading out into quite a few new areas of the game code, certainly much more time-consuming than banging out simple and well-documented game mechanics!

Plus, I don't want to screw something up now in the core program that'll become a source of endless headaches later.

Recent developments have been all about paving the way for a new interface. The HUD is still waiting on the sidelines, mostly because I have yet to decide what exactly it should contain and how to organize it all. Instead I'm testing the system by implementing a simple inventory window. I know your soldiers are getting antsy about the fact that they just *know* they have more ammo in their backpack, but, um... forgot how to get it :)

Well, now they'll finally be able to stock a few extra grenades and missiles, and do it in style!



Okay, so it doesn't look like much yet, but look again... it's alive!



The system is capable of far more than you see here. This sample is powered by a simple, generic window-drawing script; the interface animations are completely exposed in text files, similar to the weapon particle effects. So, just as you see weapons producing a range of snazzy effects, windows can do all that and more, and can be tweaked, or even rewritten, from the text files. (For those interested in the dev aspect, the system is very basic but powerful nonetheless: every visual component of the engine (window/control/button/etc) inherits from the same console base class, and every single one comes with its own lightweight particle engine--I LOVE PARTICLES! Besides making it not too difficult to implement good-looking effects, giving every object its own particle engine also makes control/manipulation fairly easy: even windows containing complex interconnected animations can be manipulated piecemeal and the flow seems to work almost automagically!)

In the game you won't have to watch entire windows be redrawn every time they're accessed--the way I have it now only the content portion will be redrawn after seeing the complete animation once (per run).

In its current state, the inventory screen should already be pretty informative and usable, showing TU costs, weight/encumbrance changes, highlighting valid/invalid targets for moving items or reloading, and telling you exactly why you can't do something, etc. It'll be expanded later on with additional functionality like the ability to define and apply set loadouts/equipment kits, and direct manipulation of other units' inventories (tanks that hold things, or those with modular weapons that could be swapped out by an engineer?).

In terms of control, the inventory is 100% controllable by obvious and intuitive keyboard commands. I used the mouse in the video so you could better understand what the heck was going on...

I originally thought the inventory interface would be a bit more graphical, but that wouldn't be as compatible with the new arbitrary inventory slot system. Armor and inventory slots have now been completely exposed in the text files, enabling simple creation of different kinds of armor which provide unique amounts of storage space and locations. Races are also connected to the slot system (also through the text files), so different races can specify different natural slots (which combine with armor slots to give a unit's total inventory layout). As each unit keeps track of its own available inventory slots, eventually adding the possibility of losing a limb won't be too much trouble (it'll still require a more specific body part list, though, which would also be compared against armor to make sure a given armor is usable by a certain unit at all).

Soon/next I want to finally integrate some sound effects into the particle engines to see how that should work with the animations. Hopefully those windows will be bleeping, blooping, whishing, and whooshing in no time. The audio engine is already in place, I just have yet to put together the resources and add ways for particles to trigger sounds.

DLL Hell, that is.

Spent some time wading through boring non-X@COM-related code, working out various annoying library dependencies. Finally got all the correct compatible versions playing nice with each other, then tested the new engine--seems to work fine. Then ported the game code over to the new engine, and X@COM looks... suspiciously unchanged:


That's because it's still using the same old DejaVu font (little coincidental pun there). The point is what it's now got under the hood: The foundation is in place for much more interesting design possibilities now that it's a completely different engine ready with sound support, archived resource access, parent-child console interaction, command processing (as opposed to kb/mouse processing) and more.

Now back to work on the game proper. The latest addition is a second particle engine, this one 2D, for animated interface effects. We'll see in the next post how it manages to draw windows!

I've also been playing with new fonts. Eventually there will be multiple fonts to choose from while playing, but I'll need to decide on an official default appearance. The problem is that square monospace fonts aren't all that easy to read, and the ones that are don't look all that great. On the other hand, square cells are somewhat essential for tactical strategy to avoid distortion of space.

Another issue is the font's readability in words vs. single characters. With more stylish fonts, identifying a character/letter by itself (i.e., on the map) may be more difficult when it doesn't appear in a word. Perhaps this could be solved by using a separate font for the each the map and interface text, but then that's not very console-like.

Anyway, here's the alternate test font I made recently:

Doesn't look all that great yet, but it's passable.

Proper X@COM development has been put on hold while I get busy reinventing the wheel.

After weeks of debating the issue with myself, I've decided to write a complete game engine from scratch rather than continue with libtcod. I originally intended to write a new libtcod framework that would replace Umbra and make coding X@COM a lot easier, but finally convinced myself that with just a little extra work I could write my own engine right on top of SDL, one that would be both simpler and much easier to modify to fit my own needs. Libtcod is a really cool library, but since I already have my own rather large collection of game classes (on which X@COM is based), I was only using a tiny fraction of libtcod's features in the first place (namely the console display).

After a little bit of planning (probably too little), Rogue Engine X was born this weekend. Here's a shot of "REX" in action--very impressive stuff, really...

Okay, maybe not so impressive. Right now it can't do much of anything except load a bitmapped font and draw one full-color console window. The color support is essentially the same as libtcod, although with a slightly different HSV pattern for the default colors.

REX features (eventually):

• Based on SDL
• Fully object-oriented (C++)
• 32-bit color console
• Command-driven input processing
• Sound/music support
• Access to archived resources through PhysFS

I already warned that X@COM's alpha debut is quite a ways off (two months, maybe?), so taking a detour to crank this out doesn't really change that. Consider this taking several steps backward in order to make huge leaps forward!

Be prepared for a totally different experience when you play the next release: True X-COM mechanics are finally here.

Actions now trigger reaction fire (opportunity fire) from enemies that have spare TU. The system is almost identical to the original, though a few of the small quirks were removed to keep it as straightforward as possible--there aren't any strange exceptions to the way it works.

Melee reactions/counterstrikes are also possible. Out of ammo when that sectoid rounds the corner and starts firing at you point blank? As long as you've got the time left you'll just whack him with your rifle, or whatever you happen to be holding. Heck, find a sword and intentionally have your ninja-reflex soldier wait around corners for unsuspecting aliens--the heads will roll!

About the mechanics: I can't recall whether X-COM units actually turns around as part of reaction fire to shoot aliens after being hit in the back (probably because you rarely survive hits from behind by alien weaponry, anyway...). Either way, that behavior is a per-unit setting in the data files, so it's easily changed. For now I have X-COM *not* turning around.

You can reserve TU for any major action (snap / burst / aimed / melee / throw), and also intentionally deplete a unit's TU with a single command so you don't have to worry about those freaking reactive snap shots with a rocket launcher (unless you want them, of course).

Check out the video below for the ultimate showdown between X-COM and aliens. This battle is 100% based on opportunity fire! Reaction fire on this scope wouldn't normally happen in the game, but I added a third "overwatch" faction which triggers the exchange and tweaked their TU so they won't interrupt the battle; meanwhile, all the other units have full TU and are just staring at each other until someone moves... (HD + fullscreen strongly recommended, otherwise it can be hard to see what's going on)





Explosions are now simultaneously animated from the side, as seen here:



Parabolic projectile trajectories are also possible now. This feature was implemented primarily for the celatid spit, which is apparently the only projectile in the game which does that, but now any projectile can be designed to follow a parabolic trajectory, so you can add mortars etc. Be sure to kill celatids from a distance--or be killed (they've got the deadliest projectile in the game). There's now a max range setting for projectiles, also implemented for celatids, since parabolas don't inherently limit range like they did in the original. You don't want them spitting that stuff at you across the map! All other projectiles currently have unlimited range, of course.

In other news, those alien saboteurs (see 2x2 post) sure are persistent. My motherboard malfunctioned yet again. Lost a PCI slot and BIOS decided it wanted to try to overclock the CPU without my permission. Thought I was going to have to build a new rig to replace this 5-year-old dev machine, but after a cleaning and rearrangement of parts it's chugging along, again. Point is, fooling around with dying hardware ate up enough of my spare time that I probably won't get to push a new release this weekend.

All the new systems are debugged and ready to play, but I want to add a scoring system and new environment/scenario for the next (and last) pre-alpha release: Area 51.

It took one heck of a mega-refactor, but... they're finally here.

First time spending this much time on any one part of X@COM (even the particle engine only took a little over a day); had to parse a big chunk of the code since large units touch on a little bit of nearly everything--display, body item mechanics, FOV/LOF, pathfinding... Those weren't actually much of a pain, though. Implementing the effects of gravity on these guys was the annoying part--proper displacement by falling objects, bumping into each other while tumbling through the air, etc... In the end it was definitely worth it (not to mention necessary for any self-respecting X-COM remake!).

First sighting: Reaper!



So in the next release you'll be able to stomp--oops, I mean get stomped by--some large units. Don't worry, you'll have tank support! Too bad we all know X-COM tanks tend to suck. I suppose I'll be generous and give you a well-armed rocket tank or something like that, but it won't save you...

Not from...





Hell yeah!


That's a bit excessive though, you won't see anything quite that big in the demo.

But anyway, as you can see, unit sizes are actually arbitrary--they can be any dimension you like, even taller than one cell! Why not, the code is the same regardless of size. Not necessary for vanilla X-COM, but could lead to some interesting mods :)

Since it's somewhat related to large units, next up is terrain smashing: Any units with strength exceeding the integrity of a terrain material can smash right through it (for a TU cost). So soldiers can jump through windows, tanks and strong aliens can push down walls, and massive units could walk right through buildings. Obviously like anything else not X-COM, this will be an optional setting you can turn off in case you *don't* enjoy jumping through windows or surprising aliens by driving your tank through the side of a house.

After that is tank/natural weapons. That'll be a quick addition, then I can get the next release out.



In other news: ALIENS HACK X@COM!



They must've found out about X@COM and are afraid us Earthlings are developing a training program to devise ways to repel their imminent invasion!

Okay, what really happened is the ASCII mapping code was a bit off and turned the help screen into some alien language. Under the new mapping scheme, a virtually unlimited number of tiny images can be added to the resources and attached to any terrain, unit, etc. This was necessary to make it possible to draw the 2x2 units using special characters. Until now I was relying on hacks to get the unit triangles, but now they and the normal ASCII characters are easy to work with, even from the text files.

"Unfortunately AI will be nonexistent, so you'll have to settle for blowing up terrain and static units." --Me, Yesterday

I lied.

I figure the ARRP release will be a lot more interesting if your enemies move and shoot at you, so today I went ahead and threw in a simple AI, as well as faction-limited perspective (cannot see non-visible enemies taking their turns, etc.).

Prepare to be blown away, unless you think your squad can fight off waves of aliens teleporting into the area. Of course, you can always steal their more advanced weapons and blow *them* away...

(I haven't made the scenario yet, but hopefully I can find enough time to finish everything by release day. Too bad this is going to be an unusually busy week...)

You read the title...

You've played X-COM before...

You know exactly what I'm talking about...

Let's flex our new-found throwing muscles and put the hurt on an unsuspecting alien emerging from his craft...


(Not a great video, but maybe throwing the electro-flare and smoke grenade helps make up for it? :)

So as you can see, proximity grenades work, as do many other kinds of grenade explosions. Any item with an attached "throwing explosion" also has a "grenade use" setting. Besides the standard/expected PRIME and PROXIMITY settings, I added support for these:

• IMPACT: Explodes immediately on impact if thrown (instead of waiting until the end of the turn like a normal grenade primed to 0).
• VOLATILE: Like IMPACT, but will also explode if it falls and hits the ground.
• REMOTE: Thrown/dropped and set off remotely/manually with a detonator. This is not yet fully supported, since there is no way to create detonators, but it seems like a frequently requested option in X-COM remakes, so it could eventually be added (not going to bother in the short-term, though).

None of these were in the original X-COM, but they could later be used to create interesting items.

In other news, I've decided to join this year's ARRP with X@COM! Everybody's doing it :) Seriously, if I wait until I'm far enough along to make the game semi-playable and good enough to get through my perfectionism filter, it could be many months away, and this being a project with a fairly clearly defined initial goal, it's not like I've got a ton of secrets to hide when it comes to gameplay. The unique components are a ways down the road, anyway.

I may as well let people try the game out early, so I'll be releasing occasional tech demos beginning September 18th, 2011. Tech demo releases probably won't be all that frequent (compared to playable releases, which will be updated quite often when they start coming), but I may as well throw something out there just to be a part of ARRP.

So what can you expect? It'll no doubt come with a big fat disclaimer, but hey, it's a sandbox tech demo, after all. Content-wise, you'll basically be getting the latest version I'm using to debug/code the game, so it'll include all the features you've read about in posts and seen in the videos. Unfortunately AI will be nonexistent, so you'll have to settle for blowing up terrain and static units. Anyone interested could, however, play with the data files (text) and create/modify just about any object... I'm still undecided on whether to leave debug output/interface features in the demo.

As usual, opinions are welcome!