Endless Sky: Game Development Vision

[MasterOfGrey]

Introduction

This discussion is to serve as a space for developing and communicating a consistent vision of what Endless Sky should look like as a final product. The key to this, is recognising that the Experience that makes ES what it is, is more than just a laundry-list of features. It is as much a holistic vibe as it is any particular mechanism which contributes to that.

To this end, this should be considered an evolution of the Roadmap to identify not just which features we want in the game, but why we want those features - and why we might reject other features (or have them implemented only as possibilities for plug-ins, and not for vanilla use.)

Structure of a Vision

To this end a Vision has 2 elements; which in formal terms are "Values" and "Principles".

• "Values" - the goals for the gameplay experience; what we want playing the game to feel like.
• "Principles" - the derived gameplay design elements that are targeted to create that desired experience.

We'll stick to just the "Vision for Gameplay Experience" and the "Vision for <game development area>" for clarity in going forward though.

The Gameplay Experience level should paint with a broad brush - it's not about what's in the game, it's about what players get out of it.
The Subsequent areas should be descriptive of features, not features themselves - they are the types of features which support the gameplay experience vision.

For example, a top level element of the Vision might be:
"A game that rewards multiple different playstyles."
Some principles of the "Vision for Game Mechanics" might then be:
"Similar levels of in-game profit from different playstyles, requires similar levels of effort to master complexity."
"Similar levels of IRL time needed to build the same levels of profit from different playstyles."

At the end of the day, it should be possible to summarise the overall approach of the vision, in only one or two sentences. Essentially a statement as to the "Goal" of the Project.
This test allows you to identify if the vision is cohesive enough to be readily tested, or if it needs more work.

Process

To submit an element to be discussed and added, please write a new top-level comment for this discussion so that things don't get lost in threads of discussion under something else.

In the section just below this, I will track all of the proposed items, as well as those pulled from existing resources, and make sure they are properly sorted into consistent categories for cohesiveness.

Where obvious conflicts emerge, I will extract those and place them in a conflicts section at the bottom, and open a comment thread for that specific conflict to be discussed. Hopefully, in those cases, a value statement can be derived which explicitly defines the balance between two points, or one can be promoted on account of synergy with other accepted statements.

Items drawn initially from other sources (such as Style Goals) will be noted with a *.
If you find them controversial, feel free to open a comment on them and the * will be removed once there is an active discussion.

NOTE: The categories are not fixed and can be changed up. Split/merged/renamed/etc. but should not be done so until there are at least 4 items in a category to split, or there are fewer than 6 items after a significant period of time between two categories to be merged. Let's not get bogged down in the categories until we have things of substance to discuss.

Endless Sky: Game Development Vision

This is the drafting zone, this is what is under consideration:

Vision for Gameplay Experience

1. "A game that rewards multiple different playstyles."*
2. "A game that feels smooth and minimalist, yet futuristic, with hints at an underlying complexity."*
3. "A game with significant replay value derived from player choices and believable world-building."*
4. "A game which rewards exploration but does not penalize simple narrative enjoyment."*

Vision Summary Statement (The Goal of the Project):

"Endless Sky should be a sandbox-style space exploration game, focused on player driven story telling, with a galaxy filled with alien species, that all follow a cohesive narrative."*
(This is just a placeholder for now, taken from here:)

Vision for Development Areas

Vision for Art Style

1. "Stellar objects should look as realistic as is feasible. A real photo from NASA should be just as at home as a fully imagined art sprite."*

Vision for Content Approach

1. "Each species provides a different narrative to explore different themes without unnecessary repetition."*
2. "Parallel and mutually exclusive storylines to explore different perspectives from their own lenses, with no meta-defined good or evil."*
3. "People should act like real people, even if the technology doesn't act like real technology."*

Vision for Mechanical Style

1. "Similar levels of in-game profit from different playstyles, requires similar levels of effort to master complexity."*
2. "Similar levels of IRL time needed to build the same levels of profit from different playstyles."*
3. "Realism should only be pursued where it enhances the gameplay experience in alignment with the vision, not merely for the sake of it."*

Vision for Engine Performance

1. "The game runs on a wide variety of devices, especially including older and less powerful ones."

Conflicts Needing Resolution:

TBD

[roadrunner56]

Considering the fact that a lot of collaborative projects have some sort of outline or guide for what they're trying to accomplish (Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Purpose and Battle for Wesnoth: https://www.wesnoth.org/constitution/ are just two off the top of my head), I think this is something that we should hammer out to ensure that we have clear goals in mind for what we want to see in this game.

[RisingLeaf]

To engine performance:
The game runs on wide variety of devices including especially older and less powerful ones.

[xX-Dillinger-Xx]

Plugins:

• the use of plugins should have a tighter control over what a plugin can do
• plugins should be add on or complimentary content
• plugins should not alter or change content that is already in vanilla. This is a big one.
• plugins should not leave vanilla in a broken state if a plugin is removed
  • when a plugin is removed it should remove and revert changes that where made. I know that's a tough one.
• content that belongs to a plugin should be identified within vanilla

[Saugia]

