Xenonauts-2 August Update

[Chris]

It's time for the monthly update on our progress on Xenonauts 2. The stuff we've been working on this month has largely been nitty-gritty work on fundamental game systems like the fog of war / shroud and the way that levels load, which are necessary but broke our existing maps and prevented us from releasing new builds until all the code work (and the subsequent bugfixes) and the new maps were completed. We're now nearing the end of this process, and we've also been working on a few other systems you'll hopefully appreciate in the next release.

This is a long post because these systems are complicated stuff and I know a lot of people in our community like reading it. If you're not in that category, just skip to the next heading once you get bored!

Dynamic Map Loading:
Maps in Xenonauts 2 are now created when the game tries to load the map, rather than being a pre-baked file. The map file exists as a sort of "plan" for the level, but some or all of the level can be randomised depending on how the map is put together. I won't go into too much detail because although this is an excellent system, it's not exactly groundbreaking stuff - the same system is used in Xenonauts 1, XCOM2 and is even used in the original X-Com to some degree. There were technical reasons that meant we weren't confident we'd be able to make it work properly in Unity at the beginning of the project but we've managed to overcome them and maps are now loading dynamically.

This improves the player experience because it allows the Xenonaut base defence missions to mirror the layout of your actual base like they did in X1 and X-Com, because it allows more potential randomisation within a level, and because it will save you a great deal of hard drive space and download time when playing X2. It also means that fully-functional features will no longer be roadblocked because they require incredibly time-consuming map updates - something that recently affected advanced dropships and night missions (both of which worked but weren't worth updating the maps over).

If you're interested in why this sort of thing happens, it's because a pre-baked map cannot be changed on load and thus you need a seperate version of each map for each ufo or dropship (or any other type of variant) it might support. If you take X1 which had three dropships, 7 UFOs and 6 map biomes, and assume you want five different maps per UFO per biome, the number of maps for crashsites is 3 x 7 x 6 x 5 = 630. And you probably want a landed (rather than crashed) variant of each of those UFOs, too, so you can double that to 1,260 maps. Each map is about 7 megabytes on the file system, so those crashsite maps would take up 10gb on your hard drive.

The problem there is that if you implement a new feature like night missions, you often have to specify where those systems apply. For instance, Alien Base missions shouldn't be affected by the night / day cycle because they are underground. That means we need to update the map settings for every map to contain a value for whether that map should respond to the day / night cycle or not, and under the old system I would need to potentially update the settings on over a thousand different maps and then regenerate all those maps so the new settings are saved into them. Not only would that take me days, it means that that tiny change to the map settings requires every player to download a 10gb update.

Clearly, that would be madness. Our new solution means a map can load in the desired dropship / UFO / etc at the start of the mission, so the number of maps is far lower and each one is only a few hundred kilobytes. Putting additional dropships into a map or activating night missions becomes something I can do in half an hour and is 10mb update for our players. Although this change has disrupted a lot of things over the past month, it's also going to pay big dividends very quickly.

New Ground Combat Maps / Art Style:
I've been very busy over the past couple of months making our new maps and trying to make the ground combat visuals more consistent. We've been working with an external studio to look over the 3d art we've already done and they've retextured most of the assets in the Desert and Polar biomes since then, and are just starting on the Farm biome.

I hope that when you see the new designs you'll think they are already better than the old visuals, but in the short term the main focus is just consistency - everything in each map needs a consistent level of detail and texture style so individual parts don't look out of place and break the immersion. There's a few subtly different artistic styles / choices we need to explore before we can call anything final (e.g. do we want to lean more realistic or use slightly exaggerated black lines to make objects pop like they do in X1? do we want the ground tiles to be relatively low-detail to let the player focus on the units and props that make up the playable battlefield, or do we try to dial up the detail at the cost of clarity?) so hopefully our ground combat maps will continue to improve as the we work through the remaining assets.

I've created a new set of maps for the Alien Base and the Desert, Polar, and Farm maps for the small UFOs (the first three UFOs that all fit within a 18x18 grid). Our previous set of maps were pretty much fully randomised, but I've taken a step back from this and created specific areas of the map that are randomised while other parts are not randomised at all. Personally, I think this gives a map that feels more "designed" while still supporting more randomisation than we had in X1, but hopefully the system below means we won't need the randomisation as much anyway.

Biome / Map Randomisation & Raids:
As well as the small UFO maps, I've designed a few Raid maps for the Desert / Farm / Polar biomes. These already exist in the game (they're basically mini-terror sites in tight urban environments with no UFOs) but I plan to make them occur more frequently and support all the major biomes. They'll contain Alenium Bombs which give the player a strategic resource reward (i.e. some Alenium) for completion so they don't become a chore in the same way that Terror Sites sometimes could.

