Greetings, citizens ~

 

This week it’s the Explorer’s turn, the 2nd part of our “End Goals document”.
 

List of player roles:

~ Builder

~ Explorer

~ Industrialist

~ Trader

~ Fighter

~ Imperialist

 

In the previous dev blog, there was some misconception on what our intentions were with these 6 player “roles”, we would like to clarify on that first.

For us, the “roles” represent player archetypes, extremely one-sided examples of what a specific type of player might want to do. We use those mindsets or “roles” to determine what we can add to StarMade to make that area of gameplay possible as a whole, making each role an enjoyable experience on its own.

 

Any everyday player will naturally fall under several roles and play the game however they want. These roles are not forced in any way, and are not even mentioned anywhere else outside the end goal document. They are just something we’re using internally to get structure in a long list of gameplay directions and features.

 

Explorer

In contrast with the Builder role, the exploration aspect of StarMade is currently not well developed. This role is for the players who like exploring a game world and uncovering mysteries, lore and interesting areas along their journey.

Flying out and discovering different places in the universe is “exploration”, but so is exploring every gameplay aspect of the game.

 

Not only do you find new places but also new block systems and how those influence your play style. However, we don’t have to delve deeper into this particular gameplay aspect, as it is already addressed in the “Builder” role and the following dev blogs.

Here, we only focus on the game world and what it has to offer for the Explorer.

 

Universe diversity

Before throwing yourself into the unknown, you need something worth exploring first. We want to create a dynamic world that has a limited amount of interesting areas, and danger in between. Exploration itself would be encouraged in multiple ways.

 

~ Resources: Restructuring the universe to condense most resources into relatively small areas will make them stand out much more than the generic space surrounding it. Uncommon resource rich regions will automatically become points of contention, and therefore points of interest where players, as well as NPCs will be drawn to.

The end result is that, without adding anything else, only a relatively small area of a galaxy is worth exploring and anything in between could be filled with some hurdle to overcome to add some variation to the vast emptiness of space.
 

~ Content: These points of interests would, in addition to its resource richness, contain much more to increase its exploration value.
This could be anything, ranging from different stellar objects to treasures and loot. Examples could be moons, nebulae, gas giants, different types of stars (supernova), black/white holes, and other abnormalities each with their own effects. Fauna and flora could add greatly to this system too, but would be an add-on feature.
 

~ Out-of-ship exploration is a whole other chapter: stations, ships, planets, dungeons, caves and fauna add countless possibilities for adding unique content. Upgrades to astronaut equipment could be found and crafted with these resources, encouraging you to leave your ship’s safety and gather those few materials you need by hand.
 

~ NPC Factions: Their primary role is to fill the universe with history and lore, making it feel alive where every NPC owned entity would have real astronauts walking around. Some of these factions need some extra diversity to make them stand out more to make it easier for a player to align to at least one of them.
 

~ Danger: Natural hazards, hostile factions and other dangerous anomalies would need to be added to restrict the amount of freedom a player has when exploring. The extra challenge is sorely needed yet should not become a nuisance. The main requirement for this to work properly would be to have a structured galaxy where certain areas are always easily accessible with little to no dangers.

 

Universe Interaction

 

~ Quest and Reward system: Quests, either given by NPC’s or triggered automatically (finding a log book), will point the player to new and other interesting areas. Although finishing the quest would give rewards, they mostly serve to encourage the player to go beyond what they already know. Additional progression can also be given with collectibles or rare decorative items, introducing some more lore.
 

~ Events: Generated events like battles, trading routes, raids, space creatures, mysterious faction appearances and supernovae will add more immersion and life to an artificial universe, and making sure the player encounters them without having to actively search them out. As an option, we could have end-game events to spice things up when a SP or MP world starts becoming stale.
 

~ End-game: Several entities in the game (prominently NPC factions) will not only provide events, but also a real challenge for anyone. The farther the player goes “out”, the more dangerous it will get to the player with the void being the most dangerous area.
 

~ Map information: The current interface that shows you what the galaxy looks like has no level of detail system, overflowing players with tons of information they don’t need.

With the point of interest system, where only a handful of systems contain most interesting parts, we can hide and show that information from the player. We can also rely on graphical elements to attract players as nebulas and giant stars would easily be seen on the map.

As each point of interest would be unique in some way, it would also be information worth trading with other players or NPC factions.
 

~ Transportation: How balanced the thrusters and jump drives are right now is unclear, mostly because the third option, Warp gates, are far from usable. The warp gate is supposed to be the ultimate traveling mechanic to get from one to another that has a huge setup cost in comparison as its downside.

