Velenka

IMO this should all be controllable with RDMS: For the constructs themselves: Right to generate blueprint from construct Right to add to a construct (voxels, elements, paint) Right to remove from a construct If the repairing mechanic is different from add/removing (which I hope it is, since you could repair without being able to add/remove), Right to repair Right to trade Right to use/interact For the blueprints: Right to switch between reuseable and one time use BP Right to use manually Right to use in a factory unit Right to trade If BPs are/can be contained in a physical thing, right to overwrite physical thing with another construct BP If BPs are/can be contained in a physical thing, right to copy to another physical thing with rights identical to first BP Rights should transfer in a specific way from blueprint to construct built from the blueprint. Either inherited from the original construct, or owner specifies rights at time of blueprinting. Owner would only be able to grant rights which he has. This probably won't be an exhaustive list, but that's the general idea. Every action which can be taken with the BPs or BPing a construct should be associated with a right which is manageable by the RDMS.

Of course no one can say, since we're still pre-alpha. I would love to see similar tools implemented into DU. We'll just have to wait and see what develops. I sincerely hope we do get them

Coming from Space Engineers, I can already say that this will be a huge timesaver compared to SE's survival. The demo of the building system showed a system more akin to SE's creative, with line and plane tools, and presumably mirror plane tools eventually. We will also have jetpacks, so we will be able to go and fly around anywhere (contextually) around a build. If you just remove the player's arm from the screen, it becomes essentially a 3rd person editor. Not only that, but the Virtual Simulation will allow "free" building inside, allowing you to design anything. My point is the balance is already heavily skewed in favor of easy design. 90% of what OP mentioned looks like it's going to be in the game in one form or another. Sure, there's no extremely advanced building tools, but this is a game, not CAD software.

I agree with wesbruce and Shynras. Losing items, equipment, vehicles, etc is enough of a motivator to avoid death.

I'm the sort of person who sees a big hole in the ground and is proud of it. Don't you dare fill in my holes.

Yes, see this dev blog post for more details on the building system as a whole.

I would agree with the virtual training idea because the arkship area will be subject to lots of change over the lifespan of the game. "Mine a couple ores? Nope, you gotta walk 10km over there to do it." Why not both? Allow new characters to do any or all of the tutorials. Afterwards, they select a few, but not all, basic skills they want to gain immediately. This way, the new player gets some kind of idea what they are choosing, and what they are not. Presumably at this point, the time-based skill training will also be explained and the new player will be able to immediately choose which skill he wants to begin training.

I agree, but this has more to do with skills than with the inventory system. So I reviewed what the short story actually says. It seems to me that the kadpack and the kads work exactly the same way. The only difference is that kads are little matchboxes on your belt and not a backpack. No. Absolutely not. This is not how it should be. If your little matchbox sized kad can hold 10k ammo, then think about what a ship sized cargo container could hold. WAY more space. That's why you would use trading ships. I do like this idea. I would only change one thing: that you should be able to hold more than one raw material in the kads, unless they are easy to find/get/make and don't take up lots of valuable belt space. It makes a bunch of what's been mentioned before less relevant. And I mention again that I would rather do Space Engineers volume limit than a Diablo style. You get the same effect and no headaches. I would still insist than making guns and munitions not be easy AT ALL. This whole thread is based on "what about having thousands of bullets." I would prefer to see the devs prevent any potential problems, than to go around inventing work-arounds to imagined issues.

I really think that people just don't comprehend the huge scale that are planets. There is no need to worry about completely mining out an entire planet any time soon. But after a time, maybe it will be possible to mine out an entire planet. I doubt it though, since it would also require lots of time and effort from many players involved. Unless literally half of the planet is a factory, I also don't see endeavors of this scale being useful. And it could be that the ore distribution is not continuous, but spotty. Ore deposits would only be a small fraction of the entire planet anyway, everything else being useless dirt. No worries there.And like Sekmeth says, devs might want limited resources as a driving force for exploration. Though I could see the arkship area being regenerative since there's new players and it's one of (and possibly the only) the safe zones.

