Page 1 of 28

Looking ahead

Posted: Sun Mar 13, 2011 12:38 pm
by JensAyton
This future is cancelled.

Once upon a time, I referred to ”the mythical next stable release” of Oolite. It became a sort of codename, and we still refer to the upcoming 1.76 as MNSR.

At times, we’ve also referred to EMMSTRAN, the Even More Mythical STable Release After Next. As we approached the feature freeze, this has popped up in feature requests, bug reports and code comments for things we’ve chosen not to fix until after MNSR. But internally, we’ve had a simpler name for it: Oolite 2.0.


What is Oolite 2.0?

First of all, this is Oolite 2.0, the significant update, not Oolite II – The Sequel. It will still be based on Elite.

Secondly, everything here is preliminary. We’ve been bouncing around ideas for 2.0 for over a year, but development is just starting.

The main reason for the major version bump is that we’ll be removing a lot of backwards-compatibility features. In fact, Oolite 2.0 will not work with any current OXPs, and saved games will not be backwards-compatible (but Oolite 2.0 will be able to load 1.x saved games).

There will also be more player-visible changes than in 1.76. In particular, the graphics will be almost completely replaced (primarily based on Griff’s ships – his forum title stopped being honorary in late 2009). We hope to improve the graphics engine – a lot. We hope to implement positional audio using OpenAL. There will also be gameplay balance changes; for instance, as previously announced, the energy bomb will be going away. We’d like to implement NPC shields. Strict Mode will be removed. (If you want it, well, 1.7x will still exist.)

Oolite 1.75/1.76 is almost fully backwards compatible, not only with OXPs but with hardware. We no longer support Mac OS X 10.3, and the IRIX port hasn’t been maintained for a while, but apart from than that any system that runs 1.65 should run baseline 1.76, probably better. Oolite 2.0, on the other hand, will raise the bar; not very high, but still appreciably higher. It will require at least OpenGL 2.0, and probably some extensions. For the Mac, it will require an Intel Mac with Mac OS X 10.6. Our CPU baseline is likely to be low-end Core 2 Duos.


The process

Again, development is just starting. In fact, I’m about to make the initial 2.0 code repository public, which is why we’re announcing this now. 1.76 is obviously a priority, but starting 2.0 now lets us do some actually fun coding between bug hunting, and provides a sink for our creative impulses.

There are some technical administrative changes to the actual development process. The most noticeable one is that we’re switching to a different version numbering scheme, where odd minor versions are development versions and even ones are releases. The initial development will be 1.89, and the first test release will be 1.90.

Oolite 1.7x will be the stable, recommended version of Oolite for quite some time, and it will continue to be maintained with bug fixes and possibly minor feature updates. Even after 2.0 is released, 1.7x may be preferable to users on low-end systems, or Strict Mode hard-liners. It won’t be abandoned like 1.65 was.


What was that about OXPs?

The OXP community is the heart and soul of Oolite. Without OXPs, the past half a decade of Oolite development would have been pointless.

However, there is a great deal of cruft in the OXP development interface, especially in the configuration files. Breaking compatibility in a half-hearted way, defining “best practices” and making everyone go through repeated compatibility tests doesn’t appeal. It would be like the scripting interface development process, only without the fun. Instead, the goal is to simplify the OXP authoring process by removing multiple ways of doing the same thing and making configuration files and scripts more similar.

The plan is to make much of the OXP conversion process automated. This is reasonably easy for configuration files, but intractable for scripts and shaders. Scripts will probably need minor updates. Shaders will almost certainly need to be rewritten from scratch (although we hope to increase the amount of stuff you can do without writing custom shaders in the first place).

We fully expect controversy over the changes. If you have specific criticisms – or suggestions for things that should be removed or simplified – we’d like to hear them. But if your response amounts to “I like it just fine as it is”, we respectfully ask that you wait until you’ve seen what the alternative actually looks like.


Some specifics

