Despite having grown to encompass a great many features since it was initially developed in 2010, Stargate remains underpinned by its initial philosophy.

This Design Philosophy was first conceived by Sturmeh and Dinnerbone, who made future development of this project contingent on its adherence. This philosophy was expanded years later by Drakia and has now been formalized on this page by the Stargate Rewritten Project.

This design philosophy influences the selection, scope, design, and implementations of all features included in StarGate Project’s core branch. Desirable features that fall outside of the philosophy are instead implemented in modules found here (part of the Addon System).

Stargate’s design philosophy consists of three pillars:

StarGate’s intended usage is as a transportation system that is accessible to and intuitively constructable by end users.
It is not enough for a server’s users to be able to use portals set up by admins, nor is it enough for particularly savvy users to be able to construct portals should they so wish.

Rather, it is necessary by design for end users to be able to create and use portals through the course of their regular gameplay. By promoting user-facing portal systems, our goals with this specification are twofold:

• To Build Communities
  • MineCraft worlds are vast; within Vanilla gameplay, players (or groups thereof) are unlikely to run into others.
  • StarGates (when widely adopted) help bridge the otherwise vast distance between players, bases, and other players.
  • This encourages community interactions and helps build the social elements of a community.
• To Organise Localities
  • In certain gamemodes (for example Towny), players reside in sprawling distant communities;
  • Through the establishment of portal hubs (i.e. “Terminals”) at various scales (in this example, towns and nations), communities become connected and curated.
    • Existing users are better equipped to navigate these communities, and new users are more readily able to find and explore places to reside.

For end-user portal usage and construction to be possible and desirable, an intuitive player-facing system is a must.

StarGate’s intended experience is to be an immersive expansion of — not an addition to — the MC gameplay experience.
Immersion has always been at the center of Stargate’s Philosophy, and was an original principle outlined by Dinnerbone.

This is a key feature that distinguishes StarGate from other transportation plugins, and has always been;
It is not enough for players to be able to intuitively make portals; they must be able to do it without pausing their gameplay.

Unlike most other transportation plugins, it should be possible to use all features of the plugin (notwithstanding administration) without commands. This is to say that Stargate must integrate all of its functionality within MineCraft’s gameplay experience.

The benefits of maintaining immersion are numerous

• Complementing Mojang’s User Experience.
  • MineCraft as a game has been carefully designed by Mojang, both in terms of User Experience and User Interfaces.
    • By not interrupting the gameplay experience, SG simply complements Mojang’s design choices.
  • StarGates should, conceptually, be treated as a mechanic of the game; not as a system shoehorned into it.
• Subconcious Integration.
  • Players are more likely to subconsciously use features they consider to be part of normal gameplay.

StarGate’s intended controls are accessible, self-contained, and expandable; to be wielded by admins of all skill levels.
StarGate must be accessible to new admins, usable and/or maintainable in the absence of the SG-Rewritten Project, and easily expandable to fit future ideas and gameplay elements.

These three administrative requirements are mostly grounded in our past as a project:

• Accessible to New Admins
  • A ubiquitous presence at the dawn of MC multiplayer, SG was once widely used by new admins on their first servers.
    • While this is not always the case anymore, we still hope to be accessible to such users.
  • Configuring StarGate should be self explanatory.
• Accessible Outside of the Anglosphere
  • For the past decade, up to half of SG communities have been non-english (especially JP & CN).
    • Everything necessary for the plugin to run should be localised; including user-facing messages and key admin-facing documentation and explanations.
  • To keep such documentation maintainable in the face of limited localisation resources, it is essential that the core’s configuration information and documentation be kept small and digestible.
• The Core Must be Self-Contained
  • Despite several years without any clear lead maintainers, as a result of dozens of short-lived forks, StarGate has remained one of MC’s longest continuously maintained plugins. Every release version of MineCraft has been accompanied by at least one functional release of StarGate.
  • Although all forks have now consolidated into a single project, and although there are clear benefits to certain centralised services (hosted web interfaces for example), it is essential that the core remain functional in the future, even in the absence of the StarGate-Rewritten Project.
• The Core Must be Expandable
  • SG is an old concept, and although it is important to stay close to our roots, this shouldn’t preclude new ideas or novel usages of new features and/or gameplay. SG must therefore be expandable, and through an API, mudles, addons, and the like should be officially supported.

Having outlined the rationale, the following practices apply.
Note that there are circumstances wherein certain features that violate a Philosophy Pillar are broadly useful and/or beneficial. In such cases, they should be excluded from the core and included in a Module, as described below.

• Even if a feature is Immersive, it is not necessarily Intuitive. This is to say that some features, although philosophy compliant, are unnecessarily complicated and/or are only useful for a minority of users.
• If a feature is complicated to explain, is not intuitive, or is unlikely to be widely used, it should not be part of the core or the Core’s documentation.

If a feature is only useful to a small subset of users, difficult to explain, and/or unintuitive;
Provided the feature is also immersive, it belongs in the Stargate-Mechanics Module.

• Commands, non-vanilla interfaces, etc. must not be a requirement to make, use, or destroy StarGates.
  • Notwithstanding the above, features only accessible to administrators (for example, plugin configuration, gate design, etc.) are not subject to this restriction, provided they are Wieldy.
• If a feature requires interfering with normal game-play, for example typing a command or visiting a website, it should not be part of the core.

If a feature breaks gameplay immersion, but is also useful or facilitiates a requested use case;
Provided the feature is also intuitive, it belongs in the Stargate-Interfaces Module.

• Any feature requiring an additional .yml configuration file(s) or exceedingly granular file-based that may be described as applying “tweaks” belongs in neither the Core nor its documentation.
• Likewise, any niche feature that is only useful to a small minority of users does not visibly belong in the core’s config.yml. Hidden nodes are acceptable, but must be documented separately from the Core’s wiki.
• Any feature necessitating hosting by the SGR project does not belong in the Core (which must be self-contained). This especially includes any web interfaces.

If a control customises or tweaks useful behaviour, but requires an editor or extra .yml file;
Provided adequate documentation / intuition, it belongs in the Stargate-Customisations module