wizardoftrash

Luckally because it won't be tracking actual projectiles, it won't be quite as nasty as it could be. Since there will be tab-targeting and direct fire, direct fire will likely have a back end snap-to feature to it. It'll be hitscan style, so it is may simply designate an impact area, and if that area is valid, checking your character's stats, the weapons's stats, and the targets stats to determine whether or not it hits and how much damage/size of damage. The snap-to will place direct fire hits from a larger area into a simpler, more specific area (not unlike bullet magnetism). "missed" shots will probably have the same animation as a regular attack, but will look like it missed and do no damage (since missed shots won't be tracked).

First, your comment on griefing being unavoidable is correct, but that does not mean we should give griefers tools to make their mischeif easier. Griefing will be against the rules, NQ will be taking measure to make greifing hard, and to allow players to report griefers. The notion that it will inevitably occur some of the time does not make attempts to reduce greifing less valid. Thanks for the essay, and though your response is articulate, it does not answer my core objection. I'm not objecting to whether or not collision damage can be implemented (which you are attempting to illustrate), I'm objecting to the idea that it should be implemented. My experience in game design is not as an engineer (could you tell?), but I'll try to articulate my technical concerns. And again, this isn't an argument it can't be implemented, it is an argument that it shouldn't. So we can assume that collision mechanics are tracking moving objects, and seeing where they intersect to stop them. Before we start talking about damage, top speed and how often the server is checking for collisions are two key factors that need to be balanced. ->how often the server checks for collisions is going to determine how fast ships can go without passing through stuff and having a bad time. This is a major technical limitation for games with large numbers of players. More players means more moving objects, all of the data the server will need to track for collisions will be multiplied by the number of moving objects. ->top speed is going to be tied to this mechanic in some way, as the server will have to check for collisions often enough that an object can't cross certain thresholds in-between checks. If this is messed up, that's how you have an object passing through another object, or an object being stuck inside another object. ->depending on how player input during flight is taken, steering is also going to Bork up this process a bit. More responsive controls=more taxing to track collisions, because the server can't look as far ahead to predict collisions if course can rapidly change. ->If you don't have collision damage, and the server checks for collisions and finds an object inside another object, crisis can be averted: separate the objects in some way. If you do have a collision damage mechanic when the server finds an object inside another object, welcome to hell. So now I'll gloss over some of the basic factors that would make for an immersive collision damage mechanic. ->Damage: for traditional Construct vs Construct damage, the factors are likely to be Player Skill (hit/miss/location), target size (hit/miss/location), target speed (hit/miss/location), Player Skill (intensity), weapon damage value(intensity), damage type(intensity), shields(intensity/cancellation), armor type(intensity). <--this is a guess for Weapons, which is a stretch goal as it is ->Armor will need to have Damage characteristics in addition to armor characteristics if it will be a factor in colliding. Non-construct objects will also need Armor and Damage characteristics as ships will crash into non-construct objects. This might need to include things like trees, types of terrain, players, etc. ->Momentum: Speed and Mass will both need to be a part of the damage characteristics for a collision, but there will need to be separate sets of factors for Structures and non-structures, as crashing into a huge rock would have a tremendous amount of mass but no speed. ->Impact surface Area: Wedge vs flate plane should feel different from flat plane vs flat plane. This hurts to think about, so I'm not going to try to figure it out. ->Splitting Force: Not all of this will turn into damage, an object ought to "bounce", especially if both objects are in 0g and mobile. Or maybe not, soft compressible structures don't really bounce. This also hurts to think about. ->Shields: should have an impact on collision. Stronger shields cancel more force? perhaps it just shaves off a hard value from the damage characteristic of the collision? good questions here. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ My point is that up there, there is a lot of factors to unpack, a lot of decisions to be made, and it needs to be balanced against Construct vs. Construct weapons and damage... which is a stretch goal And that brings me back to my core objection. As it stands right now, collision damage is not something that is on the table for NQ. Construct vs Construct PVP won't even be a part of launch unless its stretch goal is hit, and they are only planning a few armor and damage types. If NQ set Construct on Construct PVP as a stretch goal, it is probably because it is a small staff with very limited resources. Implementing a mechanic like Collision Damage probably isn't something they have the time or resources to do well. I think most of us would rather have a game with less immersive collisions than a game that will either be next to unplayable for 4 years, or no game at all.

