Orbiter MMORPG

Orbiter MMORPG

Orbiter MMORPG started in a [thread on Orbiter-Forums], bringing up the idea of Orbiter role playing in a persistent universe for what seemed like the 100th time. What followed was a discussion about why nobody is actually doing the work instead of only talking. Some users actually plucked up their courage and started to outline their ideas properly.

This page tries to be both a collaboration point for the development of a design document and a reference for future discussions on the topic.

The following topics present the ideas of certain users.

Kaito's Idea of an Orbiter Multiplayer Platform

This was made by Kaito from Orbiter-Forum on November 15th, 2009.

Following a discussion on Orbiter-Forum, someone though of a Orbiter RPG. Everyone pointed him to these multiplayer links. However, if you think about it, there can be two different idea's for multiplayer: an "Orbiter" type multiplayer, where there are no set goals, the goals are made by your brain, or an "RPG" type multiplayer, where you have a goal, no matter how small or insignificant. A common "goal" in most MMORPG's is to become stronger. A goal for an RPG Style Orbiter would be to, say, make a base on the moon, or keep some explorers alive by sending supplies.

Synchronizing time

I have a feeling this would be "simple" (I am not a coder, so I don't know to much about this): Have a server, and when someone connects to this server, change the clients time to the servers time

Lag

Eve Online has exactly one server, and they can support more then 40,000 people on it. Why? Because they have over 1,500 "solar systems", each with their own stations, asteroid belts, etc. All these are "hubs", where nearly everyone gathers. Almost no one is in between these "hubs". If you are not inside one of these "hubs", the ships aren't rendered, so there isn't much lag caused by one client. This same sort of idea can be used in orbiter: Don't retrieve information on it unless it is within rendering range. Now, of course, this causes a problem when you are going to the ISS, and there are 15 people in line, waiting to dock. If this is the case, maybe intentionally slow-down the information sent to the Client. Example: The Rendering Distance is 100km. You are 101km away from ISS, just passing into Rendering Distance now. There are 15 people around the ISS currently, which would surely slow-down your client if the information was sent all at once. So, orbiter renders each ship "separately" based on a "Level of Importance". The ISS would be rendered first, then maybe at 95km, another ship, then at 90km, another ship. This way, You would still see all the ships in time to make adjustments, but your client wasn't flooded all at once with a bunch of information that wont be useful until later.

Goals

The idea of goals and consequences could be what drives Orbiter Multiplayer. Forgetting to de-orbit your fuel tank and having it be a problem for the next guy could lead to a bunch of different things (Space Terrorism and Grieving (Intentionally causing other players to have a bad time)). However, teamwork could also arise: Trying to build a space station by yourself would be difficult, so you would need more people to help construct it, launch, monitor, etc.

Time Acceleration

The nice thing about Orbiter is the ability to make time go fast. You can land on the moon and be back in time for lunch. However, this causes an obvious problem in multiplayer. However, I think this could be resolved in some sort of way: 1) Confine most things to Earth and Moon. If someone has the time and patience to go to Mars, no one is stopping them, but it would be a boring 7 months. 2) If someone would like to time accelerate, put in a "request", which would be sent to everyone on the server at the time. If there is one "decline", then the time acceleration would not go through, until everyone agreed. The "request" would state the degree(10x, 100000x) and time (5 seconds, 10 seconds) of the acceleration. 3) "Off-line" people would be affected by this acceleration, but they could not vote. They would be subject to the needs of everyone else 3.1) This poses a problem. Lets say someone is going to the moon, and they log off. The next day they log on to find out they already passed the moon because of an un-natural amount of time acceleration by other players. I think people would learn that this is a necessary evil of time acceleration 4) Abuse of the system: Yes, people could abuse it, but that's what fair moderators are for.

Orbiter Online - Milestone 0 Goals Thread by Brad Hawthorne

0. Define the purpose, scope and background of the add-on

