Megaddd

Math doesn't work like that if you got  some fixed costs (i like your optimistic view :3, i really hope we get 100k players too) .
But it's a good theoretical example.
 
I will just add one thing, i know for sure.
 
Costs for Devs:
-Engine License
-SFX License
-Ohter License
-Servers
-Energy
-Personal
-HQ
-Equipment
-Others
 
For a similar Dev group of an indie game. I know that they churn trough 300~400k a month in development cost (and have been doing so for 3 years ;3), aka having two to three servers running + the fixed cost of the whole other stuff. Given that i know little to nothing about cloud servers and how much they cost, i can't really say what we will end up with. But lets say, we will need 10 server shards and the overall cost would end us at around 500k/month, probably.
 
That means to be selfsustaining they would need arond 33k User, who pay 15 dollars a month.
Which isn't even that much.
 
Hopefully i'm ways off about what an single server shard costs and how these providers calculate heir cost. But i would say we need around 20k User for sure, to cover ongoing development. Based on how costly all of the other things, except servers are.
 
The only people that know for sure are the Devs and maybe the investors, that will get an update about cost/etc but need to keep that under a sort of NDA. The only thing we can do, spread the word if we really love the game that once will be there for us all to play. ^^

They've publicly expressed, that while they are interested in the concept, these may not be in at launch, as it makes everything related to constructs that much more complicated (hitboxes/physics/connections/constraints/rendering/blueprinting/inheritence/optimization etc. etc.)

Theres no such thing as a true one man empire. Sure u can do stuff alone but to be a force to be reckoned with will take hundreds/thousands of friends working together for comon goals. 
 

While I can not tell you anything directly about the game, the last play-test being 5/12-14 is public information.
I can, however, tell you that during those 3 days I slept for about 7-8 hours total, and about 80% of my waking time was spent at my computer, with most of that time being dedicated to video gaming.
From that you may deduct as you wish. 

Since it has been confirmed that we will be able to build, let's call them "Megastructures", like Deathstars or possibly even howl moons, will it be a thing for man made vessels to have a gravitational pull.
Meaning that if some group or coalition actually managed it to construct a space station with ~160km width I don't see a reason why it shouldn't attract small objects.
Would it be to much load for the Servers to calculate the gravitational effects of every Ship, Station, etc?
 
 

More info is available in the pre-alpha subforum   - 
 

@Orius
It's a bit difficult to recommend a box-only voxel editor, as voxels, in general, in games such as LandMark, carry slant information, as such creating angular models like this should be possible:
 
 
With that in mind, I recommend you simply use Blender, or any other free 3D modelling program.
In Blender, using the 'Remesh' modifier on an object will give you voxel-like behaviour, with the Blocks mode showing you which 'voxels' would be mostly full in box mode: 
Keep in mind, they've shown in the videos for the player construct voxel-density to be 0.25m, so if your goal is to create game-feasible models, make sure scale your model to fit roughly 4 of these boxes in a single grid line (which you can consider as 1 meter in blender).
 
Then flipping the modifier into Smooth or Sharp mode will show you how your Blender model might look recreated in a voxel engine:

 
As you can see, my model had very thin detail in the rear, that was smaller than the voxel engine could handle, which means I would have to reduce the detail in that part of the model, or increase the overall model size, increasing how many voxels I have for detail:

@Orius
It's a bit difficult to recommend a box-only voxel editor, as voxels, in general, in games such as LandMark, carry slant information, as such creating angular models like this should be possible:
 
 
With that in mind, I recommend you simply use Blender, or any other free 3D modelling program.
In Blender, using the 'Remesh' modifier on an object will give you voxel-like behaviour, with the Blocks mode showing you which 'voxels' would be mostly full in box mode: 
Keep in mind, they've shown in the videos for the player construct voxel-density to be 0.25m, so if your goal is to create game-feasible models, make sure scale your model to fit roughly 4 of these boxes in a single grid line (which you can consider as 1 meter in blender).
 
Then flipping the modifier into Smooth or Sharp mode will show you how your Blender model might look recreated in a voxel engine:

 
As you can see, my model had very thin detail in the rear, that was smaller than the voxel engine could handle, which means I would have to reduce the detail in that part of the model, or increase the overall model size, increasing how many voxels I have for detail:

