Jump to content

CalenLoki

Member
  • Posts

    226
  • Joined

  • Last visited

Everything posted by CalenLoki

  1. Agree that tedious repetitive tasks should be avoided. But is the docking/conveyor the only and best solution? How about automation? Building and programming small vehicles to go into your cargo freighter to pick up whole containers to place them in base storage room. System would be quite simple. On paper of course. We just need some tools: 1. Lua functions "go to waypoint" and "turn towards waypoint" 2. Elements that serve as waypoints. With ability to connect them together to create paths. 3. Storage container socket, which can be filled with storage container. It should also serve as waypoint. 4. Element that pick up storage container from socket and place it in another. Why go such complicated route? There are multiple benefits: 1. Immersion. Landing pads and hangars get filled with vehicles going back and forth 2. Force ship builders to create wide corridors inside ships, which leads to more interesting boarding battles. 3. Create weak-spots in armour, if you go for externally accessible containers. 4. It pave the way for even more automation. Patrol boats (unarmed), short-range taxi, ect. BTW those two systems could coexist. Simple piping would the "easy but inefficient way" while containers the "harder but more efficient"
  2. No collision damage between dynamic constructs seems good for gameplay. But I'm a bit worried about how it will work together with lack of any structural integrity. And I don't mean battleship getting stuck on thin antena - that could relatively easy to avoid by shooting it off. I mean ship getting stuck at single voxel, one of many purposeful left floating around the base. Because AFAIK terrain voxels don't need any connection to the earth core to function. So maybe very limited collision damage? Something like remove few (up to 100) voxels on each side at contact point, and apply large breaking force. Repeat no more often than 2 times per second. So it's not terribly useful as weapon, but at least can get rid of floating debris barrier. Or simply make disconnected terrain dynamic, unless it contains X voxels. BTW: "Voxel damage will come after the alpha" (3:00), right now it's shock-wave mechanics (so distance based) damaging only elements. https://www.youtube.com/watch?v=4Vrf50dZrv4&list=PLA_lhIAGheMGtAygniJs25JDsWgxbfk6V&index=3
  3. CalenLoki

    Hacking

    Em.... how? Like, how any more than just blowing your base to bits? And how any more than any other way of hacking?
  4. The question is: can you transfer quanta over long distance, or do you need to physically give it from one char to another? If the first is true (which is most likely), then lootable quanta brings NOTHING to enhance emergent gameplay. It just creates another tedious ritual of sending quanta whenever danger appears nearby, and even more tedious ritual of sending quanta back when you want to use it. Not to mention wasting one of your characters (not a big deal - I plan to have one at Ark all the time anyway).
  5. CalenLoki

    Hacking

    I'd rather have hacking as mini-game, rather than actual programming. But I'd like it strictly connected with actual construct shape and parts, rather than being something completely separated. How: When you attach your hacking tool to enemy element, you switch the view into kind of cyber-space. There you can see the element you're in, as well as all direct connections. But you can't see any voxels or not-connected elements. You can travel along connections. Either to just to scout (You can guess construct layout based on element location. You also map them, so after leaving cyber-space you can still see them). Or to switch them on/off or use them (i.e. cameras, guns, engines). You can also overload them, making them non-operational for quite some time. But! there is a risk. If enemy actively protect the network with their own hackers, and they overload your hacking device, it get fried. Defenders can also set automatic guards that patrol along programmed route. You can spot them, and they travel at the same speed as you. You can also disable them by overloading within certain range (if they are stationary, or follow predictable route). But if you don't, and they meet you, your expensive hacking gear get fried too. TL:DR - kind of pac-man along element connections. With risk of loosing expensive hacking gear.
  6. Too exploitable. You build your base -> I place huge static core right next to it -> Just mine out your whole base with nanoformer. But I agree - building zones should not overlap (unless allowed by RDMS). That brings nothing interesting to combat, and just ask for griefing.
  7. Main reason why they don't want collision damage, is that they don't want kamikaze-like ship designs. It also make things easier for servers, but I think that's side effect. And I think there will be collisions, they just won't cause any damage. Otherwise someone could just fly his ship through the wall of you base/battleship. Would look silly to have entire fleet gathered in one spot, phasing through each other Regarding block destruction - how else could it be done? HP bar for entire base that have just antena sticking out of the ground? Or base that looks small outside, but have stacks of armour underground that multiply it's HP tenfold? Or maybe only dynamic constructs would have HP bar and can fight, while static ones wouldn't be allowed any weapons? Or only elements taking damage, while shots go through voxels without noticing them? Then should they also go through the ground (to prevent single-voxel dirt coverage to be ultimate base armour)? Or maybe indestructible one-voxel armour in general, making all interior devices indestructible? Or simply no CvC at all., and you can freely use nanoformer to make holes for AvA assault? I just don't see any other way. If you do, please share.
  8. I think the point of shield is not to buy as much time as you can. It's simply way to let defenders get online. No matter if defenders are just two guys, and attackers have huge armada of battleships - they should still be given chance to try defending their possession. So IMO it should work against surprise attacks (sometimes called night raids) - if you want those, target ships in the wilderness. Luckily devs seems to go this way.
  9. Low skill levels means disadvantage in combat. Your choice, just like taking cheaper ship, or saving on built base. Exactly. All kinds of levels. After all assassinating enemy best engineer should be a thing. Yeah. Said that just so nobody accused me of suggesting full perm-death.
  10. CalenLoki

    Loadout

    Some more thoughts on that: As loadouts can't be changed on the fly, they could be a nice way to inform other players (both hostile and not) what to expect. Thus it would both enhance gameplay, increase immersion and simply look cool if they were always visible on the character. Rifle tied to backpack, pistol in holster, ect. Also lore explanation for not being able to access nano-compressed inventory during combat: It's a technology that is really useful in the time of peace, but also really easy to jam by others. Nanoformer simply won't work if anyone within x distance turn on nano-jammer. You can always locate the jammer (within range, even through walls), so griefing by jamming will cause severe consequences.
  11. Noone of people who play game where you loose hours-worth of ship and equipment when you loose battle? Hmm... It's complicated question of "how meaningful death should be" without simple and common agreement. IMO anything that can be directly used in combat should be at some risk. Unless it's available to everyone from the beginning (nano-former, space-suit, ect). And you can use levels in combat. Traders can die, builders can die, miners can die. Making enemies by scamming or selling shit makes it way more likely. As well as just being good and upset competition. No need for separate system for them. PS. I'm against quanta or DAC loss, as it can't be directly used for combat (and are too easy to save on alts anyway). Just in case someone misunderstand. PPS. I can agree to use term "skill level" or "character skill", as a compromise. As simple "skill" apply to other things than some numerical statistics too.
  12. Sounds good. It's basically connecting two independent constructs in a dynamic way. So if implemented properly, that could easily lead to much more freedom, like custom turrets or hangar gates. But I'm afraid it may be a bit too complicated, at least in the first stages of development (alpha/beta/right after release). And you can make some basic version of it with hover engines/landing gear (to create cushion between constructs) and jet engines for propulsion. Or even skip the cushion parts, as there will be no collision damage between constructs (if collision detection is precise enough to avoid glitches).
  13. Create system to enhance word of mouth/blacklists reach. Make sure that creating alts to avoid punishment doesn't really work (levels?). As a player, make sure to support those who hunt trolls (pay for protection). And don't forget to be tough yourself, to filter out all weak unorganised trolls.
  14. Words. Levels are in-game statistics that let/help your character do stuff. Skill is player ability to control game elements. Both are learned over time, first at fixed rate, while latter depends on individual predispositions. That are my definitions. Feel free to use your own. I know it create more risk, especially for vets. But who, if not long term players, should be the most exposed? Newbies? They are already at disadvantage - in terms of levels, skills&knowledge, social status, hidden wealth, ect. Severity of character death is what dictate how people behave. The further it is from real life, the less realistic behaviours it promotes. Loosing ship is obviously large hit, but it doesn't affect people who may be very important without any equipment. And using alts for combat seems like viable way - characters are tools for players, just as weapons and ships. So you shouldn't risk more than you need to do the job. But! I have alternative idea, that would also promote assassination, but only as a tool to temporarily hinder enemy, rather than permanently harming them. It's again aimed to cause fear of death mostly amongst vets. Every time you die you temporarily loose 50% of your current level. It regenerates over time, at speed that increase proportional to the time since death. So in a first day you'll regenerate one day worth of level. Two on the second day, three at third, ect. If you're one month old, it'll take 5 days to fully heal. If year old -> 18 days. 6 y o -> 47 d. While healing you're still earning new levels. Thus no levelling time is ever lost. If you die multiple times in a row, the healing speed is re-set and need to accelerate again. I can't think of any rule that could be used to draw that line either. Bounty system? Just spend some monies to grief those you don't like. Killing a lot? What if someone just effectively defends his property? What is good and bad? Who's hero and who's villian? Attacking much smaller enemies to encourage fair combat? Too hard to determine which org is really small, and which is part of huge informal alliance of small orgs. So overall - too artificial, too easy to game the game.
  15. It's planned to be per-voxel destruction. Well, it's not that obvious. There are some games where you can build fairy dragons and they are still effective, and some where you need to follow quite strictly building rules to be competitive. It all depends on game mechanics. Example of first could be Machinecraft, mostly because it uses HP bars. Robocraft also goes in that direction. On the other end there is Crossout and From the Depths. I hope DU will find some nice balance, maybe a bit more towards function over looks. A lot depends on how armour and damage works and how important internal components are. Some mechanics can be also used to encourage certain nice looking aspects. I.e. heat propagation could be used to force players to separate ships into barely connected sections. I.e. engines create a lot of heat but it doesn't harm their performance, thus they are placed in sticking out pods. While generators require low temperature to operate And guns require low temp to initiate charging, but jump to very high ones once fired. Some other mechanics generally dumb down builds into bricks, borg cubes and balls. I.e. physical armour. And some force long cigars. I.e. drag based on frontal surface or star-gates with limited size. Internal layout can be also heavily affected by game mechanics. I.e. if combat-repairs are viable (armour>weapons) and repair tool has short range, then for sure ships will be filled with maintenance corridors. If repair is a long range and can go through walls, you may expect ships filled without any empty space. Same effect could be created by making loading/unloading based on physically moving entire boxes, rather than having pipe that sucks items in-between constructs.
  16. DACs? Probably. TCU? I don't think so. Except sanctuary units, they are just normal items in game. Ressourection Node - also normal thing. Only premium "skins" remain, and can be applied to new RN Quanta - IMO should stay non-lootable. Just so you always have something left. Levels - Actually making players loose set % upon death (i.e. 3%) would be quite interesting mechanics. So newbie (month of playing) would loose just day worth of stats, not a big deal. And veteran (2 years) would loose 21 days. Would create kind of championship "who can stay longer". Or create situation where highest level scientist of one org is under constant threat of assassination, as he's the only one who can produce weapon x. Player skill - that's what really distinguish between noob and pro player, and nobody can take it away from you.
  17. I'm not sure if it applys to dynamic cores too. I got impression that it's more of "aligning" than actually "connecting". May be wrong here.
  18. According to that video, which show construct cores (after 4:00), we'll have at least 128m long ships. But I think I've read somewhere that they plan to introduce 256 and 512 too. But it may be just for static cores.
  19. Only people that can be very unhappy about it are cowards who are afraid of attacking manned bases. Those that can only succeed by abusing the fact that it's a game, and other people have real life outside of it. IMO FFU should have proportional cost (both initial and maintenance) to the protected area. Something like 1s of mining for day worth of 10m2 protection. So for 20m radius shield you need ~2 minutes of mining fuel per day. For 200m -> ~200 minutes. It would still make bigger shields more economical, because protected volume rise to the power of 3, while cost to the power of 2. There will be enough opportunities for unexpected attack: against ships, miners, explorers, fields (if they'll have realistic sizes shielding them won't be economical), ect.
  20. You can at least try to bribe pirate, promise him periodic payment for "protection". Unless he's dumb, he's aware that attacking your base will make you move somewhere else, pay for bounty, support forces hunting pirates, ect. It won't work against griefer - he's madman who just want to destroy. Agriculture works better with small, spread settlements. It require way too much space to function in towns. Development of agriculture was one of requirements for towns to exist, due to efficiency. But not reason for them, nor their function. Trade and craft - those were the main functions of first towns. Then defence needed to protect trade and craft. Then more trade and craft to supply defence. Then even more defence.
  21. Hacking TCU would just remove it's primary purposes: preventing bypassing all defences with sneaky tunnel. Especially when defenders are off-line. I'll add drill to first post as possible solution: Relic of the past, before invention of nanoformer. Cumbersome, slow, loud and energy hungry. Can't compress matter, so you need to carry heavy boxes full of rock out of the tunnel and empty them there. Dig by brute force, so doesn't work when FFU is active, or inside Ark zone. But it can't be blocked by TCU.
  22. I know about storage space. It's even included in my post you quoted. The point of my post was: "town" is a place where a lot of semi-independent entities (players, small orgs, large orgs) build stuff right next to each other. If just one org build huge trading hub, with many enormous storage buildings, that's not a town. That's a base. And there is no reason for anyone else to build stuff around, because that base handle all the trade, storage, refuelling, repairing and respawning. I have mixed feeling about it. It could be seen as "symbolic representation of something too complex to simulate in game", not necessarily magic.
  23. Yeah. We're all in the "wild guess" territory. Another thing that may work for or against cities is the size of single claimable territory. While of course owner of TCU (i.e. town mayor) can grant permission to build single construct to another player (i.e. citizen), the permission to dig around affect whole plot of land. So if citizen get permission to dig his basement, he automatically get permission to dig tunnels all around the town (which may be later used by enemy army or sth). If plots of land are small (i.e. the size of typical small building - 50x50m) then the problem is easy to fix - just allow him to dig only within single TU. If they are big (1km2), then you need quite harsh home-rules regarding digging: either allow it only to specialised trustworthy people or give digging permission only for very limited time. Both hinder creativity of citizens. Alternative could be sub-TCU, that have very limited range (25m radius) but allow creating localised exception for digging/constructing RDMS. Just so town mayor can manage digging right with finer precision.
  24. Yes, I know. The question is - how will they do that. It can be de-centralised on global scale, but centralised locally. (i.e. only large orgs can afford market unit) I'd go for de-centralised all the way down to individual players - so trade within even small org is possible, viable and common.
×
×
  • Create New...