Oolite Bulletins

Hi everybody, hi Oolite devteam.

I'm in the planning phase of an open source space MMO(RP)G - sort of a pedant to eve online ( ... I think ... I've never played EO). It will emphasise on mass combat, a sophisticated UI (this much inspired by the EO style), relatively simpe economics and realistic flight models very much like Oolite/Elite but with slightly more control. On top of that I wish for absolute zero-fuss deployment and runability on all but the most obscure plafforms with the utmost minimum of hardware requirements

The game (Codename: "IO") / project will - of course - have to cut corners whereever possible - quite literay too actualy - and with the given goals stated above the Oolite game and most possibly its codebase appear to be a very likely starting point for IO. Wether it can be depends on certain details I wish to clarify with the devcrew of Oolite - thus the following detailed questions. It would be of great value to me if someone from the Oolite devteam could answer these.

Beforehand, one last thing as a sidenote, just to put this post into perspective: I'm a professional game developer (i.e.: I program MMOGs for a living) in a dept. of roughly 60 gamedevs and have world-class real-time MMOG server expertise just up the hallway of my office. I've actually repeatedly discussed some details of IO with colleagues allready. ... I'll be doing most of the work on IO on my own though. That's what I expect anyway.

With that said, here are my questions:

- How well is the architecture designed? I.e. do I have to expect a naming and convention mess or is it relatively consistent?

- Is there an API documentation? If yes, how up-to-date is it? Is it of any use to somebody unfamiliar with Oolite code and real-world Objective-C developement? And with regarding the first question: Do I need API docs or is Oolite simple/good enough to be self-explainatory?

- How well does the Oolite engine handle thousands of objects (up to approx. 5000) of which around a thousand should be able to move independantly at the same time + up to 50 000 polygons alltogether? Is there performance optimisation in place (object and poly/mesh culling f.e.) to ensure optimal performance with such loads? If not, how difficult would it be to implement that and would the Oolite devteam be interested in introducing such a feature to the Oolite engine and focussing on clean low-end performance over 'feature bloat'? Note that I expect IO to perform supperbly on a 900Mhz Netbook or simular computers.

- Is there any experience with FSAA (full screen anti-aliasing) of the actual 3D scenes - not the UI - in Oolite developement? How does it affect performance if the Oolite engine is used for FSAA with very low-poly models that aren't textured?

- Does the Oolite Engine support vertex painting? Could a performant vertex painting solution be introduced into the OE easyly? ... I'd actually like to vetex paint only one object: the skybubble (200-300 vertexes/vertecies(?)). ... That's what Homeworld did and the cost (performance)/result ratio is perfect for this sort of thing.

- Is there a flexible UI kit in the OE or are there APIs in place for low-fuss post-rendereing access to the framebuffer?

And last:
- Any pitfalls I have to expect in developing a server with Objective-C over doing that in C++, C# or pure C? ... Not that I'd expect any, but you probably know better.

Thanks for any help.

Strange nobody has answered.

Probably because reworking oolite in such a way would be a rather huge undertaking.

I think that only Ahruman can answer these questions fully. After all, he is the architect of Oolite post-1.65.

I would only say this: Regarding the first question, it is my personal opinion that the game is really well designed. All game elements are organized into their own classes, which are themselves very well laid out, comprehensible and consistent. Finding one's way in the code is relatively easy. I am not a professional programmer and yet I can hack the code here and there. The way I see it, if I can do it, then a professional will have zero problems reading and understanding the code.

Also, I would want to add here that Oolite does not really offer itself to multiplayer. The entire game was designed from its very conception with single player only in mind, so going back to add multi capabilities would require such effort and revision of the design that would make it essentially a rewrite from scratch.

Hi Folks !

I had the same idea as ritschratsch, but now to tech-talk:

I think that a rewrite from scratch (thou i have not seen the code yet ) will not be necessary if it´s possible to somehow .. see the mmo-stuff as an expansion. If this is possible we can make a wraper or stuff which would be just between "oolite-display" and "oolite-core". - Just my two cent.

(On the other hand i am a java-programmer and i think some things will work quite different in C/C++)


Anywho .. Atm i work together with the creator of the meta-Mod: "Oolite Shipyards Extension WiP V0.4" and it makes simply sense to me to bring oolite on-line to a new dimension.

Best Regards
Katharsis

