Looking ahead

[Simon B]

Um ... there may be a way forward for adding some multiplayer elements to the game - one can add player chatter and a shared economy. Having players able to fly together would mess up all kinds of stuff, but we can have interaction to some level mediated by the stations ... arrive just after a player leaves in his anaconda and fine the markets all cleaned out ... there are more complicated economic models.

Similarly one could at least leave messages to each other bbs style in stations.

This would need a server to keep track ... one possibility could be to use the google app engine.

[Simon B]

Simon, you can tell the programmers you know that if they can program in C/C++, learning the basics of Objective-C is a matter of three to four days. In very few weeks' time they will be fully capable of generating at minimum sufficiently good quality code. Tell them that this comes from someone who is not a programmer by profession and has only had his first encounter with Objective-C when he found Oolite - up to that point I did not even know that a programming language with that name existed.

Understood, and for me personally that is a good argument ... but I am talking about people much better than me. They'd have to shift their existing tools and personal libs and all the gomi that accumulates when you've been coding for a long time to something, to them, less.

But changing the language in which the Oolite core is written, when the established codebase exceeds half a million lines of code, now that would prbably not be very well received by the team. The shift to gcc 4.6 at some point in the future could be a possibility, though. But that is just my opinion, others may have somewhat different points of view.

Shifting the toolchain need not involve much of a shift in the code - mind you, I havn't tried so there may be a gotcha in there.

The object is to improve collaboration by sending clear signals.
Perhaps an alternative is to add a sticky to the forums detailing how C++ code is to be included?

Ah - I see Ahruman has replied - I'll reply to that one separately.

[Simon B]

I haven’t got to the point of evaluating physics libraries. There will probably be support for low-LOD models and/or separate collision meshes.

I’d like to be able to switch to gcc 4.6 (or clang) for improved Objective-C features, and Objective-C++ would be a nice bonus feature, but that has to be weighed against the burden of installing extra tools.

once - add in the message this sends ... of course, if all I am hearing is a communication issue - perhaps there is a need to more explicitly document the way to use C++ in oolite?

Even if we adopted Objective-C++, the game would still predominantly be using ObjC classes, so you’d still need to learn the language. Also, Objective-C++ takes several times longer to compile. The most practical way to use it is generally to write only those classes that interface with C++ libraries in ObjC++.

Sure - the beauty of this approach is that other people will make the transitions.

Of course I have to be careful - it is trivial for me to install the extra tools and that may not be the case for others. If this move is at least interesting I think the next step is to figure out what needs to happen for it to be accepted. Perhaps it's something I can help with?

I'll obviously have to go look ... I suspect some donkeywork will be needed. I can sort-of read the code but get caught out in the details.

[another_commander]

Updating the toolchain will not be a trivial issue, especially considering that there are three architectures to be supported. What may be easy to do in Linux and/or Mac can be a nightmare to set up in Windows (which is more often than not the case) and sometimes the opposite holds true too. If this is to be done, consideration should be given not only to the burden of migrating, but also to the fact that all three ports must remain compatible. As an example, deciding that the move to gcc 4.6 is worth the work in Windows may not be enough, if this means that Linux will have to stay behind because of technical problems with migration (I understand that in the real world and in this scenario, Linux will probably have much less trouble migrating, but you get the point).

Regarding Simon's comment about programmers not willing to set up different tools that may disturb their current development setups, if any of those programmers are using Windows, they will be more than happy to know that the Oolite development system for said platform is provided as a single download, is completely portable, contained and self-sufficient and can run in parallel with any other environment they may be using, so the disturbance is minimal to non-existent. Not sure how things are with Mac and Linux, but I would dare guess that fears of messing up existing development environments might be a bit exaggerated.

[Switeck]

arrive just after a player leaves in his anaconda and fine the markets all cleaned out ... there are more complicated economic models.

I've always accepted that stations hold more than they appear to offer for sale. Their internal volume is huge compared to even an Anaconda. The limited market each visitor sees is to prevent a small number of ships from "cornering the market".

[pagroove]

-I like to see (in a future Oolite) that Oolite recalls the state of stations, objects and asteroids and stores them in memory. In that way you let the game build unique systems. Ships are still randomized though except if it is a system patrol ship.
-Save anywhere on every station
-Safety zone Hyperdrive lock. Not able to use Hyperspace in the safety zone.

[Simon B]

Updating the toolchain will not be a trivial issue, especially considering that there are three architectures to be supported.

I see you:
http://gcc.gnu.org/onlinedocs/gcc/Objec ... tions.html
... it looks like this (the - (id) .cxx_construct and - (void) .cxx_destruct methods) needs to be checked for non-OSX10.4 machines. And there is the .mm thing.

Lets back off a bit - I personally think that moving off objective C has long-term advantages that outweigh the short term inconvenience. However, that's a personal prejudice... I've checked: migrating the entire codebase to, for the sake of an example, C++, would be insurmountable ... we'd be better off moving the models and gameplay to an existing system like sega-strike - also for the sake of an example. So I kept an eye out for something incremental ... positing a shift to Objective C++, many of the long-term advantages are realisable without messing very much with the existing code. This is a much smaller prospect and there are actually other people working on making it easier right now.