Your idea is mostly just ragdolls / beds + character scripts. A ragdoll means just that. A limp bodied character rolling around on the floor. With both beds and ragdoll you have persistent constructs. With both beds and ragdoll, you have persistent characters. As far as scripted offline characters, I would say that the devs should put that at the bottom of the list. There's many features which should be developed first. If that can't be done, perhaps just some algorithm to make the character walk around randomly at the spot you logged off at.

You should read this Most of what you describe should be possible with the RDMS and Territory Units. It would be up to the players to decide how to organize themselves and how to organize territories.

Would this be different from the nanopack? In the short story the capacity of the nanopack is described like this So if you do have lots of stuff, why wouldn't you just put it in the nanopack? It would be nice to see some balance in player capabilities, but I don't think it should be balanced against inventory. Each piece of equipment could have stats for weight and stealth instead. This way, to be stealthy, you have to wear stealthy clothes and use stealthy equipment. To move fast, you have to wear lightweight things. Slow movement: Equipping big, heavy guns and armor make you slow. Normal clothes and lightweight equipment lets you be quick. Stealth: Equipment with high stealth rating has a smaller distance at which others can detect you. Low stealth rating has a farther distance at which others detect you. As far as the large ammunition possibility mentioned in OP, I see three very, very important issues which would become apparent before you tried any of that: 1. You actually have to make all that ammunition first (or buy it). Making ammunition shouldn't be easy or cheap. It would take an immense amount of time, energy, and materials to build the infrastructure to make ammunition. Then, you have to spend yet more time, energy, and materials to make the ammunition. In terms of money, selling that much materiel should net a massive fortune, or cost one to buy. 2. You have all that ammo on your person. If you die, you lose it all. You would lose a fortune in ammo, explosives, guns, equipment, etc. You would seriously need to think twice before bringing a literal fortune with you where you might very well die and lose everything. Any sane person would take only what he needs and no more. 3. So you have a huge stockpile of munitions. You either have a large infrastructure which made it, or lots of money. In either case, you are not by yourself but rather with an organization. If hostilities broke out between your org and another, you would use these munitions. But not just you. Most of your org will probably engage in the hostilities, too. That stockpile of munitions will get divvied up between everyone involved. You won't have one person do bombing runs. Instead, you form a whole squadron to do it. Now, the huge stockpile of munitions is no longer large, once everyone gets his small share. In any case, I would rather see a Space Engineers system than a DIablo system. You get the same effect (limited space) without all the grief inducing inventory management.

I like this.

So you did. But let's stress that point then.

I mentioned this briefly in another thread, but repairing could be another skill. Whether or not you need a special tool/element to do it, I don't know. Repair skill would give rise to a real occupation of engineer. Ship-to-ship repair sounds too fast and easy. It would eliminate all the gameplay mechanics I mentioned and probably more. I do like the power transfer idea. In yet another thread I suggested that shields could have polygon surfaces to make up the shield. Each surface would behave individually. So to do a power transfer, you would have to drop shields below the power-transfer device on your ship, and on the other ship. Then you could get LoS, then establish the transfer. So it's balanced, since you will have to expose part of your ship to the enemy if you're in the middle of a battle.

Perhaps the maintenance bar would tick down, then once it gets to 0, it would "advance" to the next stage (the stages that I was talking about) and the bar would return to full. To push the maintenance bar back up takes some amount of resources per tick of the bar. Higher stages would take more resources per tick. Each stage would affect the device's efficiency (or equivalent). Stage 1 would be 100%, 2 would be 95%, 3 would be 80%, etc. I would have just gone with losing device health over time, but having a separate maintenance bar could allow for a repair skill, giving rise to the engineer occupation. I like it. After too many stages, the device would break. Whether that means losing a lot of "health", or disappearing, or just stop working, I don't know. But it should be severe enough that it gets people's attention, but doesn't put the player completely out of action. I would go for the health option. I agree with your mothball idea. I would say that maintenance ticks over time would be reduced by half, where maintenance ticks over time regularly would already take long periods of time to affect the device. IMO usage of device should be the main cause of regular maintenance in a regularly or occasionally used device.

