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.
yummy 🙂
A ruleset conflict handler of some sort might come in handy at some point though. Would be a shame if my BramCraftMod somehow had too much in common with the SupSuperTroopCarrier for the game to handle, however unlikely 😛
Sounds exciting though!
Nothing to do with rulesets, but an improvement over the original that I really hope you’ll include is a 2xSAI scaler or something like it. The low resolution of Xcom graphics is kinda hard to bear by now. Finding a mature code example shouldn’t be too hard since multiple emulators such as dosbox, snes, kega, feature several scalers.
Ideally you’d just delegate the scaling to a plugin so several alternative ones can crop up.
On topic: everyone seems to pick xml by default for their data files, but it’s too verbose and annoying to edit. So unless you need DTD validation and XSL transforms, might I suggest YAML as a modder-friendly data language? See yaml dot org, and the yaml-cpp parser on google code.