X@COM

Well, yes and no.

What I mean is the game is going to be re-branded with a different name and content while keeping the same mechanics and premise--you'll still be leading an organization tasked with defending Earth against aliens; soldiers, battlescape, geoscape, bases, craft, and all. This will enable more freedom in both design and fundraising. (If you *really* want to play the original in ASCII form, I'm sure a mod will be able to help you with that--we more or less have one already, minus the geoscape.)

We don't really need another X-COM clone, anyway, which X@COM is already decidedly not, so... first thing's first: we need a new name to

• preferably represent what the game will be (or at least some aspect thereof)
• get at least a little further away from "X-COM"
• be easier to search for, '@' characters not being all that search engine friendly
• be pronounceable ;p

Since this plan has been in the back of my head for a quite a while now, I've already had plenty of time to come up with, mull over, and throw out the window lots of ideas. The only one that's stuck to date: Company X.

While X@COM is not a clone and does/will include lots of additional features, it obviously has its roots in X-COM (as well as some of the trunk as well, considering core mechanics and gameplay), so I preferred a name that still embodied those roots (okay, trunk), hence the 'X', and "Com..." (cleverly reversed, mind you!)


In 1973 a close group of respected scientists exploring the entertaining possibility of alien life on Earth made an important discovery. Although based purely on a confluence of soft evidence, it appeared that aliens really could be responsible for a series of unexplained and seemingly unrelated events across the globe in recent years.

While they couldn't take their views to the public without risking their reputations in the scientific community, they were convinced that given more time and information it might be possible to piece together enough evidence to prove the Earth was in fact under alien surveillance for an unknown purpose.

They called themselves "The Company," a joking reference to not being alone on the planet.

Uniquely positioned to gain access to normally restricted data, The Company slowly pieced together behavioral profiles and hypothesized about technological advancements behind various unnatural phenomena, all rooted in real science. For several years they silently investigated and monitored suspected alien activity, even developing technology capable of detecting Unidentified Flying Objects and tracking them for a short distance.

It is now the year 1985, and the aliens are becoming more aggressive. No longer are incidents limited to brief sightings and random abductions. Inexplicable small-scale attacks have begun to shake the public psyche even as governments are quick to initiate cover-ups and attribute them to terrorists.

The Company decides it's time to act.

Through one part pattern analysis, one part behavioral science, and two parts luck, they successfully predict the next target site. Acting in coordination with local law enforcement contacts, they have an entire squad of officers briefed and waiting in ambush when two armed aliens arrive at the scene, immediately surprising and subduing them before they can react.

Major world governments are impressed at the group's success, and unanimously agree to fund them as a new independent initiative tasked with combating the alien threat in all its forms. Knowledge of the alien threat is not yet ready to be brought before the public, thus the deal is kept secret and for now the group appears on government defense ledgers as simply "Company X."


The term "Company" can be taken in the military, economic, or even "group" sense. Obviously you're leading a paramilitary organization, as well as essentially a company what with manufacturing and selling equipment on the side to supplement income...

The story is not incredibly unique, just another possible way such an organization could be formed that covers most of the necessary bases while keeping it generic enough that it could play out in any number of ways from your starting point.

More or less this same news was first posted yesterday on Bay 12, so you can check there for other responses if interested.

Unfortunately while the name fits the theme, series, and story fairly well, it isn't all that amazing on its own as a name, which is definitely a drawback. I've also come up with an alternative which stands on its own pretty well and you may prefer instead: Xenocorps.

The good thing is, either name could essentially use the same logo concept I'm rather fond of (which is really just a modified X@COM logo, at that):

