Velenka
-
Posts
344 -
Joined
-
Last visited
Posts posted by Velenka
-
-
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.
-
-
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.
-
The problem arises from Power Armor. A Power Armor would make you carry a laser gatling gun and enough power cells to drill through walls.
A power armor should be a kind of thing people unlock and feel special, forfeiting many other things, like crafting skills, to become a murder-machine.
I agree, but this has more to do with skills than with the inventory system.
The inventory system in the Lore, doesn't have to be the sameas the inventory system in-game. Lore can be retconned.
Also, the cartridges are those Kad-Packs, so they do take space and store materials, but not complex items.
You wouldn't be able to store 10,000 bullets in them :V
So yeah, in that sense, the Lore is good.
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.
Also, yes, the 3D printers can create magazines of bullets on the fly and en masse.
No. Absolutely not. This is not how it should be.
Having 10,000 ammo on you, defuses the point of having trading ships mate. Everyy trader would have a man-purse and simply deliver 10,000,000,000,000 tons worth of minerals in a wallet sized F.U. to logic and reason. Also, it would make thins like THIS, irrelevant.
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.
But, if my assessment, or more accurately, ShadowLordAlpha's assessment is correct, the Kads (the cartridges) are able to store one material tpe at a time and have a maximum capacity. You know, because black holes and stuff. So a Kad can take up to 10,000 voxels worth of a material, sure, the number can be different, but you get the idea. So, when you go to the market, you sell a Kad worth of 10,000 voxels of iron, which another person can take and apply it to a foundry unit, to make whatever items they want.
Again, bullets are complex structures, raw iron is not. Compressing raw iron would be a simple process, compressing a gun would not be.
The Kadpack thing and the Analogous Inventory can work. There's no need for one to exist without the other, just make the Kads only work for RAW MATERIALS.
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.
- Sekmeth and NERDFIGURE
-
2
-
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.
- Snowfox, DaSchiz and CosmicDragon
-
3
-
Would this be different from the nanopack? In the short story the capacity of the nanopack is described like this
I’ve got the equivalent of four sequoias and six tons of rock in cartridges housed in my belt! The worst part is that I don’t even feel their weight thanks to anti-gravity technology!
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'd personally limit the range of any repair tools to very short ranges, like a few meters.
combined with some system that remembers the undamaged state of a given construct (or just plain blueprint access) it would strongly encourage shipyards (with repair arms) and small repair vehicles that crawl surfaces.
neither variant would make it "too cheap" or particularily useful in combat.
and would make repair yards and fleet tenders an asset to be protected.
with all the repair equipment and production capacity at hand.
I like this.
-
didnt i say that already?
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.
-
i'd say that functional elements (generators, thrusters, weapons, etc) have a limited "maintainance" point count.
this point count goes down naturally over time (with or without use) with a slow rate.
the maintainance bar can be refilled by using some tools and resources.
maintainance needs go up with usage of the device (output power x runtime or discrete uses for devices where it applies).
so the older a device and the more it has been used the more its maintainance bar has been depleted.
a ship just being stored in a hangar would still need upkeep, albeit less than an actively used ship.
requiring regular attention and resource input.
as a bit of mitigation it would be possible to "mothball" individual functionals (or just the whole ship, but thats just mothballing all the functionals of the ship)
this would take some time and resources and reduce the maintainance decay strongly (or even to zero) but deactivate the component untill it gets taken out of mothballing again (again taking resouces and time).
this would discourage massive ship stockpiling as every ship thats in a flyable state is taking manpower and resources.
and the ships that arent taking a lot of resources are either not built yet or in a state where they arent readily flyable.
putting some strategy and thinking into what ships you build and keep flyable, not to speak active.
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.
-
what would definitely bring forward sectioned shields would be to have shield projectors not generate closed bubbles but only single polygons of shield "plates".
a single projector would generate a corner/vertex of a shield and it has to connect to other projectors to provide the other vertices for plates/bubbles.
the projection distance could be configured per projector to make the system a bit more flexible.
single projector -> point (pretty useless)
two projectors -> line (a bit less useless, but people are creative)
three projectors -> a closed triangular sufrace that provides protection against projectiles that would cross it.
four or more projectors could completely enclose a volume.
every projector could be part of multiple polygons to generate closed bubbles without gaps.
this would enable custom shield forms for any form of ship in a relatively easy to understand fashion.
(the whole wireframe shield bubble could be smoothed over afterwards to provide more pleasing shield shapes, if so desired)
and would also provide sectioned shields for localised damage modeling on shields.
in addition forcefield doors, shield domes and other uses with custom shapes would come for free with the system.
damage/power needs could be distributed per shield projector or maybe to shield generators by which the projectors have to be supplied from.
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 imagine it would work as either you stated or possibly with a different spin,
You have a first and last name, you can use the same last name as people but not the same first (seen this used multiple times).
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.
-
If it is more of simply adding on without changing any of the original script and still keeps the script secret then cool.
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?
-
I demand Trial by Combat against Jeronimo. I know Gun-Fu.
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 should specify that this idea is specifically about items that your character carries; armor, guns, tools, etc.
It's pretty much a given that we'd expect ships to take damage and require repairs over time.
Would using an item cause it to decay in quality over time, or would it have to take damage to decay over time? Would dying possibly cause it to take damage?
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.
Ship Copyright Infringement?
in The Gameplay Mechanics Assembly
Posted
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.