What goes up must come down... and preferably explode
by Kyzrati on 20110906 , under Progress, Screenshots
You can now toss things around. The throwing model pretty closely follows the X-COM strength/weight-based range system, with one major (and no doubt highly-anticipated) exception: you won't encounter problems caused by limited arcs.
The game will first try the "ideal" peak for your throw (according to distance) and plot a parabola through that. If the path is blocked, it will successively attempt worse and worse peaks until it finds an unobstructed one (if any). This flexibility isn't free, of course! The further away you are from the ideal peak, the lower your accuracy. So while you can theoretically try to throw your grenade like a fastball straight across the entire map, you're probably going to miss. And missing can be a big deal with a primed grenade, since the miss trajectory could send it bouncing off a nearby wall or ceiling to land not far away...
Here are some normal throws (the side view of course comes in very handy for checking your throwing trajectory):
A throw onto a roof:
A throw from a roof:
One exception to the friendly arcing system is the map ceiling, which unfortunately does limit your throws--fortunately throws from high positions to other high positions (which are the only ones really affected) aren't very frequent. You can still try your throw from building-top to building-top, but thrown objects cannot leave the map so you'll have to risk a pretty straight trajectory (the drawback is negligible if it's close, so don't worry about that). Throwing from a high position (even at the top of the map) to a lower one usually won't be affected much by the ceiling, since the peak will be quite low, generally even level with you.
(On a technical note, throwing makes no attempt to use actual physics or gravity modeling; it actually just picks a peak and two midpoints and draws up to four lines between them.)
Oh yeah, and thrown objects can crash through windows:
Thrown items are integrated with the particle engine (they're actually particles themselves), so they can have special effects associated with them as well (smoke grenades trail smoke while flying through the air, electro-flares pulsate on their way to a target). I designed a few placeholder particle effects for throwing, but I'll wait 'til next time to put up a video together with a few of the other new additions.
The game is not, however, quite to the point where you can play hot potato with primed grenades--grenade priming is coming next, though currently any grenades that require no priming (i.e., smoke) will go off instantly.
Any item can now be attached to both/either/none of a "firing" explosion (usually for explosive ammo) and "throwing" explosion (usually for grenades), so it would be pretty easy to make interesting objects like alien bodies that explode when you throw them, or a kind of explosive ammo that can also be thrown to make it detonate... Imagine some super buff soldier grabbing a rocket and literally tossing it at a group of aliens :)
The game is not, however, quite to the point where you can play hot potato with primed grenades--grenade priming is coming next, though currently any grenades that require no priming (i.e., smoke) will go off instantly.
Any item can now be attached to both/either/none of a "firing" explosion (usually for explosive ammo) and "throwing" explosion (usually for grenades), so it would be pretty easy to make interesting objects like alien bodies that explode when you throw them, or a kind of explosive ammo that can also be thrown to make it detonate... Imagine some super buff soldier grabbing a rocket and literally tossing it at a group of aliens :)
See the Light
by Kyzrati on 20110831 , under Screenshots, Video
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).
4
comments
more...
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:
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).
Conflagration Propagation
by Kyzrati on 20110828 , under Progress, Video
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:
Current state of the near-term TODO list:
4
comments
more...
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
Console-Sized Quantum Mechanics
by Kyzrati on 20110821 , under Video
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:
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!)
9
comments
more...
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!)
Ka-boom!
by Kyzrati on 20110811 , under Screenshots
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!
Let's check out the damage distribution (floor 0, 1, 2):
The Sky is Falling
by Kyzrati on 20110808 , under Progress, Screenshots
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):
8
comments
more...
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
Heads Up
by Kyzrati on 20110729 , under Brainstorm
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):
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.
3
comments
more...
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.
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 grenadeJ.Kyzrati primes alien grenadeMuton #2 fallsJ.Brenner diesMuton #2 shoots J.Brenner with plasma rifle (snap shot)J.Kyzrati no longer under alien mind controlJ.Kyzrati under alien mind controlJ.Kyzrati panics...Obviously this HUD appears to the right of the map.
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.
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.