What do you think about all this? (Before you suggest it, just this afternoon I was thinking of other names and already came up with Hot Pink Elephants From Space Ate My Pajamas. I'm a little on the fence with that one.)


This re-branding is not happening right now, but will come eventually once the project enters the refactoring stage where I clean up all the crap I've been stitching together just to keep the project playable and fun while new features were added.

What are the specific implications? I'm glad you asked, because you'll get...

• new races!
• new weapons!
• new... everything!

Well, under the hood you'll still have X-COM's familiar core mechanics which are, after all, what I developed this elaborate prototype for in the first place...

In time there will be plenty of room for discussion regarding the new content and overall game design. Before then, once the new name is determined we'll likely have a new general forum to help direct future development and provide a place for players to interact. 

Several days ago I had a nice post ready to publish, complete with geoscape mockups and all, but the focus was the announcement of donation support and I discovered only at the last minute that PayPal donations aren't allowed in my country (seriously, they told me to "start a company and sell a product or service"...), so... we're suddenly talking about this instead.

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.

As we're all aware, atmosphere is an integral part of the X-COM experience, and an important element for building that atmosphere is sound. The sound of unfriendly footsteps echoing through the darkness; civilians screaming as the aliens find them before your squad does; hearing gunfire pierce the silence as unseen aliens fire on your position, but miss their mark so you still have no idea where they are. These add to the suspense, while also making the "hidden movement" phase that much more interesting (and informative).

This aspect of the game has been on the back burner for quite some time while we squared away the core mechanics, and with that done it's now time to decide what needs to be heard.

Items:

• Weapon fire / attacks
• Projectile impacts (projectile+material-dependent)
• Explosions 
• Throwing/landing (latter could be material-relative)
• Dropping (essentially same as landing)
• Picking up
• Melee swings / misses
• (Ammo loading/unloading probably unnecessary for now since only possible through inventory window, which has its own sounds)

Units

• Footsteps (usually terrain-based, but units may override that in special cases, such as flight or huge stompy aliens)
• Death

Terrain

• Footsteps (us. material-based)
• Door open/close
• Destruction (us. material-based)
• Falling prop impacts (unbroken, us. material-based)

Aside from the lists above, the sound system is already accessible through special abilities scripting, so sounds can be connected to just about any game element to create unique situational sounds like a terror unit roaring on spotting a target, or a chryssalid screaming on injecting a victim, etc.

Much of the functionality already exists, as particles and anything that uses them (attacks, explosions, throwing, melee...) are already capable of playing and controlling sounds (which is how the UI emits sound). We still need control for sounds related to non-particle objects, and to [elegantly] deal with various issues like the extreme cacophony that would result from huge explosions destroying wide areas of terrain, footsteps out of sight (it will slow down turns to always have NPC unit steps heard--not sure by how much), and many more I no doubt have yet discover.

After that it's mostly a question of putting together the assets, but I won't be doing all that now, just a core set used for testing/R9.

Fortunately I have handy a nice library of 157 footstep sounds I put together for an old game, so hopefully they'll work well for X@COM without too many adjustments (although I may have to edit them all--doh--to get them to work with the faster movement speed than the game they came from). Categories include dirt, grass, gravel, metal, mud, puddles, water, wood, rocky, snow, stone, and undergrowth. Because you need something other than my wall of text to look at, here's a color-inverted shot of one of the snow footsteps in Audacity (my primary sound editing tool):

*crunch*

Another issue at hand is to determine what level of control the player needs over sound. Besides the obvious option of muting the game entirely, will it be sufficient to split sound effect control into two categories, UI and game? That's what the plan is, in any case.

Other features under consideration (any opinions?):

• Dynamic sound effect volume based on the distance of the source from the nearest unit under the player's control
• Music isn't appropriate, but some kind of ambient drone or beat as heard in X-COM can help set the mood (as long as it's not too intrusive).
• [Unlikely:] Very subdued map-wide ambient/background sound effects, like distant shouts and screams in a densely populated urban map, wind through the trees in forests, etc.
• [Unlikely:] Environment sounds emitted by props, and heard only by the currently selected unit; examples would include fireplaces, gushing streams, machinery, alien facilities, etc.
• Radio chatter?

I'm not going to press forward on all this immediately. First there are a few little items sitting on the to-do list that need cleared away while awaiting any comments/input you guys have to offer.

Okay, so there's no swimming, we already have running (though X-COM soldier endurance leaves much to be desired), and we aren't going to have high-tech bikes.

Today we instead have climbing, jumping, and hurdling for you. (Maybe.)

Climbing:

This could open up a lot of new strategic options for movement. Terrain would have a "climbing difficulty" while units would have a new climbing skill that determines how easy it is to climb different terrain, if they can at all. Unless climbing something far beyond a unit's skill level, failure would usually just mean wasted time and stamina rather than outright falling to the ground.