Orbiter Online is to be a set of add-ons for the Orbiter simulator. The purpose of the project is to add another layer of complexity and interest for the Orbiter community to enjoy, help build and be a part of. This is merely adding a social aspect to the simulator and a few systems to give meaning to flying other than just because you can. We could easily design something too complex to implement -- which is not what I want to see. I'd like to see us come up with something both feasible and fun that can plug into Orbiter.

It is the near future. Earth still has the current political structure as present day but we're just now establishing semi-permanent commercial footholds in Earth orbit, the Lunar surface, Mars surface and certain portions of the asteroid belt.

Earth Initiatives: There have been incentives pushed for low and null gravity manufacturing and production of products outside the Earth gravity well. Also certain factions of Earth government are pushing a "clean Earth" initiative that seeks off-Earth resources to replace and phase out many of the resource dependencies that drive the Earth economy. A shift from terrestrial coal and fossil fuels to new resources that can be found on the Moon or other places within the solar system.

Lunar and Mars Initiatives: The Moon and Mars also have colonization initiatives currently in place to seek development on those locations. Resources on both locations are in high demand to accomplish colonization goals and establish on-site industrial base for futher expansion.

Outer-Rim Initiatives: Why not have a wild outer rim, without established big bases like in the inner solar system, but instead some island-like wild settlements, like for example the Jovian or Kronian system. After all, it would be some sort of gentrification in the solar system, if you politically start out like that - bigger companies that take less risks would displace smaller, more risk-seeking companies, forcing them further outward for not getting into lossy competition with the big ones. Of course, you would then need also ship wharfs and factories, which would be more around Earth, but maybe establishing small wharfs and factories outside the inner solar system might offer some good plots.

1. Define core developer positions for the add-on

• Project Coordinator - A position meant to help steer the overall project and play cat herder as needed with project devs and resources.
• Programmer - The key people who take the concepts and make them reality. This would be a title that would cover aspects such as server programmer, add-on programmer, voice-chat integration programmer, etc...
• Media Artist - Works on both 2D and 3D art assets for the add-on. Includes a wide range of media assets for user interface, cockpit panels, ship models, etc...
• Systems Designer - A catch-all title for those with interest in helping with the theoretical aspects of the add-on design including but not limited to all aspects of the game such as economy, building, corporations, mining, construction and anything in-between. Systems mechanics and how those systems interact.
• Quality Control - A group of people within the dev pool that test all aspect of the add-on and notify the dev pool if any bugs or balance issues need to be addressed. This would also be the group who would test out individual add-on assets for compatibility with the Orbiter Online add-on to make sure there are no incompatibilities.

2. Define the sub-systems of the add-on

• Key Add-On Systems - Economy, Communication, Quests, News
• Economy - Establish and define a system based on finite resources, the exploration of the resources and the ability to harvest them. Have the further ability to manufacture useful items from those base resources though construction and manufacturing mechanics. Impose a supply and demand mechanic on every entity in the add-on.
• Communication - Define the ways communication could occur within the add-on. Text communication could be piped in via an IRC interface and voice chat could be integrated via either ventrillo or teamspeak SDK with appropriate time delays enforced within the client-server design. An email system might also be useful to explore.
• Quests - I envision the quest system for the add-on to use dynamic player generated content based on supply-demand needs of the playerbase. Quest content could also be generated by News events or goals internal to your corporation or country affiliation. Quests could be at the level of plots and missions. Plots would be elements of a bigger storyline, while missions happen in between and only have side effects on the plots.
• News - Current events and how they unfold within the add-on is an important aspect to give meaning to the interaction in the add-on. While supply-demand mechanics will drive much activity being made aware of such supply-demand issues via add-on News will also be important.

3. Put infrastructure in place for dev group to communicate

• Forums - Face has offered use of the OMP sub-forums for this.
• IRC - irc.orbithangar.com #orbiter-online
• VoIP - VoIP embedded in multiplayer framework as needed.
• Wiki - To help document the add-on

See also

• Multi-player -- an overview of multi-player add-ons for Orbiter
• IRCMFD
• Multiorb
• OMP
• Project Hamac