X@COM

"Unfortunately AI will be nonexistent, so you'll have to settle for blowing up terrain and static units." --Me, Yesterday

I lied.

I figure the ARRP release will be a lot more interesting if your enemies move and shoot at you, so today I went ahead and threw in a simple AI, as well as faction-limited perspective (cannot see non-visible enemies taking their turns, etc.).

Prepare to be blown away, unless you think your squad can fight off waves of aliens teleporting into the area. Of course, you can always steal their more advanced weapons and blow *them* away...

(I haven't made the scenario yet, but hopefully I can find enough time to finish everything by release day. Too bad this is going to be an unusually busy week...)

You read the title...

You've played X-COM before...

You know exactly what I'm talking about...

Let's flex our new-found throwing muscles and put the hurt on an unsuspecting alien emerging from his craft...


(Not a great video, but maybe throwing the electro-flare and smoke grenade helps make up for it? :)

So as you can see, proximity grenades work, as do many other kinds of grenade explosions. Any item with an attached "throwing explosion" also has a "grenade use" setting. Besides the standard/expected PRIME and PROXIMITY settings, I added support for these:

• IMPACT: Explodes immediately on impact if thrown (instead of waiting until the end of the turn like a normal grenade primed to 0).
• VOLATILE: Like IMPACT, but will also explode if it falls and hits the ground.
• REMOTE: Thrown/dropped and set off remotely/manually with a detonator. This is not yet fully supported, since there is no way to create detonators, but it seems like a frequently requested option in X-COM remakes, so it could eventually be added (not going to bother in the short-term, though).

None of these were in the original X-COM, but they could later be used to create interesting items.

In other news, I've decided to join this year's ARRP with X@COM! Everybody's doing it :) Seriously, if I wait until I'm far enough along to make the game semi-playable and good enough to get through my perfectionism filter, it could be many months away, and this being a project with a fairly clearly defined initial goal, it's not like I've got a ton of secrets to hide when it comes to gameplay. The unique components are a ways down the road, anyway.

I may as well let people try the game out early, so I'll be releasing occasional tech demos beginning September 18th, 2011. Tech demo releases probably won't be all that frequent (compared to playable releases, which will be updated quite often when they start coming), but I may as well throw something out there just to be a part of ARRP.

So what can you expect? It'll no doubt come with a big fat disclaimer, but hey, it's a sandbox tech demo, after all. Content-wise, you'll basically be getting the latest version I'm using to debug/code the game, so it'll include all the features you've read about in posts and seen in the videos. Unfortunately AI will be nonexistent, so you'll have to settle for blowing up terrain and static units. Anyone interested could, however, play with the data files (text) and create/modify just about any object... I'm still undecided on whether to leave debug output/interface features in the demo.

As usual, opinions are welcome!

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

Quick addition: light-emitting items. It was only a few lines of code, since light sources were already attachable to any other object--it was just a matter of detecting and updating light-equipped items. Below is an unexciting shot of an electro-flare (seen top-center, on the ground, as a squad moves in on the area).

The last set of YouTube videos were pretty fuzzy, small, and unimpressive-looking, so I've made a new one that includes most of the same material, but in a larger format and zoomed. Check out the smoke-filled incendiary extravaganza below (you can use HD/fullscreen):

There's no sound yet, so I added some music instead. Not all that X-COMish, but it's the first thing I thought of. The game itself won't really feature much in the way of music--ambient sound/music at the most (like the original)--there'll be an emphasis on sound effects (with lots of interface sfx).

By popular request, here's a screenshot showing damage distribution from a large rocket, as impeded by brick walls:
(Okay, it was just Creepy who mentioned it, but seeing as how few people know about X@COM, he does make up a good percentage of the readership :)

I've also added a page containing the full changelog, which will be updated with every new version (whether internal or released). See the link at the top of the blog.

Probably going to work on parabolic trajectories next, to enable throwing and the potential for weapons like mortars (obviously not something to be included in the initial core game, but they could appear in a later mod).

Ready to roast some aliens? The newest additions are all about various ways to turn up the heat.

First, explosions of any kind can now be attached to props and entities, so UFO power sources, cyberdiscs and more can now explode. How to do a suicide run on a UFO:


Taking out a cyberdisc (2x2 units aren't yet implemented, but it blows up just the same):


Incendiary weapons now create fire which ignites terrain and entities. Here's a rocket launcher firing incendiary rockets, after which you can see the fire spread a little (it would spread much more in a wheat field). Burned terrain will produce varying amounts of smoke/dust based on its composition (also occurs when destroyed or when props fall from heights and smash into the ground).


Although not as effective as incendiary ammo for the job, HE weapons may of course cause some small fires, too:


Fire is naturally useful as a makeshift light source:


Smoke grenades make a much denser, longer-lasting patch of smoke (throwing not yet implemented--this is shot from a weapon):


Smoke affects FOV (kinda the point):


And for the grand finale, lets burn that house to the ground, just because we can (and then blow it up afterwards, because that's fun, too :)


On a side note, even though the videos were already cropped down to nothing, YouTube still  felt compelled to compress them to nothing. Maybe next time I'll just record the entire window in HD instead. (I wish I could use screenshots instead, but the latest updates are best shown in videos...)

So here are the latest major additions:

• Exploding Props & Entities
• Effects of incendiary weapons/explosions
• Fire burning/propagation and light emission
• Entities catch fire and burn
• Smoke results from fire and some weapon effects
• Smoke affects FOV and stuns units
• Materials can release varying degrees of smoke/dust when burned or destroyed

Current state of the near-term TODO list:

• Light-emitting items
• Variable animation speed
• Throwing
• Sound effects
• 2x2 units
• Reaction fire

Talk about an unexpected diversion!

With explosion damage calculations out of the way, next up was figuring out how to best animate them. One moment I'm scratching out some possibilities, then I jot down an innocuous little note along the lines of "need a particle system?" and ended up resting on the idea.

Next time back at my desk I'm writing a fully-featured particle engine, and the next and the next...

Never written one of these things before so it was a somewhat slow start, but once the pieces started coming together it became obvious this was the way to go. Particle engines are awesome!

I've opted for the heavily parameterized single-class model. Overall it's a pretty versatile system:

• Particles make use of a wide range of dynamic variables:
• Age can be a constant, random, or dependent on distance from a point
• Speed can be static, constant, random, or follow a linear or sine function
• ASCII characters, if used, can be static, based on direction, or sourced from an animated list or a random set
  
• Color blending options (foreground/background) are more or less the same list available in libtcod: 
• Add
• Subtract
• Multiply
• Scale
• Linear Interpolation
• Add Alpha
• Screen
• Color Dodge
• Color Burn
• Overlay
• Any color can be dynamic, since particles are able to mix multiple colors based on their current age or speed using 10 or so kinds of linear/sine functions
• Particles can also be emitters themselves, spawning other particles based on various triggers, rates, randomness, direction information, etc, so it's pretty easy to chain together complex effects
• All these parameters are loaded from a text file, and attaching a particle effect to a weapon/item is as easy as writing its name in the item text file.

Internally, projectiles and explosion results are now a kind of particle, since integrating them into the system seems like an obvious choice.

Particle engines are pretty powerful, and I still don't know all the tricks to using this one, but in the coding process I designed several test effects and made a video where you can see them in action. Everything's kinda small at first, but it'll zoom in; and going fullscreen will help a lot since I recorded it in large format. (Note: This was my first-ever attempt at recording a video. Next time I'll try to keep the mic out of my mouth, promise!)

Okay, so I haven't added the sound system yet, but I can just hear it already as I test the explosion code. Everything seems to be working nicely--explosions are propagating damage as expected, terrain is blocking the force of explosions based on its stats...

No animation yet (that's coming up), but below is a shot of the results when a small rocket is fired into a hillside. The rocket hit the second level from the ground, and you can see how the grass is blown away and the dirt caves in.

On the right is some debugging info, showing the relative damage on each level (0, 1, 2). Unlike X-COM, explosions are in 3D, though I've made them a fair bit weaker in the third dimension, so they would technically be more of an elliptical shape if viewed from the side. Vertical explosion effects are completely optional, and can be deactivated to preserve the original X-COM explosion effects (same level only).


You may notice another difference from X-COM: blast patterns. X@COM uses a more rounded pattern, rather than the squarish patterns of X-COM, so your explosions will include a few extra squares. This difference is most noticeable for smaller blasts.

And now on to what I've been waiting for... Time to unleash some serious firepower on that house. Here it is, awaiting destruction, with roof view on (remember, it's two stories):


First we'll pull out our rocket launcher and smack the front door with a small rocket.

But that's not enough! Who has time to fire a few small rockets just to bring down a house? You desire a more effective way to level that thing... How about a large rocket fired through an open door (explosion in middle of first floor):

Still, they have a FENCE left! And someone even managed to survive! Okay, okay--here it comes... the Blaster Launcher!
Soldier-boy there singed his eyebrows with that one!

Let's check out the damage distribution (floor 0, 1, 2):



As you can see, hanging around anywhere outside a window, even in the air far away from ground zero, would be a bad idea when that bomb goes off.

It's been a little while since the last update as I wasted (spent?) a couple days fretting over how to code the interface windows. Eventually decided to put that off and continue with the mechanics--next on the list was gravity.

Gravity is optional for terrain, but obviously adds some fun tactical considerations.

Damage inflicted by/to falling objects is calculated based on mass, or relative mass in the case of multiple objects (obviously there are armor and other modifiers). Objects can displace each other as they fall, and most objects leave rubble if not completely destroyed--a battlefield littered with rubble is a little harder to traverse (higher TU cost). Terrain now also has a stability property which determines how likely it'll fall apart as it loses support from other connected terrain/objects (i.e., the more holes you shoot in a large section of wall/roof/floor, the more likely it is to come crashing down).

Here are the results of one test on a house (an exact replica of an actual X-COM house, btw),
where I opened up on it with my heavy plasma using unlimited TU and ammo :) At present, rubble is represented by semi-colons.



Apparently there were entities in that house after all! I only fired at the first floor walls, and you can see that half of the second floor collapsed, which brought down areas of the roof as well.

Next up: Explosions! Probably won't be so much rubble left after this next update...

Progress Report (copy of public changelog):

• Units spurt blood when taking critical wounds, and may trail some blood while moving (color of blood, if any, set by race)
• Added Material class to describe properties common among certain groups of terrain objects
• Added system of terrain degredation to be followed when terrain objects are destroyed
• Added terrain/object destruction handling
• Added [optional] effects of gravity on terrain/objects which have insufficient support from connected terrain
• Added mass property to units/terrain and relative damage calculations for impacts
• Added projectile collision handling for all object types
• Added dynamic updating for light/FOV maps due to terrain/obstruction changes

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.

Today was all about dishing out the pain! Projectiles now deal their respective damage, cause critical wounds, etc...

After that, went ahead and implemented gravity for entities so that shooting the flying ones out of the air has its proper effect. Killing/stunning a flying unit sends him crashing into the ground (or whatever happens to be below him, hopefully his friends).

Certain objects on the ground may cushion your fall, so you can intentionally jump off a roof into some bushes and hopefully not break anything (probably still a bad idea from the third floor). Or if you're breaching a house from the roof SWAT style, choosing a spot over a bed might be a good idea :)

Here's a screen of testing where units were jumping off the house like so many lemmings... splat!
Such a fall usually wouldn't kill outright, but for testing I had everyone's health dropped to 1, which also made stun tests significantly less of a hassle.

And by extension you get the offensive leap, AKA death from above. You can theoretically jump off a building and drop down on an alien's head--hopefully he'll take more damage than you (wear powered armor for the best effect!).

That gives me an idea for later: What about a quick dog-like alien ally that hangs around on roofs and does exactly that to your soldiers... Now that sounds like a scary terror unit.

Primary recent changes:

• Added damage effects of non-AOE projectile-entity impacts, taking into account armor, modifiers, etc.
• Added critical wound system
• Added body items for unconscious/dead entities
• Added handling for unit death/unconsciousness/revival
• Added faction FOV update on member status changes
• Added falling damage and handling for special cases while falling
• Added items to map display

This being a 3D world, a direct overhead map is often just not sufficient to show whether your barrage of plasma is going to take off that alien's head, or just burn a hole in some tree.

Enter the side view.

It's not much to look at, but it serves its purpose as a functional firing aid to show the elevation of your LOF. The side view appears automatically above the top of the map whenever your LOF is displayed on the map, and shows the LOF elevation in every vertical column of cells it passes through. The higher the elevation, the brighter the line (though cell traversal distance still impacts the line's shading).

