Oolite Bulletins

nijineko wrote:

i think the only way to make it multi-player would be to recreate it as an mmo...

Nice.. several person-years worth of re-designing, coding from scratch, and debugging, all buried inside one little word..

Diziet Sma wrote:

nijineko wrote:

i think the only way to make it multi-player would be to recreate it as an mmo...

Nice.. several person-years worth of re-designing, coding from scratch, and debugging, all buried inside one little word..

And such an inconspicuous little word at that.

Oolite IV? The same treatment as Elite IV?

I think not. E : D can be multiplayer. I like my Oolite single player thanks.

nijineko wrote:

i think the only way to make it multi-player would be to recreate it as an mmo

Well, there are two possible ways:
1) MMO, making serious gameplay alterations to deal with the big issues (which Elite: Dangerous is doing an excellent job of highlighting). As previously said, it wouldn't be Oolite any more.
2) Primary-secondary multiplayer: allow players to control ships in another player's universe, but like an NPC the secondary player(s) only exist when the primary player needs them, neatly sidestepping most of the major issues raised upthread. This is within the reach of an addon program using existing Oolite features, which interested parties are welcome to write.

in response to the "single player mode only" style comments - i admit i quite enjoy playing the current version of oolite. i have few problems with it which is pretty rare for me.

however, what i don't really understand, is how, with galaxies of hundred and thousands of starships, swapping out the computer ai for a human ai on a few of them somehow makes it "not oolite"? unless some of the original designers say that they had a firm belief that elite and later incarnations should be single player only, rather than the technical abilities of the day shaping the programming decisions, i don't really see any justification for a single player only bias.

if it's a personal preference, on the other hand, no problems.

nijineko wrote:

however, what i don't really understand, is how, with galaxies of hundred and thousands of starships, swapping out the computer ai for a human ai on a few of them somehow makes it "not oolite"?

It's not the AI that would be the problem - it's the other compromises needed for an MMO-style game. As I said, Elite: Dangerous gives a good idea of what some of them are, if you watch its development.

• all time must be synchronised, so hyperspace jumps and equipment fitting must be near instant. This takes away a lot of "race against time" possibilities, the strategy of making several short jumps rather than a single long jump, a lot of the suspense in the contract market "do I have time to get my shields repaired?", etc.
• OXPs would have to be extremely tightly regulated for multiplayer - basically limited to purely visual changes: HUDs, textures, etc. and maybe not even that.
• The current "if you die, you just reload" set up would need highly controversial adjustment.
• Most of the current core missions would have to go. "The Naval Research Centre at Xeer has had a whole fleet of its prototype 'Constrictor' craft stolen in the fifth embarrassing break-in of this nature this year. Rumours that they are intentionally letting the ships be stolen to get cheap combat testing have been denied by the base commander."

And so on. I'm not saying it wouldn't be a good game at the end of it - I expect I will get a lot of enjoyment out of Elite: Dangerous, after all - but it would be a very different game to Oolite.

As I said, none of these are really a problem for the "primary-secondary" multiplayer mode, which is "simply" a matter of writing the server and networking programs, and an OXP to interface between those programs and Oolite.

cim wrote:

As I said, none of these are really a problem for the "primary-secondary" multiplayer mode, which is "simply" a matter of writing the server and networking programs, and an OXP to interface between those programs and Oolite.

And dealing with all the related security issues that opens up, to say nothing of all the cheat-prevention measures that will be required.. two HUGE cans of worms..

Diziet Sma wrote:

cim wrote:

As I said, none of these are really a problem for the "primary-secondary" multiplayer mode, which is "simply" a matter of writing the server and networking programs, and an OXP to interface between those programs and Oolite.

And dealing with all the related security issues that opens up, to say nothing of all the cheat-prevention measures that will be required.. two HUGE cans of worms..

Security is just part of the programming. I think the cheat-prevention measure would be "don't play with people who cheat", as it has been in every non-MM form of competitive entertainment since before computers were invented - I don't think anything else is practical in open-source games.