The reason why I think this is interesting is because it ties in nicely with our new system to minimise map repetition. Why is this important? In the first Xenonauts, most of the battles were crash sites - so if you build your first base in a desert region of the world then you'll mostly be shooting down UFOs near that base and generating a lot of Desert crash site missions. The maps are picked randomly, so if there's five Desert maps available that support the first three UFO types, there's a decent chance you'll see a map repeat before you've even played five missions (even though the game had 100+ maps in it). Nothing kills the excitement in a combat mission faster than immedeiately recognising the map.

Our new system attacks this problem in multiple ways. Firstly, it tries to randomise the biome of a map if possible - each spot on the Geoscape can support up to two biomes, so if the mission occurs in a specific place on the map (i.e. a UFO crash site) then the game will pick the biome that has been encountered least often in the last ten maps. If the mission just spawns somewhere within a region (e.g. Raids) then the game will check all the biomes available within that region and spawn the mission in a spot that supports the biome that has occurred least frequently.

Once the biome is set, the game will then check a list of the last 100 missions you've played across all of your different campaigns. It will check the map "family" of all valid maps and try to pick one that you've not already seen, and then it will look inside the map family and try to pick a specific map you've not seen before. If you're unclear what a map "family" is, it's basically a group of linked maps - every unique map has its own family, but if we then create variants of that map (e.g. changing the spawn or UFO location, slightly changing the layout) then they will share the same family as the original map.

What this means is that every time you shoot down a UFO, the game will attempt to pick a biome you've not seen recently and will then search within that biome for any valid unique maps you've not seen before. If there aren't any available, the game will try to pick a variant of that map if one is available before it finally shows you a map you've seen before - and then then, there might be enough randomisation in the layout that you don't recognise it. The game will continue to track what maps you've seen even if you restart the game.

Raids work well within this system because they offer lots of additional variation. The map pool doesn't overlap with the crash sites, and contains more densely packed buildings that should give the mission a different feel to the UFO missions. Most importantly, though, they allow the game to place missions in biomes you're unlikely to see much of otherwise - e.g. if you've mostly been seeing Desert and Arid maps and the game generates a Raid in North America, it'll probably stick it up in a polar outpost up in Alaska or Northern Canada. If the game mixes in one Raid for every two or three Crash Sites then I think it'll have a big effect on how repetitive the game feels. Or at least I hope so!

Ground Tile Destruction:
Although the ground in Xenonauts 2 isn't destructible in the sense that you can't actually blow hole in the world and then fall through it, it also hasn't shown visible damage up until now. Explosive weapons used to place a decal on the ground to show their point of impact, but this never looked particularly convincing and didn't really bear any relation to the tile grid and the objects on it. Making the ground tiles visually react to damage inflicted on them makes weapons (particularly explosive weapons) feel meatier and more powerful.

We did some experimentation with 3d craters but anything that cuts into the ground looks kinda weird because units end up hovering above it, so we're just using a tile-based damage decal overlay system similar to what we had in the first game. It's not the most exciting feature ever, but honestly I'm happy to see it in because there we had some concerns it wouldn't be possible to implement the ground destruction without breaking batching on the ground tiles and thus causing massive performance issues (thankfully we found a way to do it that does not affect performance at all). Hopefully we can now use the same method to replace the blood effects with something that looks better, too.

