X@COM

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

As I warned, most of the past month was spent on vacation. So no X@COM :(

What I didn't foresee, however, is that I'd come up with a fun idea for a 7DRL, which I'm now spending my free time brainstorming for.

So no X@COM, still :'(

At least it could possibly be a fun little test bed for X@COM UI elements, since it'll be developed using the exact same tech--in fact, it's going to run under a gutted 2D version of X@COM itself.

I'm not quite sure if it's going to work out yet, and I can already smell a failure on the horizon since this game idea would be better suited to a 3-6 month dev time, but in order to squeeze down the design doc I've been hacking the features list to about 10% of its original length. The result should still be playable, though not quite as dynamic or interesting as I originally intended it, as the gameplay will have to focus purely on the core mechanic and nothing else.

The title is Cogmind, and compared to X@COM it will be a far more traditional roguelike: A sci-fi dungeon romp in which you control a single character with single-action turns. For details, you can check the Cogmind blog. (Doesn't exist yet--I'll update this post with a link at some point.)

As a 7DRL, Cogmind has a finite completion time and won't be in the way for too long, so fear not, I'll get back to X@COM soon enough. (The current public demo expires at the end of March, so I have to get out another release by then...)

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