@Orius
It's a bit difficult to recommend a box-only voxel editor, as voxels, in general, in games such as LandMark, carry slant information, as such creating angular models like this should be possible:
 
 
With that in mind, I recommend you simply use Blender, or any other free 3D modelling program.
In Blender, using the 'Remesh' modifier on an object will give you voxel-like behaviour, with the Blocks mode showing you which 'voxels' would be mostly full in box mode: 
Keep in mind, they've shown in the videos for the player construct voxel-density to be 0.25m, so if your goal is to create game-feasible models, make sure scale your model to fit roughly 4 of these boxes in a single grid line (which you can consider as 1 meter in blender).
 
Then flipping the modifier into Smooth or Sharp mode will show you how your Blender model might look recreated in a voxel engine:

 
As you can see, my model had very thin detail in the rear, that was smaller than the voxel engine could handle, which means I would have to reduce the detail in that part of the model, or increase the overall model size, increasing how many voxels I have for detail:

It's going to be combining chemical compounds, and making alloys kind of complicated. It's gonna be great!

We’re all sure it’s going to be a big part of gameplay, so how do we make it fun? Simply being ‘emergent’ or freeform isn’t enough to make a mechanic fulfilling in and of itself, of course. So what can we do to keep the player engaged with this aspect of the game, or at least make it feel rewarding for its own sake. Or, if nothing else, make dealing with it not a chore.
 
I’m going to be touching on a few subjects as we go here.
~Construct Inventories
~Market Inventory Mechanics
~Storing and Deploying Constructs
~Shipment Jobs and Contracts
~EDIT: Tactile Containers
 
Part of the “Durendal has highly vocal opinions about game design” series.
~ Construct Mining and Balance: https://board.dualthegame.com/index.php?/topic/13238-mining-constructs-balance-and-you/
~ Logistics and Cargo Management
You’re already here.
 
Part Zero: What’s an Inventory Anyway?
This should probably be established early on. What is an inventory? The obvious answer is that it’s where the player stores their stuff, but the form it takes can vary. The most popular form of inventory is a simple screen with a list, or a grid into which representations of items are slotted.
 
So let’s take a moment to look at a few examples of how games have handled inventories.

From Left to Right, we have Minecraft, Astroneer, Hellion, and EVE Online.
In minecraft we can see a very simplistic and effective grid based system. EVE takes a similar approach, displaying items in a list as icons, much like a windowed computer interface.
 
Astroneer and Hellion take a vastly different approach. We can see in Astroneer that the player's items are stored directly on their characters backpack, or carried around ‘by hand’ with the mouse cursor. Whereas in hellion, anything the player wants to set down, needs to be racked onto a shelf or container in the world physically.
 
These represent various takes on two approaches, which we’ll call “Listed” and “Tactile” inventories. One represents the inventory as an abstract space, the other as a physical part of the game world.
 
So, which approach does DU appear to be going for?

“Listed” for sure. And given the scope of the game, one can see why. Having all the items players create physically represented in the game world would be impossible in a game like DU. That said, of the two styles, a tactile inventory is the more engaging and rewarding to actually interact with as a user experience. So is there some way we can implement aspects of it while still keeping within the technical and usability limitations placed on DU’s gameplay? I’m going to venture a ‘yes’ and present some theoretical mechanics and use cases.
 
Part 1: Construct Inventories
We can see in the screenshot above, pulled from the Pre-alpha tutorial videos, that the player’s personal inventory consists of a branching,sortable list of items. As an extension, we can assume the inventory of a construct would be similar. Perhaps taking the form of minecraft-like ‘chests’ into which items are simply dragged and dropped. This is absolutely a functional system, but it’s not a very satisfying one. It doesn't leave a lot for the player to interact with. So how can we take some elements of a tactile inventory system and apply them to DU’s listed system?
 
Before we get into the meat of that, first of all we should establish how the player is going to interact with the contents of a construct. The most obvious answer is ‘they walk up to cargo elements and press the interact button’ but this has the potential to become more tedious than immersive.
 
The most straightforward way would be some means of inventory pairing. With this, a character could set a current construct as their ‘active inventory’ and have the things within in available to them as if they were in their personal inventory. So long as they remain within a certain range of the construct. This allows the player to move things from one construct to another without tedium. Simply by moving from the construct that contains their active inventory to another, and interacting with it normally.
 
With that out of the way, let’s discuss a constructs inventory in and of itself. NQ has stated that a construct will have access to ‘storage elements’ which are required to contain items. These may be specific to certain item types, such as solids, liquids, elements, constructs, etc.
 
