X@COM

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

Just when I thought I'd jump into adding new content, more planning showed that a generic system to implement the chryssalid ability and a few others might as well be expanded into a powerful dynamic system.

Enter "special abilities."

The term is probably not as limited in scope as you might be thinking. Special abilities will enable objects to combine conditional triggers and effects to define unique behavior under the right circumstances, and will probably be applicable to races, entities, armor, items, and/or terrain. They'll make it possible for chryssalids to turn their victims into zombies, zombies to transform into chryssalids on death, silacoids to leaves trails of fire as they move, and many more effects that you didn't see in X-COM. They could enable:

• An alien that absorbs or eats vegetation or objects it passes over/nearby, possibly regenerating itself as a result
• An alien that emits smoke
• An acid beast that corrodes adjacent metallic objects
• Snakemen that lay eggs which can in turn spawn more snakemen (UFO TTS)
• Volatile ammunition for some strange alien device that has a small chance of exploding when loaded
• An alien man-eating plant that chomps on units that pass by it
• A plant that rapidly grows and spreads over time, perhaps with additional side-effects of its own
• etc. (<--very inclusive bullet point ;)

Of course some triggers and effects may not be compatible in all cases or with certain objects, but there will be a pretty wide variety of valid combinations, and new additions should be relatively easy once the system is in place (I'd be happy to add more in the future for modding purposes). All of the parameters will be defined in the text files.

Yesterday I started implementing the necessary data objects, and as a test merged unit death explosions into the system--so now the basic infrastructure is ready. I was considering merging grenade use and light emission (by units, items, and props), but they're already working nicely so I'll leave them alone for now, and maybe migrate those features later. Silacoid fire trails and chryssalid/zombie mechanics are next, and even the upcoming motion scanner, medi-kit, mind probe, and psi-amp functions will fit in nicely. For a single item with multiple manually-triggered abilities (as opposed to the passive kind), there will be a list to choose from when activating/using it (ex: psi-amp, which could then easily be later modified to support a broader spectrum of psionic abilities).

The way this will work:
Abilities specify an initial trigger, and all abilities with a given trigger are checked for whenever the trigger situation occurs. A sample list of possible triggers:

• "Use" an item
• Move
• Attack
• Hit by an attack
• Fall
• Death
• New turn

Abilities may qualify their triggers using one or more conditions, for example:

• Standing in or adjacent to burning/smoking terrain
• Standing next to a unit
• Holding a certain item
• Some stat has a relative value
• Random chance

Finally, once triggered there are a number of effects an ability could have, including:

• Explode
• Spawn an object (many variations)
• Assimilate a unit (switch faction--could be for psi-amp mind control)
• Panic unit (psi-amp effect)
• Mutate one unit into another
• Transmogrify an item

All of the above lists are just what I currently have enumerated in the code for eventual implementation. Many more will be added (ideas welcome).

As a part of the new system, objects will be able to list their traits (or properties, e.g., organic, sentient, metallic, etc.), where the list of possible traits also comes from an external script. So you could pretty easily add new traits and define abilities that may only (or cannot) affect objects which possess a given trait. I'm adding that feature now because it's better than hard-coding the restriction preventing chryssalids from zombifying tanks. Can't have tanks roaming around trying to bite your soldiers, now can we...

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.

This isn't the big release I intended it to be, but I figured it'd be nice to get a playable demo back out there so anyone new to the game can try their hand at perforating some aliens.

There's no new scenario this time around, or any new gameplay at all--R6 is mostly a batch of UI changes.

As described in the previous post, the engine was refactored to support multiple fonts simultaneously, which will play a big part in future UI design. Using multiple fonts of different sizes isn't very true to the console tradition, but square fonts aren't very readable, and readable non-square fonts aren't all that great for a tactical map since they distort space, so X@COM should benefit greatly from mixing the two--square fonts for maps, and narrow fonts for text. (The R6 HUD still uses the wide text font, but will eventually be narrowed once it's redesigned.)

The temporary message feedback system was replaced by a more proper version which can be easily expanded and modified through the data files.

A new Combat Log window is now available, where you can read all about your squad's glorious exploits. The log is still in its infancy, but already includes more than 80 different message types. On completing a mission, your score and log are output to an html file (it'll show you the file name and path). I originally had it writing to a text file, but decided it'd be nicer to retain the log message colors, hence the html.

If you played Cogmind, you'll recognize the text animation effects and sounds, which were from this previously unreleased version of X@COM to begin with (I've been sitting on most of it for a while now). If the message sounds annoy you, you can mute the game with F6. (Don't forget to check F1 help for new commands.) It won't be so annoying later when it's accompanied by a wider variety of console bleeps and bloops as you give commands and watch the battle.

Although it doesn't affect current gameplay, R6 comes with the refactored anatomy system. Future modders will be happy to know that they can create new body parts, then combine those parts into completely new beings where the body part parameters do actually have a number of gameplay implications. This system was already described in an earlier post.

There's also a set of new larger fonts available which can be activated for a 1280x960 window, along with somewhat improved fullscreen support. The larger fonts were a quick job--I just blew up and the normal fonts and tidied them up enough to prevent graphical artifacts, so they don't look nearly as good as the official fonts will when I get around to dedicating more time to them. Here's a shot of one of the font sets available at the higher resolution (click for full size):


The next release will bring some new gameplay and yet more UI windows.

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

The 7DRL Challenge game which has been keeping me from X@COM development is now complete! Check out the Cogmind blog for details. The blog should look pretty familiar... Hell, even the game has a visual style identical to X@COM since it was written based on the same code.

Unfortunately there was way too little time to use Cogmind for some of the X@COM test development I had intended--my initial 7DRL plan was far too ambitious and I barely managed to crank out a finished game as is.

However, the interface does show off some features already available in unreleased versions of X@COM, so you can check out Cogmind to get a preview of what'll be coming down the pipe for R6 and beyond. Tell me if you like (or don't like) what you see. Things to look for: the message log, UI test sounds, and animated HUD (though the X@COM version is going to look much cooler, since I threw together the Cogmind HUD as fast as I could).

While the two games may look similar, Cogmind plays totally differently. I had lots of fun playtesting it, and you should definitely give it a spin. Tell me my hiatus from X@COM was worth it! :)

(click for full size image:)