X@COM

Well, not really. I'd happily pour all my time into X@COM development if I could, but holiday season is upon us, and I'll be out of the country for a three-week computerless vacation. I'll try to crank out a new release sometime in February after I return--I look forward to sending you up against chryssalids! (I think I'll move them up to the next release so I have a reason to include a new scenario featuring new challenges.)

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

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!