XCOMRL

You Need a Break

by Kyzrati on 20111221 , under

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:

[tech demo]
0.00+ CORE MECHANICS
[alpha]
0.10 Inventory
[^CURRENT STATE^]
0.11 Sound: UI
0.11 Mechanic: Morale
0.11 Mechanic: Variable Anatomy
0.11 Item: Medkit (+UI)
0.11 Item: Mind Probe (+UI)
0.11 Item: Motion Detector (+UI)
0.11 Messages: Info
0.12 Messages: Combat/Logging
0.15 Sound: Weapons
0.15 Sound: Destruction
0.15 Sound: Entities
0.16 Unit: Chryssalids
0.16 Unit: Silacoids
0.17 Item: Psi Amp (+UI)
0.17 Mechanic: Psi Powers
0.18 Battle Recorder
0.18 Mechanic: Experience
0.18 Mechanic: Scoring
0.20 UI: Intro
0.20 UI: Main Menu
0.20 UI: Mission Intro
0.20 UI: Mission Results
0.20 UI: HUD
0.20 UI: Map Dynamics
0.21 UI: Options
0.21 Mechanic: Difficulty Levels
0.25+ DATA
0.30+ MAP GENERATION
0.35+ VISUAL/SOUND EFFECTS
0.40+ AI
0.50+ GEOSCAPE
[beta]
0.90+ Testing/Adjustments
1.00 Complete X-COM Remake
1.01+ MORE FUN STUFF

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.)
11 comments more...

R5: "Alpha Genesis"

by Kyzrati on 20111219 , under ,

Well, X@COM still isn't where I wanted it to be for the year-end alpha release, but my hand was forced since the R4 demo will expire soon. (Every demo release is actually hard-coded to expire after a certain period--it keeps me releasing new versions [mostly] on schedule!)

So I bring you 0.10. The changelog isn't all that impressive, but this is actually the biggest release yet in terms of modifications, most of them internal as the game is now powered by a brand new engine. Let alpha development commence!

At least now you can try out the new inventory system. With full inventory access you'll also be able to keep those grenades out of your off-hand for better accuracy with two-handed weapons, and carry spare ammo for heavy weapons to make them a lot more useful.

Remote detonation of explosives is now supported. This marks the debut of the 'u'se command, which will be for all sorts of special functionality in the future. Priming your remote charges will create a detonator, which can then be activated at any time by using it. The original X-COM didn't have remote charges, but it's a commonly requested feature, so I've added them since it was easy and the vanilla mode can simply leave them out. Later on when aliens can pick up weapons, it would be amusing if/when the dumber ones happen along and pick up your primed remote charge...

To make downloading the release a little more worthwhile, I added a new scenario: Exodus. You get to assist the National Guard during the evacuation of a city overrun by aliens. This mission shouldn't be too difficult to "successfully" complete, although there's potential for a much higher score if played well. Replayability is high as the city layout and opposition forces are randomly generated. You have a smaller squad this time around, but they're better armed (and armored). You'll also face a new alien species, a weaker precursor to the upcoming Chrysalid (minus the zombies).

Here's a shot of a generated city (revealed):


"Looks quiet. Also looks like we've arrived a bit late..."

During one of my test runs, a huge group of civilians came swarming my way, and right before they reached safety, a blaster bomb came out of nowhere and toasted them all... poor civvies.

Oh, and being a city, I upped the map height to 6, so you can have some pretty tall buildings out there.


The older scenarios have also been modified/updated, mostly to give you a little more firepower and flexibility since now you have inventory access. Area 51 might be slightly easier since there's enough explosives stocked about to level the entire base. Just try not to be in it when that happens.

Your rookies should be ever so slightly more effective now, since while overhauling the armor data format I discovered that the armor value application (a temporary hack for the demo) was overriding all rookie armor with zeroes... So at least now they have that minute amount of armor (which we all know they so desperately need).

I noticed the annual Roguelike of the Year competition is being held right now. There have already been a fair number of votes cast for X@COM (I was pleasantly surprised when I first opened the page and saw several dozen votes), but let's try to get that number higher! Obviously X@COM won't (and shouldn't) win, but the extra awareness would be good, so go put in your vote! (Of course, that assumes you're reading this because you like what I'm doing here.) Don't forget to check out the other entries, too; I voted for DCSS, DF, Infra Arcana and MageGuild. Oh yeah, and myself :)

