HWP

Let's hope it's not anything in works so far, if we want to see Xeno by 2015.

I was thinking along the lines of curing civilians. It runs the risk of turning an overpowered enough squad into essentially a medical team, which likely runs contrary to the vision for these missions. Perhaps. Replacing essentially infinite damage with a % risk of infection for every attack that deals damage is, on the other hand, a relatively very simple change.

I'm usually all for difficulty, but there are some issues with introducing mechanics that ignore other mechanics. For one, if Reapers ignore armor, one of the best armors against them is naked. Is that really the idea - that it makes sense to be naked around them? "X disregards all your defensive mechanics" should be a last resort measure; balancing is about making mechanics outweigh one another, not go over all others' heads. I think a better way to add challenge would be to make Reaper infections probabilistic and occasionally not easily detectable. E.g. have some civilians turn into walking zombies, others turn into a corpse harboring a Reaper, others still just get infected and hatch with no prior signs. If the idea is that Reapers can not be "tanked", using MMO jargon, - then you can give non-lethal Reaper attacks on a Xenonaut a moderate chance to cause an infection. Said infection would then have random chances on each following turn to 1) zombify them or 2) hatch a new reaper outright, or 3) "mind-control" the Xenonaut and in a couple turns or upon death spawn a reaper. This way you can't safely stand there and have your armor take it all, but it doesn't promote battle nudity either. The difficulty of detecting infections would make Reapers more challenging without requiring magic-like mechanics. More fearsome, too, since unknowns are the worst. "Egg extraction kit" would be too gimmicky, but allowing a medical scanner to detect infections (with no chance of treatment) is probably fair enough. Taking control away from the player upon detection, e.g. via panic, to prevent exploiting this for a safe suicide.

It's not a hard choice at all. You just assign a couple recruits to be pack mules and load them up with equipment you don't plan for them to ever use and have them sit in the dropship. I'll respond with the same criticism that has been thrown at new XCOM time and time again. "Fake difficulty. Fake choices." It's one thing to live with the choice of using a valuable soldier and possibly getting him killed. It's another to deal with artificial and contrived choices for the sake of choices. "You can take grenades or medkits. No, you can't take grenades and medkits and only a pistol. No, you can't take just grenades and medkits. What will it be, grenades or medkits?"

Correct. That's why you shouldn't bother about the cost of bottom tier ballistics - all the guns and ammo your squad will ever use will cost less than one fighter missile. I would kinda like the idea of managing even that cost if the game was laid out differently. Let's say you were to start out poor (rather than with 50 million already invested) and wouldn't even have fighters at first, responding to the aliens already landed, like in Xcom Bureau. That's mod territory, just that the option needs to remain there. There are two groups of players waiting for this game. 1) Give us X-Com! 2) Give us a sim! The second group is people who might have played Operation Flashpoint and found it not realistic enough. Aliens or no aliens, you can handle even the most preposterous scenario with believable means. This group will find a way to balance even a proper simulation. And this is where magic comes in. Or, more precisely, Alenium. Alenium is a non-monetary cost. However much money you have, you can't make it, and that's the resource you had to manage in X-Com or in this game. Since no one knows how much of it exactly what takes, we can safely make the expense far more comparable, like 1 unit for a clip, 3 for a missile, 9 for an AtA missile, etc.

