The Ninex server hosts projects related to X-COM, including UFO: Alien Invasion, UFO: The Two Sides and our very own OpenXcom. Server and bandwidth isn

For all the contributors out there, a new library will be added to OpenXcom’s dependencies soon (yes I know how much you love those!). yaml-cpp will be supporting all data externalization (yes I know how much you love XML!), so you’ll have to figure out how to get it installed on your respective platform.

For Windows users, the folder structure is also changing: Dependencies will now be split in deps\include\SDL, deps\include\yaml-cpp and deps\lib folders. Check the updated Compiling instructions for more info.

You might’ve noticed there hasn’t been a lot of actual development news from me lately. Sorry about that, I’ve been busy with university junk so I haven’t been able to devote as much time as I wanted to this. Specially since 0.2 isn’t very gameplay-oriented so I wanted to get it over with quickly. But it just wasn’t meant to be!

One of the advantages of X-Com is that it’s extraordinarily localizable. Aside from the limited font, every language is stored in an external file, so to change languages you just have to change files and you can easily replace one string with another, since every single text string is contained in those files. Well, all except…

You might’ve noticed how the Geoscape buttons are slightly different from every other button. How the button text looks different from the default font. This is not a coincidence. In fact, the Geoscape button text is hardcoded into the sidebar graphic, so different languages have to change that graphic outright. Of course I have control over the game now, so changing the buttons to use the default font would look something like this:

So what do any prospective translators think? Would you rather keep the original Geoscape look and be forced to edit the graphic yourself to translate into your language? Or would you be fine with the default font so you’d just have to edit text strings as you’re supposed to?

One of my goals for 0.2 was to take some time to clean up and improve the codebase, get rid of all that sloppy mess that I’ve been leaving behind. Refactoring, optimizing, getting rid of copy-pasting, etc. You know, the kind of things boring nerdy programmers care about.

Which is all good, but as I’ve realized, it’s also a very dangerous trap. It requires a lot of restraint, because once you start cleaning up code, you never stop. There’s always something that can be improved. Something that could be done slightly better. You’ll get stuck in an endless loop always trying to think up of better ways to do everything, because it’s never perfect. Who knows how many more precious frames you could gain! Then it becomes contagious and all the other programmer contributors start chiming in on all the wonderful new ways you could be doing things. Before you know it you’re ignoring gameplay bugs for programming issues, completely lose track of your goal and only put out a new version years later with no visible changes. And guess what?

Nobody gives a shit!

This is a game! The whole point is to give people things to play! I shouldn’t forget that! So starting now I’m gonna stop wasting time and losing sleep over clean code and going back to implementing actual features. The reason I’m posting this publicly is not only to remind myself of this fact, but to everyone else involved in the project or other similar projects that tend to fall into this trap without noticing. Hope you find it helpful.

So 0.2 development has been kinda slow, what with being busy with real-life stuff, and it’s a lot more gritty-nitty coding than some exciting new feature. Can’t talk for Daiky, naturally. 😛

Anyways, one of the biggest debates that goes around is how open will OpenXcom actually be? I mean, technically, it’s open-source, so anyone could already immediately start developing their own wacky versions with their own wacky changes and patches and graphics and options and…

Haha yeah right, like anyone ever does that. Plus that’s a terrible approach. The goal of OpenXcom isn’t to just leave people to fend for themselves whenever they want a feature, having to rely on various fragile third-party patches or thousands of options. It’s really unfriendly and a maintenance nightmare. This is all about the player!

For one thing, OpenXcom will try to improve the original as much as it can without jeopardizing its “purity”. This kind of stuff will probably only be implemented later on, when the game is more feature-complete. But you can expect the kind of features you’ve always wanted or gotten from fan-patches like XcomUtil or Enemy Unknown Extended. Stuff like pre-battle equipping, right-click doors, item stacking, interception groups, keyboard shortcuts, auto-sell manufacture, customizable base layout, etc. Anything that’ll improve the experience will be supported right out of the box. Anything that might be too big a change to gameplay (eg. enhanced interception logic, alien AI, etc.) will probably be left as an option. You don’t need to worry about what’s different, you’ll always get to play the game the way you want.

Another thing that’s being worked on for 0.2, is rulesets. This will provide more direct game moddability without having to touch the code, but it also won’t be anything big like custom game logic or scripting or whatever. The thinking goes like this:

There’s stuff that X-Com always has in common and which is always different. For example, UFO and TFTD contain completely stuff but they still both work and play exactly like X-Com. They just change stuff like crafts, weapons, aliens, base facilities, maps, etc. What makes them different? For example, every craft handles equally, so what separates a craft from another?

Looking at the UFOpaedia you can easily see this kind of stuff has stats. Maximum Speed, Acceleration, etc. This is the kind of stuff that makes game elements what they are. A whole bunch of boring hard-coded values defining and balancing stuff. But wait, why should they be hard-coded? Why couldn’t you just define a craft like:

<craft id="SKYRANGER">
   <speed>760</speed>
   <acceleration>2</acceleration>
   <fuel>1500</fuel>
   ...
</craft>

That way you could have your game however you want! Purist original UFO, or some improvements like better tanks and laser weapons (ala XcomUtil), or even completely new weapons, aliens and more! All just by editing a bunch of numbers.

And that’s exactly what rulesets will let you do. Mod to your heart’s content while never breaking the original X-Com feel.

Time to get some more controversial debate going on here!

As every X-Com veteran knows, when a craft returns to base, it always goes through the maintenance cycle: Repairing -> Refueling -> Rearming. While a craft can start at any step (eg. an undamaged craft will skip Repairing), it’ll always goes through the remaining steps, even if they’re not necessary. So for example, any craft that goes on a little trip will always have to Refuel and Rearm when returned to base, even if no ammo was spent or the craft doesn’t even have any weapons.

This has sparked some debate on whether this is correct or not. A lot of people just consider the “Rearming” step a necessary evil, like a final “maintenance” step (fix the paint, warm the engines, etc.) a craft always needs to go through before it’s ready to take off again . Others think it’s a bug that just wastes time and don’t want to have anything to do with it.

So what do you think? Should the original logic be preserved? Or should it be considered an unfixed bug and crafts should skip Rearming if they can? And don’t just say “make it an option” or I’ll just make it twice as annoying. 😛

Apparently nothing gets comments going like boring programming stuff. 😛 Anyways, the exciting conclusion!

You were all wrong. I was wrong. Well, half-wrong After all, the buggy code did rise from the grave and came back to haunt me one month later! Just in time for Halloween.

The _speed variable in question was inherited from MovingTarget. Which would’ve been fine, except there was a leftover _speed variable in Craft too. Uninitialized too, naturally. Just hiding there, no warnings, no anything, just happily confusing me and the compiler. Ain’t programming wonderful? A learning experience every day.