The next release will come some time next month and should include at the very least medkits (stop bleeding already!), UI sounds (ooooh), and a main menu (not really all that essential yet, but I might as well..). Other things high on the alpha list that will be appearing in the next few releases:
  • sounds
  • proper message system
  • special units (Chryssalids, Silacoids)
  • special items (motion detector, mind probe, psi amp)
  • morale
  • psionics 
  • battle recording?

I should also spend some more time on HUD design/planning, and there will probably be another post dedicated to it that provides some HUD content proposals which can hopefully attract input.
5 comments more...

Interfacelift

by Kyzrati on 20111213 , under ,


It's been a surprisingly long time since the last post. Sorry about that. Not that nothing's been happening over here, but I prefer having something concrete to show with every post. I'm still chipping away at the todo list, but the current stage of development involves spreading out into quite a few new areas of the game code, certainly much more time-consuming than banging out simple and well-documented game mechanics!

Plus, I don't want to screw something up now in the core program that'll become a source of endless headaches later.

Recent developments have been all about paving the way for a new interface. The HUD is still waiting on the sidelines, mostly because I have yet to decide what exactly it should contain and how to organize it all. Instead I'm testing the system by implementing a simple inventory window. I know your soldiers are getting antsy about the fact that they just *know* they have more ammo in their backpack, but, um... forgot how to get it :)

Well, now they'll finally be able to stock a few extra grenades and missiles, and do it in style!



Okay, so it doesn't look like much yet, but look again... it's alive!



The system is capable of far more than you see here. This sample is powered by a simple, generic window-drawing script; the interface animations are completely exposed in text files, similar to the weapon particle effects. So, just as you see weapons producing a range of snazzy effects, windows can do all that and more, and can be tweaked, or even rewritten, from the text files. (For those interested in the dev aspect, the system is very basic but powerful nonetheless: every visual component of the engine (window/control/button/etc) inherits from the same console base class, and every single one comes with its own lightweight particle engine--I LOVE PARTICLES! Besides making it not too difficult to implement good-looking effects, giving every object its own particle engine also makes control/manipulation fairly easy: even windows containing complex interconnected animations can be manipulated piecemeal and the flow seems to work almost automagically!)

In the game you won't have to watch entire windows be redrawn every time they're accessed--the way I have it now only the content portion will be redrawn after seeing the complete animation once (per run).

In its current state, the inventory screen should already be pretty informative and usable, showing TU costs, weight/encumbrance changes, highlighting valid/invalid targets for moving items or reloading, and telling you exactly why you can't do something, etc. It'll be expanded later on with additional functionality like the ability to define and apply set loadouts/equipment kits, and direct manipulation of other units' inventories (tanks that hold things, or those with modular weapons that could be swapped out by an engineer?).

In terms of control, the inventory is 100% controllable by obvious and intuitive keyboard commands. I used the mouse in the video so you could better understand what the heck was going on...

I originally thought the inventory interface would be a bit more graphical, but that wouldn't be as compatible with the new arbitrary inventory slot system. Armor and inventory slots have now been completely exposed in the text files, enabling simple creation of different kinds of armor which provide unique amounts of storage space and locations. Races are also connected to the slot system (also through the text files), so different races can specify different natural slots (which combine with armor slots to give a unit's total inventory layout). As each unit keeps track of its own available inventory slots, eventually adding the possibility of losing a limb won't be too much trouble (it'll still require a more specific body part list, though, which would also be compared against armor to make sure a given armor is usable by a certain unit at all).

Soon/next I want to finally integrate some sound effects into the particle engines to see how that should work with the animations. Hopefully those windows will be bleeping, blooping, whishing, and whooshing in no time. The audio engine is already in place, I just have yet to put together the resources and add ways for particles to trigger sounds.



8 comments more...

Back from Hell

by Kyzrati on 20111113 , under

DLL Hell, that is.

Spent some time wading through boring non-X@COM-related code, working out various annoying library dependencies. Finally got all the correct compatible versions playing nice with each other, then tested the new engine--seems to work fine. Then ported the game code over to the new engine, and X@COM looks... suspiciously unchanged:


That's because it's still using the same old DejaVu font (little coincidental pun there). The point is what it's now got under the hood: The foundation is in place for much more interesting design possibilities now that it's a completely different engine ready with sound support, archived resource access, parent-child console interaction, command processing (as opposed to kb/mouse processing) and more.

Now back to work on the game proper. The latest addition is a second particle engine, this one 2D, for animated interface effects. We'll see in the next post how it manages to draw windows!