Plug-ins are outside the domain of our vision. Anything goes in them, and we don't want to restrict any creativity in them. Anything that affects vanilla or otherwise changes the game is both on the plug-in creator for communicating, and to the knowledge of the user that a plug-in may break a game. Plug-ins are the responsibility of the user, not ES's organization. No game ever has vision or restriction on plug-ins (with the exception being nsfw or illegal practices of course).

Sure, you could say there are standards for plug-ins, and we could have some stated guidelines, but we don't have nor should have the ability to enforce anything upon plug-in creators, and it's up to the creators themselves what they want to do.

[xX-Dillinger-Xx]

There is no reason you can't have official plugins that follow certain guidelines and un-official plugins, that do not follow the guidelines.

• official plugins could be considered safe, within reason
• un-official plugins will come with risks and are the players responsibility, as you stated.

If nothing else, there should be rules in place that require the plugin creator to include a detailed description as to what changes their plugin will make to vanilla.

and it's up to the creators themselves what they want to do.

But they are plugins being created for your game and creators should expect some rules.
My concern is that many players try these plugins and run into all kinds of problems. How many of these 'problems' are being blamed on ES and the development team, because the player is unaware the plugins are to be used at the player own risk?

[Saugia]

Well, what exactly defines an "official plug-in"? Anything made by the game's creators for the base game is vanilla, and additions to it would be "DLC" content. Now, a game developer or contributor could create plug-in content, but that doesn't mean it's an official plug-in. There isn't really a difference between an "official" or "unofficial" plug-in if it's not made as official extension o vanilla, which at that case, would be, well, vanilla. In these terms, what's official or not would be whether or not who created it, not some defined ruleset.

We wouldn't endorse something as an "official plug-in". It would be the creator endorsing their own plug-in as "official", as in, they made it, not some other party making plug-in content based on theirs, which would be unofficial. So, for example, I could say that Midnight Expansion is officially made by Midnight, but we wouldn't call it, or anything, an official ES plug-in. Still, we could say it's one of ES's most popular or major plug-ins.

Now, the creator can make a defined ruleset, but we can't make a blanket ruleset for plug-ins- we don't control what a creator can and cannot do. This isn't something to look at for a statement in ES's vision - this is with basically every game that has ever existed. There could be a content plug-in for an RTS game that, says, adds a new chunk of content. That RTS game wouldn't call it an official plug-in, but the creator would officially have made it. What you're asking for a rule-based official recognition of a plug-in just doesn't exist in game development.

But, to address your concerns:

If a plug-in affects vanilla, a plug-in affects vanilla. It is up to the creator on whether or not they decide to include a description that it does or doesn't, not us to police the necessity of such a description. It's their responsibility, not ours. In the same venue, it is the player's responsibility to figure this out prior to using a plug-in if they're worried about their save being affected. It's the same logic with continuous - you are acknowledging that a plug-in will be editing the game's base content, be it adding to or changing it. Again, this isn't ES-centric, this has gone for basically every game that has ever had mods.

Many players do try plug-ins and run into conflicts. It's not ES's organization's responsibility to fix these. This is solely on the plug-in creators, or players, for communicating and researching what a plug-in does. So, your concerns would be something to bring up to the creators of the plug-ins, aka the developers of those plug-ins, not ES's development organization, where we don't control plug-ins as user-modded content.

As for us being blamed for plug-ins breaking the game? I don't think that has ever happened. If a plug-in affects a save in vanilla, people usually first ask about it, and when they find out it's a plug-in (or already know), they approach those creators or those who know about it. I know it sounds harsh, but it's pretty much common sense that a mod can affect a game. That's why they're called mods, plug-ins, total conversions, etc.. And that's been the case everywhere.

TLDR: What you're asking for and who you're asking are two separate things. You can ask for more clarity for vanilla affects in plug-ins, but that's not ES's developmental jurisdiction, it is the plug-in creators. And this isn't an ES thing, this is with any game.

[Zitchas]

I'm afraid I'm going to have disagree here. , Dilinger, on three counts.

a) The whole point of the plug-in framework is to allow people the maximum flexibility to do what they want. And yes, that includes altering vanilla content. That's probably one of the most common reasons for plug-ins, really.

b) I value my immersion in the game, and having a mission (or ship, or outfit, or planet, or whatever else) come with a "Part of Zitchas's Lampyrid Plug-in" label on it is just going to ruin the immersion for me. If this became a thing, it's virtually guaranteed that the first I did when installing a plug-in would be deleting every (in-game visible part) that identifies something as being part of a plug-in.

c) Having "official" plug-ins means that the Devs are taking responsibility for ensuring those plug-ins meet standards of quality, content, and functionality. They're sufficiently overloaded already, we don't need to give them responsibility for vetting plugins.

And I'll just note that the game does already have a certain degree of "protection" built into it. If a pilot is off exploring some far off galaxy when the plugin that adds it is removed, they revert to New Boston. Likewise, ship data is stored in the pilot, so their ship will still be available to fly. (the sprite will be gone, which causes some issues, but the actual data for the ship is still there.). The game picks up on missions whose source is no longer available, etc.

[MasterOfGrey]

Separate to any concept of what one might want to expect from plugins...
(Since we can't really dictate what people make - as they're essentially mods.)

A fertile avenue of discussion which does fall within the realm of things the Devs can influence, would be how the base game is set up to functionally handle using plugins.