Again, please remember that this is preliminary.
  • There will be two expansion pack formats: a directory-based format similar to OXPs (tentatively called OXD), and a single-file format (OXZ) that’s essentially a zip file. The “end-user” version of Oolite 2.0 will only support OXZ, while OXD will be supported in the “developer” version. A single-file format is less confusing to users, and avoids file-system-specific issues like case sensitivity.
  • Expansion packs will be required to have a “manifest” that specifies their name, version, and a unique identifier, along with some optional data. This will allow expansion packs to explicitly refer to each other – for example, to specify dependencies or load order constraints in the manifest.
  • Property lists will be replaced with a format based on JavaScript. (If you’re familiar with JSON, this is essentially what you thought JSON was just before you became familiar with it. In particular, comments are permitted.) This solves two problems: we’ll be using the same parser on all platforms, and the syntax will be the same as in scripts instead of being confusingly similar yet different.
  • While we’re at it, configuration file keys will change to camelCase, and match script properties as closely as practical. Shader uniform bindings (or their replacement, depending how things work out) will also use the same keys. This “shared vocabulary” should make expansion pack development more approachable and also make it easier to write complete and consistent documentation.
  • Less stuff will be implicit, based on roles, scan classes or (worse) combinations of them. For example, all stations will need to have isCarrier: true in their shipdata entries.
  • Similarly, there will be less flexibility in some situations. For example, there are currently at least five ways to specify colours (not counting special cases like the old flasher syntax). In 2.0, all colours will be specified as arrays of three or four numbers (RGB or RGBA components).
  • The DAT model format will be replaced with a more efficient and more flexible format. The new format allows material properties to be specified in the model where they belong (which makes it easier to import them from other 3D mesh formats), and permits arbitrary vertex attributes; for instance, you could have multiple sets of texture coordinates, or per-vertex colours, as long as you write a shader to make use of them. The only requirement is that there’s a position attribute to use for geometry calculations. The syntax of the new format is identical to the new configuration syntax, but with extra constraints on the structure of the file.
  • Mission variables will support all JSON types directly. If you put a string in, it will always come out as a string, not be converted to a number.
Here is an example of how a shipdata entry might look in “not-quite-JSON” syntax. It looks a lot like an OpenStep-format plist, but it’s also a valid JavaScript value (you can test this in the debug console by surrounding it with parentheses and pasting it in).

Code: Select all

{
    adder:
    {
        aftEjectPosition: [0.0, -4.5, -23.0],
        aftWeaponPosition: [0.0, 0.0, -22.5],
        AI: "scavengerAI.plist",
        autoAI: true,
        cargoSpaceCapacity: 5,
        cargoSpaceUsed: { min: 0, max: 1 }, // likely_cargo = 1
        cargoType: "CARGO_NOT_CARGO",
        energyRechargeRate: 2,
        exhaust:
        [
            [-5.75, 0.0, -22.5, 6.0, 4.0, 4.0],
            [5.75, 0.0, -22.5, 6.0, 4.0, 4.0]
        ],
        forwardWeapon: "WEAPON_PULSE_LASER",
        forwardWeaponPosition: [0.0, 0.0, 22.5],
        fuel: 7.0,
        equipment:
        [
            { equipmentKey: "EQ_ECM", probability: 0.01 },
            "EQ_FUEL_SCOOP"
        ],
        maxEnergy: 85,
        maxFlightPitch: 2,
        maxFlightRoll: 2.8,
        maxFlightSpeed: 240,
        maxThrust: 30,
        missileLaunchPosition: [0.0, -2.5, 16.0],
        missileCount: 1,    // “missiles” is reserved for explicit array of identifiers, similar to JS Ship semantics.
        model: "oolite-adder.oomesh",
        name: "Adder",
        portWeaponPosition: [-15.0, 0.0, -14.5],
        roleWeights:
        {
            hunter: 1,
            scavenger: 1,
            shuttle: 1,
            hermitShip: 1
        },
        scoopPosition: [0.0, -2.0, -7.5],
        starboardWeaponPosition: [15.0, 0.0, -14.5]
    }
}

Re: Looking ahead

