Idea RPG elements

[Codz]

And I certainly, certainly don't see the need to make it more World-of-Warcraft like. Orbiter...is a different kind of fun. It's more...sophisticated somehow.

You seem to be misunderstanding the OP's request. By "RPG", he doesn't mean some fantasy MMO, or a repetitive level-fest with arbitrary rewards. Think more along the lines of Falcon 4.0, or Il-2, with their pilot career modes. It doesn't soften or cheapen the simulation at all, but it gives the user a sort of persistent avatar, or in Orbiter's case, crew to "inhabit".

I'm thinking more about a teacher that wants to install Orbiter on a school computer, which IMHO is quite legitimate. But schools usually have a "no game" policy. So now the distinction isn't arbitrary. The administration does a google search for Orbiter and turns up Star Trek, "resource management" schemes, etc. Are they going to think that Orbiter is a game, or a simulation?

The website itself has a wealth of information about what exactly Orbiter is, and it makes it abundantly clear that it is not a "game". Orbiter can be a fantastic tool to educate both students and laymen about orbital mechanics and the intricacies of spaceflight, but it is also a sandbox with a vibrant community who create and use addons of their choosing, and by extension give a near constant breath of fresh air to Orbiter itself. As great as Orbiter is as a standalone, how many people would continue to use Orbiter on a regular basis for years, without addons? I think it is currently, and will continue to be fine as a combination of both an educational tool, and a recreational sandbox. There's no need to sacrifice one for the other.

 

[2Gm over cxc]

Actually, I can of think that they it do. There, I said it. :hide:

From the perspective of someone that doesn't fully know what Orbiter is, what are they to to make of seeing that most add-ons are from established science fiction franchises where the science is fictional. It doesn't send the message that Orbiter is about accurate physics.

To me it sounds like it sends the message that there is a very active modding community around the program. Yes, someone may be turned off to the program by judging it based on a select few optional mods. But I would bet money that the majority reaction would be one of interest.

Another scenario is that a person with little interest in orbital mechanics may be very interested in something like Star Trek. They see a Star Trek addon, and install Orbiter to check it out. Next think you know, we got another one

And if they really are going to judge an entire program based on a select few, and optional, unofficial mods, that's kinda their problem for being so silly.

Orbiter is certainly entertaining, that isn't quite what I'm saying. I like KSP, too. But I don't see the need to make Orbiter more KSP like. And I certainly, certainly don't see the need to make it more World-of-Warcraft like. Orbiter...is a different kind of fun. It's more...sophisticated somehow.

World-of-Warcraft? Never played the game so I don't know, but what does that have to do with this?

Was it the word RPG that triggered the association?

I'm thinking more about a teacher that wants to install Orbiter on a school computer, which IMHO is quite legitimate. But schools usually have a "no game" policy. So now the distinction isn't arbitrary. The administration does a google search for Orbiter and turns up Star Trek, "resource management" schemes, etc. Are they going to think that Orbiter is a game, or a simulation?

You mean the distinction isn't arbitrary among some arbitrary school computer rules....

A solution would be, don't install any Star Trek mods. But they may need to request a light version of Orbiter which leaves out all those unrealistic spacecraft, which would be everything but the Space Shuttle and a few rockets.

I mean, could you imagine the shock when the teacher reads that Orbiter comes with SSTOs built with unobtainium and with impossible ISP's ?:hmm:

Kidding aside, a hypothetical reaction by a hypothetical teacher in a hypothetical school following hypothetical rules seems like a bit of a stretch as far as addon criticism goes....

 

[boogabooga]

To me it sounds like it sends the message that there is a very active modding community around the program. Yes, someone may be turned off to the program by judging it based on a select few optional mods. But I would bet money that the majority reaction would be one of interest.

Another scenario is that a person with little interest in orbital mechanics may be very interested in something like Star Trek. They see a Star Trek addon, and install Orbiter to check it out. Next think you know, we got another one

And if they really are going to judge an entire program based on a select few, and optional, unofficial mods, that's kinda their problem for being so silly.




World-of-Warcraft? Never played the game so I don't know, but what does that have to do with this?

Was it the word RPG that triggered the association?




You mean the distinction isn't arbitrary among some arbitrary school computer rules....

A solution would be, don't install any Star Trek mods. But they may need to request a light version of Orbiter which leaves out all those unrealistic spacecraft, which would be everything but the Space Shuttle and a few rockets.

I mean, could you imagine the shock when the teacher reads that Orbiter comes with SSTOs built with unobtainium and with impossible ISP's ?:hmm:

Kidding aside, a hypothetical reaction by a hypothetical teacher in a hypothetical school following hypothetical rules seems like a bit of a stretch as far as addon criticism goes....

There is a difference between delta-glider type craft, which are unrealistically engineered but still follow the rules of mechanics and Star-Trek craft which do not obey known laws of physics at all.

