X@COM

The next stage of development is focused on re-working and fleshing out the interface, and you'll notice on the roadmap that among the new elements is the UFOpaedia database. As I imagine it, you'll be able to access the database directly from the battlescape for detailed information about items, creatures, terrain, and more.

Ideally each entry will be accompanied by an image, albeit drawn as ASCII art. Note this does not mean conversion of images to ASCII (which doesn't count as "ASCII art" in the same way that simply lowering the resolution of an image doesn't qualify it as "pixel art"). According to the current plan, images will be comprised of the standard 256-character code page 437, probably including at least some use of background colors as well.

ASCII art fits well with roguelikes since both tend towards abstract representation of objects,
so I figure that many RL players can also enjoy ASCII art. That said, enjoy these samples I've been working on while testing concepts and tech/tools:

ASCII concept art, who would've guessed...

I'm still a beginner at this ASCII art thing (this being my first attempt ever), but your discerning eye should be able to recognize them. One can hope.

When doing RL GUI mockups a few years back I used ASCIIPaint and WEPaint over on the TIGForums, but they suffer from clunky interfaces and are a pain to use, especially when compared to eigenbom's ASCII Paint fork which I discovered only recently. He's done an awesome job of making this type of software relatively user-friendly, and his fork is what I used to draw the above images.

I used only the colors provided in his standard libtcod palette, which was in some cases limiting (sure there's the whole "limitations breed creativity" idea but in this case I was missing a few shades that would've helped a lot). The point of my tests was elsewhere, anyway: Attempting to determine whether ASCII art looks good enough at large sizes using a square font, the main issue being code page 437 is traditionally represented using the non-square IBM font, and trying to force it into square cells tends to result in far too much empty space that can impact the density and thereby cohesion of an ASCII image.

Obviously we want the art to work at any size X@COM can be scaled to, so I drew the above with a 16x16 font, then reloaded them with a smaller font to test their appearance. What do you think? Both look viable to me.


Having said all that, I'm pretty sure that my next task here will be to take a quick detour and code a new ASCII editor, one that will write to a format that X@COM can read and display directly in game. While the main purpose is to create a tool to streamline creation of the game art, and there is a chance it will later be used to create multi-cell UI pieces that could be a component of for map overlays (though at this point I'm not sure whether that will be necessary), and it will also be useful for drawing UI mockups in the near future. I also enjoy seeing what creative works users come up with, as seen in the TIG thread (there is some cool-looking stuff over there), though it would seem that by now everyone is kind of ASCII'd out so I'm not too hopeful on that front.

The editor of which I speak, likely titled REXPaint after the engine it's based on, is feature-wise more or less eigenbom's fork minus a few elements I don't need, plus a few I do need that it lacks.

On the new/different side you'll be able to

• browse through all art assets from within the editor itself and switch over to painting mode at the press of a button
• do in-program palette editing and manipulation (with a true color picker)
• use layers for easier tweaking (and possibly other advantages later)

I have a more detailed design doc outlining features-to-be, but those are the highlights. Feel free to make suggestions or feature requests. Besides saving to the X@COM art format (*.xp), the editor will export PNG images so it's perfectly possible to use it as a general purpose stand-alone ASCII art editor.

Below are some REXPaint UI mockups, not exactly feature complete (or even correct, since I've changed my mind on a few parts since drawing these up). The second one includes the concept for a browsing mode interface.



The color choices aren't too important at the moment, since re-skinning the interface will be very easy.