If I may digress for a moment - skip way down if you like. In a perfect world, "Sunlit window white", "Nuclear flash white" and "Office spreadsheet white" would've been three completely different colors. In a perfect world, everyone would use Lab color space where L is a floating point value from 0 to millions, and displays would then represent it to the best of their ability. Our world's not perfect and computer graphics have suffered from working in two modes, 1) being what they are, active light sources, and 2) pretending to be sheets of paper. For an active light source, 0 represents perfect darkness and max value (e.g. 255) represents maximum possible brightness. For a sheet of paper, you range between max (255) for no ink and 0 for ink. In a perfect world absolute scale, these are completely differen. Maximum human tolerable brightness is about 40,000 cd/m^2, professional video editing displays have a brightness of 2,000-8,000 cd/m^2, consumer TVs top out at 500-1,500 cd/m^2 and a blank sheet of paper in an office is 75-125 cd/m^2. With early CRTs the display wouldn't pull more than 100-150 cd/m^2, which was close enough to paper, and all in all it was easy to conflate the two: 0-255 for display brightness and 255-0 for the amount of ink to put on paper. It broke with later CRTs that were much brighter, and most of them had at least two modes, one for representing a light source and another for representing a reflective surface, i.e. pretending to be either a window to the real world or a sheet of paper. Same with LCD. Thus the two modes were allowed to persist well past the point where it should've been fixed; instead, we keep switching our displays between text and game/movie/graphics modes. It works to a point, as long as the two are always separated in time and never mix on one screen. Now back to the point. Xenonauts breaks this convention. It mixes two display modes, "reality" and "paper", on the same screen. It's not the only game to do so and it's not the worst offender (Last Light holds that cup), but it's enough for people to notice. These modes can be mixed, but then one has to account for sunlight white and paper white not being the same color. It's especially noticeable with the game having a pretty dark gamma. For instance, here the "paper" whitepoint is clearly much higher than the background whitepoint, even being brighter than the ceiling lamps. What I see that can be done about it: * Ensure that all backgrounds have a full brightness range (0-255). * Pick a "paper" whitepoint that's well darker than the background whitepoint. Perhaps also warmer, or, even better, matching the background. * Possibly use a light texture and/or minor gradient for the "paper" areas to allow for a little less average luminance for the same whitepoint. * Possibly add minor darkening gradient around intended-white elements to keep high perceived brightness with less eyestrain. We evaluate what is white/light/dark based on surrounding colors, so a darker whitepoint can look bright enough as long as the image makes a good impression of it not being particularly well-lit. For instance, the OLED panel on this page looks far brighter than the page background, even though print-screen will show it's the exact same color. In contrast, on this image the UI looks grayish despite being much darker than a sheet of paper would be in the depicted room. To avoid that, the brightest points of "paper" elements only need to look at most as bright as a sheet of paper. That's much darker than now, but the UI can actually avoid looking gray if it matches the ambient lighting on the background image and particularly if it cuts, by a lot, the brightness of these few small white areas that are now very close to 255. These areas represent the whitepoint and making it much darker can help the rest of the element look brighter.

In real life, an air-to-air missile will cost as much as $500,000-$1,000,000. It's not something trivial. To put it in perspective, a maxed out fighter's loadout will cost as much as a M1 (not upgraded) or T-90S tank, or as much as 3,000-9,000 assault rifles. You wouldn't save up your missiles in actual combat, but they aren't "too cheap to meter". If your money was as tight as in Xeno, it wouldn't even constitute micromanagement. I get it if the game is intended to be simpler, though I hope a limited stores mod is possible. Ballistics should indeed be too cheap to meter, but not higher tiers and not fighter weapons.

That's what always been my reason for asking for a darker UI. I have a big display with high max brightness, which 99% of the time is a good thing. But if most of the game is dark enough and the UI is very bright, going into the UI, for any reason, becomes a dreaded blinding flash that not just causes almost painful discomfort, but sometimes makes it impossible to play for a minute or two. I have to reach for display controls, switch it to low brightness, do what I need in the menu, then switch the display back to game mode again. Xenonauts is probably not a game to dim the lights for, but still, guess I'll have to go around darkening the white areas to make it reasonably playable without reaching for display controls. I know, my problems... still, while the impact is reduced on a dimmer and smaller screen, it has to be there in some form. Hey, here's an idea: What about a separate "Menu brightness" control (or just an ini setting)? Has to be brightness rather than gamma to affect the white point, and it doesn't address the aesthetic concerns, but shouldn't be too hard to do.

Activation mechanic just kills this game. I've been part of the modding community that tried to optimize the game, balance it, make it better, then buried its head in bytecode decompilers looking for a way to disable it, to no avail. You can't balance the game with this mechanic. Any reasonable difficulty increases are easily bypassed by exploiting alien activation. Any extreme increases require exploiting alien activation to win, sucking all the fun out. All you can do with it is make a fun, quick, easy squad tactics shooter in third person. I can't help but laugh at all the super-marathon mods and other efforts to prolong the game and make it more hardcore, including my own. They just don't work. Because of the lack of a strategic layer and because of this mechanic. You say you found a way to disable it? You should come to Nexus with that: http://forums.nexusmods.com/index.php?/forum/559-xcom-mod-talk/ Please do so. We have plenty of skilled coders in that community that could make it available to the public. Alternately, it may turn out that you didn't actually disable the mechanic itself, only parts of it, but at least we'll know that, which is better. Toolboks does disable parts of the mechanic, removing activation animation and special moves, but not the whole mechanic. Either way, do tell, you may have made the breakthrough the EU modding community has been struggling for for over a year.

Considering everything that's been said, I think a simple three-step solution could do the job. 1. Calculate hit chance as required by balance considerations. 2. Using bell curve distribution, plot rays out from the tile, corresponding to scatter angle. 3. For each ray, make a weighed distribution of hit probability for each tile on its way. Tile weight can depend on: - distance: lower weight for close tiles, higher for distant - solidity: does the tile contain an obstacle, low weight if not (floors) - solidity accumulator: each obstacle on the ray's way adds to it - coordination: for friendlies tile weight is decreased. I think the last one, coordination, is pretty important. It can be a value based on difficulty and soldier's mental state. For the intended target weight is set at 0, since it's determined in a separate hit chance calculation. Now with this weighed distribution you know each tile's chance to be hit in advance. It can be a good mechanic to display friendly fire chance for each target (like it's done in AoW), at least at lower difficulties. Then just roll the RNG and display the outcome it picks.