Yes, I think I was a bit put off by the use of the phrase "RPG" and may have said some unfair things. My apologies to Star Trek developers. :tiphat:

Having said that, this is what I DO NOT want Orbiter to become:
http://www.orbiter-forum.com/showthread.php?t=31861

 

[2Gm over cxc]

Having said that, this is what I DO NOT want Orbiter to become:
http://www.orbiter-forum.com/showthread.php?t=31861

:lol:

Agreed.

 

[Shifty]

P.S. I just checked out that Kerbal thing and it looks interesting, thanks. I assumed it was pure game, with little in the way of physics and simulation. But it seems it might be legit... Do you know much about the simulation side of it as it would compare to Orbiter?

KSP is more a space program simulator than a flight simulator. And it's a simulator more in the vein of The Sims than FSX, i.e. it's a bit cartoonish; definitely meant to be understood as a game first and simulation second. There are many ways that Orbiter is more hard-core/realistic:
- KSP uses patched conics for gravitation exclusively - 2-body gravitational physics with spherical sources. This is done to facilitate time acceleration, but it does make things like Lagrange points impossible.
- The KSP solar system is much smaller than the real one. The whole thing, from the sun to the outermost planet (Eeloo) would fit inside Venus's orbit. Again, this is done to facilitate playability. Interplanetary transfers can happen in reasonable times.
- All planets (and moons) in KSP have their equatorial and rotational planes aligned. (Though they do have varying eccentricities and inclinations.)
- Atomspheres in KSP taper off exponentially with altitude, but also simply don't exist above certain cut-offs. It's possible to have a perfectly stable orbit just outside the atmosphere that lasts 100 million years.
- KSP vessel instrument panels are typically rudimentary (the capability exists to make them more complex, but I've never seen one that is) and there's no HUD. The vessels are not really meant to be flown from inside the cockpit. I suspect this is mostly because vessels are built from components and so command pods have to be somewhat general.


On the other hand:
- KSP has a full featured lego-like vehicle editor where you can build rockets, space (or atomspheric) planes, rovers, landers, space station components, etc out of a variety (hundreds) of components, then (attempt to) launch them into space. Orbital mechanics are accurately modeled (for 2-body systems.)
- Collision detection is modeled and momentum is transferred appropriately when docking with (or crashing into) another vessel.
- Planetary surfaces have full terrain: mountain ranges, crater walls, canyons, etc. There is water, with a flotation physics model.
- An effort has been made to make orbital mechanics easier to visualize, with a map screen which shows the orbit in 3D and "maneuvering nodes" which let you plan maneuvers in advance and show you how they'll affect your orbit.
- Like Orbiter, there is a robust mod community with hundreds of add-ons.

 

[kamaz]

But the work has decent pay, providing David operates efficiently and causes no accidents (maintenance is expensive!). After a few jobs as a delivery man, David has enough money to upgrade his XR-2 (via changes to the config file).

Programmatically, that's quite easy ("easy" as in "a 2nd year student project"). You write a program which allows you to configure XR2 taking into account budget. Then it generates the XR2 ini file and the scenario file, and launches Orbiter. You fly the mission in Orbiter. After you exit Orbiter, the program looks at (Current state).scn, checks if mission goal has been met, looks for damages etc. and updates the budget accordingly. Rinse and repeat.

So the programming part is easy. What is much more challenging and time-consuming is design -- i.e. how to define missions/goals and upgrades/prices that the whole thing is actually fun. For example, how many ISS missions must the player do before he can afford equipment for flying Moon missions?

BTW: If you can't resist cheating by pressing F4, delete Modules\Plugin\ScnEditor.dll

 

[2Gm over cxc]

BTW: If you can't resist cheating by pressing F4, delete Modules\Plugin\ScnEditor.dll

:lol:

What can I say? I was the kid who finished his entire pack of Bubalicious/Big League Chew within 5 minutes. :jiggy:

My programing is limited to Excel functions and writing high school physics equations on a TI-83+........

But my design/imaginative/creative skills are pretty good. I'd like to think I am no amateur in the fun and vision department lol.

And I have certainly played enough games and tweaked enough cfg. files to know a thing or two about balance and rewarding but challenging progression.


If any developer is interested in anything in this direction, I would love to be involved in the design/balance department.

 

[Urwumpe]

:lol:
If any developer is interested in anything in this direction, I would love to be involved in the design/balance department.

I currently do some initial research about a dynamic campaign module for an add-on that I currently develop, but it won't appear this year for sure. Technically, there is nothing that speaks against the current plan, but gameplay wise, I am not sure if it works out.

The rough outline of the module:

1. There is a special DLL for Orbiter, that provides the API and functionality of the dynamic campaign generator.
2. When running Orbiter, this DLL will run in the background and maintain and monitor the global campaign state during the mission
3. When you fullfil some not yet defined conditions, the dynamic campaign generator will become active.
4. The DLL processes the current global state, lets AI vehicles finish their missions and handles the logistics and new AI missions while the player is resting, his vehicle repaired (or replaced) and the
5. The DLL generates and writes the next scenario into a subfolder of the current context: "Scenarios/<vessel context>/Campaigns/<Player name>/<Campaign name>"
6. The DLL shows a dialog in Orbiter about the out-come of the last mission and requests the player to quit Orbiter (though this could also be done by the DLL)
7. The DLL also generates a set of post-mission files, like newspapers, reports or statistics.

It would also be possible to keep the campaign running in Orbiter without quitting, but that would require much more capable vehicles in the simulation. You would need much more ground handling, rearming, repairs and logistics, even in a very abstract way, this would mean a lot of code to write especially for each vessel (additional to the lots of code in the campaign DLL). This could be too much work.



Also, saving the missions as scenario and starting again could allow exchanging the campaign later with other players to play it as single missions.

 

[4throck]

Looks simple enough to actually work :thumbup:

Regarding upgrades to vessels: I don't think that would work, because its up to each developer to implement new functionalities or not.

Perhaps the players should be rewarded repaints (there are many already) or clearance to land in certain bases (many already exist). Simple draw on what's already available on OH.

Example of a mission tree using what exists:
mission 1 » Apollo to earth orbit and return
mission 2a » Apollo to Skylab
mission 2b » Apollo to lunar orbit
etc....


Orbiter AI traffic is a separate topic. It would be great to have it, regardless of career mode or not.

 

[2Gm over cxc]

Looks simple enough to actually work :thumbup:

Regarding upgrades to vessels: I don't think that would work, because its up to each developer to implement new functionalities or not.

Regarding upgrades, couldn't this be done via changes in the cfg. file?

Things like better ISP, thrust, lower weight, seating capacity, oxygen use, fuel capacity, ect.

Providing that it were possible to add a script (if that is the correct word?) which could edit the cfg. upon certain conditions being met. Such as spending some sort of currency or completing a task.

Then one could add a semi-realistic description for what the upgrades actually do to add to the immersion.

For example:

"Coiled propellant piping surrounding the combustion chamber - The motor can now burn hotter without melting: Increased main engine thrust with a slight increase in propellant consumption. Main engine thrust increased by 10%, decreased ISP by 3%. 14,000 Orbidollars. Installation: 2,000 Orbidollars."

"Additional folded arms installed on the XR grappling system - Payload grapple range increased by 20 meters, dry weight increased by 85kg. 2,000 Orbidollars. Installation: 500 Orbidollars."

"Precision ceramic landing gear bearings - Wheel surface friction coefficient decreased by 15%, maximum wheel break force decreased by 5%. 4,000 Oribdollars. Installation: 1,000 Orbidollars."

"Re-calibrated nozzle geometry - ISP increased by 10%. Installation and machining: 10,000 Orbidollars."

"Propellant replacement suite: LOX/RP-1 is exchanged with fluorine/hydrogen (F2/H2) - ISP increased by 50%. Due to increased corrosion and environmental clean up, propellant and motor maintenance costs increased by 20%, and an environmental tax of 5% is added to all future purchases. 100,000 Orbidollars. Installation: 50,000 Orbidollars." (Possible changes in fuel quantity as well due to decreased density...)


ect.

I like the idea of adding in both a component cost, as well as an installation cost. This way, upgrades do not need to be permanent, and can be swapped out and stored in the pilot's personal hanger depending on the pilots needs. The installation costs also add a level of strategic thinking, as the spacecraft cannot just be made ideal for every situation with no cost to the pilot.

Also, thanks Urwumpe for that post. Need to read it over again lol.

 

[Hielor]

Regarding upgrades, couldn't this be done via changes in the cfg. file?

Things like better ISP, thrust, lower weight, seating capacity, oxygen use, fuel capacity, ect.

All but the simplest Orbiter vessels define these parameters in a module instead of the config file. Any interesting vessels (XR2, DGIV, stock DG even) won't work this way.

You'd need to make any vessels that you wanted to support this method yourself--and at the point you're making them yourself, there's probably better ways of doing it than using the config files.

Plus, making the vessels yourself for this sort of addon gives you the advantage of being able to control the look-and-feel of the entire universe, so that things are consistent. Not necessarily bad, just time-consuming.

 

[2Gm over cxc]

All but the simplest Orbiter vessels define these parameters in a module instead of the config file. Any interesting vessels (XR2, DGIV, stock DG even) won't work this way.

Doesn't the XR series use a config file? At least that is where I always modified the parameters. Or maybe I didn't understand your post.

 

[Hielor]

Doesn't the XR series use a config file? At least that is where I always modified the parameters. Or maybe I didn't understand your post.

Maybe? But it's not a universal solution.

 

[malisle]

UCGO has a great potential that was never truly used to give Orbiter a role-playing side, although there were some good tries, like this. Whatever ideas and/or add-ons come out of this thread, it would be great if it utilized this piece of "infrastructure" in some way.

What makes sense for me is some kind of crew / resource management on space-stations or bases. It could be something as simple as keeping a log of your flights, with some planning tool to help you choose where to go next.

Such as system could easily incorporate some RGP elements. For example, once you land on the 4 jovian satellites, you get a "galilean satellite award".

All this would only be accessible to the pilot while docked or landed on a base.
So it wouldn't interfere with the "flying" (that makes orbiter unique) but it would give you something to do once you reach your destination.

Orbiter could use some sort of achievement system similar to what FSX has. It's not campaign, but people seem to love those.

 

[2Gm over cxc]

UCGO has a great potential that was never truly used to give Orbiter a role-playing side, although there were some good tries, like this. Whatever ideas and/or add-ons come out of this thread, it would be great if it utilized this piece of "infrastructure" in some way.

Fully agreed. :thumbup:

I remember looking at this addon a while back, and it looked very interesting.

So many people have put in hard work to create infrastructure like the item you linked. It only seems natural to link these elements in a way that gives a specific goal, and builds on itself.

For example, I love the space station building blocks. But once I completed my first station, I never used it again. Now if building a station around a Jupiter moon with an ore-extraction operation opened up further possibilities, such as colonization and residential base demand...... I then have a reason to earn income to purchase something like a long-haul cargo-optimized XR-5 to meet that demand.

Then once that is completed, there is a waypoint with enough fuel and supplies to expand my operation - maybe to Saturn's moons :hmm:

 

[MJR]

Fully agreed. :thumbup:

I remember looking at this addon a while back, and it looked very interesting.

So many people have put in hard work to create infrastructure like the item you linked. It only seems natural to link these elements in a way that gives a specific goal, and builds on itself.

For example, I love the space station building blocks. But once I completed my first station, I never used it again. Now if building a station around a Jupiter moon with an ore-extraction operation opened up further possibilities, such as colonization and residential base demand...... I then have a reason to earn income to purchase something like a long-haul cargo-optimized XR-5 to meet that demand.

Then once that is completed, there is a waypoint with enough fuel and supplies to expand my operation - maybe to Saturn's moons :hmm:

I kinda like that idea of ore-extraction and maybe delivery. Sounds within the realm of possibility. I think it would need to be a huge collaboration though. If we could pull in many of the great brains here I am sure something like this is possible. By the way, what ever happened to that collision module that was being made? I think it was October Sky or something?

 

[kamaz]

[Editing a config file is] not a universal solution [for setting engine ISP]

If you want to create a playable prototype quickly, then generating an XR2 config file is the simplest way. As an engineer, I prefer working, if deficient, prototypes over perfection on paper

After looking at the API, a universal solution seems possible: calling VESSEL::SetThrusterISP() inside clbkPreStep() should override whatever the vehicle code sets by default.

---------- Post added at 10:07 PM ---------- Previous post was at 09:59 PM ----------

UCGO has a great potential that was never truly used to give Orbiter a role-playing side, although there were some good tries, like this. Whatever ideas and/or add-ons come out of this thread, it would be great if it utilized this piece of "infrastructure" in some way.

I thought about it yesterday evening, and came to this:

Mission: "Blah, blah, blah, deliver water to Brighton Beach".

Mission is completed if all these conditions are met:

primary body is MOON,
vehicle state is LANDED,
vehicle position is WITHIN 1km of Brighton Beach,
vehicle carries AT LEAST 1 WATER UCGO.

Scenario: contains a stack of water UCGOs (or a machine creating water UCGOs) at Shackleton Crater.

Find some way to script the above in a generic way, and you can define missions.

 

[Urwumpe]

Maybe, such a mission design could be done by scripting with Lua, maybe with some additional C++ module for more complex functions.

Of course, Orbiter is a sandbox and it would be cooler if Orbiter could stay a sandbox. There are works on an economics systems for Orbiter, but a RPG would be a bit more.

 

[kamaz]

Of course, Orbiter is a sandbox and it would be cooler if Orbiter could stay a sandbox. There are works on an economics systems for Orbiter, but a RPG would be a bit more.

I do not see why there would be a conflict.

Just include a switch disabling the logic verifying mission completion. If enabled, you have an RPG. If disabled, you play the same scenario in sandbox mode.

 

[Urwumpe]

I do not see why there would be a conflict.

Just include a switch disabling the logic verifying mission completion. If enabled, you have an RPG. If disabled, you play the same scenario in sandbox mode.

No, I rather mean a sandbox world for a RPG, like you have in many modern RPGs. Not too much focussed on one storyline and static missions.