Hi K,

welcome to the Oolite boards!

Very much looking forwards to producing OSE WiP V0.9 with all six thousand ships with your help

Cheers

L

EDIT: If it's going to be possible to produce an online Oolite ... looking even more forwards to that!

If there is ever an online MMO version of Oolite then it should have its own BB because one of the reasons I think that this board is so friendly is none of that nasty "you pwned me you cheating nazi" type stuff that spills over from a particular game to the boards currently happens here - which is just the way I like it

BB = BuildBranch or BulletinBoard ?

Anywho ... both are ideas i will keep in mind - Thanks !

Best Regards
Katharsis

EDIT: First i will go to make a function for submitting your scores, shiptype, etc. (Cheaters and stuff : ... well ... live´s nasty and then you die ...)

Hi, I do some dev on the project, but what follows should not be taken to be me speaking on behalf of oolite, its purely personal, and probably wrong

Katharsis wrote:

thou i have not seen the code yet

You can get it from berlios easily enough, and both the wiki and this forum contain no end of discussion on building from source, so if you want to see the code, its pretty easy to get it and have a play.

Katharsis wrote:

(On the other hand i am a java-programmer and i think some things will work quite different in C/C++)

Not really, Java and objective C are both "C like" languages, and although the syntax is different, not by enough to make it hard to read. Most java apps I have seen have been web based mutli-layer (persistence/business/ui) and oolite isnt like that, but it isnt due to language differences.

I really want you guys to do this, and make it a success, so please dont take this too negatively, but there are some serious challenges to using the oolite codebase.

Firstly oolite is very player-(or even player ship)-centric and having multi-player will need a wide range of changes simply to be possible.

Then there is the universe. Currently there is one system at a time, generated at runtime in a predictable manner with the player in. WHere are you going to run each system? There are 8 maps, each with 256 systems, are you going to have all 2048 running in real time on a central server (or 8, or maybe 2048 server instances)? At the moment 3rd parties (pirates etc.) are generated with each system when the player enters, how are they going to be generated multi-player, and are we going to track each one between each system as they trade?

Often in mmorpg there are problems with things like collision detection, one player thinks there was a hit, the other does not, and a large part of many games is for resolving this sensibly, and of course oolite has none of this.

How do we resolve different players having different OXPs (I guess all must use the same as the server)

What are we going to do about the stock markets on each system. Currently there are normally only about one shipload of each commodity at a time. Is this allocation per player (2 players docked can buy twice as much?) and when is it replenished?

Things like escape capsules will need to be thought about again.

All in all, Id say that basing an elite/oolite style game on the look and feel of oolite, taking assets, trying to involve this community and so on would be really cool. I suspect that a green-field development, stealing bits like some of the entity handling stuff where appropriate would make sense, but trying to bolt on multi-player seems rather doomed to be honest.

Katharsis wrote:

BB = BuildBranch or BulletinBoard ?

BB == Bulletin Board (this forum). The only branch we refer to really is trunk (currently 1.73).

Cmdr James wrote:

You can get it from berlios easily enough, and both the wiki and this forum contain no end of discussion on building from source, so if you want to see the code, its pretty easy to get it and have a play.

gotcha !

Cmdr James wrote:

Then there is the universe. Currently there is one system at a time, generated at runtime in a predictable manner with the player in. WHere are you going to run each system? There are 8 maps, each with 256 systems, are you going to have all 2048 running in real time on a central server (or 8, or maybe 2048 server instances)? At the moment 3rd parties (pirates etc.) are generated with each system when the player enters, how are they going to be generated multi-player, and are we going to track each one between each system as they trade?

Yes .. i am thinking about socket-connections with synchronized methods (here it comes to C/C++ and if C++ makes us of synchronized methods .. dunno). But ... sure ... the server-load would be gigantic and anything under a quad-core with 8gb of ram and a light-weight OS (ubuntu server, gentoo, etc. ..) will not be able to deal with it.

Cmdr James wrote:

Often in mmorpg there are problems with things like collision detection, one player thinks there was a hit, the other does not, and a large part of many games is for resolving this sensibly, and of course oolite has none of this.

No clue ... didn´t thought about yet ..

Cmdr James wrote:

How do we resolve different players having different OXPs (I guess all must use the same as the server)

Yes ! ... Building on "Oolite Shipyards Extension WiP V0.4" of course (anything else would not make sense to me)