There's no need to do the move right away ... I am talking about v2.0 only so the old system remains intact, write things in objC++ classes/objects when there is an advantage in doing so and it's method for wrapping C++ methods is available though initially unused. Presumably we want to know about hidden gotchas for this approach - and it is better to find these early than later - which is a good reason to talk about it now. I'll be able to start reality checking this before the end of the week (fingers crossed) and I figure it will be a crash course in the oolite codebase for me even if the idea is not adopted in the end.

If there is a chance, though, then it is probably a good idea to have this possibility in the back of our minds as we write our other changes.

[Simon B]

-I like to see (in a future Oolite) that Oolite recalls the state of stations, objects and asteroids and stores them in memory. In that way you let the game build unique systems. Ships are still randomized though except if it is a system patrol ship.
-Save anywhere on every station
-Safety zone Hyperdrive lock. Not able to use Hyperspace in the safety zone.

Well... something like this could form part of a shared environment (on an opt-in basis). - the main trouble would be greifing.

And more - there could be rescue missions triggered from actual player deaths - need not have much in-game effect, perhaps when you dock you see a news item that so-and-so successfully ejected after vaporization in system xyz - rescued by blah-blee and insurance payed out 250cr.

For that matter - there is already an implied usernet thing in random-hits ... this could become explicit and different types have access to different newsgroups etc. in oxz could have seedy space-bar news reporting successful hits both npc and pc, pirate bays report on wanteds (as a form of boasting). (hmmm... run piracy missions from pirate bays ... but that's OT).

Of course, players could leave messages for each other in-game. Need to work out what to do about the time stamp - but it could be safely ignored by handwavyness: ship time is not objective. People who don't like this don't opt-in.

(I still think that when you eject you don't get your ship back - certainly not in the condition it was when you ejected ... you should get the cash value of your ship and transport to the nearest station with a shipyard - or, maybe, all shipyards have an old adder up for grabs in a pinch? To avoid disturbing the current methods, means there is a need for a dummy player ship ... use the escape pod? ... until a proper ship is purchased with the insurance payout. Or maybe not - use a mission screen: you have received an insurance payout - (1) go to shipyard, (2) book passage to another world ...)

Please note that I am not presenting complete solutions here - I know this. Just promising lines of inquiry.

[Zireael]

-I like to see (in a future Oolite) that Oolite recalls the state of stations, objects and asteroids and stores them in memory. In that way you let the game build unique systems. Ships are still randomized though except if it is a system patrol ship.
-Save anywhere on every station
-Safety zone Hyperdrive lock. Not able to use Hyperspace in the safety zone.

I agree with all three suggestions.

@ above: And with not getting a ship like the one you fly for free after ejecting, too.

[JensAyton]

Lets back off a bit - I personally think that moving off objective C has long-term advantages that outweigh the short term inconvenience. However, that's a personal prejudice... I've checked: migrating the entire codebase to, for the sake of an example, C++, would be insurmountable ... we'd be better off moving the models and gameplay to an existing system like sega-strike - also for the sake of an example.

Just to be clear here, I have absolutely no interest whatsoever in moving any part of the existing code to C++ – except possibly the geometry types, but given how much slower compiling ObjC++ is (which is entirely down to the C++ side) I’d actually rather stick with annoying function calls there.

Objective-C++ is useful for writing glue to libraries, but there’s no “transition” in the cards for Oolite as a whole.

[Mauiby de Fug]

Something that ought to be fairly simple - making galactic hyperspace jumps take some time. At the moment it's possible to get to neighbouring planets within minutes of game time if you jump all the way through the 8, far quicker than the hours it would normally take to just jump there directly! Okay, this costs a lot, and can usually only be done with oxp equipment, but that fact that it's even possible feels a little wrong to me...

[Smivs]

Because of the way this works, I view the galaxies as maybe being stacked vertically, one above the next but quite close in 'space'.
So in real world terms a galactic jump is like going upstairs whereas a jump to a neighbouring system is like going to the shop at the end of the road.

Having said that it does seem a bit odd.

[Ad_Astra]

-I like to see (in a future Oolite) that Oolite recalls the state of stations, objects and asteroids and stores them in memory. In that way you let the game build unique systems. Ships are still randomized though except if it is a system patrol ship.
-Save anywhere on every station
-Safety zone Hyperdrive lock. Not able to use Hyperspace in the safety zone.

I agree with all three suggestions.

@ above: And with not getting a ship like the one you fly for free after ejecting, too.

I'm all for Commanders getting a ship identical to the one they flew - it's basically a like-for-like replacement Insurance Policy, after all. However, just as an Insurance Policy's premium's go up as you make more claims on it, so should the price of Escape Capsules go up the more often and more frequently you eject...

[DaddyHoggy]

Oh, an insurance premium hike - that's an interesting idea!

[Ad_Astra]

Oh, an insurance premium hike - that's an interesting idea!

I think it would work like any other reputation - your reputation with the Insurers would go down (and your cost to replace your Escape Capsule up) every time you have to punch out... your rep would go up (and your next Escape Capsule cost go down) the first time you dock into a Space Station after witching in. Leaving a Station and redocking without Witching shouldn't count at all unless your kills have increased or your cargo has increased changed, either by picking up cargo (pods, Escape Capsules, Thargoids, etc) or doing some in-system trading.

Hmm, now would would non-main stations (Seedy Bars, Rock Hermits, etc), count somewhat positively (like a less positive increment), count negatively against your rep or not count at all..?

This sounds dangerously like an OXP idea, but can OXPs change the costs of standard (non-OXP) equipment?