NanoDot

That's why semantics are important. "Not seeking out" implies that something can be avoided if you do not pursue it. "While trying to avoid" implies that something is seeking YOU out, which is an accurate reflection of DU game play. Trouble will actively come looking for you, whether you look for it or not.

Semantics are actually vitally important. For instance, I'd phrase that last part of the sentence as: "...but you can play the game while trying to avoid PVP." Subtle difference, but the emphasis shift is significant.

We don't know enough about the final implementation of DU's mechanics to say with confidence that "nothing will be bot-able". There are some very resourceful people around, and there's no doubt that many will attempt it, given that playtime can be earned via buying DAC with ingame currency. What NQ needs to do is to make sure that the EULA is clear and their monitoring systems are able to identify and flag "suspicious" behaviour.

I'd imagine the greatest risk is that your landlord gets into a fight with some other group and the "tenants" get caught in the crossfire. The landlord will always try to protect his own assets first, anything else will get protection if there's spare capacity. Additionally, tenants are seen as legit targets, given that they provide the landlord with additional income.

Perhaps, we will have to see ingame whether my interpretation or yours is closer to the mark. I believe the "basic Lua functions" that JC fleetingly mentions in the commentary are the movement functions of the construct. But as he doesn't elaborate on the subject, it's impossible to tell for certain whether the scripts he's referring to are running on the RCU carried by the player or the construct's own control unit (or even somewhere else). What's the point of having a Remote Control Unit if you can just use Lua scripting to achieve the same result ? Or perhaps the RCU is not involved in "following", and all dynamic construct control units have a basic "follow" function, in which case you could even get a dreadnought to follow you around...

That ship/construct is following the player because the player is using a Remote Control Element. The actual "following" is not caused by a player-generated Lua script running on the construct. I'd imagine the Lua scripting will allow you to change the behaviour of the thing following you (e.g. speed, distance, altitude, etc.), rather than giving you the ability to issue a random "Follow me" command via scripting. Without the use of a Remote Control Element, nothing will follow you. The limit on what can be done via Lua scripting will be determined by NQ to a great extent, because you can only manipulate the functions of an element (e.g. ship weapon) which are exposed by NQ in the scripting interface. So if NQ doesn't want a weapon to be automated, they simply won't provide a Fire.weapon() function for you to call in Lua.

DU has more varied possible combat scenario's than any other MMO I'm aware of. In DU we have the possibility of combat involving: Avatar vs Avatar Avatar vs Construct Construct vs Construct All of these battles can potentially take place: on the planet surface (on land) on the planet surface (in or under water) *not planned for launch* in the planetary atmosphere in space NQ is not a large dev team, and I expect that the combat mechanics for launch will be fairly basic, with things being expanded and refined "after release". Some aspects of combat may simply be disallowed at launch, for the simple reason that there's not enough time to develop it into a satisfactory state in the limited time available. Otherwise NQ will probably have to postpone launch by 2 years so that they can fully develop all aspects of combat... What are the minimum combat features you'd expect to see at launch ?

DU-u-EVE ?

As longs as you remain in the safe zone... At this stage, we have no idea what the shape or limits of the inventory system in DU will be AFAIK. What I do know is that managing 100's of BP's and copies will rapidly become a PITA if it's not a well-designed inventory system...

You can make unlimited amounts of BP's and copies, but you'll have limited personal inventory space. They have to be stored somewhere, and BP's are lootable AFAIK.

Basic refining will be done in the inventory (e.g. iron + coal = steel), but more advanced processes will need to be run in external elements (e.g. refineries, smelters, etc), which will be constructed from the basic materials you refined in your inventory.

So, does this mean Tortuga will be the de-facto "pirate capital" ? Either the safest place in the galaxy, or the most dangerous, depending on your point of view...

There simply aren't enough resources to tackle such a project. There has been a suggestion that NQ should add a "creative mode" for building things in game to allow players to create blueprints without physically gathering all the resources first. Even that request was answered with "possibly some time after launch". There's still a massive amount of development ahead for DU. And all that has to be tested, balanced, optimized and polished. It would certainly be a nice toy to have, but I'd rather have the game launch 3 months earlier !

It would be strange indeed if ships flying in the atmosphere couldn't attack structures on the planet surface, or even engage player avatars. Anti-construct defenses on bases would have to be able to counter both flying ships and hovercraft. Anti-personnel turrets will also be needed. We'll have to wait for the PVP implementation to see how it all works out.

Just be careful with the "replica" ideas. Nobody will be any the wiser if you build a pixel-perfect copy of an X-wing in your single-player SE game. But the moment that happens in an MMO where potentially tens of thousands of players will see it, buy and fly it, the owners of the original IP will quite likely have an issue with it.