Posted: Sun Mar 13, 2011 3:14 pm
by Zireael
I see some OXPs will become redundant (I hope things like Accessories will become as much a part of Oolite 2.0 as Griff's ships).
What about the rest? Will they be able to be ported to 2.0? (I mean not only mission and planet ones, but also various knicknacks...)
There will also be gameplay balance changes; for instance, as previously announced, the energy bomb will be going away. We’d like to implement NPC shields.
Yaay for both!!!!

Re: Looking ahead

Posted: Sun Mar 13, 2011 3:21 pm
by JensAyton
It will be possible to update most if not all OXPs for 2.0.

The code repository is now up at https://github.com/Ahruman/Oolite2. It’s spectacularly uninteresting at the moment, essentially a slightly crippled version of 1.75.1 that only builds for Mac OS X.

Re: Looking ahead

Posted: Sun Mar 13, 2011 5:11 pm
by ClymAngus
Ahruman wrote:
Oolite 2.0, on the other hand, will raise the bar; not very high, but still appreciably higher. It will require at least OpenGL 2.0, and probably some extensions. For the Mac, it will require an Intel Mac with Mac OS X 10.6. Our CPU baseline is likely to be low-end Core 2 Duos.
Ah sweet sweet progress. unfortunately I have just taken delivery of several second hand g4 and g5 (risk) and have no intention what so ever to pay for a new computer to play oolite (I might be able to hack together a linux box) but we'll see.

I appreciate that we are all victims of the hardware and software makers pressure to "upgrade every other year"by hacking away at backward compatibility. Inevitably oolite was going to bow to this pressure. Honestly my old pc does everything that I need it to do. Newer, shinier and more complex simply doesn't float my boat.

I will be hanging around 1.76 for a while (maybe a lot longer that the rest of you,) Maybe make up some DVDs of working oxps. Please understand that I'm not "having a go". I would suggest that we don't throw the baby out with the bath water and museum the last oolite 1.7* so skin flints like me or people on second hand kit can still enjoy the great game.

But this is for another topic. "In our embracement of the future let us not forget our debt to the past."

Re: Looking ahead

Posted: Sun Mar 13, 2011 5:28 pm
by JensAyton
You know, I can’t remember the last time Intel came around and offered me a bribe. It would come in handy right now.

Re: Looking ahead

Posted: Sun Mar 13, 2011 6:03 pm
by CheeseRedux
Ahruman wrote:
There will also be gameplay balance changes; for instance, as previously announced, the energy bomb will be going away. We’d like to implement NPC shields.
For a while now, I've been meaning to write up my brainstorm from this thread as a proper proposal, but there's always something less important that gets in the way.
So how about it? Can we get rid of a third player-only gadget while we're at it?

Re: Looking ahead

Posted: Sun Mar 13, 2011 6:18 pm
by Zireael
CheeseRedux wrote:
Ahruman wrote:
There will also be gameplay balance changes; for instance, as previously announced, the energy bomb will be going away. We’d like to implement NPC shields.
For a while now, I've been meaning to write up my brainstorm from this thread as a proper proposal, but there's always something less important that gets in the way.
So how about it? Can we get rid of a third player-only gadget while we're at it?
Put this brainstorm as a separate thread (I think I understood what you meant in this post, but it would be nice to be able to discuss your idea without clustering another topic).
I second the brainstorm completely. Maybe name it not TimeDrive, but Stardreamer (and yay, it preserves the TAF in some way :D)

Re: Looking ahead

Posted: Sun Mar 13, 2011 7:50 pm
by ClymAngus
Ahruman wrote:
You know, I can’t remember the last time Intel came around and offered me a bribe. It would come in handy right now.
They don't have to, it's called monopoly. "The best sort of bribery is the one you don't have to pay for."
So I take it you whole heartedly agree and lend your undying support to the general principle of an oolite museum then? :D

Re: Looking ahead

Posted: Sun Mar 13, 2011 8:01 pm
by Commander McLane
ClymAngus wrote:
Ahruman wrote:
You know, I can’t remember the last time Intel came around and offered me a bribe. It would come in handy right now.
They don't have to, it's called monopoly. "The best sort of bribery is the one you don't have to pay for."
So I take it you whole heartedly agree and lend your undying support to the general principle of an oolite museum then? :D
This seems to be the point of what Ahruman wrote in his initial post, doesn't it?
Ahruman wrote:
Oolite 1.7x will be the stable, recommended version of Oolite for quite some time, and it will continue to be maintained with bug fixes and possibly minor feature updates. Even after 2.0 is released, 1.7x may be preferable to users on low-end systems, or Strict Mode hard-liners. It won’t be abandoned like 1.65 was.

Re: Looking ahead

Posted: Sun Mar 13, 2011 8:01 pm
by JensAyton
ClymAngus wrote:
So I take it you whole heartedly agree and lend your undying support to the general principle of an oolite museum then? :D
Did you read the next part of the post?

Monopoly is irrelevant. If Macs were still using PowerPCs, we’d be dropping G4s and G5s anyway, because supporting such old systems means crippling new ones. As it is, SpiderMonkey doesn’t fully support PowerPC, and most of the speed gains made since the old version don’t apply to PowerPC (because no-one had the time to do the work for a small fraction of a percent of the user base). We’d support antique systems if it was cheap, but it isn’t.

Also, realize that by the time Oolite 2.0 is ready, the small percentage of Mac users on PowerPC will be much smaller still.

Re: Looking ahead

Posted: Sun Mar 13, 2011 8:06 pm
by Commander McLane
Ahruman wrote:
The main reason for the major version bump is that we’ll be removing a lot of backwards-compatibility features. In fact, Oolite 2.0 will not work with any current OXPs...
This will require us to deal with the issue of orphaned OXPs, with its deep entangledness in the whole licensing issue. Otherwise some of the oldest OXPs will be gone forever.

Re: Looking ahead

Posted: Sun Mar 13, 2011 9:43 pm
by Selezen
Ooh, this sounds exciting!

Do you have a timescale in mind for the 2.0 release?

Is there any place in the 2.0 mix for any online options, like automatic version updates, on-demand OXP/OXZ installation or (yeah, I had to push it) the Personalities or Personalities Plus concepts (or similar)?

Re: Looking ahead

Posted: Sun Mar 13, 2011 10:18 pm
by TGHC
As usual I'm a traditionalist, but technology advances demand, wether we like it or not, that that we keep moving inexorably forwards.
The only thing I would say is that the "flavour" of the gameplay remains as true as possible to classic elite and the game remains "balanced".
I am confident that this will happen, since this seems to have always been the case and in line with Aegideans original concept of Oolite.
I have total respect for all the developers and contributors in the way in which the game has been developed so far and congratulate them.

So onwards and upwards you have my complete trust and support.

Re: Looking ahead

Posted: Sun Mar 13, 2011 11:17 pm
by JensAyton
Selezen wrote:
Do you have a timescale in mind for the 2.0 release?
My ambition is to beat my previous record of five years. :-)
Selezen wrote:
Is there any place in the 2.0 mix for any online options, like automatic version updates, on-demand OXP/OXZ installation or (yeah, I had to push it) the Personalities or Personalities Plus concepts (or similar)?
Unlikely. (Well, except the update thing, which is in 1.75 for Mac OS X.) If someone set up a web service for managing OXZs (OOSat4?) we might integrate with it, but I don’t have any interest in working on the server side. The addition of a mandatory manifest would make it easier to build services around this sort of thing, e.g. updating OXPs and resolving dependencies.

Re: Looking ahead

Posted: Mon Mar 14, 2011 10:24 am
by ClymAngus
Ahruman wrote:
ClymAngus wrote:
So I take it you whole heartedly agree and lend your undying support to the general principle of an oolite museum then? :D
Did you read the next part of the post?

Monopoly is irrelevant. If Macs were still using PowerPCs, we’d be dropping G4s and G5s anyway, because supporting such old systems means crippling new ones. As it is, SpiderMonkey doesn’t fully support PowerPC, and most of the speed gains made since the old version don’t apply to PowerPC (because no-one had the time to do the work for a small fraction of a percent of the user base). We’d support antique systems if it was cheap, but it isn’t.

Also, realize that by the time Oolite 2.0 is ready, the small percentage of Mac users on PowerPC will be much smaller still.
Ok hang on here a small second, I'll admit that I missed the second part of your post, that was unfortunate (makes me look like a bit of a dick to be honest). That said I am very happy that as an introductory thing, oolite 1.7* will be kept chugging along. Of course everyone likes eye candy and I fully intend to locate a scratch build linux box at some point. I do (and will continue to) decry the system that created the rebuy principle.

It is good to see that you are trying to insulate us from that.