Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Chris last won the day on October 16

Chris had the most liked content!

Community Reputation

290 Excellent


About Chris

  • Rank
    Beloved Leader


  • Location
    London, UK
  • Occupation
    Project Lead, Xenonauts
  1. Chris

    X2 Audio Design

    Thanks. We're in the process of starting work on the first batch of new sounds for X2 right now actually. Feel free to send me an email (address in signature) with a link to your portfolio; maybe it'll come to nothing but there's no harm in seeing if there's anywhere you might be able help us out
  2. Chris

    Ground Combat Items

    This stuff is already in Xenonauts 1, no?
  3. With preparations for the closed beta of Xenonauts-2 very much underway here at Goldhawk HQ, it's time for me to give you all an update. As I talked about the strategy layer last time around, this time I'll be focusing predominantly on the ground combat. I'll also be giving a little information on the timelines and progress towards our closed beta. First up, apologies for the radio silence here on the forum. The harder I'm working the less time I have to spend reading and commenting on forum posts, and this effect is magnified when I'm working on a few big tasks rather than working on lots of little things because I have far fewer 5-minute gaps in my day where I can grab a moment to check out the forums. I've spent a lot of time making maps recently, which is definitely a big task! Map Variety: Having a decent number of maps in the beta is pretty essential to keep people interested as we release our updates, because seeing the same map over and over again really kills any excitement in the ground combat. I've made roughly 35 maps for the early-game UFO crash sites and alien base missions in the past two weeks, and I'm still working on more (Terror maps, crash sites for the larger UFOs, etc). I'll write up a longer forum post on the map editor at some point, but these maps support more randomisation than the equivalents in Xenonauts 1 so those 35 maps should go a long way - although naturally we'll continue to make more as development continues. However, please note that we're concentrating on quantity rather than quality right now. Some of the buildings / props / ground textures look pretty rough in some biomes, but I'm more interested in the gameplay variety than the visuals at this point and so I've just thrown them into the game anyway. These will be polished and improved once we've got basic versions of all the tiles and terrain we want in the game. We're both expanding old biomes from the first Xenonauts to contain more variety, and also adding new biomes to Xenonauts-2. This should give a really great end result in terms of keeping the gameplay experience feeling fresh and giving the game a suitably "global" feel, but the scale of the work required is significantly more than was needed for the first Xenonauts (which itself contained a LOT of environmental art) so we ask for your patience as we work our way through it all! New Mechanics, Weapons & Abilities: Although the focus has been on some core gameplay systems over the past month, we've quietly finished up a quite a few more self-contained mechanics and battlefield items. Fans of the original X-Com will be pleased to hear that we've implemented proximity detonation for grenades, so the classic proxy grenades are now functional and in the game. We've also got the Reaper "infect" ability working, so units are turned into zombies if killed by a Reaper ... and those zombies hatch into Reapers if killed or after 5 turns. We're now moving on to adding the psionic alien abilities, starting with Mind Control - and we'll probably be adding a psi-amp item to the game for testing purposes so if we do want to give the human side psionics it's going to be very easy to do. We've also revised a couple of gameplay systems to make them cleaner and easier to understand. Stun Damage used to be a pretty complex calculation but now it just starts at 0 and counts upwards as soldiers take Stun Damage. This is displayed as a small yellow line under the HP bar of the soldier, and if the yellow bar ever reaches the current HP of your soldier then they are knocked unconscious. Same gameplay effect as before; just displayed more clearly. The other revised system is Armour Penetration and Armour Destruction. Armour now provides a set of resistances - e.g. a suit of kevlar armour might give you 40% resistance against kinetic damage, which reduces incoming kinetic damage by 40%. Armour Penetration is just a percentage set on the weapon that controls what % of the weapon's damage ignores this resistance (e.g. if a rifle does 100 kinetic damage and has 20% Penetration, a target will take 20 damage even if they have 100% Kinetic Resistance). Armour Destruction is another percentage set on the weapon, and it controls how much armour the weapon destroys with each successful hit. A sniper rifle with 30% Armour Destruction will leave the target with 70% of their starting armour after a successful hit. This means it only offers 70% of the protection (against all damage types) it did when it was undamaged; e.g. that kevlar armour that offered 40% kinetic resistance would only offer 28% kinetic resistance after being hit with a sniper rifle round. Similar to what we had in Xenonauts 1 but a bit simpler for players to track. Inventory: I mentioned last month that we were implementing the full soldier inventory system from Xenonauts 1. We've got this system working now, which is a pretty big deal given it touches on all the following: All inventory items have grid sizes and weights, and soldiers have grid-based backpacks / belts and suffer TU penalties for being overloaded Units can open their inventory on the battlefield and spend TU to change their equipped weapons or drop items on the ground Units drop the contents of their inventories when stunned or killed, and other units can pick this up Items from the battlefield are transferred back to strategy (or not), including stuff picked up by your soldiers and brought back in their backpacks, etc This is a pretty huge system, and it's also pretty notorious for having even more "invisible" work in it than other parts of the game. For example, once you finish all that and start testing it you rapidly realise that there are certain special-case items that actually should not be dropped by a stunned / killed unit - e.g. the claw weapons from a Reaper, or the body armour of a stunned Xenonaut. Today we set up the "integrated" tag that allows us to specify those items, which wasn't a huge amount of work in itself but was just yet another small special case that eats up our development time. This sorta thing means that the inventory system took quite a bit longer to finish up than we expected, and as a result it's now working... but it's not yet working well. You can do pretty much everything you want with the system, but there's a load of obvious usability functionality missing - e.g. dragging and dropping an item on top of another item doesn't swap the position of those items, so if you want to change the weapon of a soldier on the Soldier Equip screen you first have to unequip their current weapon before you can assign a new weapon in the empty slot. The question over whether this is good enough for a beta release brings me onto the next part of this post. Progress Towards Beta: The closed beta for the £35+ Kickstarter backers is slated for the start of next month - the internal date we were looking at was the 6th or 7th of November. We are sprinting as fast as we can to get things ready, but I'm also very conscious that releasing something too rough means there simply won't be much useful feedback you can give us. A good example of that is the inventory system mentioned above. Fixing bugs and doing all the "invisible" work means we've not made as much progress as we'd like in recent weeks, so we're simply not going to be able to finish on the obvious usability issues with the Soldier Equip screen before the planned beta date - as we're concentrating on actual critical game-breaking bugs at the moment. I think those bugs will be fixed by 7th November, so we *could* release a working build on that date... but I think we'll be wasting everyone's time by doing so. Here's why - anyone who has played Xenonauts 1 for any length of time immediately pick up on the usability problems with the Soldier Equip screen and will flag them up... but we're already well aware of those issues, we just haven't had time to fix them. There's enough of these problems scattered throughout the game that I think we should try to address them before the beta, else we'll be wasting the enthusiasm behind the first few beta builds just collecting information on issues we're already got on our work lists. Player feedback is a valuable commodity and I think spending a few more weeks fixing the gameplay would make the experience more worthwhile for everyone. We're therefore going to delay the start beta by few more weeks. I'll announce the updated beta date next week, as we're still working on a couple of areas where fixing bugs revealed yet more bugs hiding underneath - we can't really do any meaningful planning until we've got those things working, as we still don't know how many bugs there are left hidden under the bugs we're currently working on. Anyway, I hope this post has explained the logic behind the delay - but I nonetheless apologise to anyone disappointed by the news!
  4. Chris

    Xenonauts-2: ATLAS Base

    Yeah, if we end up using the single-base approach then the missile is indeed going to be plot related in some manner. The type of base mechanics we end up using are subject to gameplay testing though
  5. Yeah, you raise some valid questions but I think in many cases you're overestimating the advantages of the solutions you'd prefer and underestimating the disadvantages. The single / multiple base question is still one we're undecided on. We may go back to the X1-style base mechanics but I think the single-base concept has potential and the only way to find out is to give it a proper test, and we can have a clear-eyed assessment of the advantages and disadvantages properly then. However I'd be cautious of leaning too heavily towards incentivising multiple "proper" bases though; we tried it in the early stages of X1 by setting the dropship not to have global range (forcing the player to have multiple combat teams) and people hated it because it felt super-inconvenient. Reducing the range of the dropship in X1 is something you can do in like 2 minutes with a text editor and it might give you a bit more perspective on whether that's a change you actually want or not, as it has a variety of knock-on effects on gameplay. Moving to Unity from our old engine was definitely a good idea; without going into too much detail Xenonauts 1 was built on an ancient engine that had been abandoned by its creators and caused us no end of troubles throughout dev and afterwards. It'd have been amazing if we'd built our own specific engine for the game, but instead we built a game held together with sticky tape on top of foundations made of sand. So keeping the same engine / codebase was never a viable option for us, hence why we never did any DLC. Re: the combat stuff - we'll have to experiment in more detail when we hit beta. Xenonauts with 10% of the complexity stripped out is still an extremely complex ground combat so I don't necessarily think we need to announce another feature to replace the loss of the defence bonus from crouching (which is effectively a tiny balance change, as effectively is changing the tanks from being 3x3 to 1x1). But in any case I very much doubt you'll feel the game is any less complex overall once you start playing the finished version of the game; I don't have time to list out where the changes net out with each other but the idea is that they should. In short, I know it's always tempting to say "instead of the devs removing complexity, why don't they just add it!" in pretty much every situation but that leads to an unwieldy and overly complex game (as well as requiring far more dev time and resources) ... and in many cases it actually makes it the gameplay experience less fun, as the ill-fated short-ranged dropship in X1 illustrates.
  6. Chris

    More vertical map design

    So X2 does incorporate more verticality than X1 does, but I'm still quite leery about it - fundamentally the problem is that line of sight / line of fire gets more complex and more confusing when you're shooting from one height level to another, or looking / shooting up stairs and through small gaps in floors / ceilings. The problem is it tends to expose the kind of errors that annoy people; stuff like the "shooting round corner" logic from X1 that makes the game feel unfair. I don't think stairs / ramps are currently in the game (I was initially hoping to get by on just ladders) but I suspect they will make it in fairly soon.
  7. So the music is currently planned to be more of the same, unfortunately. What you're talking about is contextual music which changes dynamically based on what's happening on the battlefield, which requires some work from the coders as well as most likely some additional work from the composer. I'm not actually sure how much work it'd be so maybe it's something we can look at later in development as a "nice to have" feature... but right now I'm definitely prioritizing coder hours onto things that are more key parts of the gameplay!
  8. (This is a cross-post of the Kickstarter update I just posted!) Now the dust has settled on our successful Kickstarter campaign, it's time for a progress update on Xenonauts-2! There's lots of exciting stuff to talk about, even though the lingering admin from the Kickstarter has kept us busy and the summer holiday period means that we've frequently been without one or more important team members! Air Combat: The first thing I want to show off is a very early incarnation of the air combat. The art and design are both still very rough, so try to look past all the placeholder art from the first Xenonauts and the rather simple combat interactions in the video. Our objectives for the X2 air combat were to make something that was fast-paced but still rewarded the same skills as the rest of the game – tactical and strategic planning (I felt the X1 air combat emphasized reactions over good tactics). I've been playing with a lot of different ideas over the past few years, but I feel we've now hit on a good idea that will be able to combine both speed and tactical depth once complete. Essentially the player has a certain number of turns to shoot down each UFO before it engages its jump drive and escapes from your interceptors. Your interceptor weapons have limited ammo and generally do more damage the closer you are (as do the alien weapons). Your interceptors can make one move each turn before they attack, but the UFO is also able to move - which it does by moving your jets up and down the battlefield to represent it speeding up / slowing down. Different UFOs will of course have different strengths and weaknesses, and the system supports up to three combatants per side. I'll likely be writing an entire update devoted to the new Air Combat model once things are a bit more polished and the design has developed further, so I won't try to explain any more about the rules for now – but I just wanted to show everyone that we do already have a basic air combat system working and hooked up to the rest of the strategy layer! Armory & Soldier Equip: The next thing I wanted to talk about is the Armory screen and the soldier inventory mechanics. The UI concept above incorporates two major mechanical changes since the start of the Kickstarter, and also gives you some idea of the direction we'd like to take the final UI now we can afford to divert some of our funds to a dedicated UI artist (although it is only a rough style / layout concept, so don't read too much into the details). The first big mechanical change is the return of the grid-based soldier backpack from Xenonauts 1. We were initially planning to remove this as part of a package of changes to make the inventory system less cumbersome, but we reconsidered our position after the community raised some valid points about why this might make the game less interesting to play. We're currently in the process of implementing the old backpack / inventory mechanics (they'll be in for the closed beta), as well as the other planned changes that were uncontroversial improvements to the system. The second change is my first concept for the modular armour system that forms part of the modular equipment stretch goal. This works by splitting armour into two different inventory slots: the "Armour" and the "Plating", and giving items in both a set of % resistances against different types of damage. The “Armour” is the base layer of armour your soldier is wearing – at the start of the game it's the blue Tacsuit, but your research efforts soon unlock different types of suit that offer better / different protection against the various damage types (ranging up to the endgame Exosuit). “Plating” represents any additional armour you wear on top of this base suit, so the starting Tacsuit allows players to wear either “Light Kevlar” or “Heavy Kevlar” plating (the heavier plating offers more protection but weighs more). As the player progresses through the research tree, the Plating can be upgraded – e.g. Kevlar vests become more protective Alloy vests, etc. This system allows players to mix and match armour to suit the specific mission. If you want good Chemical protection, you can equip your soldiers with a Chemsuit but then issue your assault troopers heavy plating and your snipers light plating. The way that plating upgrades through the game keeps older types of armour relevant, too - that same Chemsuit will still be somewhat viable in the late game if you have sufficiently advanced plating available, although advanced tech like an Exosuit would obviously be better in most situations. Remember that this idea is still at concept stage and not yet implemented, so it may well change prior to release (or even prior to the closed beta!) New Aliens: Finally, I just want to show off a quick piece of concept art for a new alien to go in the game. The 3D art for this alien is not yet complete, but it's planned to be a single-tile psionic support unit. We've got a number of new aliens working their way through our art / design pipeline, and we're making an effort to include some more distinctive aliens in the game this time around. There's certainly a place for humanoid aliens in space jumpsuits in the alien roster, but I think any X-Com successor also needs to embrace some of the absurdity of the original games to properly capture their spirit. A floating alien brain seems a pretty good place to start! Anyway, that's enough from me - there's a lot more I'd like to talk about but I really should get back to work! The closed beta is still planned for the start of November and I'll keep everyone informed on our progress towards that deadline as it approaches.
  9. I don't really think there's much to be gained by discussing ways we can remove the air combat from the game. I'm pretty intent on putting air combat in the game (indeed it's already in the game); it's just finding the appropriate level of depth for it.
  10. I did toy with the idea of having Sebillians rise from the dead earlier in development, but there's a couple of practical things to consider. Firstly, it's (intentionally) kinda hard to target a dead alien with your weapons so killing them for good might force a rewrite of how the shooting UI was handled. Secondly, how does it work with regards to the end of the mission? If you down the last Sebillian but it's still alive, does the mission end? Might also be annoying if you kill a Sebillian and leave the area, but then later discover that it has got up and run away and you have to hunt it down again. I think in the end I decided it might just be a bit too annoying, so just boosted their HP regen mechanics instead.
  11. It's now the final day of August and about six weeks since the Kickstarter ended. Those of you who frequent the forums will be aware that I've been away for the past month getting married and going on my honeymoon, but I'm now fully recharged and back at work! The team have of course been hard at work in my absence - here's a quick update on where we are on some of the headline features we've been working on recently. Realtime Geoscape For a long time we were experimenting with a turn-based Geoscape model, but we eventually decided to move back to a realtime Geoscape before the Kickstarter because we just couldn't make the turn-based Geoscape feel as interactive and engaging as the realtime Geoscape did (even when we were giving the player exactly the same strategic choices in both systems). This has *definitely* been the right decision; the game feels far more alive now you can see UFOs flying around the world generating events and so on. Two or three months ago I breezily said this was only a few weeks of work, but unfortunately it turns out the rabbit hole went deeper than we expected - we've ended up rewriting essentially all the logic for the alien invasion and the Geoscape map setup. The basic work on the realtime Geoscape was finished a week or two into my absence, but a second pass is going to be needed before the Realtime Geoscape is considered finished. To give an example of what I mean: UFOs currently spawn on the Geoscape and fly around spawning events, and are detected when they enter the radar range of your bases. You can launch interceptors at the UFOs and shoot them down in the new air combat to create crash sites ... but there's no way to issue new orders to interceptors that are already airborne. Thus the functionality is present and the system is largely "complete", but we still need to do a pass on the gameplay aspects of the Geoscape because the player can't yet access everything they need. This is what I'll be focusing on in the short term. Air Combat I mentioned the "new air combat" in the previous post - this first iteration of this is now implemented and linked up to the strategy layer. We're working on a second iteration that improves the experience (UI improvements, combat music, weapon sfx / vfx, etc) that'll be arriving shortly, but even in its most primitive state it's pretty fun. I'll be experimenting a bit with it next week to see how it works within the context of the strategy layer, but maybe I'll post up a video or something so you can see it in action. There's been a LOT of discussion on the new air combat design in this thread. I've got some cool ideas for how we could further expand and develop things, but it's exciting just to play with the basic set of mechanics we currently have. In conjunction with the new realtime Geoscape, the strategy layer is feeling a lot more interactive than it ever has done before. AI Update Our technical director GJ has been working on a number of things over the past month, but his most recent task was to start work on the "non-racial" combat AI. This is the general AI that all combatants will use as their basic way of interacting with the battlefield - it controls how they choose what enemies to shoot at, where they move, how they choose cover, and how they choose to split their TU between different actions available to them. This is by far the most important part of the AI, because it controls whether the AI does obviously stupid things like choosing not to shoot at a Xenonaut caught in the open a few tiles away, etc. Later in development we'll be focusing on the more advanced types of "racial" AI that makes aliens behave differently depending on their racial abilities and equipment - e.g. Sebillians are likely to be more aggressive because they are tough, while Reapers would spend more time trying to stay hidden and lay ambushes, etc. But we need a solid "non-racial" tactical AI underneath before all that stuff becomes useful. GJ is now off on his own holidays for a week, but he's got about a week of work more before we have the first iteration of the new non-racial AI in the game. I do expect the first iteration of it to be fairly rough when it comes in, but it should still be an improvement over what we had in the Kickstarter combat demo and I also expect it to improve quickly throughout development and during the closed beta. Soldier Backpack & Ground Combat Inventory We're about halfway through implementing the soldier backpack on the strategy layer at the moment. Our old design was slot-based so didn't have to worry about the grid size of items, so we're now setting up the grid for the backpack and giving equipment the various properties they need to interact with it. Once that's done we'll be adding in the ground combat functionality for units swapping items to and from the backpack, and dropping / picking things up off the ground. That's everything for this update - there's quite a few smaller things we worked on over the last month too, but I can't be bothered to type any more - and I suspect I'll write another update expanding a little more on this for Kickstarter in a couple of weeks once the air combat has progressed a little more!
  12. I don’t think proposal 2 is a good idea. Proposal 1, possibly - I think that’s just something we’d need to experiment with. I think it might introduce a problem where the soldier turns to make a step he cannot take, and then doesn’t have any TU left to re-orientate to a more useful direction. Not sure whether that situation is worse than the one you are currently experiencing though; we’d need to test it.
  13. Thanks for your thoughts - looks like you got quite into this! I’ll admit in advance I’ve only skim read everything so far, but a couple of thoughts struck me as I did. Firstly, there’s more than one way to skin a cat. It seems like quite a few of the systems you’ve come up with could be supported by my existing mechanics just by changing the balancing - e.g. rolling 4 individual plasma cannons, each with a specific hit chance can be approximately represented by a single plasma cannon with an appropriately wide damage range. Instead of limiting the weapons a plane can fire each turn, you can just set missile racks to have 2 ammo and do half damage so a plane needs to stay in combat range for longer to unload all it’s firepower. This is obviously preferable to re-implementing our existing work! Secondly, I can definitely see the influence of Slay the Spire coming through in your design. That’s not a bad thing, though - we’ve discussed the whole “UFOs displaying their intentions in advance” concept before with regards to how Into the Breach handles it, but I can see how a semi-randomised AI script each turn (eg “powerful attack”, “boost jump drive charge”, “evasive action”) could keep the encounters fresh, given there’s potential for a different sequence each time. Obviously the UFO would need to have a basic attack that it performed each turn anyway though. When I get back I might post up some of the numbers I was using for the paper prototyping, but even then I think you might need to play the air combat in-game for us to properly be on the same page. If I was going to add more compexity to the existing design (although I think it may already have more complexity than you realise) then I’d probably think about adding in lateral movement too, as then you could map the alien attacks in more detail (“first plane in this column takes 3 damage”, “everything in this column hit for 5 damage”). The size of the UFO matters too; a small UFO is only one column wide so multiple interceptors would struggle to fight it effectively (assuming friendly fire is on), whereas a bigger corvette would be wide enough for several interceptors to engage simultaneously. But I guess the problem here is an interceptor could always dodge an incoming attack, as it would be shown to them before they make their move... In any case, interesting thoughts.
  14. Sorry, your diagrams aren’t aligning correctly on my phone. I’m not quite clear what the issue is here though - are you saying that a soldier with an interrupted move will not have their movement terminated as soon as they take their last step (so soldiers can waste TU doing “useless” turns trying to orientate themselves towards a tile they don’t have enough TU to move into?)
  15. Chris

    Sidesteps in combat?

    We experimented with “leaning” around corners for a while and it was a nightmare in terms of the shooting mechanics. As such I’m very reluctant to allow any form of sidestepping beyond potentially adding the ability for units to literally step sideways (i.e. move sideways but remain facing the same direction), and even that would complicate the control system more than I’m strictly comfortable with. Would be very handy near corners or doorways though.