Zistack

And that focus, frankly, needs to change. This is primarily a building game, not, I repeat, not an action-RPG. Game devs need to recognize when their vision conflicts with their audience (this is an industry-wide problem, not just for this game). The audience Avorion attracts will be the type of people who play Starmade, Space Engineers, From the Depths, and their ilk, not the Diablo series or Path of Exile or Torchlight. That's not to say those two audiences are mutually exclusive, I myself have played Diablo 2 and I'm sure many other gamers enjoy both types of games, but generally speaking, the type of gameplay and the desires of the playerbases are extremely different between the two game styles. The ability to build your ships with/around their weapons is not just a nice feature, it's outright mandatory for this kind of game. If we can't custom design and build our weapons themselves, that's fine. I know when to pick my battles. But at minimum, the ability to place turrets and weapons on your ship at creation is required, or the building side of Avorion will always remain incomplete. Giving us the ability to customize our ship itself to a degree unequaled by any other game of this type, but then restricting our weapons choices to the tyranny of the RNG, is not only at odds with this style of game and its gameplay, but given the frequency with which new posts about this topic appear (about once a week or so), it's at odds with the desires of the vast majority of the playerbase as well. Finally. Someone other than me had the guts to say this. +1 I feel obligated to link my thread about this here. Note the Dev's response on the last page... Note that doability is not an issue here, so stop claiming otherwise if you're not the dev! Another relevant quote for this discussion... It's odd that the inspiration for the game was space sims and a creative sandbox game, and yet people claim that this should be an RPG. It's not labelled as an RPG on the steam store page, although I feel like the point of the quests and the RNG is to make the game feel more like an RPG. Mind you, adding more quests or story or whatever wouldn't be a bad thing (I would like to see more 'things' happening, not just ships flying around), but I agree that the RNG does not fit the rest of the game. It basically eliminates the possibility of strategy as it is currently implemented, and I note that the 'improvements' that the dev is proposing would not change that. With the ability to manufacture found turrets in bulk, this problem does not go away. Ultimately that's a balance issue, which turns out to be completely independent of how exactly turrets are obtained, contrary to the dev's claim (I am also a programmer/designer).