I've also been playing with new fonts. Eventually there will be multiple fonts to choose from while playing, but I'll need to decide on an official default appearance. The problem is that square monospace fonts aren't all that easy to read, and the ones that are don't look all that great. On the other hand, square cells are somewhat essential for tactical strategy to avoid distortion of space.

Another issue is the font's readability in words vs. single characters. With more stylish fonts, identifying a character/letter by itself (i.e., on the map) may be more difficult when it doesn't appear in a word. Perhaps this could be solved by using a separate font for the each the map and interface text, but then that's not very console-like.

Anyway, here's the alternate test font I made recently:

Doesn't look all that great yet, but it's passable.



5 comments more...

Hello World

by Kyzrati on 20111031 , under

Proper X@COM development has been put on hold while I get busy reinventing the wheel.

After weeks of debating the issue with myself, I've decided to write a complete game engine from scratch rather than continue with libtcod. I originally intended to write a new libtcod framework that would replace Umbra and make coding X@COM a lot easier, but finally convinced myself that with just a little extra work I could write my own engine right on top of SDL, one that would be both simpler and much easier to modify to fit my own needs. Libtcod is a really cool library, but since I already have my own rather large collection of game classes (on which X@COM is based), I was only using a tiny fraction of libtcod's features in the first place (namely the console display).

After a little bit of planning (probably too little), Rogue Engine X was born this weekend. Here's a shot of "REX" in action--very impressive stuff, really...

Okay, maybe not so impressive. Right now it can't do much of anything except load a bitmapped font and draw one full-color console window. The color support is essentially the same as libtcod, although with a slightly different HSV pattern for the default colors.

REX features (eventually):
  • Based on SDL
  • Fully object-oriented (C++)
  • 32-bit color console
  • Command-driven input processing
  • Sound/music support
  • Access to archived resources through PhysFS

I already warned that X@COM's alpha debut is quite a ways off (two months, maybe?), so taking a detour to crank this out doesn't really change that. Consider this taking several steps backward in order to make huge leaps forward!
8 comments more...

R4: "Area 51"

by Kyzrati on 20111021 , under

After much hardware-induced delay, a new release is ready for the ASCII-loving, alien-hating commanders out there to test their skill (and/or luck) on.

In addition to the many new features mentioned in the previous post, R4 adds a new scenario and scoring system to tide you over until the first alpha release, which probably won't be available until the end of the year! Most of the core mechanics are complete (the rest will come in alpha), and huge changes will be taking place over the next couple months as I build a libTCOD framework from scratch to handle the kinds of things I want X@COM to be able to do. I'll occasionally post progress updates when there's something to show.

As for the new scenario: Fight alongside soldiers defending an Area 51 base against an alien assault, and be prepared for some surprises. To play, run Area51.bat. The environment is non-random, but enemies are mostly randomized. Once the remake is complete, later versions could optionally include similar handcrafted scenarios, though of much better quality and properly balanced.

