I'm aware this is alpha, and there are tonnes of things planned, so I've tried to steer away from suggesting new features as there are an endless number of things people can come up with, and it would be pointless/meaningless, and instead focus on the current features and content of the game.
I've split this list into a few different sections to keep relevant topics together.
Game mechanic/performance issues.
Ship control.
Catalogue settings/usage.
Building/Salaving issues.
Minor item issues.
Turret & AI issues.
Game mechanic/performance issues
Networking
The first and perhaps most important one is in regards to the data that's constantly communicated.
Problem: The other day I was on a very laggy server, and was attempting to change my weapon distribution points, I noticed that each time I clicked on one of the arrows, the number would sometimes bounce back to the original. My guess is that my client is communicating with the server each time I alter my weapons by a single percent, while I have the weapons computer open. This is not needed at all.
Solution: There should be some temp memory set aside which records all my alterations on the client while I'm in that window, and once I've closed the window, it should send off that 'packet' of information once. The game really doesn't need to update my weapons with every single click of the mouse in that computer, in fact, I can't actually fire my weapons while in that computer, so it's completely redundant, and clogs up client/server communications.
Assuming this problem isn't limited to just the weapons computer, I would like to suggest that client/server communications are split up into (at least) two categories:
Instant communications (UDP) - such as weapon fire, ship movement and other combat actions.
Non-instant communications (TCP) and packets - such as changing game options, weapon options, etc.
Grey areas - Some parts of the game can understandably be communicated in either way and these should be tagged as such so they can be switched easily from one to the other based on performance/gameplay testing. Things like: some types of building, especially if alone in a sector, there's no need for the server to be constantly aware of all the client's goings on, however you would need instant updates in some cases if blocks are being destroyed by combat etc. Also, shop item purchases, these can in many cases be non instant communications especially if only one person is interacting with a shop, however, if there are multiple people, then it might need to be instant as someone could entirely buy out the same thing you're looking to purchase.
The cached actions will only be sent to the server as a block of info once a trigger is tripped. For example, for any options screen, the trigger may either be a 'save' or 'accept' button, or simply closing the window. Another trigger may be based on a timer, in the case of building, to ensure that the package doesn't grow too large.
There do obviously need to be extra checks with non-instant comms to check whether the action is valid once the action is sent to the server as there can potentially be conflicts, i.e. with people at the shop purchasing the same items, or two building something simultaneously.
Collision
Obviously, the greater the number of blocks in an entity, the larger of collision checks there need to be.
Firstly, I just want to say, I have no idea how collision is coded in this game, but this is just an idea that I hope might help.
For each ship/entity, you have height, width and length variables, I imagine there's a preliminary check to see if two cuboids based on those measurements are within colliding distance of each other, if so, then you go down to checking each block (or chunks of blocks) for collision?
I'm not sure how it would appear to the game, but you could keep the idea of a bubble around each ship, perhaps projected by the core, or it's shields (but that's assuming all ships have a basic level of shielding, which could be possible). Collision may only need to be calculated based on that bubble, not necessarily a sphere, but an ellipsoid based on the entity's dimensions. Sadly this would lead to problems with docking as it currently stands, but that could be solved by ships requesting permissions to dock from your main computer, and then reverting to the previous form of collision detection if docking is accepted. This would greatly cut down on the number of calculations needed as docking is a rare occurance compared with any other sort of collision. Entities which wouldn't have a bubble, such as asteroids are not likely to collide with other asteroids, so the calculations again for collision with a ship's bubble should be vastly cut down.
Loading of large ships/entities
Again, I'm aware I don't know how this currently works, but hopefully this idea helps.
Large ships tend to lag a client when they appear, is it possible for them to be loaded, or gradually streamed to a client earlier, from greater distances away, than smaller ships? Perhaps the distance to be directly based on the size of the ship in question.
Also a 3D version of a 'mipmap' for these ships would be extremely useful if there isn't already, this would only be interested in sending blocks which have a visible face, together with the stats of the ship as a whole, so all the essential information is transmitted first enabling speedy display and combat potential. It's not as essential for the internal workings of a ship to be known to a new client immediately, nor internal blocks to show immediately, in the case of the external ones getting destroyed by immediate combat (which wouldn't occur more often than simply passing by each other).
Essentially, ships simply passing each other do not need to know all of their block information immediately.
Pirate ship creation
The server I currently play on has one blueprint that the pirates and trading guild seem to prefer more than any others, in fact, I haven't seen any other blueprints get chosen. The blueprint in question was created about two weeks ago by someone testing something I assume, as it's name is Test3, this blueprint has no weapons at all. The pirates and trading guild simply sit there in space, effectively as loot baskets.
I'm not sure the reason this design is always chosen, but it definitely kills the NPC threat on the server as you might imagine. The design is listed in the catalog on the server with the Owner (unknown), so either that player was cleared from the server logs, or whatever, but this might explain why? The design is also at the very top of the list if that makes a difference.
Initial spawning location
I understand that this is probably not the final version of how it will work in the released version of the game, however, it might be better if a random shop was chosen within the first star system, rather than always at 2, 2, 2. This would give players more of a chance to get up and started on a multiplayer server where spawn killing is rife, and 2, 2, 2 is littered with ships large and small. It would give a sort of added game play novelty if two friends need to find each other when starting on a server together.
Maybe some day players would initially spawn on planets though as opposed to in the middle of space, but I guess that sort of content isn't relevant for an alpha stage until vague story outlines about where people come into existence is decided upon.. besides, people can be born in space etc, etc.
Protected sectors
I again assume that protected sectors on multiplayer are there for players to have a chance to get going. However this often leaves servers (ones which I have visited) crippled with abandoned giant ships, unfinished ships, stations etc. being unremovable in that sector. Hopefully the above point about the initial spawning location may go some way to resolving this issue in an alternative fashion. If not, would it be possible to make ships in protected sectors only invulnerable while a player is inside, or perhaps have unattended ships have a time limit of an hour or so before they become un-protected? This would allow regulars on the server the chance to destroy and clear out any extra server baggage.
The following two are perhaps possible bugs than anything else.
Blocked Core on login
The core in my ship doesn't have bags of space around it, so when I log in, I get ported a short distance away which is fine. Sometimes however, there's a giant 16x16x16 block of the ship removed around the core (including the core sometimes). This happens rarely, and is easily retrievable as I can purchase a new version of the ship from the Catalog. I'm not sure what causes it, but it is a bit strange. I recently found that if I log out and back into the server, it reappears, so I guess it's a client/server communication issue of some sort. While on that topic, I have also noticed on login that my ship and it's turrets sometimes explode away from each other and go flying off into space.. again I'm not sure why this is, possibly some initial collision, or stuck check? But relogging often puts it all back into position, so the entities must remain in the same place on the server, and there's a synchronisation issue there? Not a clue what's going on here, but I thought I should note it as an oddity.
Multiple Entities not being destroyed
I attempted to create a space station the other day around a shop. I placed the initial block close to the shop structure, it wasn't in quite the correct position, so I destroyed it, and placed a new one. I did this about 10-15 times, fine. I came back later and noticed several large 10x10x2 or so blocks of red hull all located on top of, and within each other at the same location. On checking, each of the previous entities I had created still existed despite having destroyed each one before I placed the next. I may have used a 10x10x2 setting in the advanced build mode to build my station, so that's potentially where the size came from, but I didn't use any red hull, so that's a mystery to me. Again, I don't have any idea what caused this, so I can only really pass on the symptoms.
This brings the game mechanic/performance issues section to a close.
Ship Control Issues
Navigation Waypoint system
I keep hearing mild complaints about this on my server and how it makes you turn all the time to head to new sectors.
There is no reason anyone needs to turn more than 3 times once they've plotted in a course. The way it's set up right now, it sends you along the axis which is furthest away from the destination until one of the other axes is further, then it switches to that one, and so on until the destination is reached. While this closely models a straight line, it still makes the player turn and head in a zig zag manner, axially towards the destination. Because of this, it saves no time at all over simply travelling the full distance down each axis in turn to reach your destination.
It should (hopefully) be a simple enough change to make the navigation system travel down one of the axes at a time. This should save many players from having to constantly turn in this zigzag pattern.
Alternatively, a more beneficial method (although a lot more hassle) would be to calculate the vector from the current sector to the destination and plot a separate waypoint beacon on the screen for the player to take them there in a direct line. Note, this doesn't have to be a HUD-diamond located on the destination sector at all (as I doubt a distant sector will be loaded), it can just be a notation on the HUD at the angle from the current sector the player needs to take.
These could be different methods used in different versions of a navigation computer block.
Also, while on this topic, sometimes when entering a new sector (possibly negative ones?), the orientation of the ship suddenly jumps to face a completely different direction which is quite disorientating and if you're not paying attention, you can end up travelling a few sectors in a completely random direction to where you intended.
Plex doors on ships
I think it would be a nice addition if you could link plex doors on a ship to a 'plex door computer' and then link this to the core. Not all plex doors would have to be linked. The advantage of this would be with docking, you would be able to open and close specific doors from the core itself rather than one of the two pilots leaving their cores to operate the doors.
Weapons computer links
I think the weapons systems needs to be taken down another level if possible, it shouldn't affect complexity for new players either. Each individual block of cannons should be attached to a single weapons 'controller' to signify that that is one, single individual cannon system. I.e. if you fired that from the core, only one beam would fire, be it made of a single block, or multiple.
Linking up multiple cannons to work from the same number in the core should be the next step with the weapons computer.
The reason for this, is simple usability, sometimes you only want to fire a certain set of cannons, sometimes all at the same time.
Technically, I've heard that you can do this, by linking the same cannons to two different computers, however, this is not an appropriate way of managing this, as if you have a 3x3x3 block of cannons, and you want to link them to two separate computers, there's no way to select the centre cannon for use with the second computer, not to mention that it's a real pain in the arse to do if you've got a ship with several hundred plus cannons on it.
Breaking it down into single cannon groupings is a lot simpler and easier to understand, not to mention it gives you great flexibility with deciding on how to set up your weapons.
This item was challenging to word concisely for some reason, so I assume it's easy to mis-read, please re-read if there's an issue you'd like to raise with it.
GUI Element Computers/Components
I believe each element on your GUI should be linked to a block which allows with it, if you don't have the block, you don't have the GUI element.
- The Core should be responsible for basic life support, the health bar, and the build mode ability.
- The power bar should be separate from health and display only once a power block has been added.
- The weapons window should be accessible only once a relevant weapons computer has been added.
- Similarly, there should be a separate docking block which allows you to dock onto things, i.e. not like the current one which allows things to dock onto you. The advantage of this would be more user defined docking, not to mention making building turrets easier, and extending the amount to which you can build them. Imagine being able to line up plex doors with the ship you're docking onto! Air locks ahoy!
- The navigation elements, i.e. the diamonds on the HUD which tell you whether things are asteroids, planets, stations or other ships etc, should be viewable only once a 'Navi-comp' block has been added, also the navigation window and waypoint system.
In terms of complexity to new players, you will still be able to fly your ship without these, and it would be easier to get to grips with as the ship construction is more modular and broken down easily for tutorial aspects. For example, one of the first elements of the tutorial then would be adding in the navicomp and explaining the navigation elements to the player.
The idea behind this is a more immersive feeling to how you're building your ship.
But the main benefit would be in development. I'm currently working on a basic college game project at the moment (or should be, hah) and I'm the only programmer. I'm amazed how much coding goes into the GUI alone, it's almost half the number of lines of code of the entire thing so far, editing any of it seems like a nightmare. So, with splitting these things up into blocks like this, you can actually attach those GUI elements directly to the blocks, then whenever you want to upgrade a GUI element, simply add a new version of that block, i.e. a 'Navicomp Mk2' would bring the new GUI element in with it.
Ship flying permissions
As I understand it, currently you are not able to enter the core of a ship belonging to another faction, it would be good if you could extend this to prevent people from the same faction entering your ship. Maybe have a friends list, and tag individuals who are authorised to fly your ship. For example, the core might have a retinal scanner.
This brings the Ship Control Issues section to a close.
Catalogue settings/usage
First off, I have to say, this is perhaps one of the great things that makes this game unique, and is such a saving grace for the alpha, since you can protect your creations against major loss, and not to mention transferring your ideas between servers which was a major flaw with other games of this genre, cough cough.
However, this also brings in concerns of intellectual property/design ownership, albeit only between players.
Many people will spend days, weeks, and maybe months building their ships, so this is definitely worthy of some consideration.
Ship Ownership
There should be an option to attach your player signature or ID to a design you have created, and also have it registered on your website.
As an example, some time in the future, I'm sure someone will have a competition on the best designed ship which someone will want to submit their design to, however, they will have been using that ship for the past X amount of time on a server, and other players may have the blueprint also. There needs to be some way to distinguish the actual creator, from someone who just bought the ship from the catalog and saved it themselves under their name.
Linking the ID to the core
The creator ID should also exist linked to the ship's core in the case that it becomes captured by another and then catalogued and claimed as their own design. This would prevent it from being catalogued. These ships may still be edited, salvaged, or improved upon by the capturing player, but it should still retain the original player's creator ID.
Default Permissions
The setting to share your creations with others should be set off as default; currently it is set on, and new players are not aware of this.
Server Catalog
Blueprints need to be protected and if possible, encrypted.
Cataloging Stations
I'm sure this has been given some consideration already, but I'd like to throw in a short bit about it.
Cataloging is the primary way to save and protect your creations. At the moment, only creating a ship really makes sense as you can ensure that your work will always exist, and not be wiped out by a server rollback of all things. It would be nice to have the same ability for stations.
One disadvantage of it that I can see at the moment, it that players may spawn in a new station whereever they choose, and have multiple, similar looking stations all over a star system providing safe docking points with ease. ...actually I'm not sure how this differs all that much from ships.
However, if multiples of the same station is a concern, is it possible to have each player only have one station blueprint uploaded which they can only use once on that server?
One major problem with it would also be placement, since you can't alter it's location once it's been placed, or bought. Going back to my station example which I built around a shop, being able to place the station precisely would be a huge concern there. Loading up a station and carefully adjusting it before you buy it would be problematic to say the least, but if you had a 'marker' block which you have added to the station blueprint in specific locations, you could then locate the station-to-be-built by using those markers as a frame work. I.e. On my station, I would place marker blocks close to, and around the section which fits around the shop; when buying it on a server, it would give me a build element, similar to the yellow block outline in build mode, with the locations of the marker blocks showing only, rather than the whole station, and then it could be aligned like that.
Again, I've overlooked the fact that you can only purchase blueprints at shops, so buying a station in the middle of nowhere would also be another issue.. which again would have many options for a solution. Perhaps along the same sort of lines of my shipyard suggestion further down.
This brings the Cataloging issues to a close.
Building/Salvaging issues
Station built around a shop
My main reason for doing this, was so that when any member of my faction dies, they have access to a location where they may purchase a ship core. It also has all the benefits of having a shop in your station too of course.
But, this does bring up a couple of points.
Firstly, players are able to build a factioned station around the shop in sector 2, 2, 2 and effectively close in the undeathinators preventing new players from doing anything on that server.
There are two solutions to this:
1. As per my earlier suggestion, spawn new players at random shops throughout the star system, and maybe give a player an option of three different undeathinators to spawn at in the spawn menu.
2. Prevent players from building within a certain distance around a shop.
Station Shop
This goes hand in hand with the above point really, it would be nice to be able to place your own shop on your own station, especially if building around current shops is prevented!
Shipyard
Instead of being able to purchase ship blueprints at shops, there should be shipyards located throughout the galaxy.
At these shipyards, you do not get your designed ship instantly. The ships are built, it takes time. The time is based on the mass of the ship you're purchasing. This should hopefully go some way to prevent blueprint spammers, and will definitely reduce the immediate load on the server.
You will have to gather all the outstanding resources the ship needs, and the shipyard does not have, before the shipyard can start/finish work on it. This would prevent people from creating solid blocks of a certain resource to by-pass the shop's item limits, and would definitely increase the value of investment of a large ship to a player.
The shipyard would take a 20-50% extra charge on the labour for building it, depending on the shipyard.
This in itself would slow down and limit the rate at whichlarge ships can be built.
As touched upon in the Astrotech AI point below, if at some point there are AI controlled ships which can use the Astrotech beam, perhaps a ship blueprint could be given to these to slowly construct your ship, so you can see it appearing before your eyes.
The build block salvaging issue
I prefer simple solutions as they tend not to lead to any further problems. I would suggest simply removing the option to remove anything other than single blocks. It's not precise when building a complex structure. I don't really make use of it when building a large ship as you're likely to do more damage than good; I'm not sure if others actually make extensive use of it for it's intended use. If on the rare occasion that does happen, then perhaps a small salvage vessel would be the preferred option to allowing people to mass gather a station/planet/asteroid.
Ship Inventory
Again, this could be a GUI element which only appears once a ship chest has been added.
The suggestion here, is to have a block, other than a PlexStorage, specifically designed for use in ships.
Raiding pirate bases, looting pirates, and to a lesser extent, salvaging, all usually end up filling your inventory to the point of overflowing. There are too many different types of items dropped.
Instead, anything gathered or salvaged by your ship, will go directly into the ship's chests rather than your own inventory. The idea here, is that you can add additional chests so that you don't have to keep stopping, exiting the core, manually filling the chests, getting back in the core, and flying into the other items, or much worse, picking the items up manually (it's a pain if you have a large ship). Also, items may timeout and disappear before you can even make space sometimes.
You should also be able to directly sell items from the ship's inventory.
And on that note, please change it so that if your inventory is full, items do not get picked up, but stay thereuntil you make room.
This brings the building and salvaging issues to a close.
Minor item issues
Corner hull pieces
Nothing major, just that the square face is only available on the top or bottom of the block and not on the sides, although this would raise the number of variations of it to 24 rather than the 8 it's at currently.
If it's possible to give it these variations, would it also be possible to have an inverted version of it so you could fill concave corners rather than only convex? Perhaps as variations of the same block if not another one entirely?
Antimatter cannons
I am curious if these are working as intended, the description says that adding more cannons to a block increases their combined damage, distance, speed and reload. Yet, one cannon block, re-assigned to full damage, gives 50 damage, but two cannon blocks combined re-assigned to full damage gives 75 damage.
In this situation, it would be beneficial to have the two cannon blocks separate and set to full damage so the combined output would reach 100 damage. I.e. it seems that contrary to the item description, you get more output from the cannons if they are separated rather than in a block together.
Re-assigning/Distributing cannon points GUI
Would it be possible to add a GUI element to this window please? A slider bar for setting the percentages would be handy, a max and min button would as well. Even if you could simply hold the mouse button down while clicking on the left and right arrows. At the moment you have to click for every single one percent. If you're re-assigning something to be one stat heavy, then you're clicking 175 times for each cannon! Not even considering a laggy server which keeps resetting your distributions.
This brings the minor item issues section to a close.
Turret & AI issues
First off, Bobby AI is fine. It's the first, basic AI block that can be bought, however, we are in desperate needs of a BillyAI.
Turrets linked to core
Firstly, it would hugely beneficial if docked turrets on a ship could be directly linked to an interface in the ship's core. We can already choose to undock them, so hopefully we will be able to interact with them in other ways too in the future.
The AI modules on the turrets should be accessible from the core so you can activate and deactivate them as and when you choose to, as well as being able to set their other parameters. This would hopefully go some way to resolving my next issue, and goes hand in hand with it.
Perhaps there should be a turret computer block, similar to the weapons block, which then takes care of all the turret interfacing.
Turret targetting
Dreadful. I have accidentally killed faction members. I'm sure many others have. I've accidentally shot up and sprayed a space station I was working on. The aim is atrocious, unfortunately, I'm not talking about combat necessarily, but if they were accurate enough, I'd only have to replace 10-15 blocks, but because they randomly pepper an area... well, I was there for a few hours repairing a momentary accidental selecting.
There needs to be a different way of selecting a ship, asteroid whatever, to setting it as a target. Or even expressly giving your turrets the command to attack.
When you enter a sector, and there are several things there, you select them, as that's how the names of things appear, that's how you tell players apart, there's nothing hostile intended about that.
I would greatly prefer if turrets would have the attack settings of 'On Command', 'Hostile' and 'Hostile or Neutral'.
'On Command' would not attack at will, but would only attack the targets you speifically give to your turrets.
'Hostile' would attack at will only those entities around you which were marked as red on your HUD, and within range, you would also be able to select and specifically give a new target to your turrets, hostile or otherwise.
'Hostile or Neutral' would attack at will, anything other than a faction member or ally.
Turrets would not actively seek out and attack asteroids or planets on their own regardless of setting, you would need to give the attack command for those specifically.
Turrets would only ever attack a faction member or ally if you specifically gave them the attack command.
Turret Aiming
I sat for ten minutes the other day with my turrets trained on an asteroid, they were just as inaccurate at the end as they were at the start, nothing was moving, the ship wasn't, the asteroid wasn't, but the turrets were jittering all over the place. Would it be possible for the aim/accuracy of turrets to improve slightly over time on stationary objects? Or maybe even advanced AI blocks to have a lock on ability, as missiles do?
Turrets damaging other turrets on the same ship (possibly docked ships also)
I'm not sure if this one is intended, but I'm tending towards thinking it's not, because your own ship weapons don't damage your own ship.
I had three forward turrets, and three rear turrets, the rear three destroyed the forward three in the back of their heads. Ideally if you were building a set up like that in real life, you'd be able to prevent the movement of the rear turrets from hitting the front ones; in the game, it would be harder to do that than simply have them shoot through the forward turrets, as the weapons on your ship shoot through your own hull without damage.
Astrotech AI
Hopefully this is already planned, but it would be pretty cool to have a few small astrotech drones docked on your ship which you can send out to repair your hull either in battle, or after. They shouldn't affect combat all that much, as if you're hulls are damaged, your shields are down, and you're likely dead anyway, but for post combat recovery they could be pretty nice. In addition, they could use the current blueprint for your ship, in conjunction with the ship chests suggestion above, and use the materials from there to replace missing blocks.
Although, just thinking about this, takes me back to the shipyard suggestion; they could have drones which gradually build your ship.
Salvage Drones
Again, hopefully this is already planned, maybe there could be another AI block for ships with only salvage cannons that you can leave on a planet or asteroid to salvage it.
This brings the Turrets & AI section to a close.
I've split this list into a few different sections to keep relevant topics together.
Game mechanic/performance issues.
Ship control.
Catalogue settings/usage.
Building/Salaving issues.
Minor item issues.
Turret & AI issues.
Game mechanic/performance issues
Networking
The first and perhaps most important one is in regards to the data that's constantly communicated.
Problem: The other day I was on a very laggy server, and was attempting to change my weapon distribution points, I noticed that each time I clicked on one of the arrows, the number would sometimes bounce back to the original. My guess is that my client is communicating with the server each time I alter my weapons by a single percent, while I have the weapons computer open. This is not needed at all.
Solution: There should be some temp memory set aside which records all my alterations on the client while I'm in that window, and once I've closed the window, it should send off that 'packet' of information once. The game really doesn't need to update my weapons with every single click of the mouse in that computer, in fact, I can't actually fire my weapons while in that computer, so it's completely redundant, and clogs up client/server communications.
Assuming this problem isn't limited to just the weapons computer, I would like to suggest that client/server communications are split up into (at least) two categories:
Instant communications (UDP) - such as weapon fire, ship movement and other combat actions.
Non-instant communications (TCP) and packets - such as changing game options, weapon options, etc.
Grey areas - Some parts of the game can understandably be communicated in either way and these should be tagged as such so they can be switched easily from one to the other based on performance/gameplay testing. Things like: some types of building, especially if alone in a sector, there's no need for the server to be constantly aware of all the client's goings on, however you would need instant updates in some cases if blocks are being destroyed by combat etc. Also, shop item purchases, these can in many cases be non instant communications especially if only one person is interacting with a shop, however, if there are multiple people, then it might need to be instant as someone could entirely buy out the same thing you're looking to purchase.
The cached actions will only be sent to the server as a block of info once a trigger is tripped. For example, for any options screen, the trigger may either be a 'save' or 'accept' button, or simply closing the window. Another trigger may be based on a timer, in the case of building, to ensure that the package doesn't grow too large.
There do obviously need to be extra checks with non-instant comms to check whether the action is valid once the action is sent to the server as there can potentially be conflicts, i.e. with people at the shop purchasing the same items, or two building something simultaneously.
Collision
Obviously, the greater the number of blocks in an entity, the larger of collision checks there need to be.
Firstly, I just want to say, I have no idea how collision is coded in this game, but this is just an idea that I hope might help.
For each ship/entity, you have height, width and length variables, I imagine there's a preliminary check to see if two cuboids based on those measurements are within colliding distance of each other, if so, then you go down to checking each block (or chunks of blocks) for collision?
I'm not sure how it would appear to the game, but you could keep the idea of a bubble around each ship, perhaps projected by the core, or it's shields (but that's assuming all ships have a basic level of shielding, which could be possible). Collision may only need to be calculated based on that bubble, not necessarily a sphere, but an ellipsoid based on the entity's dimensions. Sadly this would lead to problems with docking as it currently stands, but that could be solved by ships requesting permissions to dock from your main computer, and then reverting to the previous form of collision detection if docking is accepted. This would greatly cut down on the number of calculations needed as docking is a rare occurance compared with any other sort of collision. Entities which wouldn't have a bubble, such as asteroids are not likely to collide with other asteroids, so the calculations again for collision with a ship's bubble should be vastly cut down.
Loading of large ships/entities
Again, I'm aware I don't know how this currently works, but hopefully this idea helps.
Large ships tend to lag a client when they appear, is it possible for them to be loaded, or gradually streamed to a client earlier, from greater distances away, than smaller ships? Perhaps the distance to be directly based on the size of the ship in question.
Also a 3D version of a 'mipmap' for these ships would be extremely useful if there isn't already, this would only be interested in sending blocks which have a visible face, together with the stats of the ship as a whole, so all the essential information is transmitted first enabling speedy display and combat potential. It's not as essential for the internal workings of a ship to be known to a new client immediately, nor internal blocks to show immediately, in the case of the external ones getting destroyed by immediate combat (which wouldn't occur more often than simply passing by each other).
Essentially, ships simply passing each other do not need to know all of their block information immediately.
Pirate ship creation
The server I currently play on has one blueprint that the pirates and trading guild seem to prefer more than any others, in fact, I haven't seen any other blueprints get chosen. The blueprint in question was created about two weeks ago by someone testing something I assume, as it's name is Test3, this blueprint has no weapons at all. The pirates and trading guild simply sit there in space, effectively as loot baskets.
I'm not sure the reason this design is always chosen, but it definitely kills the NPC threat on the server as you might imagine. The design is listed in the catalog on the server with the Owner (unknown), so either that player was cleared from the server logs, or whatever, but this might explain why? The design is also at the very top of the list if that makes a difference.
Initial spawning location
I understand that this is probably not the final version of how it will work in the released version of the game, however, it might be better if a random shop was chosen within the first star system, rather than always at 2, 2, 2. This would give players more of a chance to get up and started on a multiplayer server where spawn killing is rife, and 2, 2, 2 is littered with ships large and small. It would give a sort of added game play novelty if two friends need to find each other when starting on a server together.
Maybe some day players would initially spawn on planets though as opposed to in the middle of space, but I guess that sort of content isn't relevant for an alpha stage until vague story outlines about where people come into existence is decided upon.. besides, people can be born in space etc, etc.
Protected sectors
I again assume that protected sectors on multiplayer are there for players to have a chance to get going. However this often leaves servers (ones which I have visited) crippled with abandoned giant ships, unfinished ships, stations etc. being unremovable in that sector. Hopefully the above point about the initial spawning location may go some way to resolving this issue in an alternative fashion. If not, would it be possible to make ships in protected sectors only invulnerable while a player is inside, or perhaps have unattended ships have a time limit of an hour or so before they become un-protected? This would allow regulars on the server the chance to destroy and clear out any extra server baggage.
The following two are perhaps possible bugs than anything else.
Blocked Core on login
The core in my ship doesn't have bags of space around it, so when I log in, I get ported a short distance away which is fine. Sometimes however, there's a giant 16x16x16 block of the ship removed around the core (including the core sometimes). This happens rarely, and is easily retrievable as I can purchase a new version of the ship from the Catalog. I'm not sure what causes it, but it is a bit strange. I recently found that if I log out and back into the server, it reappears, so I guess it's a client/server communication issue of some sort. While on that topic, I have also noticed on login that my ship and it's turrets sometimes explode away from each other and go flying off into space.. again I'm not sure why this is, possibly some initial collision, or stuck check? But relogging often puts it all back into position, so the entities must remain in the same place on the server, and there's a synchronisation issue there? Not a clue what's going on here, but I thought I should note it as an oddity.
Multiple Entities not being destroyed
I attempted to create a space station the other day around a shop. I placed the initial block close to the shop structure, it wasn't in quite the correct position, so I destroyed it, and placed a new one. I did this about 10-15 times, fine. I came back later and noticed several large 10x10x2 or so blocks of red hull all located on top of, and within each other at the same location. On checking, each of the previous entities I had created still existed despite having destroyed each one before I placed the next. I may have used a 10x10x2 setting in the advanced build mode to build my station, so that's potentially where the size came from, but I didn't use any red hull, so that's a mystery to me. Again, I don't have any idea what caused this, so I can only really pass on the symptoms.
This brings the game mechanic/performance issues section to a close.
Ship Control Issues
Navigation Waypoint system
I keep hearing mild complaints about this on my server and how it makes you turn all the time to head to new sectors.
There is no reason anyone needs to turn more than 3 times once they've plotted in a course. The way it's set up right now, it sends you along the axis which is furthest away from the destination until one of the other axes is further, then it switches to that one, and so on until the destination is reached. While this closely models a straight line, it still makes the player turn and head in a zig zag manner, axially towards the destination. Because of this, it saves no time at all over simply travelling the full distance down each axis in turn to reach your destination.
It should (hopefully) be a simple enough change to make the navigation system travel down one of the axes at a time. This should save many players from having to constantly turn in this zigzag pattern.
Alternatively, a more beneficial method (although a lot more hassle) would be to calculate the vector from the current sector to the destination and plot a separate waypoint beacon on the screen for the player to take them there in a direct line. Note, this doesn't have to be a HUD-diamond located on the destination sector at all (as I doubt a distant sector will be loaded), it can just be a notation on the HUD at the angle from the current sector the player needs to take.
These could be different methods used in different versions of a navigation computer block.
Also, while on this topic, sometimes when entering a new sector (possibly negative ones?), the orientation of the ship suddenly jumps to face a completely different direction which is quite disorientating and if you're not paying attention, you can end up travelling a few sectors in a completely random direction to where you intended.
Plex doors on ships
I think it would be a nice addition if you could link plex doors on a ship to a 'plex door computer' and then link this to the core. Not all plex doors would have to be linked. The advantage of this would be with docking, you would be able to open and close specific doors from the core itself rather than one of the two pilots leaving their cores to operate the doors.
Weapons computer links
I think the weapons systems needs to be taken down another level if possible, it shouldn't affect complexity for new players either. Each individual block of cannons should be attached to a single weapons 'controller' to signify that that is one, single individual cannon system. I.e. if you fired that from the core, only one beam would fire, be it made of a single block, or multiple.
Linking up multiple cannons to work from the same number in the core should be the next step with the weapons computer.
The reason for this, is simple usability, sometimes you only want to fire a certain set of cannons, sometimes all at the same time.
Technically, I've heard that you can do this, by linking the same cannons to two different computers, however, this is not an appropriate way of managing this, as if you have a 3x3x3 block of cannons, and you want to link them to two separate computers, there's no way to select the centre cannon for use with the second computer, not to mention that it's a real pain in the arse to do if you've got a ship with several hundred plus cannons on it.
Breaking it down into single cannon groupings is a lot simpler and easier to understand, not to mention it gives you great flexibility with deciding on how to set up your weapons.
This item was challenging to word concisely for some reason, so I assume it's easy to mis-read, please re-read if there's an issue you'd like to raise with it.
GUI Element Computers/Components
I believe each element on your GUI should be linked to a block which allows with it, if you don't have the block, you don't have the GUI element.
- The Core should be responsible for basic life support, the health bar, and the build mode ability.
- The power bar should be separate from health and display only once a power block has been added.
- The weapons window should be accessible only once a relevant weapons computer has been added.
- Similarly, there should be a separate docking block which allows you to dock onto things, i.e. not like the current one which allows things to dock onto you. The advantage of this would be more user defined docking, not to mention making building turrets easier, and extending the amount to which you can build them. Imagine being able to line up plex doors with the ship you're docking onto! Air locks ahoy!
- The navigation elements, i.e. the diamonds on the HUD which tell you whether things are asteroids, planets, stations or other ships etc, should be viewable only once a 'Navi-comp' block has been added, also the navigation window and waypoint system.
In terms of complexity to new players, you will still be able to fly your ship without these, and it would be easier to get to grips with as the ship construction is more modular and broken down easily for tutorial aspects. For example, one of the first elements of the tutorial then would be adding in the navicomp and explaining the navigation elements to the player.
The idea behind this is a more immersive feeling to how you're building your ship.
But the main benefit would be in development. I'm currently working on a basic college game project at the moment (or should be, hah) and I'm the only programmer. I'm amazed how much coding goes into the GUI alone, it's almost half the number of lines of code of the entire thing so far, editing any of it seems like a nightmare. So, with splitting these things up into blocks like this, you can actually attach those GUI elements directly to the blocks, then whenever you want to upgrade a GUI element, simply add a new version of that block, i.e. a 'Navicomp Mk2' would bring the new GUI element in with it.
Ship flying permissions
As I understand it, currently you are not able to enter the core of a ship belonging to another faction, it would be good if you could extend this to prevent people from the same faction entering your ship. Maybe have a friends list, and tag individuals who are authorised to fly your ship. For example, the core might have a retinal scanner.
This brings the Ship Control Issues section to a close.
Catalogue settings/usage
First off, I have to say, this is perhaps one of the great things that makes this game unique, and is such a saving grace for the alpha, since you can protect your creations against major loss, and not to mention transferring your ideas between servers which was a major flaw with other games of this genre, cough cough.
However, this also brings in concerns of intellectual property/design ownership, albeit only between players.
Many people will spend days, weeks, and maybe months building their ships, so this is definitely worthy of some consideration.
Ship Ownership
There should be an option to attach your player signature or ID to a design you have created, and also have it registered on your website.
As an example, some time in the future, I'm sure someone will have a competition on the best designed ship which someone will want to submit their design to, however, they will have been using that ship for the past X amount of time on a server, and other players may have the blueprint also. There needs to be some way to distinguish the actual creator, from someone who just bought the ship from the catalog and saved it themselves under their name.
Linking the ID to the core
The creator ID should also exist linked to the ship's core in the case that it becomes captured by another and then catalogued and claimed as their own design. This would prevent it from being catalogued. These ships may still be edited, salvaged, or improved upon by the capturing player, but it should still retain the original player's creator ID.
Default Permissions
The setting to share your creations with others should be set off as default; currently it is set on, and new players are not aware of this.
Server Catalog
Blueprints need to be protected and if possible, encrypted.
Cataloging Stations
I'm sure this has been given some consideration already, but I'd like to throw in a short bit about it.
Cataloging is the primary way to save and protect your creations. At the moment, only creating a ship really makes sense as you can ensure that your work will always exist, and not be wiped out by a server rollback of all things. It would be nice to have the same ability for stations.
One disadvantage of it that I can see at the moment, it that players may spawn in a new station whereever they choose, and have multiple, similar looking stations all over a star system providing safe docking points with ease. ...actually I'm not sure how this differs all that much from ships.
However, if multiples of the same station is a concern, is it possible to have each player only have one station blueprint uploaded which they can only use once on that server?
One major problem with it would also be placement, since you can't alter it's location once it's been placed, or bought. Going back to my station example which I built around a shop, being able to place the station precisely would be a huge concern there. Loading up a station and carefully adjusting it before you buy it would be problematic to say the least, but if you had a 'marker' block which you have added to the station blueprint in specific locations, you could then locate the station-to-be-built by using those markers as a frame work. I.e. On my station, I would place marker blocks close to, and around the section which fits around the shop; when buying it on a server, it would give me a build element, similar to the yellow block outline in build mode, with the locations of the marker blocks showing only, rather than the whole station, and then it could be aligned like that.
Again, I've overlooked the fact that you can only purchase blueprints at shops, so buying a station in the middle of nowhere would also be another issue.. which again would have many options for a solution. Perhaps along the same sort of lines of my shipyard suggestion further down.
This brings the Cataloging issues to a close.
Building/Salvaging issues
Station built around a shop
My main reason for doing this, was so that when any member of my faction dies, they have access to a location where they may purchase a ship core. It also has all the benefits of having a shop in your station too of course.
But, this does bring up a couple of points.
Firstly, players are able to build a factioned station around the shop in sector 2, 2, 2 and effectively close in the undeathinators preventing new players from doing anything on that server.
There are two solutions to this:
1. As per my earlier suggestion, spawn new players at random shops throughout the star system, and maybe give a player an option of three different undeathinators to spawn at in the spawn menu.
2. Prevent players from building within a certain distance around a shop.
Station Shop
This goes hand in hand with the above point really, it would be nice to be able to place your own shop on your own station, especially if building around current shops is prevented!
Shipyard
Instead of being able to purchase ship blueprints at shops, there should be shipyards located throughout the galaxy.
At these shipyards, you do not get your designed ship instantly. The ships are built, it takes time. The time is based on the mass of the ship you're purchasing. This should hopefully go some way to prevent blueprint spammers, and will definitely reduce the immediate load on the server.
You will have to gather all the outstanding resources the ship needs, and the shipyard does not have, before the shipyard can start/finish work on it. This would prevent people from creating solid blocks of a certain resource to by-pass the shop's item limits, and would definitely increase the value of investment of a large ship to a player.
The shipyard would take a 20-50% extra charge on the labour for building it, depending on the shipyard.
This in itself would slow down and limit the rate at whichlarge ships can be built.
As touched upon in the Astrotech AI point below, if at some point there are AI controlled ships which can use the Astrotech beam, perhaps a ship blueprint could be given to these to slowly construct your ship, so you can see it appearing before your eyes.
The build block salvaging issue
I prefer simple solutions as they tend not to lead to any further problems. I would suggest simply removing the option to remove anything other than single blocks. It's not precise when building a complex structure. I don't really make use of it when building a large ship as you're likely to do more damage than good; I'm not sure if others actually make extensive use of it for it's intended use. If on the rare occasion that does happen, then perhaps a small salvage vessel would be the preferred option to allowing people to mass gather a station/planet/asteroid.
Ship Inventory
Again, this could be a GUI element which only appears once a ship chest has been added.
The suggestion here, is to have a block, other than a PlexStorage, specifically designed for use in ships.
Raiding pirate bases, looting pirates, and to a lesser extent, salvaging, all usually end up filling your inventory to the point of overflowing. There are too many different types of items dropped.
Instead, anything gathered or salvaged by your ship, will go directly into the ship's chests rather than your own inventory. The idea here, is that you can add additional chests so that you don't have to keep stopping, exiting the core, manually filling the chests, getting back in the core, and flying into the other items, or much worse, picking the items up manually (it's a pain if you have a large ship). Also, items may timeout and disappear before you can even make space sometimes.
You should also be able to directly sell items from the ship's inventory.
And on that note, please change it so that if your inventory is full, items do not get picked up, but stay thereuntil you make room.
This brings the building and salvaging issues to a close.
Minor item issues
Corner hull pieces
Nothing major, just that the square face is only available on the top or bottom of the block and not on the sides, although this would raise the number of variations of it to 24 rather than the 8 it's at currently.
If it's possible to give it these variations, would it also be possible to have an inverted version of it so you could fill concave corners rather than only convex? Perhaps as variations of the same block if not another one entirely?
Antimatter cannons
I am curious if these are working as intended, the description says that adding more cannons to a block increases their combined damage, distance, speed and reload. Yet, one cannon block, re-assigned to full damage, gives 50 damage, but two cannon blocks combined re-assigned to full damage gives 75 damage.
In this situation, it would be beneficial to have the two cannon blocks separate and set to full damage so the combined output would reach 100 damage. I.e. it seems that contrary to the item description, you get more output from the cannons if they are separated rather than in a block together.
Re-assigning/Distributing cannon points GUI
Would it be possible to add a GUI element to this window please? A slider bar for setting the percentages would be handy, a max and min button would as well. Even if you could simply hold the mouse button down while clicking on the left and right arrows. At the moment you have to click for every single one percent. If you're re-assigning something to be one stat heavy, then you're clicking 175 times for each cannon! Not even considering a laggy server which keeps resetting your distributions.
This brings the minor item issues section to a close.
Turret & AI issues
First off, Bobby AI is fine. It's the first, basic AI block that can be bought, however, we are in desperate needs of a BillyAI.
Turrets linked to core
Firstly, it would hugely beneficial if docked turrets on a ship could be directly linked to an interface in the ship's core. We can already choose to undock them, so hopefully we will be able to interact with them in other ways too in the future.
The AI modules on the turrets should be accessible from the core so you can activate and deactivate them as and when you choose to, as well as being able to set their other parameters. This would hopefully go some way to resolving my next issue, and goes hand in hand with it.
Perhaps there should be a turret computer block, similar to the weapons block, which then takes care of all the turret interfacing.
Turret targetting
Dreadful. I have accidentally killed faction members. I'm sure many others have. I've accidentally shot up and sprayed a space station I was working on. The aim is atrocious, unfortunately, I'm not talking about combat necessarily, but if they were accurate enough, I'd only have to replace 10-15 blocks, but because they randomly pepper an area... well, I was there for a few hours repairing a momentary accidental selecting.
There needs to be a different way of selecting a ship, asteroid whatever, to setting it as a target. Or even expressly giving your turrets the command to attack.
When you enter a sector, and there are several things there, you select them, as that's how the names of things appear, that's how you tell players apart, there's nothing hostile intended about that.
I would greatly prefer if turrets would have the attack settings of 'On Command', 'Hostile' and 'Hostile or Neutral'.
'On Command' would not attack at will, but would only attack the targets you speifically give to your turrets.
'Hostile' would attack at will only those entities around you which were marked as red on your HUD, and within range, you would also be able to select and specifically give a new target to your turrets, hostile or otherwise.
'Hostile or Neutral' would attack at will, anything other than a faction member or ally.
Turrets would not actively seek out and attack asteroids or planets on their own regardless of setting, you would need to give the attack command for those specifically.
Turrets would only ever attack a faction member or ally if you specifically gave them the attack command.
Turret Aiming
I sat for ten minutes the other day with my turrets trained on an asteroid, they were just as inaccurate at the end as they were at the start, nothing was moving, the ship wasn't, the asteroid wasn't, but the turrets were jittering all over the place. Would it be possible for the aim/accuracy of turrets to improve slightly over time on stationary objects? Or maybe even advanced AI blocks to have a lock on ability, as missiles do?
Turrets damaging other turrets on the same ship (possibly docked ships also)
I'm not sure if this one is intended, but I'm tending towards thinking it's not, because your own ship weapons don't damage your own ship.
I had three forward turrets, and three rear turrets, the rear three destroyed the forward three in the back of their heads. Ideally if you were building a set up like that in real life, you'd be able to prevent the movement of the rear turrets from hitting the front ones; in the game, it would be harder to do that than simply have them shoot through the forward turrets, as the weapons on your ship shoot through your own hull without damage.
Astrotech AI
Hopefully this is already planned, but it would be pretty cool to have a few small astrotech drones docked on your ship which you can send out to repair your hull either in battle, or after. They shouldn't affect combat all that much, as if you're hulls are damaged, your shields are down, and you're likely dead anyway, but for post combat recovery they could be pretty nice. In addition, they could use the current blueprint for your ship, in conjunction with the ship chests suggestion above, and use the materials from there to replace missing blocks.
Although, just thinking about this, takes me back to the shipyard suggestion; they could have drones which gradually build your ship.
Salvage Drones
Again, hopefully this is already planned, maybe there could be another AI block for ships with only salvage cannons that you can leave on a planet or asteroid to salvage it.
This brings the Turrets & AI section to a close.