One way to make this a bit more engaging is to implement a two-stage inventory for constructs. In this, there are two primary types of inventory elements: Containers (previously ‘storage elements,’) and Racks.

 
When a storage element is installed on a construct, it contributes to that constructs capacity to hold items. Interacting with it, or opening one’s player inventory when paired to the construct, will allow the player to drag items between any appropriate spaces. Be it their inventory or the Containers of a linked construct.
 
A Rack, on the other hand, allows Containers to be installed in it directly. This allows them to be used in the manner described above. In addition, however, when interacting with a rack or other construct, a player can drag an entire Container from one Rack to another. Allowing the movement of physical containers from one consruct to another. (The Rack element here will display the container it contains, but that container won’t be a separate element. Though it may affect the characteristics of the Rack as if it were.)
 

 
This should allow a great deal of flexibility in cargo handling and inventory management. As well as giving a pseudo-tactile to feel to the process. Giving the player the possibility to see their cargo hold actually ‘fill up’ with goods in some way should add at least some small aspect to making the task fulfilling. It also has some knock-on effects to other mechanics, taht will be discussed in following sections
 
Part 1b: Secondary Conjectures
This is stuff outside the scope of the above, and is more conjecture than solid suggestion or opinion.
 
~ Containers could be allowed to be dropped freely as physics objects? This could be problematic. But having either an ‘ejection’ rack or mechanism for detaching containers rapidly could allow for some interesting interactions. It also ventures the possibility of placing containers in a ship without a rack, or piling them by some method in a warehouse without racks. This is beyond the scope of the proposal, though, and probably incurs too much overhead for what it achieves.
 
~It might be possible to store multiple smaller containers in a larger rack. This incurs the problem of designing a UI element to display how this is being accomplished, in the case of odd fits. While it’s perhaps possible to clearly communicate how much space is remaining in a give rack for containers, this may also be more headache than is necessary.
 
~Possibility the distance an inventory transfer can take place it is related to ‘nano beamformer’ elements? This may be an unnecessary complication. But the elements themselves would provide a jumping off point to script the automatic transfer of containers and cargo.
 
Part 2: Storing and Deploying Constructs
 
Dev blogs have stated it will be possible to store entire constructs inside of a storage element. So how do you get them out? And how does that play with our new Container and Rack system?
 
In addition to container types for different resources or items, one can assume there will also be one specifically for constructs. In fluff terms, we can consider this as a complex device that stores a complex object deconstructed by nanoformers as its component parts, along with all the information to reconstruct it.
 
The capability to store constructs in this way is vital for a number of reasons. Both to facilitate mass production and to reduce server load. (While the image of a lot of ships for sale is delightful, it may be hard to handle for multiple reasons, including interaction with market mechanics.)
 
So first of all, how do we store a construct? We can posit that a construct becomes any other item and is placed into a container suitable to it. Issue arises with constructs that take up more volume than a single container holds. How does one put battleship soup in a can? Here, we can assume that a construct could be ‘partitioned’ across multiple Containers, that become a linked item, or at least a cross-referenced one.
 
Next, we need to get Constructs both into and out of containers. An issue that arises here is that we don’t want this to happen instantly. While time has already been invested into making the construct, we also don’t want units being deconstructed in combat to save them, or freighters instantly spitting out fighters from their holds. So this process should take some time.
 
To facilitate it, we have two elements. We’ll call them a “Garage Array” and a “Construction Array” for brevity's sake. A Garage Array deploys or undeploys dynamic constructs. It’s either linked to secondary elements defining an enclosed space, or has some sort of volume set on its deployment. A Construction Array deploys and undeploys static constructs wherever the operator points it.
 
The size of the array elements themselves determines the maximum size of the construct they can work on, and how quickly they do so. (Possibly in conjunction with player skill.)
 
Thus, storing or deploying a capital ship or large station should take a fair bit of time, while fighters and houses should be quick affairs.
 
The Container that an undeployed construct should be placed in would be selected via GUI upon beginning the process. While deploying one could use existing UI elements. (The item sidebar specifically.)
 
Part 2b: Secondary Conjecture, The Second.
~It may be a Good Idea to factor the deployment time into the time needed to manufacture a construct in the first place.
 