Besides generated old/deactivated warp gates, the player and NPC created ones suffer from an issue where they are too easily destroyed. It will take some testing to narrow down which areas need to be altered to alleviate this issue.

 

One galaxy to rule them all

Procedural generation, the tool that allows us to create an infinite world comes with a large downside that mainly affects exploration. Everything you see and encounter along the way, is generated content and you will see the same over and over again. Not only that, but the recurring patterns devalue every little handcrafted piece.

 

We cannot avoid this issue, yet we can mitigate the problem.

The starting galaxy, with perhaps a few islands of stars, is big enough to create an unique enough environment for a player to enjoy.
The trick isn’t necessarily to create enough content to fill it up, but to spread it out properly and make sure the player does not see it all in one day. It is also why we are focusing on these points of interests, as those act as small islands in an endless ocean.

 

What’s next?

A few higher priority bugs were found in the pre-build version that we fixed now. Currently we’re doing some additional pre-release testing to make sure there are no other remaining high priority issues.

 

In case you’re interested in helping us out with some 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

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 the 1st part of our “End Goals” document.

 

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

Greeting, Citizens ~

 

We’ve uploaded a pre-release to the “pre” branch. It’s mostly feature complete, but there are still a few bugs left to fix, and it’s still missing a few graphics. Remember, 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)

Features

Segment requester

As mentioned in a previous dev blog, 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.

 

Outline

A new graphical effects that outlines/highlights entire entities or groups. Right now we only use it for the current selected target and for most C + V systems out there. Most likely we’ll integrate this system later with the upcoming power changes and its information warfare portion.

 

The outline system uses a highly optimized mesh that can quickly be generated for any number of blocks. Although this system is not able to replace the existing mesh and chunk system due to lacking information, they’re still a necessity for future plans as they would also be used in far-aways LoD views of a model. In combination with higher-granularity chunk system, should give a large FPS increase when viewing bigger objects in the distance.

 

Note: framebuffer has to be enabled in your graphic options as it would not work properly otherwise

 

Build Mode

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.  You can adapt the line thickness with a slider.

We’ll add more features in the future, such as splines.

As with the new GUI, this is also a work-in-progress, so we’ll be improving it and fixing any issues that arise.

 

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 fill button with a block selected on your hotbar.

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.

You can use the slider to set the amount of blocks added by step. The max amount can be changed in the config.
 

Different method of selecting

With adding the line tool, we added a new way to select portions of blocks altogether. It is now possible to select boxes by selecting the starting and the end point. This comes in especially useful for copy & paste which in the past always was a bit finicky to use.

UI improvements

Besides the new look, we’ve changed quite a lot of the original’s build mode functionality. We’ve grouped the available tools together accordingly and those groups can be collapsed or expanded when needed. When the expanded areas become too large, it becomes scrollable. However, the orientation group with the undo/redo buttons however is fixed at the top so that you never lose track of it.

Which group is expanded or closed is saved on exit and restored next session.

 

The orientation group at the top also functions as a radial menu for shape selection, simply left click it and hold to make it popup.

 

The sliders have received a makeover, now allowing more ways for you to change their value. Their value can now be entered manually by left clicking the value on the left side and functions like a text box only allowing numeric input.

If you have a mouse wheel, you can also change the slider’s value by hovering your mouse over the textbox on the left and scrolling up or down, allowing for quick adjustments.

 

The build helpers have also gotten a general overhaul. We got rid of the annoying popup dialogs, so everything can be set or changed directly from the build mode panel itself. This also allows you to recalculate a build helper’s parameters without having to redo everything. You can also change the placement of the build helper

The placement of the build helper can also be moved independently without having to clear the current build helper.

 

Symmetry planes now have their individual odd-mode, allowing you to work with an off-center XZ plane but a centered YZ plane at the same time for example.

We’ve also added tooltip support to the build mode panel. It’s not used that much right now but later we can add some nice descriptions to some of the tools if needed.

 

Additionally we added “sticky advanced build mode” by pressing the advanced build mode key twice rapidly, which allows you to keep advanced build mode active without having to hold the key. Pressing the key once more gets it back to normal.

Load/Unload Rail

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

 

General GUI updates

~ Main menu tooltips:

~ Loading advice

~ Keyboard options menu using new lists with subcategories and filters

~ Sector Heat warning marker if you’re getting close

~ Shop menu panel is a bit better/consistent

