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.