You'd simply face the terrain you want to climb and use the standard upward movement commands (or let the pathfinder do it for you). You can change facing while climbing to look around, but must again face a surface in order to climb it. Reaction fire is also allowed while climbing, but only with one-handed weapons. If shot while climbing, there's a chance you'll fall. Upon reaching the top you'd climb up onto the roof or whatever flat surface is there. To climb down rather than jump down, you simple walk backwards (this would be a new command) over an edge.

Jumping:

The ability to leap across gaps would be nice, even better if jumping allowed you to fly off a roof and crash through a window in another building.

Hurdling:

It would be useful to quickly jump/slide over shorter movement-blocking terrain objects like bushes and tables, rather than going around them.


So... none of this is implemented yet, but I've been thinking about them for a while and still there are quite a few details to be ironed out before coding could begin. Because it may take some time, I've decided to put this up to a vote! Let's decide whether all this should wait until later (in the interest of actually making it to 1.0 this century), or go in now. Rather than using a poll, I ask that anyone with input leave thoughts in the comments section. There are certainly some gameplay implications to consider here, like the ability to climb trees to escape zombies (which would then attack the tree and bring it down?), and no doubt a lot more interesting aspects than that.

Keep in mind all of these features can/will be optional, and that even if not implemented in the current version they would still probably make it in one day, so even if you want to vote nay, feel free to bring up any relevant details I may want to consider when the time does come to add these features.

As cool/fun as these would be, I'm somewhat tending towards skipping them for now, even though I've already put a lot of thought into them. They're fairly complicated and there is a good bit to take into account and test so these systems work smoothly with everything else.

Anyway, I'll leave this topic in the incubator and work on the list of assorted loose ends and general improvements for now.


EDIT 2/1: Well, not as many opinions came in as expected based on the readership, but I think the general trend is apparent: Hold off on this until later (I am combining responses from here and Bay 12). So the parkour skill/actions have been pushed back to 1.0+ territory.

In the meantime I've heard that Linux/Wine and some Windows users have been unable to play the mods using the new standalone format. I've repackaged them all with a second batch file inside the actual game directory which should work in cases where the original/primary batch file does not.

Lately I've been reviewing my plan to make mid-mission armor swaps a reality for X@COM, and thought I'd throw my ideas out there to see if any of you have any opinions/suggestions.
I originally didn't bother with this feature since I was trying to keep everything fairly simple and focused on the tactics, so armor currently isn't even represented as an instantiated object in the game. Now I'd like to turn armor into an actual item, mostly intended for mods and special uses, since in a standard X-COM mission your soldiers would obviously be suited up beforehand and are unlikely to have time or reason to swap out while on the ground.

First of all, switching armor shouldn't be as trivial as firing a weapon or sprinting some distance, so it should have a fairly high cost, perhaps 100% TU to remove and another 100% TU to equip, striking a balance between so quick it's unrealistic/too easy and so slow it's annoying/wasteful (the costs are of course adjustable, or even vary by armor type, though probably only in special cases).

For this I'm proposing the addition of "multi-turn actions." Based on this concept, the cost of removal/equipping can be split across more than one turn, thus you can start taking your armor off this turn with your remaining 43% TU, then next turn start with 57% less TU, deducted as the remainder of the previous turn's removal action. This would lessen the impact of the action on a single turn, and not require that you do absolutely nothing else for a given turn in order to complete the action (which could waste a lot of extra TU the turn before). Some special actions added later could also take advantage of the multi-turn system, like hacking an alien computer terminal, which could be set to take 200%, 300%, or whatever makes sense.

The biggest issue with swappable armor is unit representation. Right now armor changes a unit's color, which has worked fine since X-COM soldiers are traditionally the only units with non-racial armor, and a few color shades are enough to effectively convey the difference while still knowing who's in your squad. As alternate armors become more widespread, colors are no longer sufficient to show armors without making the map somewhat more difficult to decipher at a glance, not to mention we'll soon run out of colors. (Even without armor swapping this would become an issue eventually, because I'm not going to stick with the meager three armor types of the original, and many more types of enemies could have armor since there are going to be quite a few possible human factions out there.)