Yes, but we do not know if you'll be able to apply a script to a construct you purchased without edit permissions. If scripts are considered a part of the construct, then you would not be able to add a custom script to a ship you purchased from another player, just as you wouldn't be able to take the ship apart and reverse-engineer it.

This depends on how edit permissions work on purchased constructs. If it turns out that buying a construct that you cannot edit (only repair) prevents you also from adding new scripts to that construct, you would have no way of pasting-in the superior script. If you bought something with an excellent script, you would have to build a construct to run that script from scratch, or buy additional constructs that already have the script. Also there is a good chance that these custom scripts will work better, but only for specific ship layouts. If a script is fine-tuned, applying the script to a ship with different mass, power, and thruster configurations might make it less optimal than default.

Did I hurt your fee-fees? My comment addressed the whole thread, including myself. It is common for people who lack coding and game design experience to expect it to be easy, and many suggestion threads fly under the assumption that their request is simple. I addressed that no one who has commented thus far was qualified to make that judgement call, including myself. Am I wrong? Also, I'm seeing a great deal of "I know you are but what am I" style arguments, and I fully expect a response to the tune of "if you don't posses the knowledge, then how do you know this isn't feasible?" I've presented the closest thing to evidence that I could (i.e. comparisons to other games, with large budgets and brilliant minds, that either took for ever to make a much simpler version of this mechanic work, or that still can't get this right). Just rolling out "this isn't the same game" doesn't actually refute my examples, your statement is accurate, but I presented them as examples of how hard these mechanics are to design. I can look at those examples and imagine how hard it could be to make ship crashes not suck for everyone, and if what we lose by not having that mechanic in the game is a bit of immersion, that is a very easy design decision. The actual developers have commented on collision damage, and they commented on it in the context of sacrificed that they needed to make for multiplayer to work smoothly (i.e. it is not feasible to have collision damage and stable multiplayer). This is not OP presenting a novel idea and users rushing in to stomp on it for funzies. OP is trying to make the case that a mechanic should be added that the devs already have plans not to add. If the goal is to pressure the devs to consider adding collision damage with user feedback and requests, expect to see the other side of the coin. A mechanic like this can have disastrous consequences even if it works perfectly (griefing), and can cripple the game if it does not work perfectly (and it likely won't). What you have to lose here way outstrips what you have to gain.

I was also excited about that base

Not offended, a little surprised however. There are a lot of games where disconnecting during battle does not penalize you at all, intentional or otherwise. We don't truly know what disconnecting in this game will be like, but I can break down the real concern. PVP probably won't happen often in this game. The focus is "rebuilding civilization together", so it isn't like a MOBA where the focus is player vs player. However, after the initial setup period, players are going to spend a lot of time flying ships. A player might understand losing their ship in combat due to a bug, it won't happen often enough to be a big problem. However, if each time you fly your ship you gamble all of those resources because crashing is so punishing, it will be a serious detractor from the game. Think of the time players will be investing in their ships (according to the devs, ship building will be quite a process). Even if we assume that there will be no bugs, and that a player's connection is perfect, losing their ship more than once because of a minor player error (and this happens often in similar games), will be enough for NQ to lose a potential subscriber. This would be compounded by connection issues, bugs, or other unforeseeable setbacks that can cause a crash by no fault of the player. This is one of the features that keeps me from playing Space Engineers more regularly, as even very stable servers rob you of a ship or even a base because of stability issues+collision damage. Without that collision damage, it would be a VERY different game. Sure players could fly more recklessly, and battles would devolve to just how many turrents and heavy armor plates you can afford to slap on your ship, but it is basically that way at the moment regardless, and DU won't have that problem since they are borrowing so heavily from EVE. But that's exactly it, Space Engineers is a simulator first, and a multiplayer game second. DU is a multiplayer game first, simulator isn't even on their radar.

The devs mentioned that the highest quality player desings would permiate, so I'm guessing there will be some kind of rating system for blueprints? it is possible however that simply players will talk, good ships and designs will get recommendations, there will be organized tournaments of some kind and the winner's design would likely be promoted, that sort of thing. Youtubers will definitely have a lot of influence here, the less info the trade system will present, the greater youtuber influence will be. However so far selling completed constructs will effectively lock the sold construct in its current location, a buyer will probably have an opportunity to look at the construct before buying unless its stashed far away.

I don't see the reason to hide a name. It would be nice if a player could decide not to see names further than a certain distance (to avoid clutter) or for names in-general to not be visible at a certain distance. I'm willing to bet that proper cloaking could probably hide your name if that ever gets implemented, otherwise it would be suspicious as heck to see a name floating around with no ship or character.

My concern with zone laws potentially leading to steep penalties is the capacity to abuse. Trolls might make a small town, draw a bunch of new players there, and they might discover the hard way that doing something really normal there is totally illegal. I'm guessing some of this will boil down to the mechanics of the Territory Unit and "claimed territory". We already know that build permissions, and mining permissions are likely going to be controlled by whichever character or org controls the TU, but the rest is completely up in the air. I was hoping that scripting might be robust enough to allow a clever city planner to set up "law enforcement scripts". For example, if a city (not inside the savezone) wants a law that prevents PVP with the exception of bounty hunting, there might be a scriptable element that can "look" for unauthorized pvp, and can react. If the script could command the city's defenses to attack the offending player(s), or if you could have a script create a bounty on the offending player(s), then you have a mechanism for punishing criminals. Larger cities might even have law enforcement players, but I kind of doubt those systems will last. Most likely we will end up with 2 kinds of "cities". A traditional style city that is built in a safe-zone to prevent pvp and that uses TU to prevent griefing, where "laws" won't even be needed. The other would be an Org HQ, that restricts access based on org membership, and relies on automated defenses and org members to keep outsiders out. I could be wrong, I don't think the game is at a stage yet where there are mechanics for any of this, so it is very much in the air.

I heard somewhere that the starter jetpack would only be used for the "build area", but I don't consider that recollection very reliably and for jet bikes to be a reality, there would need to be a "cockpit" element that is more of a motorcycle seat&handlebars rather than an enclosed spaceship cockpit. hence this thread

Let me pull you back to Genre here, because this is an MMO. Which MMO's expect you to know how to fight with a sword IRL? Which MMO's expect you to be able to cast spells IRL? Which MMO's expect you to really have the skill that your character has? Most Racing games are also effectively part of the Simulator Grenre, and this is not part of that genre. The games that expect the player to posses the same skillset as their "character" are the exception, not the rule. Yes the game expects you to know how to build, except oh wait, it doesn't. A player can just collect enough resources to build the in-game default blueprints until they earn enough spacebux to buy either complete constructs or blueprint copies. Building is this game's focus, Building and miltiplayer stability are the two areas where the devs will spend most of their time, and collision damage threatens both of those play aspects. oh and nice slippery slope argument with "why allow combat at all". I don't even need to answer that The player on player interactions in this game will make it immersive enough. We don't need crash our ship and die for this to be an immersive game. We especially don't need to crash our ship and die because a structure didn't load properly, or because landing gears are buggy (look up the Space Engineers landing gear bug).

I wouldn't be surprised if a character-equippable item was some kind of jet back or hover boots or something.

At this point I'm ready to keep posting the horse pics until things quiet down in this thread. The payment method has been decided on already, the fine details of how redemption will work is a bit in flux, but it's pretty much settled.

On the note of griefing, have you seen the posts about characters suggesting an imprisonment system like DayZ, or anything CaptainTwerk posts? But I do believe that "rust" style players would back this game for some of the similarities, because they see "sandbox" and immediately think anarchy death carnival of fun. This is an MMO. Immersion is not a high priority, not as high as smooth multiplayer, the sandbox functions, etc. FPS shooting, tracked projectiles, collision mechanics, these are the kinds of features that make multiplayer impossible to code in a way that plays consistently and smoothly. Desynch will happen, and you won't want a hiccup in an otherwise solid internet connection to cause you to crash your ship. Don't get me wrong, I do love Space Engineers, but that game can barely handle 8 players little lone 8,000. Even minecraft, one of the simplest sandbox games, took years to keep Boats from desynching in servers that had as few as 30 players, and Boats were only tracked on a 2D plane, and could only destroy themselves when they crashed. No one in this thread REALLY has any idea of how fragile multiplayer mechanics are. Without collision damage, a bug simply causes you to fly strangely or boot you for a minute. With collision damage, a server hiccup could cost you your ship, someone's base, your inventory, possibly skill points, and a huge police bounty. just for Emerson, that is not worth it

So you think it is a problem then for the game to assume that your character in the game is a skilled enough pilot to avoid crashing. The game does not expect you as the player to know anything about how to refine ore into materials, nor does the game expect you as the player to know how to build a jet engine from parts. However you think the game should expect the player to be an expert pilot to avoid crashing? This seems a bit silly to me for the game to potentially aim for you, but not avoid crashing for you. I'd be happy to see this compromise from the prospective of "one of the many things the game assumes you character is smart enough to do", mainly fly without crashing. Also, have we considered not crashing as a potential extension of shield systems? It it impossible to imagine a science fiction universe where tech is advanced enough that no one crashes accidentally? or is this still a covert scheme to get ramming into the game as a griefer tactic.

It just won't stay down

Everyone starts with a resurrection node, but not a TU. The devs mentioned that a TU will be a hard item to build that will require a lot of resources, to keep land hard to claim.

I'm pretty sure we need to let this thread die

Build protected mud-huts for the win! (yes I'm aware that the resources needed for a TU in the first place will not be located in the safe zone, and will be hard to build)

There is another problem with collision damage which you may not have considered, which is how crashes will affect zones with rules regarding PVP. For one, without any collision damage mechanics (AKA how the devs intend), any aggressive action a player take will have to be intentional. Damage will require weapons fire, not the kind of thing a player can accidentally do. Damage as it stands right now, is a mechanic that will only be implemented and tested in the context of weapons. Where the damage occurs, how much damage, whether or not you even hit will involve your characters skills and the stats of the weapon. -If ramming bypasses some of those rules, ramming would potentially be more precise that firing a weapon, which seems odd in a sci-fi world. -In a save zone, collision damage would have to be turned off. -In an area where PVP has consequences, wouldn't this also apply to anyone who accidentally collides? could a player who crashes their ship into a monument be banned for griefing? if not, couldn't ramming be a tool for griefers to use and just "claim" it was accidental? -If a law enforcement script is running to put a bounty on players who attack a base, and a player accidentally crashes into the base, wouldn't that trip the law enforcement script and put a bounty on the unlucky player? -If ramming was not a viable combat strategy, wouldn't collision damage just be a nuisance to players? and if so, WHY build a damage system outside of the mechanics for ship on ship combat (which is a stretch goal as it is, not a launch feature) that will simply be a nuisance to players? for emmersion? When you delay the development of a game and inconvenience the playerbase at large for an inconsequential mechanic that will simply be a nuisance, that would be a mistake. When you implement a consequential mechanic that gives griefers the tools to wreak havoc, you do not promote the game's slogan/goal (rebuilding civilizaton). You are welcome to play games in the physics simulation genre, but this is not one of them.

Again, they only would take a hit if they respawn multiple times in a short time period. An org coupd have a valiant past stand, respawn, have another last stand, and then have a choice of either respawing and taking a penalty, or waiting for their timer to re-set and hoping there is enough still to defend. A valiant stand can still be a good strategic last stand. Plus in your analogy, what is happening to the attackers? If the attacking force is has the defenders so outmatch that they are not suffering casualties, then it simply should prevail. On the other side of that coin, what if an attacking ship lands near your base, but too far to launch a counter attack. Their ship has a respawn node, and the attackers simply re-spawn and suicide run your base with expendable weapons over and over again, not being penalized by their recklessness. Your automated defenses should be more than sufficient to mow down poorlu equipped foot soldiers, but since they don't lose any xp for their suicide runs, eventually your defenses run out of ammo and they can take their time cutting into your base and disabling your TU. Depending on how the res nodes work, an attacking force of two players could spend an afternoon disabling large a base just because getting killed in rapid succession doesn't penalize them.

It would hurt defenders that die over and over again, yes. If defenders are having to resort to a suicide run strategy to defend a structure, it should be taken by the attacker, or the defenders should be penalized. Not penalizing suicide run tactics encourages sloppy and immersive play.

Would you be opposed to EXP loss when a player dies repeatedly in a short time? It seems to me that a system where EXP penalties only kick in when a player dies many times in a short period of time would only penalize players that are doing suicide runs.

NQ already stated there will be a way to salvage constructs at some future point (possibly not at release). This will not allow pirates to reverse-engineer a ship, but will allow a pirate that wrecked or stole a ship to reprocess it for some of the resources it took to build it. Salvaging WILL be a thing, but Blueprints will be HIGHLY protected because building is the game's primary focus. NQ will not do anything to allow Master Blueprints to be stolen because they want to encourage building over destruction. The game's slogan is "rebuilding civilization together", hence their leaning towards protecting player blueprints.