Over the past few weeks we've been posting endgame document parts on our forum, which you may have seen. Now that all parts are released, here is a single document detailing all parts :) We realise this document doesn’t really have much new information for our veteran players, this is simply a single repository for what we want to achieve with StarMade. This should be especially useful for new/out of the loop players.
Dev blogs will be returning to Steam from this point on. We’ve found that there isn’t always news every week, so we’ll likely have dev blogs in some weeks with no new information. Alternatively, we may switch to a different dev blog schedule.
End Goals Introduction
Our “End Goals” document...is not a list of features. Although a simple feature list is useful to get an overview of what’s next, it is not a great way to show the public what our game is about and where we’re going with it. New feature ideas get added, changed or removed all the time which only makes it more important to not depend on them when we’re talking about the final product.
Not to mention that as a player, you can only see what’s in the game right now and how that all ties together. You do not see what we want to achieve at the very end, making it impossible to give accurate feedback when the big picture is simply not there for you to see.
When we talked about how to write this document, we simply put ourselves into a specific play role/play style, defining what we would like to be able to do in the finished game. Coming up with ideas was easy, but getting rid of just as many to form a solid, cohesive game was not. StarMade is after all, a sandbox game. A type of genre where you’re allowed to discover a complete world and do whatever you want.
It’s unlikely that we’re going to change our end goals significantly, but the features leading up to it are subject to change. A destination often has multiple roads leading to it, which one we pick depends on our personal opinion and the community’s feedback on it.
As for the document itself, we’ve divided it up into several player roles which coincidentally gives us some time to make a nicer public version of it as we can release it in parts. Of course at the end, we’ll bundle it up in a single thread so that you don’t have to piece it all together yourself.
All of this is based on a base goal, which is purposely kept very simple:
StarMade is a space sandbox game where you start with very little and work your way up to the top.
You are put in a galaxy for you to explore. How you want to go about it and what your final role is going to be, is left to the player. The driving force behind it all is progression, without restricting creativity and freedom.
The roles we will talk about are the following:
StarMade v0.199.651 - Fixes & Context Help
Greetings Citizens, ~
Apologies for the steam post delay, here’s the most recent news post from star-made.org
(The previous weeks devblog: http://www.star-made.org/news/starmade-v0-199-646-build-mode)
~ T2507: Connections and statistics not showing correctly - client issue that was always there, but became a lot more common because of the improved speed with chunk requesting.
~ T2500: Sorting in Main Menu Local Play Adv. Settings is by tooltip
~ T2498: Unable to lock symmetry plane in place with empty hotbar slot
~ T2495: false positive for “is waiting for docks” | “still needs entities to dock on it”
~ Fix for infinite stock shops
Additionally a new “context help” has been added, replacing the old help keyboard list. it’s a lot less in the way and hides/shows information when needed:
You can deactivate these “Keyboard HUD Icons” in the options menu - general.
Onwards to implementing the power system prototype (which has been worked on already for the past weeks).
Thanks for playing StarMade,
~ The Schine Team
Devblog 11th July 2017 - End Goal Document Part 1
Greetings, citizens ~
A few months ago, we planned to release our End-Goals document but never really got around to make a public version. As announced in the previous post, this dev blog contains
End Goals Introduction
Our “End Goals” document...is not a list of features. Although a simple feature list is useful to get an overview of what’s next, it is not a great way to show the public what our game is about and where we’re going with it. New feature ideas get added, changed or removed all the time which only makes it more important to not depend on them when we’re talking about the final product.
Not to mention that as a player, you can only see what’s in the game right now and how that all ties together. You do not see what we want to achieve at the very end, making it impossible to give accurate feedback when the big picture is simply not there for you to see.
When we talked about how to write this document, we simply put ourselves into a specific play role/play style, defining what we would like to be able to do in the finished game. Coming up with ideas was easy, but getting rid of just as many to form a solid, cohesive game was not. StarMade is after all, a sandbox game. A type of genre where you’re allowed to discover a complete world and do whatever you want.
It’s unlikely that we’re going to change our end goals significantly, but the features leading up to it are subject to change. A destination often has multiple roads leading to it, which one we pick depends on our personal opinion and the community’s feedback on it.
As for the document itself, we’ve divided it up into several player roles which coincidentally gives us some time to make a nicer public version of it as we can release it in parts. Of course at the end, we’ll bundle it up in a single thread so that you don’t have to piece it all together yourself.
All of this is based on a base goal, which is purposely kept very simple:
StarMade is a space sandbox game where you start with very little and work your way up to the top.
You are put in a galaxy for you to explore. How you want to go about it and what your final role is going to be, is left to the player. The driving force behind it all is progression, without restricting creativity and freedom.
The roles we will talk about are the following:
~ Builder
~ Explorer
~ Industrialist
~ Trader
~ Fighter
~ Imperialist
Some of the roles of course overlap and/or have sub-roles, which will be reflected in the other parts of this document.
Builder
Our first player role to be addressed is also the one with the most work put into it: the Builder. From all roles, this one is probably also the most realized in the game already.
Starting from close to nothing, you’ll have to do some form of building first to at least travel where you want to go. While you’re doing that, you get to know what StarMade’s backbone has to offer. Mining, simple early game trading, basic ship building and travelling around the universe would all come to light in the first few hours. As soon as you have a functional ship, you can focus on anything that you’ve liked so far.
If you, up till now, prefer building above anything else, you will most likely continue in that direction. Your ultimate goal is a never ending one, to make better and more creations. This on its own, is already a form of progression which is limited by your own player experience. However, this might not be enough for most players and we need a more controlled form of progression on the game’s side to help with that.
We want to slowly open up this building aspect to the player, not only to make sure there’s still things left to explore later on...but also to make sure the player isn’t overwhelmed at the very start. Later, when you’re base of operations is well established, you slightly shift your focus from building to selling and marketing. Your goal isn’t necessarily to get rich, but to get known as a reliable ship builder that is capable of doing anything. Not only are you better at building now, but your ship/station producing speed is much faster after upgrading and maintaining your own shipyard(s) along the way.
Several features, as well as redesigning or tweaking existing systems will make this vision a reality.
Block Availability
At the moment, all blocks can be easily bought or made in large quantities with only a few small steps. Every resource you need can be gathered in almost any star system which is concern when you try to get more progression into the game. Base blocks such as power, basic hull and thrusters still need to be easily crafted no matter where you are, yet more advanced systems that you don’t need from the start, such as effects and the future reactor chamber blocks, could definitely use some changes.
By fine tuning the crafting recipes and universe resource allocation system, we can create an unique world where, as a builder, you’ll have to play differently every time you generate a new universe. If certain block resources are tied to specific locations, you won’t be able to immediately build any block in large quantities. Those resources could still be found anywhere, but just in small quantities to allow small scale experimentation and open your mind to new possible ways.
The idea here is that the player will have to adapt to the resources they have at their base and fully explore the functional blocks they can create there before moving on.
Block Progression
Most decorative blocks should always be available and cheap to build, as they only function to make things look better and barely affect ship/station performance in any significant way.
Rails, logic and other similar systems, are just like decoration when it comes to performance. These already provide a large amount of end-game content which can only be fully utilized by players that are experienced with it. There is no need to add additional progression here.
Some functional blocks do need some extra depth to lengthen the amount of time needed to achieve this endgame build quality. The key could be in the balance between efficiency versus longevity. Longevity is where your ship can survive a decent amount of incoming damage and is still able to fight back afterwards. Efficiency is where you get the most statistical value out of your ship compared to its build cost and mass. Balancing these 2 out is a never ending task and depends on the ship’s purpose and its potential opponents. Right now we already have this in multiple ways, but it could be way more prominent by changing how some systems work.
Rebalancing systems will also provide more defined roles for differently sized ships. Small ships, while they never should be as powerful as a considerably larger ship in a 1 vs 1 fight, would still be extremely useful when used in larger numbers. In addition to that, some weapon systems could benefit greatly depending on the ship type and role.
Shipyards
More immersion should be provided by private and public shipyards. It also gives access to creative mode and several build tools without breaking immersion of plopping down thousands of real blocks out of nowhere. The player should be made familiar with this feature as soon as possible, it’s why public shipyards and a proper UI are important. For this goal to be realized, several smaller features have to be implemented first in order to get a fully usable and reliable build method without relying on the “spawn whole ship anywhere” blueprint system.
Shipyards also make it possible to build and maintain more than one ship. That combines nicely with the fleet mechanic to open up a lot more gameplay possibilities for the builder Suddenly all of your previously build ships get a different purpose if you put them together in a fleet. This would change your perspective and your way of building ships, adding even more progression for the player to explore.
Shipyards would also be the gateway to open up trading for more than just a bunch of blocks, as instead, you will trade real ships or their designs for other people to make more. Before we can get to that stage though, the blueprint system would need to support this form of trading and security.
Of course, there is still a lot of work to be done on shipyards to have them fully fulfil their role.
Expandability
As building is StarMade’s backbone, it’s important to keep that part interesting by expanding on it from time to time. Its user interface would need to allow for that, to avoid adding complexity to a system that is meant to be simple and easy to use.
We could add more build tools, decorative blocks and smaller UI elements. All of that needs to be based on something the player already knows. If something entirely new is introduced, it should be applied on existing systems too where applicable to keep everything consistent with each other, streamlining the player experience even more.
Preparing the UI for further expansion is a necessity even in an alpha stage, but non essential additions would be more useful for the beta stage or post release.
That was it for the builder part, we hope this gives you some more insight to our gameplay decisions and the road we’re taking. Stay tuned for the next part, where we will go more into roles that aren't as prominent yet in the current game version.
What’s next?
Currently we’re refining our pre-release candidate and fixing its remaining bugs. If all goes well, we will be able to release this week and move on to the power update.
If you’re interested of helping us out with testing, make sure to check out our pre-release post here. Remember to always use a separate installation for preview builds as they may potentially include game-breaking issues.
If you come across anything new that doesn’t work or you believe you’ve located a new bug, report that here to help us out: Report a Bug (Release Candidate)
As always, thank you for playing StarMade!
~ The Schine Team
Devblog 18th June 2017
Greetings, citizens ~
We’ve added some exciting features this week, including a fill and line tool, and new rails. There’s also a new Advanced Build Mode GUI! Everything should be cleaner and much easier to access now. However, keep in mind that the layout and content is still a work in progress, and so may change significantly between builds. Over the next few days, we’ll tweak what each group contains and adjust how the tools work in order to streamline the experience.
New dev build!
This first dev build contains the core functionality of two new tools: the Fill Tool and the Line Tool. Both are available under the Shape Tools group.
Fill Tool
The fill tool allows you to incrementally fill (or replace) areas with your desired block. It’s quite simple to use: you can freely select your starting point with the camera (similar to ‘create docking’), and press the [Do Fill]* button with a block selected on your hotbar.
* We are absolutely going to rename this later.
The fill tool allows both space-filling and block-replacing, depending on what the starting point is. If it’s empty space, the tool will flood-fill; if it’s a block, only that block type will be replaced. Also: this is a step-based system, meaning undo and redo work, allowing you to easily fix any mistakes.
For now, the filling process is done in a single step, and uses a fixed amount of blocks. We will change this over the next few builds to allow you to specify how many blocks to place at once, as well as allowing servers to impose their own limits to reduce server strain.
We’ll be adding some optimizations to this in later builds.
Screenshots below
Hollow torus made of crystal armor
Filling the torus starting from the bottom
Filling the shell of the torus with blue hull, replacing crystal armor along the way.
Line Tool
This is an addition to the build helpers. You set two points (using your camera position, as with the fill tool) and it will create a line between them.
We’ll add more features in the future, such as splines and line thickness.
As with the new GUI, this is also a work-in-progress, so we’ll be improving it and fixing any issues that arise.
Load/Unload Rails
We’ve added two new blocks to the game: the “Rail Load” block and the “Rail Unload” block. (We’re still working on their textures)
You can place them anywhere, and they work identically to normal rails, but they have an added feature: item transfer. These blocks allow transferring items between connected storages on a station and a docked ship via the Load/Unload Rail. Example:
You connect a storage to your rail docker on a ship, and dock it to a Load Rail on a station. The ship is then able to pull items from any storage on the station connected to that Load Rail.
If you instead dock the ship to a Rail Unload block, the station may then pull items from the ship’s connected storage to any storages connected to that Rail Unload block.
Again, both docker and rail need active connected storages. Also, the station will only pull items if it has permission to do so!
The ship radial menu allows you to select between 5 different permissions for the load/unload rails:
~ Always allow
~ Always allow faction, ask for rest
~ Always ask
~ Allow current (the entity you’re docked to; this allows manually activating or deactivating)
~ Never
Advanced Build Mode GUI
The new GUI is much cleaner, and all of the controls are much more accessible. You may show/hide individual groups, and in later dev builds, these will be customizable in location, order and size. The game will remember these settings between instances.
We’ve added new sliders, too, which allow dual input: you may enter values manually, or use your mousewheel while hovering over the controls. This also allows scrolling through the GUI without changing sliders’ values unintentionally.
This is not the final version, of course, as we will continue to work on the design.
Outline System and New LoD mesh
This completely new system is able to produce highly-optimized meshes of any number of blocks. It will be used for several effects in the future, especially for outlining the systems of a ship (e.g. for building and/or scanning). The outline itself will also be used for selecting entities in subsequent builds for this release.
This system is not able to replace the existing mesh and chunk system. Not only should any object realistically only be loaded into memory in chunks to begin with because of the sizes involved, but also in terms of graphics it’s not possible for the block meshes to retain all of the information needed. The new system simply doesn’t work with multiple textures in the same mesh. We’d have to use one mesh per block type, which would pretty much remove any advantage the system confers. Also, no lighting or material information can be stored in the limited amount of vertices of such meshes, and furthermore: making a mesh of a large object might be too much for the graphics card buffers to handle... so a chunk system would be needed anyway.
However, it is absolutely perfect for far-away LoD views of a model since block types can be mapped to a low number of colors, thereby producing one mesh per color. This, when combined with a higher-granularity chunk system, should give a large FPS increase when viewing bigger objects in the distance.
New Chunk Request System
We’ve completely rewritten the chunk request system! The new approach streamlines the order of chunk requests over multiple entities. They’re now ordered in the background on a global level, meaning nearby chunks will have much shorter load times. This also benefits the lighting calculations, which should improve overall performance.
Moving Forward
Dev builds should come out a lot more frequently from this point on. Though as always, be careful and use a separate installation so you don’t risk anything bad happening to your data, as dev builds can occasionally contain game-breaking bugs.
As always, thank you for playing StarMade!
~ The Schine Team
Devblog 13th June 2017
Greetings, citizens ~
News
It’s with a heavy heart that we announce, Auburn is leaving the Schine team for new opportunities. He completed his project here and we are extremely proud of his work. We are currently working on its integration into the universe update coming later on.
What are we working on right now?
We are currently completely reworking the advanced build mode and other GUI functionality to work with a planned GUI scaling update in the future.
Advanced Build Mode
We’d like to go in-depth for one specific build tool that we are going to add. The Fill Tool.
The fill tool is one of the tools we are most excited about. It fulfils quite a few purposes that the community has been asking for and will help you update your ships in the future power update.
Once you engage the tool, it uses the camera position to determine where the fill area starts. When the user confirms the fill location, the game will use the highlighted block type to flood fill up to a number of blocks set by the user.
Each click on “fill” will then add a set amount of blocks (maximum amount per step determined by the server). It will keep track of the blocks already placed so it will reach even into the farthest ends of your ship. Alternatively, it can be used to make some cool spherical shapes on your ships.
The great thing about this tool is it isn’t only for filling empty blocks. It can also be used to fill over existing blocks. One way this will be useful as a “Paint” tool. You can select which block type to replace when filling. The default is the “Empty” type and it would work like described before as a normal fill tool. But you can also select “Grey Hull”, which would replace groups of touching grey hull blocks on your ship. It, of course, would replace special shapes like wedges or slabs with the right shape of the replacement type if possible (grey hull wedge -> red hull wedge with the same orientation).
Another tool we’re working on is the Line Tool. We will implement this in two stages. The first stage will be a simple version. Just like in “Create Docking” you will be able to select two points on the grid (the free point selection is something we will also add for other build tools). The helper will make a line between those points which can be used as a reference or to restrict building/removing just like any of the other build helpers.
Additional stages will add line thickness and additional line segments that can also be set to splines, which then would enable you to make curves.
Cargo Transfer
In our discussions about build mode item handling, we also remembered the inconvenient cargo handling that players have to go through, in case they want bidirectional cargo transfer between a station and a ship. The current system is too complicated and also doesn’t allow for item flows down a docking chain. Altering the feature will open a better way to transfer cargo.
The way we will do this is to add two new rail blocks: Rail-Unload and Rail-Load.
The visual difference will make it easy for players to see what the dock is before docking. All connected inventories to your docker block will either be loaded or unloaded to or from the entity you are docked to. These 2 rail blocks will be swappable through logic interaction just like the other ones.
To prevent exploitation, a ship can be set into four modes: “Always Allow Transfer”, “Deny Transfer”, “Always Ask”, and “Only ask for different faction”.
When your ship is set to “Always Ask” (default), whenever you dock to an Unload or Load-Rail, the pilot will get a dialogue asking him to confirm the transfer. If there is nobody to get the dialogue, the transfer will not start. Of course, the transfer can at all times be manually triggered on/off via a ship’s hotbar, and the mode can always be changed in the ship menu.
As for the next dev build, we should be able to release one at the end of this week, followed shortly after by a pre-release the next week if all goes well.
And as always, thank you for playing StarMade!
~ The Schine Team
StarMade News - Devblog 6th June 2017
Hello players,
The dev blog for this week features something more on the technical side. It covers a nice feature that will be very important in going forward.
Optimized Meshes
With the preview of last week, which is being able to draw any subset of blocks on any structure, we want to share another reason why we implemented this now. Not only is it already extremely useful for making existing GUI elements better and as said, adding new systems like active scanning, it also will be our basis for a new Level-of-Detail system. This system will increase drawing performance by drastically reducing the amounts of polygons at a distance.
For that, the meshes we had last week needed to be improved and optimized. Since these are one colored representation of a set of blocks, polygon reduction is extremely viable.
First of all, however, it needs to be explained why this method is not viable for all the mesh drawing, especially close. Reducing polygons means giving up information that is stored in those vertices. In our case that is texture information, the baked lighting, material, and a lot of other graphical meta information. Some of that can be compensated with techniques like deferred lighting, which would work yet does not scale well most of the time, and will force a lot of other optimizations to be removed. Also, the more detailed the mesh is with additional shapes, the less advantage the polygon reduction will provide.
That’s why combining both techniques will give us the best result. At a distance we can draw a minimal mesh that will speed up things dramatically. We can even make that multicolored with mixing multiple meshes on a fixed map of colors. Best of all, for close up, this still gives us the option of using deferred lighting eventually, but mixing it with existing lighting to have a smooth transition at a distance for maximal performance combined with the cool graphical experience of dynamic lighting.
Here is how it works:
As an example, we just take one side of the mesh. In production, this algorithm applies to all sides and all ‘depths’ (layers). Individually, however, we are looking at a 2D mesh.
This is the raw drawing, which each block representing a full square. As you can see, the amounts of vertices and polygons are pretty high, especially if only one texture would be used.
The algorithm itself at this stage records all vertices and its connections to other vertices, as well as diagonal vertices individually. Diagonals are handy to know that there was a filled out block at that position, and not just a one block gap.
The first step for the algorithm is to remove inner vertices. These can be easily identified by checking the amounts of diagonal vertices a vertex has. If the number is exactly 4. We can remove it. At the same time, we can remove unnecessary connections. This is a bit more complicated to explain. Essentially for each non-inner vertex, we check for each existing direction the two orthogonal neighbors in the same direction. If both exist, the connection is unnecessary.
A similar approach is used to remove the vertices that are not corners.
Now the mesh is as simple as it can be. However, to draw it, we need to define triangles. There are several methods to triangulate a mesh, and it is highly complex, especially doing it with concave polygons that can have multiple holes in it.
For our case, we can make the process a lot faster by using the fact that we are on a grid. A fact that is often overlooked in a lot of projects, but since starmade is primarily a voxel game, can be used as the source of countless optimizations.
Explaining the exact process of retriangulation would take way too long for this dev blog, but you can probably understand the overall process of inserting horizontal lines at key points to subdivide the mesh into rectangles.
From there, it is rather straight forward to get actually triangles that can be drawn.
Now we do this for all sides, and their layers, and we get a mesh that is highly optimized, and doesn’t have any strangely shaped triangles (extreme angles). This has the great advantage of being able to use well formed texture coordinates if needed.
As a final step (for the highlighting), the mesh is drawn into a frame buffer and rendered with an outline shader.
As announced, we have a dev build in the making which we will release when it’s ready for public testing.
Thank you for playing StarMade,
~ The Schine Team
StarMade - Devblog May 30th 2017
Greetings, citizens ~
Here’s another weekly dev blog!
What are we working on right now?
In the wake of the power update, we’ve identified a few features that overlap nicely with the new power system and other ideas we’ve had for quite some time.
One of these features is the ability to draw groups of blocks separately and apply various graphical effects to them. Among other uses, this will allow us to display the inner workings of ships quite nicely, e.g. highlighting a specific salvager/weapon array, a circuit, damaged blocks, etc. There are several existing uses for this, but it will be especially useful on future features, such as: scanning other ships, getting an overview of your reactors, highlighting potential issues therewith, etc. We’re aiming to do a release with this feature implemented in quite a few areas.
We will be updating Advanced Build Mode with increased functionality. This will include the above highlighting, as well as new tools. This update will not only make reactor design much easier (and allow integration of their features), but it will also give players better building tools in general. Among these planned features is a fill tool, which will allow you to progressively fill any area, as well as tools to draw lines and possibly arcs.
Power Update
Thank you again for additional feedback. We went through most it, and we will be addressing more of your concerns later on where needed.
Major concerns
After reading all of the concerns and debates over the new power system, we can address two of our major concerns players had with the mechanics. The first is that players are limited to a single active reactor per ship, and the second is that only a single reactor would ever be active for a group of docked entities. We agree that some of these issues may be valid, but are not something we can easily solve in a balanced way.
We came to the conclusion that implementing a working multi-reactor system right now would compromise the whole reactor system as we do not know that system on its own works in-game.
That’s why we’ve decided that after implementing the base system (and after its initial balance passes) we will look into the concerns about the single-reactor issue again, to have a better overview on the possibilities in this system. Specifically, we will re-examine allowing docked entities to have their own active reactor, and possibly even allow multiple active reactors per entity to see if we can find a balanced, non-exploitable way to implement them without introducing countless rules and restrictions.
Even so, coming up with something to allow docked reactors only solves a small part of the bigger problem mentioned here: https://starmadedock.net/threads/starmade-devblog-may-22nd-2017.29057/
What’s next? / Conclusion
We definitely appreciate all of the feedback we’ve received thus far. It has gone a long way to help shape and solidify StarMade’s next steps. Given the work we’ve been doing, we are planning a pre-release build in a week or two. Be on the lookout for that build, and if you have questions on our release cycle, please refer to the following:
We are currently finishing off a redesign of the chunk request system which will make requesting chunks over multiple entities a lot more controllable. This means that chunks close to the player can be requested a lot faster resulting in a much better overall experience with loading times for objects (as e.g. asteroids that are far in the back get less priority over closer objects). Prioritisation did exist in the previous system, but it was more local to the entity.
Also, a few prototypes to test out if our plans for the reactors are viable implementation wise have been implemented. One example is a system which can create a convex hull (https://en.wikipedia.org/wiki/Convex_hull) of an arbitrary amount of blocks has been implemented. This system’s focus is to be as fast as possible and to provide a variable amount of precision to simplify complex structures. This is then not only usable to make the distance between stabilizers and main rector actually viable, it can also be used graphically to outline ship systems.
Furthermore, Terra has been working on a rather significant launcher update. See below for details!
Launcher update
While most of the work is done, the UI isn’t quite finished yet, so you’ll have to rely on imagination instead of screenshots for now. (Sorry about that!)
This update consists of two major changes:
Firstly, we’ve merged all of the settings popups into a single dialog. This both drastically improves ease-of-use, and gives us unlimited space to add more settings later, for example logging. (Implementing this required extensive changes throughout the codebase, so the thorough QA required for this will delay release somewhat.) We’ve retained the settings gear icons, but instead of opening their respective popups, they now act as shortcuts into the new settings dialog; this should help with transition. The architecture behind the consolidated options also allows us to implement more complicated and/or settings-dependent features, of which this release’s second feature is a good example:
The second is something that people have been requesting for ages: official support for multiple StarMade installs! Adding them is straightforward and easy, and you may have as many as you like. There’s also a dropdown on the main window that allows switching between them quickly. No more manually changing the path. No more version/branch mismatches. No more multiple launchers.
There have also been minor tweaks throughout; some visible, some not.
Power feedback
Thank you for the large amount of feedback on our new power proposal. So far it seems that we need to iron out some key issues and tweak the system here and there.
The major concerns so far seems to be:
These are definitely valid concerns. In the next few days we’ll work try to work on resolutions to as many issues as we can and try to improve the power system so that doesn’t have to compromise on build creativity that much yet also not open up for exploits.
As a side note, with the power proposal we are of course planning a responsive and informative GUI that will come with the system, which will indicate exactly how the system is functioning so that it’s easily understandable just from that without having to read one word of explanation.
Making things work with docked entities Perhaps an interesting topic to talk about and why it’s not that easy to find a solution for it that still follows the goals we’ve set up.
With the current in-game power system, the main reason why people use docked reactors, is to bypass the softcap limit that is set per entity. It gives you more favorable power production per block by spreading it out over multiple entities. Anyone that doesn't do this, such as just sticking with a single big ship, will be at a severe disadvantage.
In this proposal, we have power reactor blocks scale in a linear fashion, there’s no way to get more power per block by splitting them over multiple entities…
But there's still something related to power that can be bypassed which is the minimum distance required between the reactors and stabilizers. That distance scales differently depending on reactor block count. It only influences the amount of volume your ship needs to get more power out of it but it comes down the same exploit but most likely just less severe.
There’s a possibility where the distance can scale linear just like the power blocks do, it depends on preliminary playtesting to figure that out.
If that was the case, docked reactors would already have a big chance of coming back.
There are also power related things we have to care about when talking about docked entities such as chambers, but you can simply disable those from working and it will be just fine from a ship perspective.
However, when investigating what exactly is wrong with this, we noticed that there are plenty of other inconsistencies when it comes to docked and undocked ships. Both examples could literally be the same ship yet as soon as you dock one of them, it becomes part of another ship and it loses a part of its systems and functionality.
The docked power allowing you to bypass the softcap is far from the only issue StarMade has with inheriting systems and functionality. It’s just the most severe one which is why it’s being focused on so much.
Just a few examples that we can bring up:
There are 2 distinct cases here:
Docked entities should be fully independent from their parent and children This would be the safest option when it comes to exploits and amount of work to be done, it would also decrease complexity and make StarMade easier to learn. Yet it comes at the price of limiting creativity a lot and reduce the amount of advanced structures you can make later on. Modular ships would not be feasible with this system.
Docked entities should completely merge with them when it comes statistics. This would be the best option gameplay wise, allowing as much creativity but also risk opening up the system for exploits. It could also be too complex for new players to get into this although that’s more of a progression problem than
As for some of the advantages of turrets versus fixed weaponry, we can always balance those through AI accuracy, swivel speed or some other system that does not add special rules to the inheriting of systems.
We’ll be looking at more feedback of course.
As always, thanks for playing StarMade!
~ The Schine Team
StarMade Ship Systems 2.0
Greetings Citizens,
Our new power proposal has been posted on our forums: https://starmadedock.net/threads/starmade-ship-systems-2-0.29026/
Be sure to check it out!
Here's a video:
https://www.youtube.com/watch?v=mbjHdbfPTDM
Thanks for playing StarMade,
~ The Schine Team
StarMade - Devblog May 15th 2017
Greetings citizens,
We have an update on the power update as well as an exciting announcement for you.
What are we working on right now?
One new thing is that in our internal builds fleets are now saving orders on logout and server start and restart. You can expect fleets to save orders in future dev builds. As previously mentioned, we have been constructing a comprehensive power document to share with the community. It is now being finalized along with a video to give an easily digestible overview of the entire proposal. These will be released simultaneously later this week.
Be sure to check our last news post [prev dev blog] for more specifics, since we are still discussing those internally.
New developer joining the team
For the past two and a half months we've been getting a new game developer familiarised with the code and how we work. Some of you will already be acquainted with him as an active community member, welcome to nightrune (Sean Sill)!
#/media/File:Parametic_Cubic_Spline.svg){kind=link}