Elite 4 with orbiter engine
- Thread starter Schimz
- Start date
jedidia
shoemaker without legs
planning something in those lines, but the amount of work is not much less than doing it from scratch. Maybe I shall get seriously started with it one day, but for now I'm more or less in preperations, helping with mods that seem interesting and helpfull in the task and taking it tiny step by tiny step. I don't think anything serious will produce in the next three years... 
GregBurch
Addon Developer
With my "mega-project" of creating a more or less integrated "future history" set of addons, an economic/social "gaming" extension of Orbiter is something I've spent quite a bit of time thinking about. I've got sketches of logic design, and notes here and there about how such a system could work. Being a coding retard, though, such a project is far, far beyond my personal capabilities.
With that said, I'd be very interested in following the development of a real economic/social sim-game extension of Orbiter.
With that said, I'd be very interested in following the development of a real economic/social sim-game extension of Orbiter.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
I had started some small third-party add-on work for creating a stupid economic model for World of 2001, mostly based on generating cargo containers with a destination. Maybe this could be used as more "Orbiter genuine" world.
Of course, once the stupid model works, nothing speaks against creating a not so stupid system.
Of course, once the stupid model works, nothing speaks against creating a not so stupid system.
bujin
New member
I don't think anything serious will produce in the next three years...
By then, we might David Braben might even have released Elite 4.
:rofl:
jedidia
shoemaker without legs
Indeed...
I think my problem is that I'm fed up with static game worlds. There are actually quite good elite-type games nowadays, eg. the open-source Vega Strike or the Indy-game Evochron Renegades (which is the first game after FFE to reintroduce seamless planetary flight - or quasi seamless. Anyways, for 25$ it is probably the best game for the cheapest price in that cathegory ever produced).
But they all are pretty static. My first aim is to get a Meta-engine that handles politics, economics, research, outpost building etc (think: master of orion), which wouldn't be so difficult per se... but making it detailed enough that it can support an imersive world for an rpg type of game is quite a different thing, especially if you want it to generate missions based on the game-word context. And if you don't, it's not really worth the effort.
Urwumpe
Not funny anymore
- Joined
- Feb 6, 2008
- Messages
- 38,965
- Reaction score
- 3,937
- Points
- 203
- Location
- Wolfsburg
- Preferred Pronouns
- Sire
Well, you are right, but I think you can develop a immersive world from a simple static world, in form of a progressive development.
For example, you can first start making a static world, which is in balance: Stations require goods, produce goods and there is no reason for change. Then, you could extend this model by a demand and supply based economy, which will make it already pretty dynamic.
Also, you could for example add a new plot engine to the economy, for example military missions or exploration.
Important is just: In Orbiter, you need a constant progress in development. Good ideas have to be scheduled for later, and you have to find the required missing links, to get forward. Long phases without progress and revolutions, are not the best here, as you would require community support for such a big project.
Tommy
Well-known member
I've also considered something like this. I have come to the conclusion that this could be best accomplished by a modular system. This would allow the user to select only the options they want, for instance by using the economics module but not the RPG aspects. It also allows different developers to use basic modules in their own projects without having to reinvent the wheel.
One of the bigger problems I've seen is in how to handle consumables like fuel and O2, even water (which would be expensive on a Jupiter station for example). My best idea was to create a "consumablesSDK" that ship designers could build into their ships. There would also be a "consumables" mod, and ships could check to see if it's enabled to determine whether or not to "charge" for consumables. The SDk would allow "cash" purchases, and also "credit card" purchases for people flying missions for the government or an employer. I felt this is best handled in the ship's code for two reasons: to enable easier bypassing of Orbiter's automatic refuel when landed on a pad or docked; and so that built-in refueling like on the DG-IV and the XR series could still be used rather than force everyone to use a special "consumables aware" refueling MFD. The MFD could still be used for non "Consumables aware" ships.
The various people working on economics projects such as Orbitrader could use the "consumablesSDK". I would think it's better to track cargo by weight rather than by the container since not all ships will be able to handle a TEU sized payload.
Also needed would be a "spaceport" vessel. I figured a Ummu compatible vessel that may not even have a mesh, and could be placed in a non-active building mesh already at the base (eliminating having identical spaceport buildings at every base). It would consist of an airlock, Ummu code, and a 2-d panel to interface with with the cargo and economics modules.
All these modules should save their data in the scenario file when the save callback is called, and store data in text or XML files during play to allow iteraction with other modules, or even other programs. That way something like Blender could be used to make games that handle the stuff that Orbiter isn't capable of doing. Blender's built in game engine could be used to create a first person RPG to handle the storyline, or be able to wander around a base and check the bar for rumors, etc. When you accepted a mission or entered the spaceport the Blender game would create the scenario file for Orbiter, name it "current state" and launch Orbiter. A "mission" module would handle tracking mission success.
Unfortunately it will be at least a year before I can begin actually starting to work on this. and as a novice coder I expect it will take quite a while before anything actually works.
One of the bigger problems I've seen is in how to handle consumables like fuel and O2, even water (which would be expensive on a Jupiter station for example). My best idea was to create a "consumablesSDK" that ship designers could build into their ships. There would also be a "consumables" mod, and ships could check to see if it's enabled to determine whether or not to "charge" for consumables. The SDk would allow "cash" purchases, and also "credit card" purchases for people flying missions for the government or an employer. I felt this is best handled in the ship's code for two reasons: to enable easier bypassing of Orbiter's automatic refuel when landed on a pad or docked; and so that built-in refueling like on the DG-IV and the XR series could still be used rather than force everyone to use a special "consumables aware" refueling MFD. The MFD could still be used for non "Consumables aware" ships.
The various people working on economics projects such as Orbitrader could use the "consumablesSDK". I would think it's better to track cargo by weight rather than by the container since not all ships will be able to handle a TEU sized payload.
Also needed would be a "spaceport" vessel. I figured a Ummu compatible vessel that may not even have a mesh, and could be placed in a non-active building mesh already at the base (eliminating having identical spaceport buildings at every base). It would consist of an airlock, Ummu code, and a 2-d panel to interface with with the cargo and economics modules.
All these modules should save their data in the scenario file when the save callback is called, and store data in text or XML files during play to allow iteraction with other modules, or even other programs. That way something like Blender could be used to make games that handle the stuff that Orbiter isn't capable of doing. Blender's built in game engine could be used to create a first person RPG to handle the storyline, or be able to wander around a base and check the bar for rumors, etc. When you accepted a mission or entered the spaceport the Blender game would create the scenario file for Orbiter, name it "current state" and launch Orbiter. A "mission" module would handle tracking mission success.
Unfortunately it will be at least a year before I can begin actually starting to work on this. and as a novice coder I expect it will take quite a while before anything actually works.
jedidia
shoemaker without legs
A concept for extendable spaceports on vessel basis is in preparation, but will take time until seriously attempted. Majorly because IMS (Interplanetary modular ship) will be the platform to build it on, and I want that one finished and running properly before using the code to build anything else on it. Making the whole thing Orulex compatible would be a major factor, I guess it could be done with help from Artlav. We'll see when the time comes...