In the test map below, our soldier fresh off the Avenger already has an enemy in his sights. As shown in the side view (the shooter always appears in the bottom left), his bullet will pass over the fence and through the second story window to smack that alien. Assuming he hits, that is... [Some objects are depicted slightly differently in the side view--you can see the fence is now a '#'; bonus: entities can finally be represented by their proper '@'!]

However, his buddy here has spotted another enemy on the roof, but his line of fire is blocked by a tree... oops. Time for plan B! (I suppose that'll have to wait for when I can add explosives enough to just bring the entire house down :)

Finally fired the first rifle shot today! Not at anything in particular, and not that it matters much since projectiles simply die after impact rather than having any kind of effect...

Been working mostly on the internal firing mechanics lately, thus despite a fair amount of progress there still isn't a whole lot to see. Copy of the latest changelog:

• Fixed misdirection in flying movement handling around obstacles
• Fixed FOV to improve accuracy of obstruction by prop objects
• Added Faction LOS check between their members and those of other factions, to record visible entities
• Added kneeling/standing
• Changed unit icon size; now larger while standing and smaller while kneeling to reflect smaller profile
• Added Race data class, which holds data common to all Entities of a given race
• Added prop height value, determines how they block FOV of entities of various heights (e.g., when kneeling) and LOF
• Added targeting/firing mode to battlescape interface
• Added accuracy calculations
• Added volume parameters to props and entities to define their profile for projectile collision detection
• Added ray shooting class for calculating projectile trajectories (subdivides map cells to properly detect collisions by object volume)
• Added LOF calculations in two varieties (option to switch between them): STRICT traces a direct line to the target and considers anything it passes through to be an obstruction; LENIENT will trace multiple lines to target corners/extremeties and try to hit any part it can when the primary LOF is blocked (enables you to hit the sides of large targets that are hiding around corners). So each map cell actually represents a cube of space, and LOF travels through different parts and segments of different cells as in a normal 3D map; visually, LOF is shaded based on its length through a given cell.
• Fixed visual oddities on side view display when based on high-angle LOS
• Added Projectile class with collision calculations and simple bullet animation

The shot below shows a Line of Fire. LOF is shaded depending on exactly how much of a cell it traverses. Each cell on the map represents a 3D cube of space, and some objects may not entirely fill their space, e.g., props and entities. Thus in some cases even when your LOF passes through a cell, it may not hit objects within that cell (unless of course you're aiming at the object). As in X-COM, LOF is more restrictive than FOV, meaning you can sometimes see targets you may not be able to shoot at.
If something is blocking your LOF, the obstruction(s) will be highlighted in red and the LOF will also be shaded red.


Here is a soldier standing behind a short fence aiming at a target (currently lower case letters and single walls are used to depict shorter objects, while upper case letters and double walls are used for fully-obstructing objects).
But when that same soldier kneels down (currently represented with a smaller triangle), he can no longer hit the target because he's hiding behind the short fence.

Not enough time tonight to post how the side view works while aiming at targets. I'll put that up this weekend.

Here are some screenshots , as promised. Not much in the way of a complete map, but putting just this together was already slow going without an editor (I'll make one eventually, so long as this game starts to look promising).

There's an Avenger dropship in the SE corner, some streetlights along a road, a two-story house, and beyond that a raised grassy area topped with trees. A small UFO lies in the NW corner. These shots show the map entirely revealed.

This is the bottom level:

Here is the map viewed from the second level. Areas below the current view height have a very slight blue tint to them, and appear a little darker. (This will be adjusted later as necessary.) You can now see the Avenger's hull, the house's second floor, the raised area in the NE corner, the UFO roof, and tree branches for the bottom level trees:

This is the third level, which only has the tops of the streetlights (from where their light is emitted), Avenger and house roofs, and NE trees branches:

No reason to show the empty fourth level, instead here's the same map at midnight (bottom level):
These brave (stupid?) soldiers have now split up--one's searching the house while the other heads for the UFO alone...

...Hopefully not to be followed by baby steps.

I'm starting development with the battlescape, primarily because its design is potentially problematic so it's the best place to start in order to determine the feasibility of this project. (By comparison, the geoscape should be relatively easy to represent in ASCII.)

Progress during the first week of development:

• Expanded personal game library (which has only been used for basic 2D applications in the past) to include 3D LOS/FOV functions, a 3D pathfinding class, more 3D matrix methods, a handle manager template, and a generic logging system.
• Defined all major game flow handling classes/modules
• Defined all major data classes (Cell/Prop/Entity/Item)
• All data objects loaded from files
• Can load a rudimentary static battlescape map, with objects, from a text file
• Map props can be static light sources; entities/items can be dynamic light sources
• Visibility, and map shading, dependent on time of day setting
• Can control members of a test faction, walking or flying around the map, which is revealed as per FOV rules
• Can activate side-view map to see a vertical cross section of a unit's LOS
• Implemented randomized unit stats, and TU costs of moving/changing facing 
• Moving units will correctly climb/descend sloped terrain/stairs (fortunately they no longer leap off buildings unless capable of flying) and open doors
• The entire game state can be saved/loaded at any time

Next up: Firing your gun at stuff. This could take a while longer, because I'll be trying out some new methods I haven't used before...

Screenshots will come soon, after I make the tiny test level a bit prettier--right now it's pretty random...

I just recently began work on a new project, an X-COM-based Roguelike, and decided to create a blog to post updates and seek comments/advice.

Check the FAQ for general information.