By "maxed out" in that context I merely meant as well trained and equipped as possible by that point in the game. All right. Let's change the assumptions. Now work under the premise that the game is balanced such that it is only just possible to complete using two highly trained squads. So what happens when you lose one of them? I don't object to TSL in combat, it's fair. Only to TSL happening this way. 1994's UD was a buggy game, we all knew it, it was forgiven because, well, old and classic. Yes. Like I said above, losing a base housing a decent squad will only happen if that squad is out on a mission. So it's not a super-rare event. Every major base loss is going to be like that; if the squad is home, you won't lose it. A potentially far easier to implement solution I proposed is to disable a defeated base, rather than delete it. The only function the base will retain is transfer. After N days delete it altogether.

Hopefully it will be balanced so that you don't get enough squad experience to max out a squad over the course of the game. Level caps in single player are hated universally and deservingly. Actually, the maximum difficulty should be balanced such that only the best 1/10-1/4 of players can complete the game at all, and not at first attempt, and only if they follow the best possible strategy. Given what your nickname is, have you completed Unreal Tournament (any chapter) on "Godlike" difficulty? If yes, you know what I'm talking about WRT proper balancing. If no, well, it's never too late. It's still suboptimal. Keeping backups "just in case" goes against the doctrine of min-maxing. The doctrine is to maximize your performance in the most important aspects for the most likely scenario. The most likely scenario is that you'll never have a TSL. And see above about balancing. Put simple, if the game can be completed on maximum difficulty after a TSL event, all it means is that difficulty needs to be increased. Max difficulty should be borderline doable *without* handicaps. That's why it's called "maximum", not "only". Where is the fun in losing your main squad without firing a single, just looking for them and realizing they've been deleted because that was easier to code? If you can bring them together on one mission, like the 26 in Avenger, then yes. Otherwise you won't be able to complete endgame content that is balanced to be only-just-doable with a perfectly concentrated squad.

Because Xenonauts is a race against time; there's no playing for years on end. (and no 8-bit unsigned rollover) Certainly. But you are going to lose that reserve as well in a base loss event. Unless you keep at micromanagement sending them away to other bases and back. If the maximum difficulty is possible to finish using suboptimal strategy or especially still possible to finish after losing both the main base and main squad, then either: 1) such an event should be very common (so that everyone has to plan for it), or 2) the game isn't correctly balanced (excessive headroom left at maximum difficulty). It's the min-max strategy. Min soldiers you don't plan to keep, max ones you do. It's a universal strategy for this game genre. Unless something is done to make it different.

Just two bases? Well, the full game isn't out yet. Presumably if all is done right, endgame craft range will cover the whole globe, and endgame content will be hard enough to be only-just-doable with a maxed squad. If loss of your good squad is surmountable, it only means it never needed to be that strong in the first place. I.e. that you had a significant difficulty headroom and probably could be doing the game at one difficulty higher. Because in alpha players are essentially stuck in midgame. Later in the game, in X-COM at least, you get more bases, but focus on one key squad that's getting increasingly less replaceable.

I suggest Magic. We can think of many ways, but only one that makes sense. Seriously speaking, this is a fault or shortcut rather than a design solution, so the correct player response is to, if attacked while crew is sent out, exit to main menu and load latest save. If you want to play completely fair, move crew to a backup base in advance. This may incur loss of some game elements. But losing your main squad past early stages is game over. Escape, Main Menu, Start New Game. Losing your main base isn't. Balancing the game such that main squad loss != game over would make it impractically easy when TSL doesn't occur. Such an occurrence does not require a coincidence. The only way you would lose a base defense mission in the first place is when your main squad is out on a mission. Yes, UFO worked the same way, but it didn't have ironman mode, so that. TSL in combat is a fair way to lose the game, TSL due to the technical implementation of object trees isn't.

I suppose the workaround is just to keep regular autosaves and keep the ironman checkbox clear.

Suggestion. Instead of deleting the base, what about disabling it? Gray everything out except transfer. Delete all objects except those explicitly allowed to be transferred. That would be soldiers on missions, aircraft, possibly personnel. Display a tutorial message about how the player has X days to move their surviving objects to any other base. After X days, delete the base. It may not happen a lot, but it will happen. The painful occurrence is when you have your good crew sent out on a mission and the base is attacked while they are there. Lacking reasonable defenders, the base will be destroyed. Losing crew that wasn't even on the base. I can guarantee that players will be cursing when it happens, and they won't be cursing themselves or the aliens or even their luck.

