Hello Players,
This is more of a blog post about the general direction of the game.
With the recent updates there have been a lot of new build mechanics and restrictions that were controversial. However, they seemed necessary to solve certain problems with people exploiting certain aspects of the mechanics. Most players never plan or intent to abuse these mechanics but they were still negatively affected by them. New players are also affected by the added complexity. Even the existence of an additional number while building has a negative effect. Understandably, a lot of those players asked the question “Why is this even a thing?”.
Restricting the build mechanics is most of the time affecting the wrong people, and a lot of times they are also not 100% effective in what they are trying to prevent. Making them more severe would put even more restriction on the whole system. Reducing them would make them completely ineffective.
With all that in mind I came to the realization that my perspective on balance might be a bit off. In trying to put out fires, new fires are coming up while development of other things suffers. We have been focusing on fighting the extreme cases of exploits way to much.
The conclusion of this is that I want to go back to those things that make the game fun.
To explain it better: The game should be fun for one or a group of players that are enjoying the game without going out of their way to exploit mechanics. While there still need to be things to prevent these exploits, it will be done with a different perspective. Measures that solely exist to prevent to exploitation will be put into a rule system, so a server admin can apply them. This rule system will be quick and easy to setup, which will be explained a bit later.
We will still be sticking with the basic premise of reactors and stabilizers but will be simplifying things a fair bit.
The first things that will be removed from the game is integrity and the reactor stream between reactor and stabilizers. Also, while I can not promise for sure, the required reactor stabilization distance will likely be reduced.
Server Rules
The server rule system will work as follows:
The server admin picks one or multiple conditions with either “all conditions must be true” or “one of the conditions must be true”. While there will be other affected areas, this explanation will be for structures. This means that these conditions will be checked while a player builds or spawns a ship. These conditions will include a reactivation of integrity, the stability stream, ship size, mass, dimension, block counts per type, weapon strength, shield strength and a lot more.
After the admin picked a set of conditions, they can choose from one or more actions. These will range from very light “ship weapons are disabled while conditions are true” to more harsh “remove ship” or even “ban player”. It’s the admin’s choice. They will also have the option to warn players on certain actions.
A simple rule would be:
- “If block count is over 1 million, deactivate the ship’s power”
The player would then be notified in their structure view in build mode that a their ship is currently triggering the rule.
Another rule would be:
- If integrity is in the negatives, the ship is disabled.
The condition can be more soft like “mark ship for admins”. Admins would be able to track those marked ships in a panel, as well as the blueprints.
This would exactly emulate how the integrity works right now.
For normal gameplay all integrity would not be visible as long as the player is on a server that doesn’t use a rule that relates to integrity. Same is true for the stabilization stream, and other things that will be removed for simplification.
When I make the game I think about people that have fun together player the game. Exploring, building, fighting. Competitiveness is also nice as long as I doesn't go to extremes. So I want to focus on that fun part. Unlike many games nowadays, I don't want to create an esport. If you want to play hardcore, you are welcome to do so, but you will have to make your own rules.
With this, development can move a lot more freely and will have a lot more resources available for other things. For anything that might be exploitive, conditions will be added to help a server effectively detect and remove it from their server if they so wish. We will be also providing default options for servers to quickly setup. These default options will be based upon what rules are typically set on the different types of servers PvP, PvE, RP, Building etc
This is all of course not a complete fix to all balance problems, but it enables us to create a balance for a specific scenario instead of doing the impossible task of coming up with a balance that works in a possible scenarios. For example, the intended vanilla balance will be based on economy also, something that currently doesn’t matter on some servers, which in turn completely changes the scenario and the requirements for any balance. By focusing on a specific scenario and then letting the admins control what kind of play they want to see on a server, we can reduce the amount of forced restrictions considerably making building and the game a lot more fun.
The rule GUI will come equipped with a simple way to create new rules. Also it will be possible to create and export/import ruleset templates. There will also be some general rulesets available that an admin can choose from like “Creative Build”, “Restricted Pvp” or “Hardcore PvP Open”.
List of Conditions and reactions
There are a lot of possible conditions and actions. I’ll be compiling a list shortly with all possible conditions and actions I can come up with. Since any action will be specific to a server to use them I’m willing to implement pretty much any request a server admin has for a rule.
Possible conditions would include
- ship size
- ship mass
- block count (per type)
- system count (specific to system)
- integrity (which would activate the integrity GUI and stats for all peple on that server. Otherwise integrity would be completely removed)
- Shield size
- Reactor level
- A lot more. Whatever we can come up with.
Actions would affect the entity & creator/spawner of the entity and would range from hidden to severe including:
- Mark entity for admins. This entity is then trackable by the admins in a panel
- Mark entity for everyone in hud/name
- Disable certain systems
- Add an effect (like a reactor effect) to the vessel
- Disable completely
- Warn player for amount of time
- Remove completely (conditions can be chained, so that would for example be after a warning)
- Kick/Ban player (same as above)
This would also enable servers to implement buffs for certain builds (e.g. bigger stations) by applying certain effects. This would be a lot easier than modifying the config. Also it would be compatible with most updates of the game.
General
In general there have been a few adjustments to my perspective as well. With the universe update coming up, I will be going moving away from trying to middleground on things that would cost extra time. Too many “you can do either this or that” choices for how the basics of the game work are not good for complexity and code. This is not directed on gameplay, in fact gameplay should be enriched with more options, but for things like having an option to use old deprecated things still (old turrets etc are a good example).
The universe update is pretty huge in scope, but all in all I’m looking very much to 100% dive into it. The basics are already there. Most of the old systems have been overhauled internally. The few old ones that are left will be overhauled at the beginning of the update (amongst other things AI, fleets, the basic loading system and sector transitions). The universe will be torn down and recreated according to what we planned. And then it will be filled with new and interesting things, adding gameplay and things to do, as well as making the surroundings a lot more recognizable.
Thanks for playing StarMade,
