mossfoot wrote:Question: How do you guys decided what becomes part of the "Core" game in terms of upgrades (graphics, features, etc) and what is OXP?
Very carefully ...
So, this is just the sort of things I think about for these decisions - the other devs have their own approaches.
I think there are essentially two semi-contradictory factors here, in that:
- Oolite is as popular as it is and as good as it is in large part because of the community and the OXPs developed by the community. Being a game which people can easily expand and modify is a key aspect of the project.
- Oolite is a game, not a generic engine for making space games. It needs to be a really good game in its own right even without any OXPs installed - especially since I think there's perhaps only one OXP which the community might unanimously recommend installing.
So for any particular feature there are (not in any particular order) these factors I personally consider. The other devs of course have their own views:
- Feel of the game. We're going for a particular style of space trading / combat game here.
- Difficulty of the game.
- Hardware requirements. Currently we're really not requiring very much hardware at all, and with the Pandora port that's likely to stay true for a while. Shaders have to be optional for gameplay, and the entity count for a system should be relatively small.
- OXP compatibility. APIs have to stay consistent between stable releases if at all possible. We try to avoid having core changes significantly change OXP behaviour even with the same API too, though 1.80 is stretching that a bit.
- OXP flexibility: how much customisation should a feature have to let OXPs rewrite the game in that area? Does the core game need to set a default at all, or can it be entirely up to OXPs?
- Canonicity: lots of details about where and when the game is set are deliberately vague and get specified in different ways by OXPs, fiction, and so on.
- Time: trying to have reasonably frequent and mostly bug-free releases limits how many extra features can go into each release. It's often much easier to say "Here, have a couple of extra JS properties and give it a go" than it is to build the feature properly into the core. OXPs can also have a much more rapid release cycle for testing and prototyping.
Maybe if I give an example: there's a comment in the code dating back to March 2008 that says
Code: Select all
// FIXME: give NPCs shields instead.
There are a couple of OXPs - [wiki]NPC-shields_OXP[/wiki] and [wiki]CustomShields[/wiki] - which give NPCs shields anyway. We could do that kind of thing in the core game relatively easily. However...
- Difficulty of the game: just giving all NPCs essentially an extra 256 points of damage is quite significant. Various things would need to be rebalanced.
- Feel of the game: NPCs should use their shields reasonably sensibly, like the player does - turning to take hits on the stronger shield.
- Feel of the game / hardware requirement: We need a good "hit on shield" visual which gives the player an idea of what they're up against, without requiring shaders.
- OXP compatibility: lots of ships and fights - especially in mission OXPs - will have been balanced with particular ship toughness.
- Difficulty of the game: the player takes equipment and cargo damage if hit without shields. That needs to be applied to NPCs too - which can help counterbalance the difficulty increase by making them more likely to run as soon as their shields go. But what does it mean in-game if an NPC has their Scanner Targeting Enhancement damaged? Lots of equipment does absolutely nothing for NPCs at the moment but is important for the player beyond being ablative armour.
- Feel / difficulty of the game: okay, so we give NPCs equipment so it can be damaged in a fight to encourage them to flee (and maybe not come back, since they're now limping back to the station for repairs). How much equipment is appropriate to give a particular NPC in a particular context?
- Hardware requirement: all of this has to be done very efficiently so that older hardware copes with the extra AI calculations.
- Time: that's now looking like a really big project. Can it be fitted into a single release cycle, or will some preparation need to be done ahead of that? Who is going to work on it? Is constructing and testing it going to interfere with developing other planned features for this version?
So for now, at least, that's an OXP feature.
Another more modern example - Oolite 1.80 adds a lot of scope for extra NPC comms. The core has virtually no NPC comms included, though - just a few messages considered crucial to gameplay - but I did separately write a comms pack OXP. I think that OXP is both too small (with only two personalities per role you hear repeats pretty often, which isn't great - you'd probably need to install four or five such packs for ideal behaviour) and too large (the descriptions.plist for it is already almost as large as the descriptions.plist for all of Oolite) to include in the core game, which is why I did it as an OXP.
As I said "very carefully".
![[EliteWiki]](/images/elitewikismall.png){kind=small}
New Cargoes
and come back to new-version fever!