There are a lot of enemies, so definitely try out this new feature: You can now press/hold the 'e' key to highlight known threats. So at the beginning of a turn when you've suddenly been engulfed in total chaos (very likely to happen in Area 51, believe me), highlight the threats to quickly get an idea of what you're up against. (Threats are highlighted no matter what level they're on.) The visual effect is currently handled with the projectile particle engine, so flashing indicators may not appear in their entirety for units at the edge of your FOV (or at all for known units outside FOV); there will eventually be a separate 2D particle engine for map/interface effects that can properly handle highlighting and all kinds of other nifty indicators.

As usual, see the changelog for a comprehensive list of what you get with R4.

You can still play the original completely randomized ARRP demo; in fact, it's still the default. Remember that the original scenario will be a fairly different experience now that reaction fire is implemented.

As requested, there is now a scoring system (applies to all modes). The game will eventually replace this temporary implementation with a detailed and extensive scoring/records system, as well as medals for soldiers and achievements you can earn as commander. Here's the result of my test run on Area 51:
There are more unlisted ways to score points, but I didn't earn those. If you have a particularly good run (or even win!), when you see the mission end screen press your PrtScn button and a screenshot will be saved in your game directory. Maybe you could show it off in the X@COM Bay 12 thread (link on right).

That's it. No more media for you. Not doing any in-game screenshots or video for this release, at least not just yet, since I don't want to spoil the fun.

Now go! Defend Area 51!
6 comments more...

Quickdraw

by Kyzrati on 20111015 , under ,

Be prepared for a totally different experience when you play the next release: True X-COM mechanics are finally here.

Actions now trigger reaction fire (opportunity fire) from enemies that have spare TU. The system is almost identical to the original, though a few of the small quirks were removed to keep it as straightforward as possible--there aren't any strange exceptions to the way it works.

Melee reactions/counterstrikes are also possible. Out of ammo when that sectoid rounds the corner and starts firing at you point blank? As long as you've got the time left you'll just whack him with your rifle, or whatever you happen to be holding. Heck, find a sword and intentionally have your ninja-reflex soldier wait around corners for unsuspecting aliens--the heads will roll!

About the mechanics: I can't recall whether X-COM units actually turns around as part of reaction fire to shoot aliens after being hit in the back (probably because you rarely survive hits from behind by alien weaponry, anyway...). Either way, that behavior is a per-unit setting in the data files, so it's easily changed. For now I have X-COM *not* turning around.

You can reserve TU for any major action (snap / burst / aimed / melee / throw), and also intentionally deplete a unit's TU with a single command so you don't have to worry about those freaking reactive snap shots with a rocket launcher (unless you want them, of course).

Check out the video below for the ultimate showdown between X-COM and aliens. This battle is 100% based on opportunity fire! Reaction fire on this scope wouldn't normally happen in the game, but I added a third "overwatch" faction which triggers the exchange and tweaked their TU so they won't interrupt the battle; meanwhile, all the other units have full TU and are just staring at each other until someone moves... (HD + fullscreen strongly recommended, otherwise it can be hard to see what's going on)





Explosions are now simultaneously animated from the side, as seen here:



Parabolic projectile trajectories are also possible now. This feature was implemented primarily for the celatid spit, which is apparently the only projectile in the game which does that, but now any projectile can be designed to follow a parabolic trajectory, so you can add mortars etc. Be sure to kill celatids from a distance--or be killed (they've got the deadliest projectile in the game). There's now a max range setting for projectiles, also implemented for celatids, since parabolas don't inherently limit range like they did in the original. You don't want them spitting that stuff at you across the map! All other projectiles currently have unlimited range, of course.

In other news, those alien saboteurs (see 2x2 post) sure are persistent. My motherboard malfunctioned yet again. Lost a PCI slot and BIOS decided it wanted to try to overclock the CPU without my permission. Thought I was going to have to build a new rig to replace this 5-year-old dev machine, but after a cleaning and rearrangement of parts it's chugging along, again. Point is, fooling around with dying hardware ate up enough of my spare time that I probably won't get to push a new release this weekend.

All the new systems are debugged and ready to play, but I want to add a scoring system and new environment/scenario for the next (and last) pre-alpha release: Area 51.

6 comments more...

R3: "Sheer Terror"

by Kyzrati on 20111009 , under ,

The number of new features has hit critical mass, so time for another release. See the files page for a link.

As detailed in the last post, large units have been added. You get a tank this time, too. Admittedly not an impressive one, but anything will help against your new enemies, the alien "terror units." For now only large terror units are included; normal-sized thralls will come in a future version.

Terrain smashing is now implemented. Talk about putting the gravity system to the test... Giant units plowing through buildings, heavily-armored X-Com units dropping through weak house roofs in style, tanks mowing down fences... Everything went smoothly except the house filled with stuff getting bulldozed by a house-sized alien--he really helped me fix all the rare bugs :)

Now you can jump through windows without bothering to shoot them out first! By default, "smash movement" is *not* active--you can toggle it on a per-unit basis using the 'h' key. (This is so that the pathfinder knows what kind of path to take.)

Stronger units can smash almost anything, while most rookie soldiers can't get through much more than glass, shrubbery, and other weak obstacles, though stronger soldiers can eventually push through fences, thick hedges and weak walls, or even smash chairs and some other furniture as they move. Later on, some armor and equipped weapons will probably improve a soldier's ability to smash things. Sledgehammer, anyone?

Essential for large units, built-in weapon modules are now operational. The system is very expandable and can later be used to enable units to accept multiple modules, even non-weapon modules with special effects.

Melee attacks (m/M) are now possible, too. In fact, you can use any item to perform a melee attack. Farm level? Grab a pitch fork and stab the little bastards! (Warning: May not work on big bastards.) I divided melee damage into three types: bludgeoning, slashing, and piercing (others can be used or more added easily). Melee attacks can of course do non-melee kinds of damage, like the stun rod.

Bludgeoning damage may also knock targets backward depending on relative strength and item mass. Whack an alien right through a window and have him fall to his death! Or, if you're strong enough, push him right through a wall...

Melee attacks do not currently harm terrain (as in the original), though that can easily be changed by modifying the materials.xt file.

Knockbacks and terrain smashing are both optional (though in the demo there's no button to toggle them); those and the many other optional settings will eventually be accessible through a config file.

About the new demo:
  • Most of the large units are what you'd expect from X-COM: UFO Defense, but I did throw in the chance of one 3x3 unit. Here's hoping you don't get mauled by a Mega Reaper. (Murphy's Law says you will.) And if you see some toppled houses and trampled hedges while you're scouting around... well, let's just say you're probably not safe :)
  • Explosives are quite effective against large units since *all* sections take damage separately.
  • For those who have previously checked out the bunker, there's a couple new toys inside :)
  • See the changelog for a full list of changes (some commands have changed)

I also put together a quick demo video showing large units. To speed things up, I'm controlling the aliens in a mock battle. In retrospect, there should've been more wanton destruction :)



There will probably only be one more tech demo release soon (reaction fire), then a rather long gap before the first alpha version.

Now what are you waiting for?! Go stun yourself an alien!


2 comments more...

2 x 2 = A Lot of Work

by Kyzrati on 20111002 , under ,

It took one heck of a mega-refactor, but... they're finally here.

First time spending this much time on any one part of X@COM (even the particle engine only took a little over a day); had to parse a big chunk of the code since large units touch on a little bit of nearly everything--display, body item mechanics, FOV/LOF, pathfinding... Those weren't actually much of a pain, though. Implementing the effects of gravity on these guys was the annoying part--proper displacement by falling objects, bumping into each other while tumbling through the air, etc... In the end it was definitely worth it (not to mention necessary for any self-respecting X-COM remake!).

First sighting: Reaper!



So in the next release you'll be able to stomp--oops, I mean get stomped by--some large units. Don't worry, you'll have tank support! Too bad we all know X-COM tanks tend to suck. I suppose I'll be generous and give you a well-armed rocket tank or something like that, but it won't save you...

Not from...


Building collapses, from the smoke and rubble emerges a huge shadowy figure.

Soldier: "Um, command, I think we've encountered a new species."

[Radio silence]

Command: "Do you have a visual?"

Dust settles.


Soldier: "Oh my god... We're going to need a lot more rockets..."

...or, just one giant rocket:



Hell yeah!


That's a bit excessive though, you won't see anything quite that big in the demo.

But anyway, as you can see, unit sizes are actually arbitrary--they can be any dimension you like, even taller than one cell! Why not, the code is the same regardless of size. Not necessary for vanilla X-COM, but could lead to some interesting mods :)