Config additions

~ ALLOW_PASTE_AABB_OVERLAPPING: Server option to disable/enable the building check if overlapping with other ship’s bounding box

~ ECMStrengthMod: BlockBehavior option that modifiers the amount of scanner modules needed versus mass of target ship to disable cloakers/jammers.
 

 

What’s next

Additional to the features we described above, this version also already contains the foundations for a lot of other bigger features to come, which aren’t finished yet. However, this is the main reason for this pre-release to have taken longer, following up on our promise to strive for quality instead of quantity.

Look out for the next dev blog which will contain the first part of our end-game documents.

 

Thanks for playing StarMade,

~ The Schine Team

Bug fixes

 

~ T2437 (Private): block exploit

~ T2379 (Private): Ctrl+A in client password entry field uncensors text

~ T2360 (Private): Cloaking/radarjammer issue

~ T2295 (Private): Uploaded blueprints can have no owner

 

~ T2467: /kick_players_out_of_entity kicks everyone on the server out of their entities

~ T2403 & T22: flip-flop and NOT signals not working properly with rail switching.

~ T2391: Rail + Storage disconnecting

~ T2388: Nullpointer with displays

~ T2372: Shootout rail launching at 45 degrees

~ T2361: Power auxiliary is disabled for AI

~ T2357: Typos in credits

~ T2323: Rail or display connection not shown or desync after logic swap

~ T2284: camera detaches from character when numpad+ key is pressed multiple times

~ T2220: weapon menu unlinking support/effect doesn't update list

~ T2218: /SQL_Query command cannot be used with starnet.jar

~ T2202: Alt Gr combinations for characters don't register

~ T2159: Race disappears from race menu

~ T2124: Advanced Build mouse cursor does not show up when key reassigned to RControl

~ T1840: shopkeep can't be respawned

~ T1819: Tooltip doesn't update for single stack items <-> multi slot | meta-item interaction

~ T1686: Shop can only accept one incoming connection

~ T1494: Display Module [] tags are cap sensitive

~ T1362: Jump distance not consistent (with changed sector size)

~ T1350: Thrust setting not saved in Blueprint

~ T111: Wireless connection isn’t wireless when on same Entity except Asteroids

 

We’ve also added more translations to the game and all of the typo fixes that were brought up by our hard working translators!

Greetings, citizens ~

 

Here’s what we’ve been up to:

 

Server Performance

 

While looking into server performance, we noticed an issue with NPC Fleet Management: something is preventing the proper clean-up of spawned fleets. This has been causing some of the larger servers to experience mysterious performance issues recently. If you have a server and are encountering high response times for ship creation, or server-related ping spikes, this issue might be the cause. We are working on a fix for this, and are monitoring the problem. In the interim, you may want to manually wipe all NPC-Fleets from your server from time to time (once per week should suffice). You may do so by running the following command:

 

/despawn_all FLTSHP all true

 

However!  Please warn your players before running this for the first time, as it may result in the server becoming unresponsive for several minutes. (Instances of cleaning up 150k to 300k ships are not uncommon, and that takes some time to process.)

 

SQL in StarNet

 

In one of the previous updates, we added the ability for server admins to query the server’s database directly via SQL.  This is an incredibly powerful tool, and many server owners have taken advantage of it to create fancy features on their websites, write fine-tuned automated scripts, gather game metrics, etc.  However, this functionality required us to inject the command directly into the console, and parse its reply -- not the cleanest or most direct approach.  StarNet, our dedicated tool for this sort of thing, also lacked the permissions to do this.  The next release will rectify this issue, giving StarNet the permissions it needs to both run SQL queries and get their output directly.  This should give admins cleaner, easier access to the internals of their server’s database.

 

 

What’s next?

 

Following our current release cycle, we’ve started releasing dev builds. These are generally buggy, unstable builds that give players early access to new features. For more information, refer to: https://starmadedock.net/threads/starmade-release-cycle-news-posts.28895/#post-338214

 

As soon as we’re happy with the development builds, we’ll release an official preview build. We will be following the procedure outlined in the document above, then after a round of both Schine and community testing, we’ll do a public release. After that, the next push will be for a playable dev build showcasing a prototype of the new power system. We want to get this in the hands of the community as soon as it’s ready, and are looking forward to your feedback. When the power system is completed, we will take a look at weapons, combat, and other utilities and give them a balance overhaul, as well as add new exciting features.

 

As always, thank you for playing StarMade!

 ~ The Schine Team

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