Strap in, this is going to be a long one.
This document is a mess of indie game dev cliches and a thorough example of Schine fundamentally failing to communicate goals both to itself and to the community in a concise, coherent and comprehensive manner. Per Jordan Peterson, the absolute first step to accomplishing anything is stating your goals in a simple and easy to read manner. These goals are not stated simply nor are they easily read. I'll give you the benefit of the doubt and say perhaps you aren't accustomed to writing these sorts of documents or were pressed for time, but this is honestly just not great. Ignoring all of the other problems, just at the very least organize this. Bullet points, to the point explanations, alphabetically or chronologically listed information, et cetera.
But I have a bigger issue with something stated at the beginning of this document.
This paragraph specifically, only the third one into the document, and it's already told me everything I need to know about how Schine is going about developing their endgame features - and why it's wrong.
Before you e-crucify me for telling someone their method of game development is wrong, let me explain. As Schine says itself, two sentences later, StarMade is a sandbox game. The fundamental concept behind a sandbox is that the player is free to do as they please, and this includes doing whatever activities they please, whenever they please and in whatever order they please. The game world exists to provide the player the means to carry out these activities ONLY - if it forces the player to do anything, it is not a sandbox.
This intangible, non-binding "player role" style of sandbox game development, where a development team will put themselves "into the mind of a player" and then add features and balance their game around this vision, is critically, fundamentally flawed. Why? Because this is a sandbox game. Because these style archetypes are not physical features, and they're not binding (like a class in an MMO), players have absolutely no reason to adhere to them. Not only will they not adhere to one specifically, but they will switch between them at will, or will play like many or all of them simultaneously! If you structure the game around roles, what happens when someone playing your game says "I don't want to be just one of those, or any of those"? Any semblance is balance or continuity is completely obliterated.
So why is this, specifically, a problem? Because this kind of development will ASSUME the goals are binding. Players must fit into one of the roles, otherwise they are now not being considered in the grand scheme of things. Features are added, gameplay is expanded, balance is created but only in respect to these roles, only within the scope of these grounded playstyles. As soon as any player steps outside these molds, again, because they're non-binding, the balance that was carefully constructed is totally shattered. Balance is give and take - the idea of roles is that each one does some things well, other things not as well. For example, the Builder role here is supposed to work on the idea that resources are unbalanced, distributed unevenly - this allows them to be able to source some materials well, others not, therefore reducing the amount of things they can build or increasing the time it takes to build as much as they want. But what if the player is also what Schine would call an Imperialist, who controls large amounts of space and assets? And an Explorer, too, having searched for and located these other areas? And an Industrialist, having a massive base of production to quickly create whatever they need? And a Trader, too, successfully making deals with those from other locations for resources they don't have? Perhaps a Fighter, when diplomacy fails, forcibly seizing resources they don't have or need more of? Or even none of these things, perhaps someone who instead prefers to simply purchase their ships and roam around looking for missions or opportunities? How does this fit within Schine's vision of game balance that says players fall into roles?
There is a critical, fundamental problem of developing a sandbox game by assuming roles that you see but others may not. There are many examples of this going awry, but look no further than a game called Of Kings and Men. Here, too, they tried this idea - four non-tangible, non-binding roles for their game. They only expected players to be one of these four at any given time. Like all game devs, they prioritised the role they saw to be most important (in this case, the one they expected players to most often be, and the most critical to further development) and began developing that role only. But very quickly that fell through when they opened their game to testing; players not only did not favor this role, but also showed that it was not the most critical to development. Time was wasted, plans had to be reshuffled, and it lead to a catastrophic implosion of a game studio that is irrelevant in this context. The point of the matter is that it has been done before, and simply because your ideas on how to play any given game are likely different from mine, the concept of these molds players fit into is broken.
This, too, is problematic;
How can the community trust Schine to effectively develop a game based on roles if Schine does not also play the game nor listen to the community? Even if this idea of intangible, non-binding roles was a working solution, how far from reality would Schine's vision of them be? Their ideas could be on a totally different page from where the game actually is, and this disconnect could lead to major balancing issues. This sort of thing already happens, but not on the scale that it could happen should it continue into this.
Despite the doom and gloom above, I'm glad you posted this now and only posted a glimpse, so that it can be corrected going forward. Should you heed my advice, I'd suggest doing these things;
- Organize your ideas from the start. "What is it I want to do, and how can I state in it the fewest words without losing meaning?" Follow this rule, always, and then work towards it. Concisely state what you want to do in order from largest to smallest goals, grouping goals based on progression and/or where it's encountered in the game and/or the difficulty in coding and implementing. Read the document, re-read it, and then pretend you're someone who has absolutely no connection to StarMade whatsoever. Does the document make sense? Can you make heads or tails of what is being said? The hallmark of a good internal goals document is it being able to be understood universally, regardless of context.
- Step away from the development strategy of creating roles and then balancing based on that. Remember that, at its core, the universe you've created serves only as a means for players to discover and carry out activities. All features of the game are activities. Every activity should be enjoyable, or be minimally tedious, time consuming and/or boring so that the pursuit of enjoyable activities can continue in the shortest amount of time necessary.
- Instead of roles, think of the game universe as an empty canvas. As said before, all features of the game are activities the player can carry out - think of them as that and that only. All features are activities and all activities are optional. They must appeal to the player in some shape or form, and/or appeal to different types of players. But most importantly, they can and will appeal to a player at different times, all at once, or not at all. Do not balance your game with the idea that players will carry out every activity or activities in a certain order, because this will not hold water. Balance your game and structure your universe so that these activities can occur independent of any player or a certain type of player. A critical component of any sandbox game is the notion that the gears will turn regardless of the player, but the player may alter how, when, why, where, etc the gears turn. Change your perspective from the universe requiring the player to the player requiring the universe. Proceeding in this fashion will allow you to better identify what features need to be added, in what order, where they ought to be located and how they should be balanced.
- Consider that what you think may be enjoyable can be different from others, so get a wide range of input from Schine, community members and ESPECIALLY non-players. For example, let us say you are working on the exploration aspect of the game. Ask yourselves in Schine what it is you want to see most when exploring (the how, the what, the where, then when, the why, the who) and then present these options as a poll to the Dock community, as well as allowing them to suggest things you may not have thought of. Balance what the Dock says with what you think and what is feasible, and then take these options to non-players you may find. I know, for example, Saber was in communication with the YouTuber TheXPGamers, otherwise known as CaptainShack. Ask him what he'd like to see, ideally, out of exploration in a voxel universe. Then balance what he and anyone else you ask thinks with what Schine thinks, what the community thinks and what is feasible. This will give you the most diverse amount of opinions you can accrue for the most efficient use of your time.
- But most importantly, keep sharing with us. Keep taking criticism. The most important part of active development for a game like StarMade is being constantly up to date with the community.
To summarize; this document has numerous problems but can be easily remedied. Start by organizing your goals clearly and concisely - this will make any further progress, however you decided to go about it, magnitudes easier. Then, reconsider how you are going about constructing this vision of the game's future, so that it includes input from many sources and appeals to as many players as possible.
