- Joined
- Aug 5, 2013
- Messages
- 5
- Reaction score
- 1
To start this thread off, I feel the need to say I immensely enjoy playing StarMade, especially because of its constructive and potentially competitive nature. That being said, I primarily play on a hardcore PvP server that has blueprints disabled because playing on a server where rich players can upload someone else’s work and use it in combat as their own is a little bit silly.
Blueprints in their current state are an excellent way to save your work and duel ships without any real losses. However, they only really contribute to gameplay in a simple Sandbox mode as they can make resource management, efficiency, and originality meaningless in a PvP environment.
To remedy this, I am suggesting a non-invasive overhaul to Blueprints that will allow them to function appropriately in a Hardcore setting while also keeping the current system intact. The basics of this system are as follows:
1) Nothing changes about the current system. Users can save their ships to local regardless of server options and can upload Blueprints to the server if the server allows it. I have nothing against Sandbox gameplay; I don’t enjoy it but that doesn’t mean I feel the need to ruin it for everyone else.
2) “Logs” are a new purchasable item in shops. They can stack and be manufactured or, if the server owner feels it is necessary, can only be found in loot from Pirates or other players. When this item is right-clicked in inventory, a menu opens asking the player whether to convert one of the Logs into a Logbook or a Blueprint of the ship currently occupied. If the Blueprint option is selected, the player receives a recipe-like item for the ship he is currently in. When the blueprint is right-clicked, a window opens listing every resource required as well as the total block count (mass).
3) Factories or a new, similar block can accept Blueprints in a similar manner to recipes. The factory can be linked to a Docking Module to specify where to output the ship. When a Blueprint and all the required blocks are placed into the factory, the factory will output the ship specified by the blueprint to the docking module.
Note that a number of things can go wrong here for the player: if the block requirements are not met, the factory has no Docking Module output or the area is too small, or the power requirements are not met, then the ship will not be produced. For the power requirements, I think a linear scaling based on mass*(constant decided by server) would be appropriate to prevent larger ships from being easily spawned, if the server owner decides it’s necessary. Also, general settings for server owners like max_mass, max_length, etc. would be helpful to keep large server-straining ships from being spammed.
And that’s the basics of the system. Now I’ll discuss the features it provides:
1) It allows servers to stay competitive and players to save their work.
With the new emphasis on resources instead of credits, even if a ship is Blueprinted it still has a resource cost to the player or faction fielding it. If that ship is lost, the player must provide an adequate number of resources to get it back; however, he does not have to worry about assembling each individual part in the exact same way again.
2) It encourages creativity and efficient designs.
It goes without saying that whenever you add an item to a game, that item’s value is determined by the way player’s use it. Since the value of Blueprints will vary from one Blueprint to another, skilled builders will be able to sell their works for top-dollar or earn a reputation on the server for their constructive talents. Also, since every ship has to be designed on the server, the factions with the best builders/Blueprints would have an advantage over those that don’t.
3) Blueprint theft.
Need I say more? If Blueprints can be traded, they can also be stolen or pillaged. There’s really nothing more hardcore than having your designs stolen by your enemies and having to fight your own ships. Or, you know, stealing designs from your enemies and having them fight their own ships. It’s fun either way.
Well that about sums up my thoughts on this. Any comments or criticisms are welcome; after all, we only want to make this awesome game better.
Thanks for reading,
K-Boom
Blueprints in their current state are an excellent way to save your work and duel ships without any real losses. However, they only really contribute to gameplay in a simple Sandbox mode as they can make resource management, efficiency, and originality meaningless in a PvP environment.
To remedy this, I am suggesting a non-invasive overhaul to Blueprints that will allow them to function appropriately in a Hardcore setting while also keeping the current system intact. The basics of this system are as follows:
1) Nothing changes about the current system. Users can save their ships to local regardless of server options and can upload Blueprints to the server if the server allows it. I have nothing against Sandbox gameplay; I don’t enjoy it but that doesn’t mean I feel the need to ruin it for everyone else.
2) “Logs” are a new purchasable item in shops. They can stack and be manufactured or, if the server owner feels it is necessary, can only be found in loot from Pirates or other players. When this item is right-clicked in inventory, a menu opens asking the player whether to convert one of the Logs into a Logbook or a Blueprint of the ship currently occupied. If the Blueprint option is selected, the player receives a recipe-like item for the ship he is currently in. When the blueprint is right-clicked, a window opens listing every resource required as well as the total block count (mass).
3) Factories or a new, similar block can accept Blueprints in a similar manner to recipes. The factory can be linked to a Docking Module to specify where to output the ship. When a Blueprint and all the required blocks are placed into the factory, the factory will output the ship specified by the blueprint to the docking module.
Note that a number of things can go wrong here for the player: if the block requirements are not met, the factory has no Docking Module output or the area is too small, or the power requirements are not met, then the ship will not be produced. For the power requirements, I think a linear scaling based on mass*(constant decided by server) would be appropriate to prevent larger ships from being easily spawned, if the server owner decides it’s necessary. Also, general settings for server owners like max_mass, max_length, etc. would be helpful to keep large server-straining ships from being spammed.
And that’s the basics of the system. Now I’ll discuss the features it provides:
1) It allows servers to stay competitive and players to save their work.
With the new emphasis on resources instead of credits, even if a ship is Blueprinted it still has a resource cost to the player or faction fielding it. If that ship is lost, the player must provide an adequate number of resources to get it back; however, he does not have to worry about assembling each individual part in the exact same way again.
2) It encourages creativity and efficient designs.
It goes without saying that whenever you add an item to a game, that item’s value is determined by the way player’s use it. Since the value of Blueprints will vary from one Blueprint to another, skilled builders will be able to sell their works for top-dollar or earn a reputation on the server for their constructive talents. Also, since every ship has to be designed on the server, the factions with the best builders/Blueprints would have an advantage over those that don’t.
3) Blueprint theft.
Need I say more? If Blueprints can be traded, they can also be stolen or pillaged. There’s really nothing more hardcore than having your designs stolen by your enemies and having to fight your own ships. Or, you know, stealing designs from your enemies and having them fight their own ships. It’s fun either way.
Well that about sums up my thoughts on this. Any comments or criticisms are welcome; after all, we only want to make this awesome game better.
Thanks for reading,
K-Boom