Not really. If you've played it and weren't impressed - it's just not going to work for you. PS:T is a lot more a piece of art than a game, but, unlike titles like Dreamfall and Heavy Rain, it's art built on the framework of a game, offering a breadth of freedom, not a movie interspersed with game elements. I doubt the new game can match it. You don't just make art, it's not enough even to be the right person, you have to be in the right state of mind, and it's been 15 years, they aren't even the same people anymore. But who knows? For one, PS:T did have quite a few flaws, like the mob grind in early stages, unnecessary and distracting.

Separate rooms would be useful. Scientists work days, troops work watches, don't want them to wake each other up. But I seriously just don't see why they should necessarily be different. How exactly do you propose the living arrangements should differ between spec ops soldiers and engineering staff?

And that's exactly why they are treated as nameless drones bought and sold in bulk.

And other staff doesn't need more than just beds - they don't shower, feed from a 120V outlet, spend their off-watch standing motionless? To the extent that your organization is military (or not), everyone in it is equally so. Most servicemen in real-life militaries don't run around with rifles and helmets, they work in what you can call operations, management, data processing, logistics, R&D. Perhaps frontline troops (i.e. your soldiers) would need extra training space, but you can't do much more than basic PT in a small underground base. And it doesn't take a special building, it takes clearing out a wardroom. Use 2 quarters slots for soldiers instead of one, problem solved. Or you could add a training center, but since training is out of the game, that won't make sense. This applies even to vessels purpose-built to be operated by a mix of military and civilian crew and staff. Naval living quarters (and an underground base, being space-constrained, has to follow navy's example) are really simple, corridors with bed bunks, there's not much to differentiate.

I remember working with the language system in EU 2012. It was rather horrible. Let me just give an example... Technical game text files use Unicode UTF-16 just so they can show a few foreign version voices (which have nothing to do with the INT version!) with diacritic marks. At the same time, soldier names and nicknames all use ASCII, and as such are shown incorrectly and can't even be set right. Without a few changes that is. Please, if you have a choice, use UTF-8 encoding for all text files. It's not going to screw up when edited in 99% of text editors, it's not going to screw up OS versions set for different locales, and it's going to provide the option for easy translation into any language. UTF-16 is a splitting headache, code pages are stone tablets. I'm pretty sure that community-translation would be the option to go for here. Professional localization can get expensive, and it's only really needed if you are selling boxed versions with an official release date. For fairness' sake perhaps give out some rewards (along the lines of Kickstarter tiers) to the people who successfully do it, then post links to their sites and stable versions for upload on the web. Plurals can be difficult though. It may not be reasonably possible to do them right for every language. Separate entries for singular and plural are a given, but more is hardly doable. Best option is probably to try and use plurals with variables in nominative case only. For instance, "Medkits: 32" rather than "32 medkits".

It's not them, it's a game genre. About the most popular game genre the last few years is called Cover Shooter. It's a relatively new genre, started with GoW. The gameplay of cover shooters is, unlike older ones where cover would be impromptu (like in X-Com example), based on preset cover points. Cover in this genre tends to be unrealistically effective, even if it's just a rotting piece of plywood protecting you from tank cannon fire. It's always predefined, it always helps, you can always shoot from behind it, these are genre specific elements, not just common sense. Cover Shooter in its pure form is a series of Shooting Range events on a stepped linear progression from one cover to the next. Using this system is an explicit and exact statement, and it accurately describes what EU12 uses.

Not sure if there is any reason. The military employs plenty of both, some as officers, some outright as civilians. The only special arrangements made (on vessels in particular) are normally simply not sharing the exact same bunk racks. Both are human, why would one need different quarters than the other. More to the point, consider that in gameplay terms it would mean the quarters for one can't ever house the other, and that's just wrong. Not quite. As it is, your research *already* happens simultaneously in Brazil and Tibet, so it doesn't matter where the scientists are. The only change a common pool brings is you don't have to micromanage them on every base, just assign them globally. The availability of living+lab slots limiting you automatically. Considering that simplification is coming either way, this is a lot better than sleeping on autopsy tables and conveyor belts or having magical built-in quarters that can only ever house people of a specific profession and never anyone else.

The above suggestion really sounds overthought. How about keeping it simpler? Soldiers are assigned to each base and transportable as usual. Scientists and engineers each form a common pool across all bases. On any base, only as many sci+eng can work simultaneously as its living space minus the number of soldiers. Scientist assignment is common between bases like projects are, auto-filling available space. Gets rid of a lot of staff micromanagement while keeping this important consideration for base design.