Cmdr James wrote:

What are we going to do about the stock markets on each system. Currently there are normally only about one shipload of each commodity at a time. Is this allocation per player (2 players docked can buy twice as much?) and when is it replenished?

I don´t understand the question .. can you specify ?

Cmdr James wrote:

Things like escape capsules will need to be thought about again.

... for me it would be fun to shoot on them *badsucker*

Cmdr James wrote:

All in all, Id say that basing an elite/oolite style game on the look and feel of oolite, taking assets, trying to involve this community and so on would be really cool. I suspect that a green-field development, stealing bits like some of the entity handling stuff where appropriate would make sense, but trying to bolt on multi-player seems rather doomed to be honest.

I will see what is technicaly possible ... atm it´s just a dream


Last but not least: I want to thank you for your time and questions ... it takes me a step closer to make this project real.


EDIT: Question --> Why the hack is OoLite lagging like hell when it comes to show planets ? Oo

Greetings
Katharsis

I mean that when you jump into a system, its commodities (I said stock-) market is generated. So there are, lets say 10t of food, 15 of textiles, 5 computers, etc.

In normal oolite, if I fly to a system, buy everything and them wormhole out, then next time I come back the whole system is generated again, including the list of stuff to buy. This clearly wont work if systems are not generated on demand, per user.

Lets say you decide to restock once per day, then players will have to rush to their favorite trade routes and do all their trade before someone else takes all the stock.

And what about places like Lave, where I guess people are going to start, and there may be hundreds of people all fighting over the same goods to trade.

Katharsis wrote:

(here it comes to C/C++ and if C++ makes us of synchronized methods .. dunno)

Just to be clear, oolite isnt C++. And I dont think you want to use synchronized (at least not in the Java synchronized sense) access to the server as you would essentially be single threading the whole thing.

Katharsis wrote:

. But ... sure ... the server-load would be gigantic and anything under a quad-core with 8gb of ram and a light-weight OS

If you imagine what you need for (single system) oolite now, lets say a single processor 1GHz machine (for example), then we know that to run all 2048 systems will take about 2000 times as much resources, so I am not completely sure that a quad core is going to cut it.

I'm no programmer, my experience with MMORPGs is player only, but...

2048 systems...does that game has to have them all? To make it really multiplayer, you would have to have like 5000+ players online all the time. I doubt you will reach such number, at least not right after start. Limit it to G1 for the beginning, you can add more later.
And perhaps you don't have to run all systems at once. From the MMORPG I play, I know it is possible to run only the active maps, not those empty ones. This would reduce the stress on server considerably.
And about restocking...well, I'd give it this...what about every planet having max stock for some comodity, and for those it produces it will restock say...1% of this number per minute. Also note I'm talking about limits being about a few hundred, multiplayer will be a lot different as you will have more than one trader stocking up.

Just to be clear, oolite isnt C++. And I dont think you want to use synchronized (at least not in the Java synchronized sense) access to the server as you would essentially be single threading the whole thing.

I thought about buying stuff, shooting same target, etc. - not about the whole thing (that wouldn´t make much sense to me).

If you imagine what you need for (single system) oolite now, lets say a single processor 1GHz machine (for example), then we know that to run all 2048 systems will take about 2000 times as much resources, so I am not completely sure that a quad core is going to cut it.

I don´t understand why oolite is taking so much ressources ... but to come to your point: I think it should be possible to create a server in a more light-weighted way .. so you can´t calculat this way.

(For Example ... our ManGos-Wow-Server was a 4GB quadcore and never had more than 10% cpu-usage at any time)


PS: Do you know why it is taking so much system-ressources ?

Greetings
Katharsis

Cmdr James has brought up some very valid points and I am sure there are many others that will start surfacing if at any moment a multi player conversion is attempted

And there is always the minor detail that usually is the most critical point whenever a multi player port of Oolite or any other game for that matter is being discussed: Who has - or can make available - the infrastructure required to run a multiplayer version of Oolite? Is anyone willing to spend money on bandwidth, servers, administration and support personnel that will be required? If yes, how much? There will be a LOT of costs involved, even if for one moment we assume that this conversion is technically possible. Given that we are not running a business like Blizzard or EA, I don't think that it will be possible with the current resources to make this move on. It will require much much more than just rewriting some code.