I'm not saying it's in any way easy, but nor do I want to overstate the difficulty in case someone with the interest, programming skill and determination needed happens across this later: someone who knew what they were doing could probably get a basic 2-player arena deathmatch server running in a couple of months, without needing any changes to Oolite's source code at all.

cim wrote:

nijineko wrote:

however, what i don't really understand, is how, with galaxies of hundred and thousands of starships, swapping out the computer ai for a human ai on a few of them somehow makes it "not oolite"?

It's not the AI that would be the problem - it's the other compromises needed for an MMO-style game. As I said, Elite: Dangerous gives a good idea of what some of them are, if you watch its development.

• all time must be synchronised, so hyperspace jumps and equipment fitting must be near instant. This takes away a lot of "race against time" possibilities, the strategy of making several short jumps rather than a single long jump, a lot of the suspense in the contract market "do I have time to get my shields repaired?", etc.
• OXPs would have to be extremely tightly regulated for multiplayer - basically limited to purely visual changes: HUDs, textures, etc. and maybe not even that.
• The current "if you die, you just reload" set up would need highly controversial adjustment.
• Most of the current core missions would have to go. "The Naval Research Centre at Xeer has had a whole fleet of its prototype 'Constrictor' craft stolen in the fifth embarrassing break-in of this nature this year. Rumours that they are intentionally letting the ships be stolen to get cheap combat testing have been denied by the base commander."

And so on. I'm not saying it wouldn't be a good game at the end of it - I expect I will get a lot of enjoyment out of Elite: Dangerous, after all - but it would be a very different game to Oolite.

As I said, none of these are really a problem for the "primary-secondary" multiplayer mode, which is "simply" a matter of writing the server and networking programs, and an OXP to interface between those programs and Oolite.

Why would it have to be near instant? instant warp is player convenient and unrealistic. neither of which fit the spirit of the game. just leave the time factor in place. maybe, put in a time dilation factor 1ly=1minute or something. and adjust the contract times accordingly. they can see ghostly things to entertain them while waiting in warp. include an auto-pilot for those long travel times in normal space, and it gives off a loud warning and flashes the screen - maybe even let it send out a text message via internet connection when something happens like getting attacked. and for fittingtimes, allow the player to rent a ship (in-the-shop-insurance), allow them to have multiple ships, have station-based events, shuttles which can move your character to different places - such as the planet for trading and so forth, while you are waiting for your ship to be fitted. or you can even become a character advertising a transport!

ship-board interfaces might be limited to things like 'gambling with the crew' or 'trading informational nuggets for value' or 'pirate attack you've been captured and enslaved' or 'repel boarders'... even without much in the way of graphics, you could use the station-based oxp as the base for text-based interaction.

as another warp option - have energy artifacts that have to be piloted around within warp - give witchspace two layers, an i'm-traveling-between-systems layer and a i-got-stuck-out-here layer. be more fun if you had to use piloting skill in warp, or risk being destroyed and becoming a witchspace ghost! and, might as well put the ninth witchspace galaxy back in place as the origin point of the thargoids while one is at it.

speaking of which, there is already a station-based oxp out there... could use the same format for planets, and even use it to include games and whatnot. shouldn't really force oxp regulation.

advanced tech systems can provide cloning technology. for a fee. you die, your clone wakes up. no clone, you die, start over. and if there are both sp/mp modes, then you can allow the reload bit in sp mode, but require clones in mp mode or start a new character. add insurance on ships to the game, so that even if you die, you can get some sort of ship back.

instead of removing the core missions, use the seed number to generate types and categories of missions in different governmental systems. track which missions happened where/when, and have some kinds of missions be repeatable within certain parameters, but other kinds of missions be a one time event for a given system that meets the criteria. some small thought given to syncing the kinds of resources available in a given system with the types of installations that will procedurally generate in said system would lend much verisimilitude. so, for the navy mission mentioned above, the mission could only generate in systems that have a military base / shipyard, and maybe limit it further to certain types of government, for example.