Here in the first two rows are the original unit glyphs, followed by a semi-hollowed test for an armored unit. The third is the less-than-satisfactory result of thinking that an "armored" unit should perhaps have "more" color than an unarmored one, so I thought of switching unarmored units to have a slightly faded outline, and the current full-color glyph represents an armored unit.
It may be difficult to tell whether some of these will work in the game, even more so because they're not colored here, but the glyphs are easy to swap, so we can look at some screenshots later. Should also look into other alternatives. Suggestions?

Another issue is inventory items. Remember (or maybe you didn't know) that armor also provides your non-racial inventory slots; e.g., humans have L/R hand slots, but the rest of their slots come from armor. Equipping new armor would mean you'd have to drop all your items (this could be done automatically for sanity's sake), then pick them all up again and put them in whatever slots your new armor provides. I don't think this is too much of an issue since someone loaded down like that is unlikely to swap armor, plus armor swapping is mostly for mod use, anyway--I envision a character starting with no armor and finding some only later.

This could lead to some interesting gameplay, especially since armor can now provide you with special abilities, so you could equip an exoskeleton that enables you to bash through walls, for example, or a medic suit that comes with a built-in medi-kit, or even armor that automatically heals the wearer. Hell, why not a battlesuit that allows you to chain fire rockets! Okay, getting a bit carried away there... lots of possibilities, anything you can do through the special ability system, really.

EDIT: Nearing the end of my to-do list for the armor-item conversion, and just dropped in some new unit glyphs to test them out in the sandbox (perhaps more appropriately called the grassbox in X@COM):
I like A, the relatively unobtrusive design submitted Shirson. I think I like it better than the more uniform triangle of B. C, the hollow/outline design shown earlier looks pretty cool, but isn't quite appropriate to represent armor. The angular triangles of D/E look too much like L's when diagonal, so they don't work well at all. F, one of the original ideas mentioned, just looks weird. For now I'm probably going to stick with A.

Just when I thought I'd jump into adding new content, more planning showed that a generic system to implement the chryssalid ability and a few others might as well be expanded into a powerful dynamic system.

Enter "special abilities."

The term is probably not as limited in scope as you might be thinking. Special abilities will enable objects to combine conditional triggers and effects to define unique behavior under the right circumstances, and will probably be applicable to races, entities, armor, items, and/or terrain. They'll make it possible for chryssalids to turn their victims into zombies, zombies to transform into chryssalids on death, silacoids to leaves trails of fire as they move, and many more effects that you didn't see in X-COM. They could enable:

• An alien that absorbs or eats vegetation or objects it passes over/nearby, possibly regenerating itself as a result
• An alien that emits smoke
• An acid beast that corrodes adjacent metallic objects
• Snakemen that lay eggs which can in turn spawn more snakemen (UFO TTS)
• Volatile ammunition for some strange alien device that has a small chance of exploding when loaded
• An alien man-eating plant that chomps on units that pass by it
• A plant that rapidly grows and spreads over time, perhaps with additional side-effects of its own
• etc. (<--very inclusive bullet point ;)

Of course some triggers and effects may not be compatible in all cases or with certain objects, but there will be a pretty wide variety of valid combinations, and new additions should be relatively easy once the system is in place (I'd be happy to add more in the future for modding purposes). All of the parameters will be defined in the text files.

Yesterday I started implementing the necessary data objects, and as a test merged unit death explosions into the system--so now the basic infrastructure is ready. I was considering merging grenade use and light emission (by units, items, and props), but they're already working nicely so I'll leave them alone for now, and maybe migrate those features later. Silacoid fire trails and chryssalid/zombie mechanics are next, and even the upcoming motion scanner, medi-kit, mind probe, and psi-amp functions will fit in nicely. For a single item with multiple manually-triggered abilities (as opposed to the passive kind), there will be a list to choose from when activating/using it (ex: psi-amp, which could then easily be later modified to support a broader spectrum of psionic abilities).

The way this will work:
Abilities specify an initial trigger, and all abilities with a given trigger are checked for whenever the trigger situation occurs. A sample list of possible triggers:

• "Use" an item
• Move
• Attack
• Hit by an attack
• Fall
• Death
• New turn

Abilities may qualify their triggers using one or more conditions, for example:

• Standing in or adjacent to burning/smoking terrain
• Standing next to a unit
• Holding a certain item
• Some stat has a relative value
• Random chance

Finally, once triggered there are a number of effects an ability could have, including:

• Explode
• Spawn an object (many variations)
• Assimilate a unit (switch faction--could be for psi-amp mind control)
• Panic unit (psi-amp effect)
• Mutate one unit into another
• Transmogrify an item

All of the above lists are just what I currently have enumerated in the code for eventual implementation. Many more will be added (ideas welcome).

As a part of the new system, objects will be able to list their traits (or properties, e.g., organic, sentient, metallic, etc.), where the list of possible traits also comes from an external script. So you could pretty easily add new traits and define abilities that may only (or cannot) affect objects which possess a given trait. I'm adding that feature now because it's better than hard-coding the restriction preventing chryssalids from zombifying tanks. Can't have tanks roaming around trying to bite your soldiers, now can we...

Here's a quick video of guided weapons in action:


I was going to add grenade priming today, but the X-COM system seems like it may be incompatible with X@COM. For a breakdown of the original timing system, see here.

I like the original system. Despite not being intuitive and obvious at first, it's fair and works pretty well. The problem is, it only really works when you have two sides (X-COM + aliens), no more (civilians are ignored for grenade timing purposes). But X@COM supports an unlimited number of factions (teams on a given level) so you can potentially have more groups than just X-COM and aliens.

Not sure what to do about this yet. Checking grenade timers only at the beginning of a new round is obviously unfair, and using the thrower's turn as a reference may not be flexible (or fair) enough in some cases. I'll have to think on it some more, but thought I'd throw it out there to see what others think.

Maybe a faction's grenades can only go off at the beginning or end of their own turn. Thus priming to 0 will explode as soon as you end your turn, 1 will go off just before your next turn, 2 = after your next turn, 3 = beginning of the turn after that. Seems confusing, though really you don't prime for much other than 0 or 1, maybe 2...

The main thing this leaves out is the ability to have a grenade go off between other factions' turns
but that doesn't seem possible to work out, or even necessary actually. And maybe I've come up with the answer myself while writing this post :)

Recently I took a break from coding the game mechanics to do some research and interface brainstorming. I didn't really want to do this quite yet, but am afraid I'll get caught in the middle of coding some big chunk of mechanics right when a big project comes along at work. I can safely stop random ASCII art endeavors at any point...

The current state of the in-game HUD area is a mishmash of debugging info, so images seen below are just mockups. I played around with some ASCII drawing software over the past few days, trying PabloDraw, JavE5, WEPaint, and ASCII-paint. But by far the award for best RL interface prototyper goes to ASCIIPaint, even though it's somewhat feature-incomplete and (!) runs in flash...

Note: Colors/font don't mean a whole lot here, since I'm not limited to ASCIIPaint's 16 colors and will be using a custom font.

This first attempt was just trying to fit in everything I wanted in the HUD. Aside from everything you see in the original game, there are plenty of extras: "Intel" describes whatever is under your cursor, "Threats" gives a more detailed list of enemies in view, and "Reports" is a quick list of the most recent tactical events.

The reports should be concise yet easy to understand--they're basically symbolic SVO sentences. Here's the meaning of the lines in the mockup (top is most recent):
Sectoid #4 dies
J.Kyzrati shoots Sectoid #4 with laser rifle (burst shot)
J.Kyzrati throws alien grenade
J.Kyzrati primes alien grenade
Muton #2 falls
J.Brenner dies
Muton #2 shoots J.Brenner with plasma rifle (snap shot)
J.Kyzrati no longer under alien mind control
J.Kyzrati under alien mind control
J.Kyzrati panics
...

Obviously this HUD appears to the right of the map.








The initial attempt was definitely too cluttered...

Got rid of any unnecessary identifiers--it doesn't take long to figure out what everything does, and once you do button/control identifiers are wasted.

Using buttons instead of words in most places, saves space.

Most importantly, adding more information about the handheld items enables direct item-action selection without any intermediate window.




















Rank might be better shown as a symbol (also clears up another line).

Soldier-related buttons probably look better if they don't take up quite so much space, as do the level view control buttons.
























Still a long way to go with this (and it will be nice to see it with better colors), but it's getting closer to something I can implement for a test version at least.