Since it's somewhat related to large units, next up is terrain smashing: Any units with strength exceeding the integrity of a terrain material can smash right through it (for a TU cost). So soldiers can jump through windows, tanks and strong aliens can push down walls, and massive units could walk right through buildings. Obviously like anything else not X-COM, this will be an optional setting you can turn off in case you *don't* enjoy jumping through windows or surprising aliens by driving your tank through the side of a house.

After that is tank/natural weapons. That'll be a quick addition, then I can get the next release out.



In other news: ALIENS HACK X@COM!



They must've found out about X@COM and are afraid us Earthlings are developing a training program to devise ways to repel their imminent invasion!

Okay, what really happened is the ASCII mapping code was a bit off and turned the help screen into some alien language. Under the new mapping scheme, a virtually unlimited number of tiny images can be added to the resources and attached to any terrain, unit, etc. This was necessary to make it possible to draw the 2x2 units using special characters. Until now I was relying on hacks to get the unit triangles, but now they and the normal ASCII characters are easy to work with, even from the text files.
7 comments more...

12K Release!

by Kyzrati on 20110924 , under ,

Hm, just noticed the X@COM code base has reached 12,000 lines. That's already six times 2K! Imagine what it'll be eventually :)

I've uploaded a new release with some minor enhancements to the ARRP demo.

Here's the changlog list for those too lazy to check:
* ARRP: HUD more informative
* ARRP: To improve cover, reduced amount of open space and added a new orchard terrain area
* NEW: Light affects unit visibility
* MOD: Non-keypad movement scheme (arrows) more flexible, allows full range of movement
* MOD: Keyboard input more responsive
* MOD: ESC cancels priming action
* MOD: Right-click cancels firing/throwing
* MOD: ESC/Right-click stops movement
* MOD: Units may fire at targets beyond obstacles
* MOD: Auto doors close at end of turn instead of immediately when unoccupied
* MOD: Previous saved games no longer invalidated by adding/moving objects in data files
* FIX: Errors caused by AI misbehavior will be corrected without crashing