in line with that, planets and various kinds of installations should be assigned values based on the seed number to generate certain types of resources over a given period of time, which should be factored into the economic model. then you can have events such as asteroid impacts and famines changing those values, and word of them spreading across the news channels (timing determined by ships traveling between systems) which would then also generate procedural missions from systems that are high in the now missing resources towards the planets where the event(s) happened. this would also allow things like news reports even in systems where the resources don't match; advertising when an event occurred and that there is a potential need which ship captains can now scramble for, or decide that since it took x amount of time for the news to arrive, the news is so old that other captains would have acted upon it and it is a bad risk....

actually, that last right there would make an excellent oxp all by itself.

just some thoughts from a gamer.

nijineko wrote:

Why would it have to be near instant? instant warp is player convenient and unrealistic. neither of which fit the spirit of the game. just leave the time factor in place. maybe, put in a time dilation factor 1ly=1minute or something. and adjust the contract times accordingly. they can see ghostly things to entertain them while waiting in warp. include an auto-pilot for those long travel times in normal space, and it gives off a loud warning and flashes the screen - maybe even let it send out a text message via internet connection when something happens like getting attacked. and for fittingtimes, allow the player to rent a ship (in-the-shop-insurance), allow them to have multiple ships, have station-based events, shuttles which can move your character to different places - such as the planet for trading and so forth, while you are waiting for your ship to be fitted. or you can even become a character advertising a transport!

Regardless of how long or short you make jumps or ship outfitting take for the player, everybody in the whole game universe has to be running on the same clock. There has to be a single universal time frame for a multiplayer game, otherwise you'd have one player doing something in their version of "now", which is simultaneously in another player's past, and in a third player's future.

I don't see the benefit in forcing players to wait for arbitrary lengths of time to make jumps or to have kit fitted. As far as "realism" goes, there's no difference between taking 7 minutes to jump 7 light years, and taking 7 seconds to jump 7 light years, but I know what I'd prefer to experience in a game ... speaking as someone who began my gaming on a ZX81, I feel I've paid all my "wait 7 minutes" dues!

yeah, i'm familiar with the network timing issues. if insta-jump is what is desired, then adjust the transport and cargo times accordingly. doesn't seem to be that huge an issue overall. i think witchspace transition times, with the risk of ambush and so forth, would be more fun.

though, i get the dues-paid idea. as for me, back then i was playing nemesis & dungeonmaster on an actrix, and adventure on a vic20... i didn't find *lite till relatively recently.

Why do we have to discuss this over and over again?

nijineko wrote:

yeah, i'm familiar with the network timing issues. if insta-jump is what is desired

No, you don't seem to be familiar with the network timing issues. If you were, you'd choose other words. Insta-jump is not "desired", it's an absolute and bleedingly obvious necessity. When you and I meet in Lave, our ship clocks have to show the same time. When we meet again in Zaonce two real-life hours later, our ship clocks still have to show the same time, or else we couldn't meet. They have to show the exact same time, although you jumped through ten different systems in the meantime, while I only made one single jump from Lave to Zaonce and then simply parked my ship right next to the witchpoint beacon. The only way to achieve that is to not have any game time passing during a jump.

If you don't believe any of that, please, by all means, go ahead and write a multiplayer version of Oolite. But write it, and don't rant about it. Ranting about something that nobody has any intention of doing is absolutely pointless and a waste of time, forum space, and resources.

cim wrote:

[*]all time must be synchronised, so hyperspace jumps and equipment fitting must be near instant. This takes away a lot of "race against time" possibilities, the strategy of making several short jumps rather than a single long jump, a lot of the suspense in the contract market "do I have time to get my shields repaired?", etc.

This made me realize that I'm actually missing some hints on how long the modifications will take when I'm purchasing equipment. The mechanics should be able to tell me (an estimation would suffice)! Should I fill a feature request for this?

More than once (but not too often) I missed a deadline because I spent too much time with repairs. Now, when I have a time-critical mission running, I don't buy anything because I never know how long that would take. If the mechanics would give me an estimation, this would be a great help!

Commander McLane wrote:

Why do we have to discuss this over and over again?

nijineko wrote:

yeah, i'm familiar with the network timing issues. if insta-jump is what is desired

No, you don't seem to be familiar with the network timing issues. If you were, you'd choose other words.