Ohohoh! I've been mulling about something closely related to this for a while now. If this were Space Engineers or Starmade there'd be no chance, but blocks can scale arbitrarily in Avorion... The short version is: It can be done. But first, we're going to talk about all of the missing shapes in Avorion. Why? You'll see in a moment. Bear with me. You can enumerate all of the primitives that you'd find if you poly'd over the various combinations of the corners of a cube. Many such combos would result in mirrored or rotated versions of things you had already found. A few of them can be constructed out of other primitives - although sometimes you wouldn't want to... After deduplication and deconstruction you end up with a nice set of primitives. I've made an imgur album depicting them. I'm sure the names of the primitives are all wrong. Someone who's an even bigger geometry nerd than I should correct me. Also, I think I've got them all, but it's possible that I've missed one. If so, let me know. There's the set that we all know and love - cube, edge, inner, tetra. Then there's a couple others that aren't too much of a stretch - the quarter pyramid and its subtraction. The rest are a bit unusual. I won't go into details. Please, just look at the album. I've attached the .scad file (as a .txt - rename before opening) for these primitives. For the truly curious - and anyone who has trouble figuring out some of the shapes - I recommend grabbing that file and looking at it in OpenSCAD (it's free). OK, so what does this have to do with arbitrary rotation? Well, given an arbitrary mesh, I believe that it is possible to break the mesh down completely so that it can be expressed in terms of only these primitives (and the various rotations and mirrorings thereof). Something like slicing the design at each vertex (possibly all three planes each time, but maybe this isn't strictly necessary?), and then identifying the contents of the 'cells' that end up being created by such an operation. You'd probably want to run some kind of binpacking algorithm or something to try to merge cells that didn't really need to be split (basically, the cubes on the inside should be no smaller than necessary). If implementing this as an editor feature, then keep the original around, and just re-rotate that if the user decides that their first choice of angle wasn't right. This is so that you don't end up with an explosion in the number of blocks. If anyone would actually like to implement this (I don't have time), feel free to ask me for help understanding how to do it. What does this mean? Let's say you have a part. It has a mesh. Now you rotate the mesh by, say, 5 degrees on the z axis. It's still a mesh. Since it is still a mesh, it can be rendered by the primitives enumerated above. Indeed, the property of 'being a mesh' is closed under the operation of rotation, so this means that we should be able to rotate anything to any position, and still be able to describe it in terms of these voxel primitives. Not only would this be useful for arbitrary rotation, but also for importing designs from external modelling programs. I think this could be a mod, and It's not so fundamentally weird as to be incompatible with the base game in principle. Overuse of the feature might actually cause performance issues though (due to the general increase in the number of blocks on a vessel built this way). In any case, I think it would need to go hand in hand with a slight tweak to how blocks are picked. I don't want to scroll through a list 3 times as long as it is now because it is polluted with weird geometry. However, I'd be OK with selecting the geometry, material, and block types from 3 separate dropdown menus (eg. cube, xanion, shield generator). It'd clean up the interface, and allow for this kind of extension without adding a bunch of clutter. VoxelPrimitives.txt

The "Scalable Turrets" idea is not simpler. Not for you, and not for the dev. At this point, several of you seem to believe that this suggestion is too complicated for the dev, and believe that making turrets scalable would be an easier solution. As a programmer who knows how both would be constructed, allow me clear the air of these misconceptions. Appearance If koonschi really wants to allow us to customize the appearance of turrets, ... ... then you can't do much better than to use the existing editor code to allow people to build the appearance block by block - even if the appearances have nothing to do with the stats. While it might be 'simpler' to have a set of pre-configured appearances, this won't satisfy the creative-types much more than what we have now, and it would require the development of yet a new menu, and a new set of options. Stats Let's assume we go that easy route. Alright, so the other proposal has us using a menu to configure the stats of the turret, at the cost of materials, and possibly physical size. This also requires the development of a new menu. My suggestion would replace sliders with block scaling, which is already implemented in the game. It's also nice and visual, and causes the turret's stats to have an impact on its size and complexity. It does not require that you open a new menu to figure out what is going on or tweak something. With that said, some of you might be skeptical about using adjacency to determine which modifiers are applied to which gun. Well, this is a simple instance of the same problem the the physics engine solves every frame. It ultimately breaks down into using a space partitioning data structure to find the nearest neighbors, up until we find one that isn't adjacent, or there are no more blocks. The funny thing is that this is already in the ship editor. Have you noticed that an integrity field generator won't cover but the nearest blocks if it isn't large enough to cover the whole ship? That's the k-nearest-neighbors algorithm at work. Plus, the ship editor also seems to be aware of connectivity, as trying to remove blocks that would break the ship into pieces will emit a warning if safe mode is on. This is almost already in the game. Motion In fairness, this would require new things that aren't in the game. Still, people have been complaining about tracking speed and accuracy being an issue, so that would require an overhaul to how motion works anyways. You see, with the scalable turrets, it's kinda hard to say how much mass one has or what the moment of inertia is unless you can decompose the turrets into blocks and analyze the mass distribution. The only hard part about making moving parts on a ship that are arbitrarily constructable is figuring out how to separate them from the body, without making them completely disjoint. Fortunately, this is a problem that has been solved several times in other games. The answer is to use a hierarchy of coordinate spaces, where one coordinate space is attached to another at some point, and can move freely subject to certain constraints. This sounds like it's a lot of work, but actually, it's just a single transform matrix and up to 6 additional bits of information. Honestly, if the dev totally ignored rails, everything would be fine, so I'm going to ignore them too for the purposes of this discussion. Basically, you just need to add a block that adds a child coordinate space (let's call it an 'assembly' instead of 'coordinate space' from now on), and a block on both sides. The assembly grants a degree of freedom, and, based on size, maybe also grants stats like a torque/speed curve (This is how motors actually work, by the way - it's not torque and speed separately; it's a dynamic tradeoff, which means that you can tune this while the device is in operation). The real trick is configuring the range of motion. This could be done automatically, in theory, but that really is hard. It also isn't right, as the designer might have a reason for constraining it further. You could do it visually in the editor, by exposing handles for configuration when you select the block (a la Spore style). This isn't the worst option, but I think this might actually be the right place to put a slider/text box combo (by the way, all sliders should be accompanied by a text box, for precision value setting). I don't think you need a whole new menu though. You know how in 3d modelling programs where you get a panel full of geometry-specific parameters when you select something? This should be like that. You don't have to click through to get at a little window that way, and nothing obstructs your view of the model. As far as controlling the turrets... well, the algorithm that controls them now would work fine - point at the target. It's just that now the exact points of motion are determined by the designer, rather than being a fixed-point 2-axis gimbal. As a counterpoint to this added complexity, I point out that most small vessels (fighters, bombers) probably don't need turrets that aim at all - they just need guns. Turrets are for larger vessels. This will reduce complexity in these vessels, as the game no longer has to worry about a turret that can move, but has been told it shouldn't. The turret lock block can disappear from the game. Acquisition As turrets would be part of ship designs, turret factories can disappear completely. So can the research system for turrets. These are both known to be buggy and broken, and that's a pile of bugs that can basically just disappear for free. Indeed, not only does the dev win in the short term, but this ends up being fewer systems overall that the dev has to maintain. To keep crafting guns from being too easy (assuming that this is at all a problem - I've never had this problem in other games like this with simpler requirements for guns), we can add costs for blocks other than the basic materials. Why should every block cost only Material + credits? Why not have computer blocks cost processors? Why not have railgun barrels cost electromagnetic coils? If we can construct a hyperspace core, I think we can construct a chaingun. This isn't Captain Forever. Indeed, turret drops would disappear as well, which is an additional subsystem that the developer no longer has to maintain. You no longer have to worry about 'dropping' turrets when they get blown off your craft, as they're part of the design. Another concern that the dev no longer has to specifically write code to fix. And you, the players, no longer have to worry about finding turret factories to build uniform fleets. Learning Curve The learning curve for this system might be higher for players used to the current system, but for players who are new to the game, this learning curve will be smaller than a scalable turrets system. This is because the interface for designing those and designing the ship (to which you are introduced early) is unified, rather than disjoint. The stats themselves can be identical across the systems, so there is no disadvantage either way here. It's ultimately a minor difference in terms of cognitive load, as neither interface is/would be terribly complicated, but at the very least, this suggestion isn't _more_ complicated. Keep in mind that the current player base is probably very small. I don't expect it to stay that way, based on what I've seen. I've also already pointed out the solution to 'I don't wanna build the turrets myself', and then Weylin inadvertantly pointed out that it is already viable even without developer effort. I get that some people just want to play the space simulator aspect, and don't really want to muck with the creative part. This game is a good enough space simulator as it is to make it competitive with other space simulators out there - while totally ignoring the fact that there's this other bit where you customize your ships. Grab some preexisting designs and play. Also keep in mind that for any game to be challenging, it's got to make you think. I've noticed that several people are complaining that the game isn't hard enough. I think that's because you can basically just slap a ton of guns on a brick and be more powerful than anything else in the game in short order. There's no real way for the AI to have an advantage against you, and there's no real way for the game to force you to change up your approach to a problem. The solution involves playing up the importance of armor, shields, size, and maneuverability. Both major suggestions as for improving turrets would afford for this - and so would require you to think more in either case. You see, no matter what route the dev chooses, the game will get more complex for the player. Performance Concerns If you weren't able to pick up on this by reading the above, then let me make this clear. The runtime costs of these suggestions are basically the same as the costs for the system that we have now. You won't notice a difference. I also note that, aside from the fact that one of the shaders won't compile, this game runs flawlessly on Intel graphics (I somehow managed to start it up and play on my Intel part once). There's a lot of room for growth in terms of the number of objects that can be dealt with there, and if the physics engine is properly parallelized (it ought to be for a space sim), then servers won't have any real issues. As it is, there seems to be a lot of room for growth there too (I help administrate a private server for my friends). Balancing and Integration Indeed. And in both cases, I believe turret physics are sufficiently unrealistic as to allow them to rotate without applying force back on the ship. In the real world, if you make a ship with a turret on it that is truly too big, then the ship will rotate instead of the gun when it aims. These physics aren't too hard to add in, but those games didn't do it, and so this is an issue. From what I have seen it is not possible because much of the key aspects changes like this require are hard coded. Unfortunately, I believe that this is the case. Not much would need to be changed in the core really, but the changes are absolutely necessary to make it work. You need to be able to create and reason about assembly hierarchies in ship designs, and you need to be able to ask about adjacency (in principle this is there already, just not exposed). Lastly, you need to be able to move child assemblies at flight-time programmatically. None of these things are hard. They just aren't available to modders. RPGs and RNGs As far as I'm concerned, the RNG for drops can disappear. RNGs are not a crucial elements to RPGs. The crucial element is the notion of a 'self', rather than just acting as an unnamed entity that abstractly decides the strategies and designs for an enigmatic fleet - which the game is pretty close to being right now (for better or worse). Quests help with this some, and more opportunities for one to exert an identity would help some more. With that said, this game could just turn into a creative space simulator. It could easily become the best one available. Starmade is a garbage space simulator (Its really just garbage in general: poorly implemented, buggy as hell, totally unbalanced...), and I don't know of any others that give you anywhere near the level of customization that Avorion does. My brother refers to Space Engineers as "Space Builders: Big Stuff is Big", because there's no engineering in it at all really - just slow, painstaking construction. Avorion is already better than that game, just in the construction aspect alone (and let's face it, that's pretty much all Space Engineers is good for). Unless you are the dev, stop speaking for him. Thank you for this. As a programmer, it has become eminently clear to me that noone else in this thread that has commented about dev time and expense is a programmer. This is actually not that hard to build. Unless you can quote him (or one of his compadres), I don't really care what you think about the developer's vision. You are not the dev. Your vision is not the dev's. It is up to the dev to determine what they are willing to devote effort to, and why. ROI, playerbase, personal vision, tractibility, feasibility, code complexity, etc... This is all constantly in the back of their mind. Trust me, I know. As I am currently designing a new programming language for my PhD, I have to think about these things too, and it's very challenging, because I am going up against established giants like C++ and Python and Ruby.

I'd like to note that this poll will be biased against change, as the people playing the game and participating on the forums are going to be the ones who like the game as it is. Unfortunately, predicting how many future users a feature will earn is very difficult. The best strategy (for a developer) is ultimately to make decisions like this based on the project's philosophy - AKA, the developer's "vision" - with the caveat that you don't want to do anything so crazy that noone will want to be a user, but I think we can all agree that none of these ideas are at that extreme. TL;DR: This poll will be biased, and therefore next to useless. Besides, Avorion is not a democracy, nor should it be.

This isn't complicated at all. This just means that the inertia of the turrets' mass applies torque to the ship when it turns or stops turning.

I disagree. This wouldn't actually add much. KSP also puts an emphasis on accuracy, and the parts aren't really attached to each other firmly - they're attached with springs, which makes things much more complicated. In this case, the constraints would be nice and clean, so you'd add maybe a handful of multiplies and adds for each one. Plus, these calculations are all nice and independent, so they should parallelize well. This is really a basic part of a good tracking speed system, and such a system would go a long way toward giving small ships a role to play in battle. Right now, bigger is better, and that's not always fun.

I would like to direct your attention to The Trouble With Guns, where a similar suggestion has been made for the turrets. As this is a suggestion (or 3), I suggest to the moderator that this be moved to the 'Suggestions' subforum.

Indeed. Perhaps a poor choice of words? How about 'unsuitable' instead. FTFY. Because that's not the point. This isn't about improving the gameplay experience for me. It's about improving it for all players. By the same token, why don't you write a mod that implements your dream system? I mean, from the way you write, you seem to know all kinds of things about development. I'm sure you could figure it out. That's an easy one. The better materials you have, the more interesting stuff you can do. The dev has already implemented a notion of ability unlocked by material tier. I think this is a cool system, and that it could be applied here. Also an easy one. Blocks take up space. Blocks are heavy. These blocks will probably be fragile. Having one weapon that can do everything will be impractical, and you will likely lose to a specialized adversary. It's more efficient to specialize, so adversaries that specialize against you will always have an advantage - unless you specialize against them too. There will not be a single best. What counts as a good weapon will depend on the situation. Since you play RPG games, you might be familiar with the notion of a 'combat triangle'. Well, in space sims, similar things exist. You've got shields and armor, and then you've also got glass cannons. Armor is good for bigger craft, shields for smaller craft, and for the smallest craft, the answer may just be thrusters, guns, and hope they don't get hit. That's how it typically is anyways. The interesting part comes in choosing which craft has which weapons. You can make a battleship that is effective at taking out strike craft. Just don't expect it to take on a dreadnought any time soon. Does it even have to change? Why should blocks only require materials that we mine from asteroids? Why not have a barrel block cost steel tubes? Would this make manufacturing a fleet a PITA because guns are limited by cargo space? Yes. Is this already the case? Yes. Would having a real faction system where you can have stations and a resource distribution network that allows you to amass the required materials in one place fix this? Yes. Fortunately, I think the dev wants the latter anyways, so that probably won't be a big deal in the long term. Actually, I'm not even sure why materials like Xanion and Avorion aren't stored in cargo bays either (aside from how awkward upgrading your ship would become, that is). It seems to me that this is something that could be changed in the future, once ship upgrading and factions get an overhaul. Then again, this is a suggestion for a (much) later time, if ever.

That's sort of the idea, except that the prefab bits (like barrels) are scalable, and scaling them does something to the weapon's stats.

Alright, so what if the templates and prefabbed designs are created by other players? Just because you don't want to do it doesn't mean that nobody does.

Now at least two of you have suggested using menus or separate GUIs to configure the turrets one way or another. I am vehemently against this idea - not because it wouldn't work in theory, or because it sounds bad in text, but because I've seen what happens when people go this route. You end up with giant awkward interfaces that are difficult to get to inside of you building screen. Kerbal Space Program suffers a little bit from this, and starts to suffer a lot more if you add too many mods. There are mods in Minecraft that also introduce such a system (or at least, there were). It isn't pretty. It is by far a more awkward interface than just placing blocks. One of the reasons that people build computers in Minecraft is because of the simplicity of the interface. Redstone is just blocks, and you don't need to go into any menus to configure stuff. It's actually easier, in some ways, to build computers in Minecraft than it is with professional CAD tools for this reason. Trust me on this; I've tried it both ways. Indeed. For one, this really isn't a problem unless the dev says it's a problem, so on some level, that's not a useful comment. For another, I'm not so sure that the dev is unwilling to perform such surgery. This would already require some fairly major surgery to how the game thinks about ships and how they interact, assuming the dev didn't write the code initially knowing it was coming - even then, foresight isn't perfect. There's still probably lots of work to do. I can't find a quote, but I know koonschi has confirmed that he's working on some kind of out-of-sector simulation, so as to make the galaxy feel more alive. This also is a lot of work, since he has to create a secondary model of the galaxy that is consistent with the one that we see, but isn't nearly as expensive to simulate. Arguably, this feature requires a similar level of work to my proposal. Yes. This is exactly what I'm thinking. Yes exactly. However, one cannot ignore... Clearly, on some level, it is. Indeed, this game is crying out to be one, and I would like to see this as well. It would appear that the issue here isn't that my suggestion is bad, so much as some people don't like the creative parts intruding on their RPG game. Actually, let's not. See, in a medieval setting, you don't have shipyards, and rarely can you claim territory. Also, depending on the game, you aren't necessarily even the one crafting your own weapons. As this is a space game, and we've already accepted that players can engineer their own ships, excluding turrets from this doesn't make a whole lot of sense. Also, we're not merely dealing with different races that grew up on the same planet, with access to the same basic materials and the same environment. We're dealing with aliens from different worlds, and if you consider the Xsotan, different dimensions even. Their stuff is gonna look a lot different than an encultured adventurer's sword from the established style. I point out that you don't even have that much freedom now. You can't even choose. You will have to learn the stats one way or another, even if you don't totally design every detail of your ship, else the pirates will eat you. If you really want, the dev could include some basic turret designs in the default templates, so that you don't even have to go shopping, but there's still absolutely no guarantee that the designs will match your aesthetic. Allowing players to involve themselves in either the adventuring or the engineering to the degree that they want is clearly the right idea. Indeed, this is an instance of one of the principles that you'll find in all of the good 4X games - make the complexity optional. Some players will dig in, and some won't. That's OK. Even for the ones that dig in, the learning curve is made shallower by not forcing them to learn everything all at once. Bad idea. We also don't really want the game modes to be truly distinct either. We can already eliminate the adventuring part with creative mode, so those people are satisfied. The trick is allowing adventuring with minimal interaction with ship design. Perhaps auto-generated designs? You've already got shipyards that'll do it. The algorithm will just need tweaked to include turrets now. If that's not good enough, and you want some customization without having to go all the way, then I don't really know what to tell you. You can't really have it both ways. Templates and prefabbed designs are about the only compromise you can get here. I have a B.S in Computer Science. I know about a dozen programming languages. My favorite programming language is C (not C++). I'm currently working on a PhD in Computer Engineering. I know exactly what is involved. I could build this system.

And there goes that manufacturability I was talking about. You are right, there are possible simplifications to this system, although your version would actually result in less variability in weapons and tactics. Using a modifier block system actually can make things easier on the devs, so they don't have to implement so many different weapon blocks to achieve sufficient customizability for each player. From the reviews of From the Depths on Steam: I will also point out the weapons system in Starmade, which is not far off from what I am suggesting. I haven't heard any complaints about that system, aside from the fact that it is poorly documented. Then don't. I don't think it even needs to be this complicated. The answer to 'I don't wanna spend all my time designing ships and turrets' is the Steam Workshop. Look at all these games where players are designing things and sharing. Reassembly Space Engineers From the Depths Empyrion While this would require Steam Workshop support (which we want anyways), this is not such a big thing. If the dev slightly changes how templates are done, it should be easy enough to share templates for individual pieces as well, rather than just whole ships. I did, and I even said I did. It looks like you might want to take your own advice, and actually read the posts you're replying to. I made a new thread because I felt that this was a new suggestion. I didn't want it to sound like it was a modification of an existing suggestion, because it isn't. I considered what I had read, and, most importantly, I considered all of my experiences with other games that have gotten this wrong before, and proposed what I thought was the most sensible suggestion I could come up with.

Hello everyone! I've mostly enjoyed my time with the game so far, but I've definitely noticed where the game is made almost entirely of placeholders a little rough around the edges. I understand the thrusters are the most broken thing right now, and they're being fixed, so I'd like to focus on another important part of the game that I think desperately needs attention: Turrets. I have read several suggestions on improving this subsystem already, but I don't think that any of them really address all of the issues it suffers from, so I've taken the time to come up with a sketch of a solution that should cover all of the bases. Now, before I go further, I'd like to note the way the turret system is currently set up is somewhat unique for a space game like this. I have to wonder if there is a reason for this beyond `that's just what the dev came up with at the time'. If there is, then my proposal is likely incompatible with such reasoning, as my proposal is for a system that is completely different than what is currently implemented. I wouldn't mind an official statement on that. What's Wrong With Turrets Now More or less everything. They do shoot, and you can destroy enemies with them, so there's that at least. I don't particularly like trusting the RNG. I wouldn't have a problem with it if I were just upgrading one weapon on one ship, but I'm not. I, like some other players, like to have a little uniformity in my fleet. In addition to that, some ship designs are good for some kinds of weapons and not others. I don't really wanna go slapping a bunch of short range weapons on the quarter-scale Death Star I just built, simply because I don't have anything else. (I haven't built this - this example is just to make a point. Kudos if someone does this though.) Neither do I want my support fleet of TIE fighters to have a random bag of weapons on them, like dumb little lasers on one, and a triple-chaingun on another. I also don't want to have to go to turret factories to manufacture my uniform set of turrets - after all, shouldn't the turrets be part of the ship's design? I mean, if we can build a hyperspace core, I think we can build a chaingun. I'm still trusting an RNG to give me a decent factory, too, which isn't a safe bet. When I create a new vessel from a blueprint, it should really be armed already - that way, I don't have to go through each one and put turrets on it in all of the places. This would become rather tedious for a fleet of any real size. On top of that, it is frankly true that the disparity between turret factories and turret drops is a problem. With that said, I don't think the answer is to somehow rebalance the stats so that they agree more. In fact, I think the whole `turrets as an item that you slap on' thing is wrong to begin with. This brings me to what I think is the most important flaw in this system. I now direct your attention to exhibit A. This is the Eye of Zorg - my primary space vessel. Allow me to further direct your attention to the turrets on said craft. The Eye of Zorg only reluctantly installs these ugly gray warts as the only means of conquering space defending itself. These turrets do not at all match the desired aesthetic - and there's nothing I can do about it. Ideally, I'd just have a mega-laser hiding behind that great big eyeball (for obvious reasons). There is clearly only one solution to this problem. We players need to be able to build our turrets block by block. The Proposal If you think about it, this approach stands to solve many of the problems that we see in the turret system right now. For one thing, we no longer have to worry so much about using modules and module slots to limit how many turrets a ship can have. I expect that the average turret will get quite a bit larger if players have to build them. They'll also be heavy, and you won't want to load your ship down with expensive heavy guns that don't serve as very good armor. With that said, we can really make them any size we want, since we get the same arbitrary scaling that we have for blocks. It should also be easy to add projectile coloration, by basing the projectile color off of the color of some of the weapon blocks. For another, I always thought it was odd that the guns could aim independently of your craft's orientation be default. It seems to me that turrets that can turn would be a more advanced feature to be earned. And then with this comes the turret lock block, so that you can add a little complexity to the system to take away that ability - because that makes sense. This also gives players something they've always wanted - spinal mount weapons. I mean, what's the point of being a giant battleship if you can't blast the thing you're facing with the energy of a moon crashing into a planet? Sure, the recoil will shove you into the next sector (granted, still at sublight speeds), if not rip the gun assembly out of your vessel and shoot it out the new hole in the rear, but it'll have been worth it. If you'd like a more down-to-earth example of this awesome technique, I point you to the Warthog. Of course, what's an idea without a little discussion about implementation? Shooting So how would one build a turret? Well, turrets shoot right? So how do we build something that shoots? Base Weapon Blocks Basically, we've got projectile weapons (chainguns, railguns, missiles), energy weapons (lasers), and particle weapons (plasma), right? Technically, there's also lightning weapons, but those actually aren't possible in space (no medium for the lightning arcs to form in, among other things). Even if we included them anyways, the approach would be much the same. How about we define some base blocks. One for each kind of weapon. We'd have firing chambers for the projectile weapons, energy emitters for the energy weapons, and particle emitters for the particle weapons. The size of these blocks will determine the amount of mass/energy that can be fired per unit time. Modifiers I expect that these weapons will generate heat. They'll also need to be fed energy/munitions. We also probably want to put barrels on some of them, or some focusing lenses on others. Long barrels help with accuracy and a bit with bullet speed in the case of projectile weapons (not just railguns). Many barrels might just help with firing speed - or maybe just redundancy in case one gets shot off. For lasers and particle weapons, you'd add a base emitter (or several), and the area of the emitters would determine how much energy could be discharged per unit time without melting something important on the firing end. You could add a focusing lens on a laser to get some armor penetration, or a particle accelerator to a particle weapon to add some range/damage. You could also add more interesting modifiers, like a block that arms the munitions with charges that explode on impact, or something that replaces the usual slug with a package of pellets (shotgun adapter). Perhaps a block that installs seeker modules on the missiles? Cooling is a fascinating issue in its own right. Something that many of you may not realize is that it is actually really hard to cool things effectively in space. This is because you can't dissipate heat into the atmosphere. There is no atmosphere. You basically have to rely on blackbody radiation. The more heat you can dump into what you're ejecting at the enemy, the better. With that said, you're probably still gonna have some heat to take care of. One option is to eject gasses that run past the hot parts and into space, but the gasses need restocked periodically (I note that ammo seems to be infinite here, so this might not really matter). Another option is to put radiator panels on your ship somewhere, and have a cooling system pump heat to them. Depending on how detailed you wanna get, you could either have an entire heating/cooling subsystem to the ship, or just add some kind of cooling blocks as weapon modifiers. I note that requiring that your ship has sufficient surface area to cool itself would discourage the cubeship designs, so this may be a desirable design constraint to add. I am thinking that this is the way to get your weapon variety, without having to come up with a bunch of different weapons with different stat tradeoffs. Let the players choose. It should also be nice and extensible, due to the separation of functions into separate blocks. It should be easy enough to add a block to either add a new base weapon type, or add a modifier to some of the existing weapons. This will probably require some reworking in the way the game thinks about ship designs, as adjacency matters here. Aiming Of course, having all these blocks is great, but since we aren't dealing with magic turret entities that we slap on the outsides of our vessels, we now have to worry about making the turrets point at the enemies. I suggest two primitives here - Rotors and Rails. Rotors These are what you expect. You place it, and it allows you to build blocks off of it that can rotate. I do wonder about the most reasonable implementation of this, as it seems that putting a little rotor block to one side of something that aims up and down isn't right, and I doubt that it would be easy to have the game detect when multiple rotors are aligned correctly. My thinking is that you'll want to additonally have something like a rod/sleeve block, where the ends are one part, and the sleeve around the center is the other part. Which you attach to the ship and which you attach to the moving part shouldn't matter too much. Figuring out the acceptable range of motion on a rotor is probably impossible to automate. There will need to be some way of letting players configure this. I don't know what should happen if the players lie get it wrong and the moving piece collides with something. Possibly explosions and death. I would expect that the rotor's ability to rotate mass would be proportional to its size somehow. This could limit the speed at which a turret may rotate into position, especially if it is large and heavy. I note that rotors might not be useful for only turrets, although a way of figuring out what position they should be in and when would be necessary. I've ideas for this, but those are suggestions for another time. Rails I know it seems like rails would be inferior to rotors, but I think for some designs, it would make a lot of sense. Think broadside cannons. The trick with rails is making them flexible enough that you can do neat things, without making them so flexible that it becomes an implementation nightmare. The most obvious constraint would be to enforce that a rail can only be built such that it specifies a path within a plane. Let's look at that another way. Imagine a ship. Now imagine a plane intersecting the ship. Suppose you want turrets to move about the surface of the ship, but only so long as they're on that plane that intersects the ship. That's what rails should let you do. Now, arbitrary planes might be a little much (although, not necessarily impossible). In all likelihood, you'll want to stick to planes aligned with the axes. Basically, adjacent rail blocks (of possibly a variety of shapes) will form a rail, but all blocks have to intersect this common plane. Only one thing may be on a given rail. This rail might use slopes to wrap around the ship, totally, or maybe just partially. The outer surface of the rail blocks must be exposed (of course). Things may slide along the rail blocks on the outside surface. Control Blocks Even for such aimable turrets that one would want to be in direct control of, the game needs to know that there's an aimable turret. I think the easy way is to use some kind of 'turret control block'. This can be thought of as a block that contains targeting and firing control for the turret, but for the implementation, this really just marks which bits are turrets, and can aid in figuring out which rotors/rails are involved in aiming it. It makes no sense for a turret to have more than 2 degrees of freedom. Since the projectiles move away from the ship, that effectively allows you to target any point in space (assuming that the 2 degrees allow for arbitrary rotation). Unfortunately, just having 2 rotors between the turret control block and the ship it is attached to does not guarantee that there are 2 degrees of freedom. If the rotors are both aligned to the same axis, indeed, there will only be one degree of freedom. I would expect that the control block will only take control of 2 rotors/rails if they grant independent axes of motion. If not, then stop at one. This should be something that can be done automatically. I note that this scheme will prevent players from stacking many weak rotors to gain rotational speed from cheap parts (although that shouldn't be a problem anyways as long as the stats make sense - take a lesson from thrusters). A note to the implementer - you would want to work from the control block in. There may be other reasons to use rotors and rails that don't directly involve aiming guns. If they become part of the game too, then you cannot guarantee that there will be at most 2 of these things between the ship and the control block. The control block would have an orientation, which would allow the player to effectively specify which way the guns are pointing. Alternately, one could require that the control block be touching the base blocks for the guns. This could allow the game to automatically determine the correct orientation for the player. It could also make it easier for the game to enumerate the weapons that a given control block is actually controlling. Once a control block knows which weapons it can fire, and which motion blocks it controls, all you need is an algorithm for aiming the turret at the target. For rotors, this is easy. For rails, it's less easy, but still not too difficult. What d'y'all think?