From Nyzaltar's OP, we get the following: It is also clear that NQ's original plan was to have DAC be unlootable items in the player inventory. But due to player demand from the current community, NQ have undertaken to implement a "redemption system" similar to EVE's, where a "redeemed DAC" will be lootable. HOWEVER, due to the considerable extra dev time required, they cannot guarantee that it will be in place at launch. But what about the DAC associated with pledges ? Will those DAC be a "credit" on the payment portal, which can be assigned on-demand and in varying quantities to a character of your choice at any time ? Or will they all be dumped into the inventory of the first character you create ? Absent a fully functional redemption system at launch, DAC's should remain unlootable until the required redemption mechanics are implemented.

My dislike for "improve-by-use" skill systems in MMO's stems from the fact that it inevitably leads to AFK botting, especially in PVP games, where people fear "falling behind" other players who have more play time than them. before you know it, everyone's botting in an attempt to either stay ahead or to catch up. EVE and DU's planned time-based training means you can play the game without having to spend hours repetitively grinding skills so that you can be "viable" in PVP.

Frankly, I think "pay-per-hour" would be a terrible idea for DU ! Players will very quickly start converting the time cost of ingame activities into RL money costs. The forums will be full of posts demanding that mining should be "faster", because it costs X dollars per hour, which is waaaaay too much ! Reddit will have posts with detailed breakdowns of the "exhorbitant" RL cost of training skills in DU...

Dumping resources "on the floor" certainly sounds like an option, but it has a security risk. Anyone can hoover-up that pile with their own nanoformer. You can't set RDMS permissions on a random pile of resources. There will HAVE to be restrictions on inventory, otherwise "space-truckers" will be replaced by "space-couriers on bikes" !

Services like Netflix use the flat-rate per month (subscription) model. You don't pay for what you watch, you pay for the ability to watch. It works because the total volume of subscriber revenue is sufficient to cover costs and generate a profit. Some heavy users will get a bargain, while others that only watch 1 movie a month will get less value. But the sub is cheap enough to be attractive for the average user, because there's cross-subsidization taking place. "Pay-per-view" services are generally far more expensive on a per-hour basis than those that charge a flat monthly fee. "Pay-per-view" also increases the administration costs for the company. Detailed logs have to be kept for each customer, and the inevitable disputes over usage has to be handled by additional CS rep's.

Indeed, I'd expect that blueprints made during pre-alpha will have to be modified several times to accommodate changes made to game systems in the alpha and beta stages.

Much depends on how much a player can actually carry in those belt pouches. If it's a significant quantity in game terms, then players WILL use "mules" to turn a small shuttle into a high-speed superfreighter. Having multiple accounts will make that very convenient, of course. The only way of preventing that happening is to introduce some "hand-wavy science" via the lore, which will somehow make it impossible. Something along the lines of "acceleration interferes with the compression tech of the belt pouches" or perhaps "the belt-pouch compression tech emits a local field-effect that disables ships' engines". That would mean compressed resources would have to be transferred from belt pouches to "specially shielded cargo containers" aboard ship. The storage crates themselves are easy to handle in game terms, because they are elements, not constructs. So their attributes are pre-determined by NQ. A player can build an elaborate "storage crate" structure out of voxels, but it will store nothing until the pre-made storage crate element is added. The element will determine the amount stored, the volume of voxels used in the "wrapper" will be irrelevant.

Balancing a "hacking skill" will be a tricky business. If it becomes too easy to use successfully, every prospective pirate and cat-burglar will train the skill, no matter how long the training times, because the rewards will be huge. The elaborate system of RDMS "locks" will become obsolete. Hacking into ships/bases while the owner is offline will be a popular passtime. If hacking is too hard, people will complain that it's a "useless" feature. Why train a skill that hardly ever works, etc. ? And what would the counter-measures be to the hacking skill ? These would have to include passive features that can be deployed while a player is offline, given that offline time will be the most vulnerable window.

The definition of "element" would be anything that's designed by NQ (as opposed to being made by a player by combining voxels). Core units are designed by NQ, so they are elements. I think one suggested mechanic is to "spread" the combat damage over an area of the ship near the point of weapon impact. So elements in that area would all take damage on a percentage basis. Point of impact may be no more sophisticated than "the side of the ship facing the incoming damage". I highly doubt that it will be pinpoint accuracy, given that it's all based on target locking, not on manually aimed weapons fire. Perhaps we'll be able to "lock weapons" on a visibly exposed element like an engine, for instance. It's all theoretical at the moment, because the PVP mechanics haven't been implemented yet. In fact, those mechanics probably haven't even been designed in any detail at this point, it's all in the "to do" list.

We have already established that DAC gives the seller an advantage, lol ! We know this, because nobody would spend RL money on something that does NOT give an advantage. How many DAC would be bought if it was just "to help NQ improve the game" ? The pro-DAC arguments basically say that the advantage gained from selling DAC to other players will have no effect on game balance. Some of us disagree, that's all.