Hmm, from reading the posts I've got the feeling that there is a misunderstanding here? As I understand nijineko, he never said something about using different time factors or anything like that, but only that instead of making witchspace jumps instant in order to keep a consistent global time one could make them more interactive, so that if the jump takes 10 minutes the player has something to do (like evade some anomalies or so)...?

Commander McLane wrote:

Why do we have to discuss this over and over again?

nijineko wrote:

yeah, i'm familiar with the network timing issues. if insta-jump is what is desired

No, you don't seem to be familiar with the network timing issues. If you were, you'd choose other words. Insta-jump is not "desired", it's an absolute and bleedingly obvious necessity. When you and I meet in Lave, our ship clocks have to show the same time. When we meet again in Zaonce two real-life hours later, our ship clocks still have to show the same time, or else we couldn't meet. They have to show the exact same time, although you jumped through ten different systems in the meantime, while I only made one single jump from Lave to Zaonce and then simply parked my ship right next to the witchpoint beacon. The only way to achieve that is to not have any game time passing during a jump.

If you don't believe any of that, please, by all means, go ahead and write a multiplayer version of Oolite. But write it, and don't rant about it. Ranting about something that nobody has any intention of doing is absolutely pointless and a waste of time, forum space, and resources.

we discuss it because it is doable, but not by us. i'm not a good enough coder to tackle something that broad. but i do know enough about coding to comment on it with understanding.

no, i'm not ranting.

yes, i AM familiar with the network issues. insta-jump, as described, is absolutely NOT a necessity in order for ship/computer clocks to be on the same page. super basic example: when you jump location to location abruptly in an mmo game there is a lag while your computer loads the new location. once loading is done, and your computer signals the server that it is ready, and there is a resync that takes place. you lose that time in-game while your computer is doing its thing separate from the server. period. unavoidable.

my suggestion previous, was to take advantage of that fact and incorporate it into the game mechanics by drawing out the time in witchspace by a specific ratio. during that travel time, next level loading is happening in the background. it would actually improve average sync time and reduce overall latency to a degree. thus when you jump from one system to another, a specific amount of time will pass, in-game and out. this aids everyone to remain in sync with everyone else regardless of if they jump, or how many jumps they make.

or to look at it another way, you would be making two insta-jumps instead of one, with a measured stretch in between them - one into witchspace, and one from witchspace into the next system. strategic addressing of the realities of networking and multiplayer. =D

anyhow, if it really bothers you that much, i can leave it for discussion elsewhere. just commenting on something of interest to me since i'm back after such a long hiatus.

GGShinobi wrote:

This made me realize that I'm actually missing some hints on how long the modifications will take when I'm purchasing equipment. The mechanics should be able to tell me (an estimation would suffice)! Should I fill a feature request for this?

The rule is actually pretty simple: 5 minutes, plus 10 seconds per credit.

nijineko wrote:

if insta-jump is what is desired, then adjust the transport and cargo times accordingly.

It significantly changes those timings, though. At the moment, a witchspace jump, depending on range, can take between a couple of hours and a couple of days. Repairs and equipment fitting likewise can take five minutes to five days, depending on what you're buying. You can save literally weeks of in-game time on a long-ish trip by choosing an optimal route and avoiding repairs. The time you spend going from witchpoint to station or sun to refuel is a tiny fraction of the clock time passed: you spend perhaps 99% of your game time either not existing in the physical universe or otherwise skipping the boring bits.

Make jumps/repairs take a length of time that someone would tolerate sitting and watching in real time, and suddenly it's the flying around from witchpoint to station/sun which takes up the majority of the clock time (just as it takes up the majority of the game time). That doesn't just require the timings to be divided by about fifty - it also changes the strategy. Currently it's best to make a lot of short jumps because they're much quicker than a single long jump, and the couple of extra hours you spend flying around inside systems doesn't make much difference. But, making more short jumps means you have less luxury to avoid dangerous systems. If the jumps are instant/minutes in length then long jumps are both the quickest and safest way to make a deadline, and an element of strategy has been lost. If repairs are more-or-less instant, then again you generally lose the "do I have time to get this repaired?" question.