The biggest change: Light now affects unit visibility, so if you thought the demo was tough already, now you're really going to be slaughtered on the night missions (as it should be). I added another flare among the starting equipment; try not to blow them up--you've only got two.

Mostly been refactoring and trying to clear my workspace of notes/TODOs accumulated during the coding frenzy leading up to ARRP. Work should start on some new feature this weekend.

Here's a screenshot of a squad disembarking at the landing site near an orchard at night:

0 comments more...

ARRP: Alien Raid Resistance Party

by Kyzrati on 20110918 , under

The 2011 ARRP release is here! Check out the Files page for a download link. I've worked on X@COM for about 70 days now, so I guess that makes this a 70DRL release, too! :)

The demo scenario can be pretty damn hard, and then sometimes you can just get really unlucky. I only tested it a few times, in one of which an alien not far from the Avenger started with a Blaster Launcher... Needless to say we all died a fiery death, roasted in an impervious shell of our own making!

You can also luck out and not meet too many tough aliens, but they'll probably get you eventually. You'll definitely last a lot longer if you commandeer alien weaponry (no time for research!) and/or find secret weapons.

The alien AI is very basic (didn't spend more than a few hours adding it), and is nothing like the AI the game will use, but it does come in multiple varieties so don't expect all the enemies to behave identically.

There has been very little real playtesting so far, and I've been coding lots of new content up until just a moment ago, so don't blame me if it explodes. Seems fine when I run it, though, so do your worst. Come to think of it, explosions are good, as long as they're properly aimed...

I will entertain requests for simple updates to make the demo more fun, but don't request anything major--coding it is fun and all, but takes time away from core development. I'll also be updating the demo with new gameplay features as they become available for testing.

Some specific notes:
  • The game could be quite a bit faster, but I compiled the release build with most of the assertions intact, so you'll actually get specific error messages if something does go wrong.
  • Check out the FOV options. The original had none, but everyone seems to want things like highlighting. I'm not yet sure it's a great idea, since it removes some of the suspense, and X-COM is all about suspense.
  • There wasn't enough time to update the latest libtcod, so there's no mouse wheel support for zooming--that will come soon.
  • Oh, and look out for Sigmund.

While I'm at it, may as well put up a fun screenshot. This is what the ARRP map gen's first run produced:
Oh the havoc one misplaced variable can wreak on a calculation :)

Never fear, you can now advance your soldiers without the danger of buildings and terrain rearranging themselves around you.

Now go shoot something already!
10 comments more...

Artificial Unintelligence

by Kyzrati on 20110911 , under

"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...)
2 comments more...

Death by Proxy

by Kyzrati on 20110910 , under ,

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!
3 comments more...

Take Me To Your Leader

by Kyzrati on 20110907 , under ,

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 :)
4 comments more...

What goes up must come down... and preferably explode

by Kyzrati on 20110906 , under ,


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:
That probably wouldn't mean much if windows were simply holes, but in X@COM they're of course made of glass so you can enjoy shooting them out :)

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


2 comments more...

See the Light

by Kyzrati on 20110831 , under ,

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

Conflagration Propagation

by Kyzrati on 20110828 , under ,

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
4 comments more...

Console-Sized Quantum Mechanics

by Kyzrati on 20110821 , under

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

    9 comments more...

    Ka-boom!

    by Kyzrati on 20110811 , under



    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.



    1 comments more...

    The Sky is Falling

    by Kyzrati on 20110808 , under ,

    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
    8 comments more...

    Heads Up

    by Kyzrati on 20110729 , under

    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.
    3 comments more...

    Death from Above

    by Kyzrati on 20110725 , under ,

    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
    0 comments more...

    A Different Point of View

    by Kyzrati on 20110724 , under

    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 :)
    0 comments more...

    Open Fire!

    by Kyzrati on 20110722 , under ,

    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.
    2 comments more...

    X@COM Has Landed

    by Kyzrati on 20110711 , under

    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...
    4 comments more...

    Giant strides...

    by Kyzrati on 20110709 , under

    ...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...
      7 comments more...

      Introducing X@COM

      by Kyzrati on , under

      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.
      0 comments more...