New Ground Combat UFO Style:
The new UFO style that we've been showing off in recent months (a new set of UFOs using the X1 style) has finally made it into the ground combat, replacing the grey box style that we've been using up to this point. Implementing this has been challenging - the X1 system of hiding the hull when you see inside the UFO and instead showing the interior floorplan took a lot of time to get right back in X1 in 2D, and it proved even more complicated in 3D. But it's a good system and after a lot of trial and error we managed to iron the bugs out and now have the code side of things working as intended.

The game now contains 4 UFOs, which have been modelled up but are currently untextured white models. The reason for this is that we want to playtest the interior spaces of these UFOs before we do the final texturing - if we want to enlarge / shrink them or change their shape, it's much easier to do that before the texture work begins. I'm currently expecting there to be 8 crashable UFOs in the game so we'll be unveling the larger ones as the designs for them are completed.

Fog of War / Shroud Changes:
We've been working on some really low-level stuff to do with the shroud and fog of war. It's easy to take for granted how smoothly the system in X1 works (one of the things the game does well is show what tiles are visible and what are not), but there's quite a few little edge cases that cause trouble with this sort of stuff. In X2 we darken everything that was in the shroud to black and return it to colour when the player has vision on it, which works pretty well in most cases but has a few issues that need to be ironed out.

For example, if you have a tall tree sitting in the shroud directly below a group of tiles that you have vision on, you'll still be able to see the silhouette of a tree jutting into the playable area. This happens often enough that it gives the edge of the shroud an irregular and "cluttered" feel. So we've had to implement a system that actually entirely hides the models on any tile that isn't visible to the player. This stops objects you can't see from interfering with the playable area - but because we're now in 3D, there was knock-on effects. Those objects cast shadows, should the shadow of that tree be visible if it falls onto a tile even if the tree itself isn't visible? Or should the shadow only pop into existence when the model itself is seen? 

Anyway, there's still a few shroud / line of sight artifacts that we ideally need to fix up, but hopefully you'll notice that the vision feels a bit cleaner next time you play.

Summary:
I'm just going to wrap things up with a very quick summary, as this is a really long post already. In terms of 2D art things have been pretty slow this month; we got the final artwork for the new Phantom interceptor done but a couple of our important artists have been busy so not much else happened beyond some work on the end-game exosuit armour and some progress on the Fighter UFO design. A different artist we had high hopes for also seems to have disappeared from the face of the Earth too, which is frustrating because it means we've wasted some time and money there - but that sort of thing happens from time to time in game development.

The timing of the next build is dependent on how well the level design work goes more than anything else, so I'm going to keep working at that and then see where we are in a couple of weeks (it's taking me roughly one week per biome at the moment so I'd hope to have five of the biomes done by then). Sorry everything's been a bit quiet here and there's not been a build recently, but hopefully now you guys understand why!

 

[Alienkiller]

The new Update sounds good with the Rework / Refits of the Maps, Lightnings and such. More interesting is the Fact that Goldhawk has found an external Studio which helps with the Maps, Bioms etc.

I personaly thought that the overwork from Beta 13 to Beta 14 will take longer then normal, esp. with the Map-, UFO-, Transporter- and Destruction- / Blood-Refits as well as the Overworks for Bases, Special-Missions and Equipments. Without the Help I calculated 6 Month, with the Help it will be reduced to about 2,5 or 3 Month. And they did much in the Time from the last Hotfixversion 13.3 in Mid June up to now the last Week in August.

And the other small / big Bugs we have found in the last 4 or 5 Betas get fixed in that new Version too or will be automatically fixed then with the Refits / Reworks.

I think we Betas will get work back in Mid September or beginning End in September. In that Time UFO2ET will come out after so many delays, so that we have an comparission.

 

 

[odizzido]

Shadows of trees should still be visible even if the tree isn't. It would give more information to people who are observant and also make more real world sense.

 

Thanks for the update as always

[Alienkiller]

@odizzido: Fully agree with you, that’s a must have for the Ground Maps. Shadows of Houses, Walls, Trees like it is now.