~If a container for part of a construct is lost, a Factory Unit should be able to replace it by being provided with the other containers. To prevent IP theft by copying. (Splitting something into five containers and ‘replacing’ the other four off each.) When the process is initiated, remaining containers should become inert. Though if they’ve been stolen or simply misplaced, the construct soup in them should be reclaimable for raw materials as a consolation prize.
 
Part 3: Market Inventory Mechanics
So now that we have containers, how do they interact with markets? It’s been stated that a market will need storage for goods waiting to be sold, so we can facilitate that in the following ways.
 
1: A container attached with no rack to the market construct and linked to the market unit provides loose item storage to it.
2: A rack attached to the market unit allows for containers within it to be sold, including their contents. (And potentially bought, but this has some issues, as a market order for ‘a size 3 Container with exactly 30k iron ore.’ raises UI questions.)
 
Alternatively, we could also allow containers in racks to be flagged to contribute to the total loose storage. Or to only do so until they’re empty, or any other number of possibilities.
 
The major takeaway of this part though is that racks and containers facilitate bulk sales for allowing entire containers of goods to be sold and delivered as a unit through the market terminal.
 
Part 3b: Secondary Conjecture; third time’s the charm.
~If market terminals also facilitate delivery or transfer contracts, this neatly sidesteps the problem of ‘placing buy orders for containers of goods.’

~That said, providing an empty container to a market terminal along with buy orders that are collectively tied to its capacity is a Good Idea.
 
~Buy orders that are tied to a target containers capacity are a Good Idea in general, because they allow factory owners flexibility in receiving deliveries from freelancers. But that’s probably out of scope for the cargo post.
 
Part 4: Shipment Jobs and Contracts
 
Containers should allow for shipment jobs to be generated easily. Instead of specifying specific items, a client can now simply say they need a container shipped from A to B. Unfortunately, a simple contract like this fails to allow for some use cases.
 
If an efficient trip means transporting a crate from a market terminal near the client’s business, to the spaceport, to an orbital transfer, then via freighter to another transfer and down to another planet, orchestrating all of this could be problematic. So it may be ideal to allow the client to specify the legs of the journey and the payout for them.
 
Alternatively, allowing potential contractors to establish routes from one freight terminal to another, simply with a fee for transit of a Container, may be a better solution. Here, the customer would select a destination in the market terminal, deposit their Container, and the contractor is paid upon its arrival. This allows a shipping company/org to worry about all the interim stages without involving the customer, but still allows such jobs to be established without require a clerk and notation on the player’s part.
 
4b: Secondary Conjectures One last time
~Yeah, just kidding. This whole part was mostly conjecture.
 
And there you have it. Ways to handle logistics and the potential benefits thereof. There could be ways to make these mechanics even more hands-on and engaging, but they’re likely outside the scope of development NQ has set. The above seems, to me, like a fair compromise.
 
I ran out of steam on the graphics to accompany this. I might go back and add some more later.
 
EDIT EDIT EDIT
Part 5: Tactile Containers
I forgot this one before I posted last night.
 
Tactile Containers would be things like lockers, shelves, weapon racks, armor stands, etc. Things players could use to display personal items such as weapons, tools, spacesuits, and various small decorative items that aren't worth making 'elements' in and of themselves. These would be placeable or retrievable just by holding the item (or nothing to retrieve) and interacting with a 'slot' on the container. These would be specifically not linked to a constructs overall inventory, and might as well includes safes or the like. (Normal containers that are not visible to the outside inventory system by anyone.)
 
The items on these would just not display to people not suitably close to them. And mostly are a way for players to facilitate showing off their personal Stuff, which is something one imagines they'll probably want to do.
 
As a wild conjecture, I'd approve of globes of planets and models of player constructs, generated somehow from in-game data, as ideal decorative items to slot into such elements.
 

 

Hello everyone, in case you missed the tweet Hrafnkell Oskarsson has joined the NQ team to work on Dual Universe. His LinkedIn says his new job is Executive Producer at NQ. 
 
Some might recognize his name from EVE Online. If I understand it correctly this man was an original game designer for EVE. 
 
I think this is very exciting news for DU. 
 
 

For reference, Hrafnkell Oskarsson worked at CCP for over a good decade of Game Design on Eve Online since 1999, 3 years of game design on World of Darkness (failed CCP MMO), and a good year of writing lore on Eve Online.

I believe he is a fantastic addition to the team.