To add to this, perhaps damage should be localized. Each polygon surface should function individually. That way, you can "punch" holes in the shield grid. I like this since it adds to the tactical combat mechanics that DU is aiming for. Generators, as opposed to projectors/emitters, could be linked together to produce different effects. Generators linked would be in "parallel" and would increase the capacity of stored charge. Generators not linked would be in "series" and would increase the recharge rate. You combine these in different ways. Few, large chains would have huge charge capacity, but very low recharge rate. Many small chains would have lightning quick recharge, but tiny storage capacity.

I kind of like this idea. I would be curious about whether account names can be viewed as part of the name, or at all (ie FirstName_LastName@AccountName). I would be interesting in seeing an infiltrator type role in the game. But if account name information is included, it could cause issues for that role. For example: Organization A has member John_Doe@abc abc creates new character to infiltrate Organization B: Billy_Smith@abc Billy_Smith attempts to join Organization B Organization B recognizes account abc and immediately rejects Billy_Smith I think some interesting gameplay would come out of infiltrators and spies. I would prefer not to exclude this kind of gameplay because of some metagame information that is easily available.

I agree with this and your previous statement about exposing the script in any way leading to theft of the intellectual property. It's probably for the best. But I would say that coding should be capable of interfacing with the RDMS. You can allow others to look at it or not. Allow others to edit, or not. Depending on how DPUs and the code interface is developed, it may be possible to limit the number of copies created or sold, too.

I could see drugs working, each with unique buffs and debuffs, but not in any inherently illicit manner. Outlawing stuff will be in the purview of the emergent gameplay. I don't see any way that slavery can work as a game mechanic without ruining people's fun or without making it underpowered. Using NPCs for this mechanic also won't work since there won't be any NPCs except for something to help the economy at the game's launch.

It's definitely going to happen with the number of threads I have seen suggesting this. Thunderdome Planet here we come! I'd even suggest increasing the scale a bit. World Wide Tours anyone? Or perhaps a race around an entire system, with stations serving as checkpoints.

Pretty neat! Will you do a static core too?

Seriously though, you shouldn't be able to put whole creations back into your inventory. You should have to deconstruct them the same way you built them, one piece at a time. And I believe that rights to do anything to a construct (blueprint included) will be fully available to define using the RDMS.

I don't think you can brush off ship damage so easily. Certainly they will probably take damage, but not all the time. Probably not even a significant amount of time for non-combat constructs. I think some kind of degradation can be applied to ship elements just like character equipment. I would say that degradation should only occur to the mesh elements, since it would be quite a pain to have to repair every 25cm voxel in a large ship, even with lots of repair crews. Degradation could happen in stages: first stage would be comparable to simple cleaning and maintenance and is low cost. Second stage begins to affect the performance of the element and has medium cost to repair. Stages beyond would cause serious performance issues and be very costly to repair, nearing the same resources it takes to build the element anew. Degradation should cause decay per use. IRL that's how devices and machines' lifetimes are usually expressed. IE millions of cycles, hours of operation, miles driven (for cars you should change the oil every 3-10 thousand miles) The rate of decay should obviously be fast enough not to be obnoxious or so slow that it takes too long to affect gameplay. Not really sure where to start but I'd guess somewhere in the ballpark of 20 hours of operation to reach stage 1, 40 for stage 2, 60 for stage 3, etc... Perhaps different rates for different devices as well. I would expect an automatic door to function a lot longer than an FTL drive, both unattended. Maybe that's good, maybe not, just throwing ideas out there too.

Firstly, expansion into the universe beyond the first planet will take months to begin, and will take weeks to travel between systems by FTL initially. After that, I don't think being infinite or not matters in this context. I think it is a question of the path of least resistance and of value. Would an organization have an easier time expanding further out into the universe or to take over another territory? Due to the time involved, it's probably the latter. Or perhaps there's value in territory because of resources or strategic location. The value may even come from constructs which exist on an otherwise worthless territory. Territories that aren't required to expand into or that have no resources or other attributes could be called worthless. They may as well not exist. But other organizations may find value in that territory for other reasons. Lastly, JC Baillie has stated that the point of procedural generation isn't to be infinite, but rather to generate the content in the first place or something to that effect.