What the hell is a ruleset anyways?

As a lot of you might have heard, I’ve been working on these mythical things called the rulesets again, but nobody actually seems to have a clear idea of what they’re for. So time for some history.

When I first started OpenXcom, one of the issues I ran into was how to structure all that valuable game logic. Should I just write it all up? Extract it from GEOSCAPE.EXE? Hardcode it in? Load it dynamically? All of it looking like a lot of work.

Then I thought of how the community loves tweaking. Things like XcomUtil and Ufo Extender are really popular by just letting you tweak little things like changing the starting base layout, giving Skyrangers a weapon pod, making Laser weapons more useful, etc. And there’s all those “game modes” people come up with to change things up. It’d be great if I could accomodate all of that easily. So I came up with rulesets.

OpenXcom uses rulesets to define all the game elements. There is a base UFO Ruleset that defines all the countries, crafts, weapons, base facilities, items, aliens, armors, UFOs, etc, etc. Something like this:


---
countries:
- type: STR_AUSTRALIA
fundingMin: 280
fundingMax: 560
labelLon: 2.35619
labelLat: 0.436332
- type: STR_BRAZIL
fundingMin: 300
fundingMax: 600
labelLon: 5.32325
labelLat: 0.0872665
- ...
facilities:
- type: STR_GENERAL_STORES
spriteShape: 1
spriteFacility: 24
lift: false
hyper: false
mind: false
grav: false
size: 1
buildCost: 150000
buildTime: 10
monthlyCost: 5000
storage: 50
- ...
crafts:
- type: STR_SKYRANGER
sprite: 0
fuelMax: 1500
damageMax: 150
speedMax: 760
accel: 2
weapons: 0
soldiers: 14
hwps: 3
cost: 500000
repair: 1
refuel: 50
range: 600
time: 72
score: 200
- ...
...

 

So if you want to tweak something, you just edit it and modify a value or two. But boy, that’d become a real pain to maintain, having to make your own versions of that big old file just to tweak a value or two. So I decided to make them modular, so that you can combine various rulesets as you please, and they only need to have the things that change. So if you wanted to make a super Interceptor that could detect everything and fly really fast, you’d just need this:

---
crafts:
- type: STR_INTERCEPTOR
speedMax: 99999
range: 99999

 

Or a Super Stingray launcher that would fire a million missiles a second:

---
craftWeapons:
- type: STR_STINGRAY
reloadCautious: 1
reloadStandard: 1
reloadAggressive: 1

 

Or a Super Pistol that would nuke the whole map:

---
items:
- type: STR_PISTOL_CLIP
power: 999999
damageType: DT_HE

 

And if you combined it all, you’d get something like this:

6 Replies

Public Service Announcement

Ok, I get that you’re all anxious to see the project develop, can’t wait to be able to play everything and wanna help as much as you can. I appreciate that. But now with 8 pull requests pending, some even conflicting with one another, let’s get some things straightened out. Here’s the easiest way you can help the project:

TEST THE GAME. Really, we spend so much time developing that we don’t have time to double-check everything and make sure nothing is broken. We put out builds not just to show we’re making progress but so people can play with them and give us feedback to make sure we’re going in the right direction, but we often don’t get much more than “oh wow”s and bugs slip through. One of our goals is to be as bug-free as possible and we can’t guarantee that without your help.

But you still really really really really wanna program something. Ok, here’s some tips on how to do that while still being helpful:

  • Please try to follow the coding guidelines and overall structure of the project. I know you all have your own flaming reasons why this style is better than that style and will defend it to the death, but it’s essential that the code stays clean and consistent. I know players only care about stuff working, but if I just accept everything as is, the code can snowball into an ugly mess that nobody feels like maintaining anymore and hinder development, so I review everything that is contributed to ensure this. Feel free to post any questions you have about the code structure and how to best integrate your stuff to avoid delays later.
  • Find something useful that nobody else seems to be paying attention to or can figure out. Bug fixes, improvements, optimizations, etc. Things that are easy to review and merge without worrying about the whole impact in the project are the best. Special thanks if it’s something that’s been frustrating us for weeks and you found the perfect solution.
  • Don’t try to work on stuff we’re already working on, specially very large stuff at once, this is very disruptive. Being surprised by a sudden huge contribution is not fun if it just makes all our effort useless, so you might think you’re speeding up the process, but it’s impossible to guess where we’re going with a feature just from looking over partially-implemented code and you’ll just take it in a completely different direction. Then we either have to scrap all our work, all your work or do our best to try to mish-mash and integrate it all coherently, either way it’s a lot of effort wasted. When in doubt, post in the forums first to make sure you’re actually being helpful.
  • Finally, OpenXcom can’t please all the people all the time. Maybe you have some crazy ideas that don’t really fit the scope of the project so we can’t accept your contribution, but don’t let that stop you! This is open-source, anyone can take it wherever they please, it doesn’t all have to be part of the main OpenXcom. You can just keep developing it separately on your own end, maybe other people like your crazy ideas and wanna see more. Some think everyone keeping their own patches / branches / versions / whatever is an ugly mess, but I think it’s a better approach than trying to turn OpenXcom into this massive bloaty all-encompassing solution for everyone’s wishes with a million else-if’s. We will be incorporating options and moddability into the main project, but only so far.

I don’t mean to sound like a hard-ass, I really do appreciate our community and how helpful you guys try to be, but it can only go so far. Right now I’m working on rulesets and started getting a lot of ruleset contributions, often conflicting with one another, and I just had to stop it before it became a mess. First and foremost, be patient and let us do our job, we’re not going anywhere. 🙂

1 Reply

Don’t panic, be safe.

When everything goes wrong …

 

… you better hope you saved your game.

In other words: panicking and berserking soldiers are implemented, but to compensate for that battlescape savegames -finally- have been implemented too.

Since our savegames are not just binary memory dumps like in the old times, they are readable yaml text files, you’ll have the whole battlescape terrain – tile by tile – nicely described for you to edit and play with.
So you can also clone your own aliens, using copy-paste 😉

Leave a reply

Full life consequences

I hope you’ve all been having fun playing around with the Battlescape without a care in a world… because that’s not gonna happen in the next version! What you do in the Battlescape will actually affect the game. To highlight that, we’ve implemented one of your favorite screens which I’m sure you will see a lot:

[17/09/2011] Debriefing screen

Also, the pre-built Windows dependencies have been updated with the new yaml-cpp 0.2.7. And these ones actually work! Not like the last ones that pretended to work but didn’t really because apparently I’m terrible at building libraries… let this be a lesson to you, renaming a file can be more dangerous than it looks.

2 Replies