If you have a newer Nvidia GPU, I would suggest you use Shadowplay, so you can press a button to save the past 5-20 minutes of action at any time, with pretty decent video quality for the most part (if you set the maximum bit-rate allowed in the settings).
 
However if you don't have access to Shadowplay, I suggest recording with OBS. You can configure it to function similar to shadowplay, easy to figure out with google for the most part.
 
Once you have your recorded footage you will want to use 'Handbrake' to encode it into a smaller file-size without noticeable loss in video quality. You need to do this if you are recording with Shadowplay as the files are, while compressed with your onboard H264 chip, still massive. However if you're using OBS, you can configure the encoder to already compress the footage to a reasonable size for editing/uploading.
 
If you want crystal-clear 1080p footage, use OBS. If you want general gameplay video that's good enough for YouTube and doesn't have a very noticeable impact on your system performance and game-play experience, use ShadowPlay.

If you have a newer Nvidia GPU, I would suggest you use Shadowplay, so you can press a button to save the past 5-20 minutes of action at any time, with pretty decent video quality for the most part (if you set the maximum bit-rate allowed in the settings).
 
However if you don't have access to Shadowplay, I suggest recording with OBS. You can configure it to function similar to shadowplay, easy to figure out with google for the most part.
 
Once you have your recorded footage you will want to use 'Handbrake' to encode it into a smaller file-size without noticeable loss in video quality. You need to do this if you are recording with Shadowplay as the files are, while compressed with your onboard H264 chip, still massive. However if you're using OBS, you can configure the encoder to already compress the footage to a reasonable size for editing/uploading.
 
If you want crystal-clear 1080p footage, use OBS. If you want general gameplay video that's good enough for YouTube and doesn't have a very noticeable impact on your system performance and game-play experience, use ShadowPlay.

Without a monetary commitment, there is nothing stopping people from remote countries on breaching the NDA. It means nothing to get your forum account banned when you haven't put down real money on it. It would not work.
 
Currently breaching the NDA means your account will be banned within 15 minutes or less, and all the money put towards supporter packs will be effectively void. This is what effectively enforces the NDA.

Whole-heartedly agree. Aesthetic delays between menus are rage-inducing. I can literally feel my time being wasted having to sit through the same thousands of menu transitions in warframe. 

I spent some time as a UI developer and intend to in the near future, and one aspect of this video had me slightly wary: 

My concern is with the responsiveness of UI elements. It's been proven by studies (and anyone that has used any bad UI for an extensive amount of time will tell you) that added delays of over 100ms between interaction and response leads to user-input frustration. As displayed at 0:07 pressing b opens a menu, however it does so slowly, sacrificing usability for an entirely aesthetic animation. At the very first time you use something slow but pretty you'll think it looks good, but after the 10th time you'll notice it could be faster, and the 100th you'll be frustrated. Same goes for the options highlighting at 0:28. 
I'm not saying that everything in the game is like this, but simply giving a warning that UI development with little regard to responsiveness will give a bad user experience. So please head this and make sure you aren't intentionally adding delays of over 100ms just because it might look pretty. Making a user interface have a responsive design is critical to how users perceive it. Thanks for your time.

The devs published few tutorials in November and December, plus one devblog in November.
 
If not already done, you should look at their youtube channel: https://www.youtube.com/user/dualthegame

Hello,
 
From this topic:
 
... I followed the link to the event to https://www.eventbrite.com/e/novaquark-open-doors-event-dec-2017-evenement-novaquark-portes-ouvertes-tickets-40138804244 but cannot find where to register for it (I have created an account).
 

 
The website says that "Sales Ended", but it was only announced for one hour... Are all the places already sold !?
 
Regards,
Shadow

I received an email notification for this forum post.
 
I hope you understand why I dislike you twice now.

I received an email notification for this forum post.
 
I hope you understand why I dislike you twice now.

1) Yes, it will float. Same as Minecraft or EQ Landmark. 
2) Yes, as long as they are still linked to the construct. Though in the video that was a static construct so it wouldn't have propelled that construct, but a dynamic construct yes. 
 

Absolutely they can. You just need to use relays with multiple inputs and outputs to wire things recursively.
 
Look up Minecraft redstone circtuis. It's basically the same concept as these logic gates, albeit simplified a bit since the logic is not based on minecraft block mechanics.
 
What you're looking for is a Memory Circuit, such as a NOR Latch.