X@COM

Actually you don't need a break, Area 51 needed a break.

While rushing to add in the new Exodus scenario for R5, I screwed up R4's Area 51 and didn't notice. Left one freaking line of code, a "break," out of a switch statement controlling some hard-coded Area 51 update processing, which led right into Exodus code... If you play Area 51 under the new release it will crash after several turns. Thanks to Tarran and stabbymcstabstab over at Bay 12 for reporting the issue. I've uploaded a new version of the release (same filename), so Area 51 now works normally.

By request, the update also includes a smaller font so the game can be played at 800x600 (press Ctrl-PgUp/PgDn to cycle fonts, but note that you have to release ctrl before each change if you're trying to switch through multiple fonts in a row). I didn't spend very long getting the small font to look nice, so some parts may be a little fuzzy, but it appears serviceable. There will be more font options in future versions.

While I'm posting, I may as well put up the version roadmap I've been working from, and somewhat cleaned up yesterday. Do note this roadmap is subject to change (in many cases I might push back a feature to the following release, or move one up), but this is at least a fairly comprehensive list of the remaining features to implement, at least for the battlescape. I'll add this information to the FAQ page later, and update it as things change. Items in all caps refer to those containing multiple components:

I'll also take this opportunity to ask for some input regarding map dynamics. What do you think will be fun/useful information to have on the map in the form of optional overlays and extra indicators, etc.? Things that can be activated temporarily for extra feedback. Currently (as requested for an earlier release), there's already a threat highlighter ('e'), which can be fairly useful in messy situations with numerous targets on multiple levels, as well as several forms of FOV highlighting (yet to be improved). Other ideas:

• Unit names and/or types shown next to their symbol
• Item names shown next to their symbol
• Building/terrain area highlighting w/names (later the map editor will ideally be able to name buildings and terrain blocks, so they can be referred to in the game and used as a reference)

So if you can think of something else you'd like to see, speak up now. I'll also be posting this question on Bay12 for discussion. (This question is a precursor to a discussion on HUD info, which will in some cases be dependent on what the map can be used for.)

Well, X@COM still isn't where I wanted it to be for the year-end alpha release, but my hand was forced since the R4 demo will expire soon. (Every demo release is actually hard-coded to expire after a certain period--it keeps me releasing new versions [mostly] on schedule!)

So I bring you 0.10. The changelog isn't all that impressive, but this is actually the biggest release yet in terms of modifications, most of them internal as the game is now powered by a brand new engine. Let alpha development commence!

At least now you can try out the new inventory system. With full inventory access you'll also be able to keep those grenades out of your off-hand for better accuracy with two-handed weapons, and carry spare ammo for heavy weapons to make them a lot more useful.

Remote detonation of explosives is now supported. This marks the debut of the 'u'se command, which will be for all sorts of special functionality in the future. Priming your remote charges will create a detonator, which can then be activated at any time by using it. The original X-COM didn't have remote charges, but it's a commonly requested feature, so I've added them since it was easy and the vanilla mode can simply leave them out. Later on when aliens can pick up weapons, it would be amusing if/when the dumber ones happen along and pick up your primed remote charge...

To make downloading the release a little more worthwhile, I added a new scenario: Exodus. You get to assist the National Guard during the evacuation of a city overrun by aliens. This mission shouldn't be too difficult to "successfully" complete, although there's potential for a much higher score if played well. Replayability is high as the city layout and opposition forces are randomly generated. You have a smaller squad this time around, but they're better armed (and armored). You'll also face a new alien species, a weaker precursor to the upcoming Chrysalid (minus the zombies).

Here's a shot of a generated city (revealed):


"Looks quiet. Also looks like we've arrived a bit late..."

During one of my test runs, a huge group of civilians came swarming my way, and right before they reached safety, a blaster bomb came out of nowhere and toasted them all... poor civvies.

Oh, and being a city, I upped the map height to 6, so you can have some pretty tall buildings out there.


The older scenarios have also been modified/updated, mostly to give you a little more firepower and flexibility since now you have inventory access. Area 51 might be slightly easier since there's enough explosives stocked about to level the entire base. Just try not to be in it when that happens.

Your rookies should be ever so slightly more effective now, since while overhauling the armor data format I discovered that the armor value application (a temporary hack for the demo) was overriding all rookie armor with zeroes... So at least now they have that minute amount of armor (which we all know they so desperately need).

I noticed the annual Roguelike of the Year competition is being held right now. There have already been a fair number of votes cast for X@COM (I was pleasantly surprised when I first opened the page and saw several dozen votes), but let's try to get that number higher! Obviously X@COM won't (and shouldn't) win, but the extra awareness would be good, so go put in your vote! (Of course, that assumes you're reading this because you like what I'm doing here.) Don't forget to check out the other entries, too; I voted for DCSS, DF, Infra Arcana and MageGuild. Oh yeah, and myself :)

The next release will come some time next month and should include at the very least medkits (stop bleeding already!), UI sounds (ooooh), and a main menu (not really all that essential yet, but I might as well..). Other things high on the alpha list that will be appearing in the next few releases:

• sounds
• proper message system
• special units (Chryssalids, Silacoids)
• special items (motion detector, mind probe, psi amp)
• morale
• psionics 
• battle recording?

I should also spend some more time on HUD design/planning, and there will probably be another post dedicated to it that provides some HUD content proposals which can hopefully attract input.

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!

After much hardware-induced delay, a new release is ready for the ASCII-loving, alien-hating commanders out there to test their skill (and/or luck) on.

In addition to the many new features mentioned in the previous post, R4 adds a new scenario and scoring system to tide you over until the first alpha release, which probably won't be available until the end of the year! Most of the core mechanics are complete (the rest will come in alpha), and huge changes will be taking place over the next couple months as I build a libTCOD framework from scratch to handle the kinds of things I want X@COM to be able to do. I'll occasionally post progress updates when there's something to show.

As for the new scenario: Fight alongside soldiers defending an Area 51 base against an alien assault, and be prepared for some surprises. To play, run Area51.bat. The environment is non-random, but enemies are mostly randomized. Once the remake is complete, later versions could optionally include similar handcrafted scenarios, though of much better quality and properly balanced.

There are a lot of enemies, so definitely try out this new feature: You can now press/hold the 'e' key to highlight known threats. So at the beginning of a turn when you've suddenly been engulfed in total chaos (very likely to happen in Area 51, believe me), highlight the threats to quickly get an idea of what you're up against. (Threats are highlighted no matter what level they're on.) The visual effect is currently handled with the projectile particle engine, so flashing indicators may not appear in their entirety for units at the edge of your FOV (or at all for known units outside FOV); there will eventually be a separate 2D particle engine for map/interface effects that can properly handle highlighting and all kinds of other nifty indicators.

As usual, see the changelog for a comprehensive list of what you get with R4.

You can still play the original completely randomized ARRP demo; in fact, it's still the default. Remember that the original scenario will be a fairly different experience now that reaction fire is implemented.

As requested, there is now a scoring system (applies to all modes). The game will eventually replace this temporary implementation with a detailed and extensive scoring/records system, as well as medals for soldiers and achievements you can earn as commander. Here's the result of my test run on Area 51:
There are more unlisted ways to score points, but I didn't earn those. If you have a particularly good run (or even win!), when you see the mission end screen press your PrtScn button and a screenshot will be saved in your game directory. Maybe you could show it off in the X@COM Bay 12 thread (link on right).

That's it. No more media for you. Not doing any in-game screenshots or video for this release, at least not just yet, since I don't want to spoil the fun.

Now go! Defend Area 51!

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.