Looking incredible.  The way that some of the dwarf sprites seem to be tilted over looks really weird to me, though.  Are they meant to be swaying about in a drunken stupor or is it some kind of perspective thing?

In the screenshot on the last page (but not the last two), the walls all look to me like they are actually floating a bit above the floor.  I think this is because of their shadows, and the way that they fall on top of the coloured tiles that indicate movement zones, which then themselves have shadows.  I would say either keep the shadows off those coloured tiles altogether or foreshorten the shadow as it falls on them to take account of them seemingly being raised.

Like the new colour-scheme, although the humans now all look a bit red in the face to me, as if they've either been running around too much or are just really embarrassed that they all turned up wearing the same outfit.  Not sure if that's simply because I'm used to their older skintone, however.

I took it more as evaluating shots and time units. 
Less:
"Hey I can kill this Muton with two rifle hits, or a rifle hit and a pistol to save ammo."
More:
"Hey I can take 2 steps and a half turn and fire a snap shot, or I can stand still and do an aimed shot."

Ah, I see - yes, it certainly did that.  Although I would argue that is slightly less immersion-breaking in that time is a real-world resource (however abstracted) and so you're still making the same kind of decisions that a soldier would make (probably a lot faster) in real life, while HP is not.  That said, I can't say I'm particularly sad to see the back of time units in the new one - it certainly helps the game flow a lot better.

The old XCOM definitely encouraged that behavior.

How so?  In the original, enemy max health and damage inflicted was highly randomised, you couldn't even see their current HP unless you used a mind probe, everything had varying resistances to different weapon types (that I don't think were actually numerically stated in-game) and you couldn't even access the ufopedia in the middle of a battle to check the actual damage your weapon did... it's hard to think of any other ways of discouraging that kind of calculating approach they could possibly have used.

I've written a big long blog post critiquing FTL here:

http://www.vitruality.com/2012/09/faster-than-light-the-quest-for-the-unknown-niggle/

But, to summarise:
- I like it.
- But the high level of randomness combined with the positive feedback loop of the power curve combined with its system of counters sometimes making battles unwinnable if you don't happen to have the right upgrade make it an often frustrating experience.
- I also go off on a couple of tangents about Alcubierre Warp Drives, Dwarf Fortress and Mr. T.

Got this earlier in the week and I love it.  It's mechanically a very different game to the original but it captures the overall feel quite nicely.  I'm in the middle of a terror mission at the moment that has been a genuinely harrowing experience - over the past twenty years I've gradually got over my fear of Cryssalids but they've managed to make them shit-pants scary again.

On the whole I understand the changes they've made - the original X-com is my favourite game of all time but I have to admit it did have some rough edges that the new one neatly files off.  But there are two big things that I think are miss-steps:

1. No randomly generated levels.  I get that by predesigning them you can make them look all purty, but I would trade in all the sparkly running-water effects for the infinite replayability of the original in a heartbeat.

2. Its approach is a lot more rule-based than the original's more simulationist approach, which I think works against it sometimes.  Stuff like hit chance being based just on range and cover rather than actually tracing the tragectory of the bullet and its slightly weird line-of-sight detection make it a lot harder to tell how things are going to go just from looking, and you get a lot less of the exciting emergent stuff happening.

I'm also kinda upset that I can't put my considerable business experience of running laser-cannon sweatshops to good use, but I can see why they took that out.

I'm not sure I totally understand what you're asking, but perhaps this will help:

When you collide with the wall you will have two forces to consider:  Firstly the reaction force, which will always act in the direction of the normal of the wall.  So to get this direction just figure out the direction of the line segment you are colliding with (i.e. get the vector that connects the start point and end point of the line segment and then unitise it) and then rotate by 90 degrees.  If you're assuming your wall is fixed then to resolve this you just need to find the component of the player's velocity in this direction (i.e. the dot product), reverse it and scale it by whatever you are using for your coefficient of restitution.

Secondly will be friction, which will always act in the direction of the wall section.  So you can just take the vector you already calculated for the wall, get the player's velocity component in that direction, and apply a force in opposition to this, scaled by your friction coefficient.

Played the demo - didn't have much idea what I was meant to be doing at first, but it's real purty and I like the way you can position and build your own weaponry.

Love the style, and it's great getting such an in-depth look into your process.

Sounds interesting.  So once your character dies do you pick up a new character in the same world, affected by the consequences of the previous character's actions?

Holy hell, those screenshots are... well, they make me want to start licking my computer screen or something.  Is that weird?

Nice! I've been looking forwards to playing this for a while now.  I guess the best way to structure my comments is with comparison to the original, so:

BETTER:

- I like the new terrain and stealth systems

- The new themed areas are a lot more characterful than the original's genero-dungeon (much as I love genero-dungeons).

- The one thing I didn't like about CQ1 was the multiple-lives system; I prefer my permadeath to be more permadeadly.  Although you've still got basically the same system I like that it's embodied in the Ankh now and takes up an inventory slot - it makes resurrection feel marginally less cheap.

- Shops/Scavengers

- The new perk-tree when you level up gives you some nice sub-specialisation options.



UNDECIDED:

- No longer healing when you level up took me by surprise since I'm used to adjusting my tactics around that, but it probably does make more sense to heal when moving between areas instead.  I do miss being able to take bigger risks when I knew that I was just about to level up, however.



WORSE:

- While I like the style of the original's graphics it seems like in this game they don't fit in well with a lot of the new art.  You also seem to be mixing pixel art resolutions a lot which looks horrible (I guess the original did that as well, but because it had greater stylistic consistency it got away with it a bit better).  I think at the IRDC you mentioned maybe bringing in somebody to redo all the art - is that still the plan?

- Similarly, the interface/HUD seemed a bit better laid out in the original, although on the plus side it seems to take up less room now.

- You've removed CQ1's single greatest feature, being that it would automatically sell junk items for you if they had no advantages over your current equipment.  Even if you reintroduce that the new pop-up system is irritating and intrusive.  Dumping items in your inventory to sort out later at your leisure was a much better system in my opinion.

- If you must keep the pop-ups, at least give the option to either sell or use immediately potions etc. that are lying on the ground when you've run out of slots for them.

- Shift + Number key hotkeys?  No no no no no.

- I'm guessing saving/loading isn't finished yet?  I reloaded a game and found myself stuck in black space to one side of the entrance with my equipment reset to the starting stuff.  I have a screenshot of this if it would help and this is not expected behavior...

It should be called Stovepipe Hat Adventure Land.

@astrospoon: I generally have the head part of the same mesh and the facial bones part of the same armature - I'm guessing you're under the false impression that you need to create bones by extruding them from other ones to form continuous chains?  You don't - you can just add new bones in edit mode and manually set their parent to the relevant existing bone (in this case, presumably the head bone).  So you don't need separate skeletons, even if you do have the head as a separate mesh for some reason.

Nice!  The first time I tried the online version it wasn't registering mouse clicks but when I reloaded the page it worked fine - I guess it had keyboard focus but not mouse focus for some reason.

Also: the indieDB download link seems to not lead to a valid page.

Nice concept, I like it.  I think I actually had the opposite problem for AlexHW in that for me the controls were a bit too responsive - even a fraction of a second on the arrow key seemed to make me spin right round, which made it really hard to make the fine adjustments necessary to align myself with the ground.  It could be that I'm just rubbish, however.  In fact it almost definitely is that, but perhaps the controls are a little too sensitive as well.

I can understand changing the name from a googling perspective, but SWØØØØRDS! was a much better and more memorable name in my opinion.  I don't think that it not really being pronouncable is that important - it didn't seem to hurt VVVVVV.

Sure, yours is probably 'better' for most situations, but it depends what you want to do with it.  The real advantage of my way is that it works for multiple inheritance levels and is therefore a bit closer in usage to things like .NET's 'typeof'.  So, it will return true for Bar and any classes derived from Bar as well, whereas in your example if you had subclasses of any of your shapes (say BCT_EQUILATERAL_TRIANGLE, BCT_RIGHT_ANGLED_TRIANGLE etc.) you'd have to check for them separately just to find out if you could treat the object as a triangle.

The way that I do this is: for each derived class that I might ever need to know the type of, I add a virtual function to the base class that returns a boolean telling you if that object is an instance of that subclass, set to return false.  Then in the subclass I override that function to return true.  For example:

Code:

class Foo
{
public:
virtual bool IsBar(){return false;}
};

class Bar : public Foo
{
public:
virtual bool IsBar(){return true;}
}

Then, whenever I need to check whether a Foo object is an instance of Bar I can just call IsBar().

Edit: Ha, just beaten to it by rivon!  His way is probably less work to implement but I think I still prefer mine since I don't like cluttering the place up with enums if I don't have to.

That screenshot looks great.  The shadow effects especially are nice, although it looks like they don't quite match up with the apparent positions of the light sources.  As another very minor quibble I don't like the way the character's dress flares out around the bottom - unless they're resting on the floor or being blown around (which from the looks of it that one isn't) most dresses follow a parabolic curve going in the other direction - i.e. they droop under gravity.