Dinkledash

I wouldn't say your hypothesis is entirely correct. If I were running a business, and random strangers were willing to throw even more money at my business just because they want to, then why the hell not give them the option to do so. It only gives NQ more leverage in the long run with future investors etc. it doesn't mean they are short on money. But we can jump to conclusions all day if we wanted, except I really don't want to.
 
Patience, just have some patience. 

The most important ships to build in the beginning will be prospectors designed for the home planet.  I don't know if we'll be able to mount scanners directly on ships or if we'll have to get out of the ships in order to scan.  The design of the ship will depend on the range of the scanners if they are ship mounted.  We may also be able to build drone-mounted scanners so you get to a location then you deploy your drones and they run a pattern around your ship and draw a map for you... a lot will come down to the instrumentation we can build, the capabilities of the elements and so forth.  I know that mining itself is going to be a human-only activity as they don't want to allow ships or drones do it since that would result in planet-wide devestation.  
 
If we have the option of refining ore using a ship-borne refinery, we may have a prospector-refinery design so we don't want to fill our inventory with unrefined resources.  I know that we store resources in our nanopacks but I don't know what the inventory capacity will be.  Maybe we'll have room for a whole day's mining on our back.  Maybe your inventory fills up after half an hour and you need to head back, in which case having cargo capacity on your prospector ship will be very valuable.
 
I've read that there will be different scanners for different materials.  If these can be mounted shipboard, it may be convenient to have the full array of scanners available in the ship.  It may be that a crew of prospectors need to work together, one on each type of scanner, which would result in a much larger ship.  Or maybe we'll be able to script the scanners together so they fire in sequence and we can build a scanner map showing different kinds of resources.  We may want a ship to run the scans then land and send out vehicles with their own cargo capacities that the miners drive to their targets while the ship moves to scan the next hex.  
 
It all comes down to the business rules are for scanning for, mining, refining (if needed) and storing resources, and what elements are available.  Will we know the depth of the resources when we detect them?  Will there be deep resources that we have to dig down to even be able to scan for?  Will we have to have ships that can drop off a mining camp with basic defensive systems, then run back to base to fill up with security forces, then return with a load of ore... so the ship may not be specialized at all.
 
Basically I'm saying what's important in my philosophy as a designer and scripter will be building vehicles that respond to rules, conditions, economic realities and the military situation.  I think it's important to consider what will be possible and come up with some basic ideas for a variety of conditions so that as we discover the rules, capabilities and conditions, we'll be in a position to come up with efficient and cost-effective designs.  I'm going to want to be able to quote a Return on Investment for the equipment I design, for example, so that people will know what they're buying. 

1) CvC
2) Survival - colonization without a survival element seems rather less of a desperate situation than it should be
3) Alien/hostile biomes which require life support/terraforming
4) Animals - livestock, alien and bioengineering
5) Weather - very difficult but would greatly enhance immersion
6) Moving parts in elements
7) Player customization
8) In game voice
9) Emotes and gestures

I believe membership in organizations and the appointment of legates are ultimately under the power of the founder, so unless the founder voluntarily shares or surrenders control, all organizations are autocracies at the moment.  And I'm sure if there are additional options made available in DU for organizational, er, organization, the founder would have to approve that transfer to a new organizational model.  Even if legates are able to accept and eject general members, I don't see any way they can do the same with other legates.
 
That raises the question, what happens if the founder stops playing?  If the founder fails to log in for several weeks and doesn't return messages from the other legates or members, will DU transfer control of the organization?  To whom?  What if there are no other legates?  Will organization assets be eternally frozen in their accounts?  Will the RDMS for objects managed by the organization be forever locked?  
 
I hope that NQ has a plan to address the maintenance and inheritance requirements of organizations and provides alternative governance models.  I could imagine different models such as Monarchy, Republic, Democracy, Syndicalism, Corporation and Dictatorship having advantages and disadvantages in terms of stability, as well as the satisfaction of the membership in terms of participation in the government.  Once the RDMS is in place, we may see Republics and Democracies appearing, as well as the existence of Boards of Directors for corporations, but unless NQ wires control of the organization and its assets to the RDMS, whatever gets voted on can be rejected at the whim of the founder and the only choice members would have would be to vote with their feet.
 
Developing business rules for civil wars could be very interesting too, as well as regional governments at the planetary/system level, or even at the city level.  It all depends on how big things get.  I can't see one person effectively managing the affairs of a 10,000 member organization.

Hello everyone!
 
Can't believe I missed the Kickstarter.
 
Well I've been waiting for a game like this for a very long time. From back in 2007 when I first got wind of Infinity:TQFE. I have since lost all hope in that game when they scaled back to just doing the Battlescape.  I can get that from many other space sims that are more fleshed out so to speak.
 
So now I'm here with my hopes up again as I greatly enjoy Minecraft and Space Engineers. 
 
See you around!
 
-Roninmizu

How would the game engine know if someone has a reason to attack someone else or whether that reason is a good reason?  Maybe the reason is he doesn't like the color of his helmet, or maybe it's because they're both running to stick a claim beacon in the same resources-rich hex.  Or maybe they had a nasty argument in a bar.  What reason is good enough for wanting to kill someone if not self-defense and how could a game engine determine criminal intent?  If someone is aiming a weapon at me but hasn't fired yet, am I allowed to shoot first?  
 
If he wants emergent politics, I think he has to allow emergent law and order as well.  He'll do what he wants of course, but I think safe zones and arkship AI-enforced property rights are a sufficient foundation for civilization.  Beyond that, if the AI is setting and paying bounties for the bad guys, then the AI effectively is the government, and I don't think he wants that.  By definition, a government is the only entity allowed to legally employ violence for any purpose other than self-defense.  Any organization that can only do so under conditions determined by the AI godmind won't be a government.

I'm thinking the inertial dampers would consist of some kind of quantum technology that generates a field inside the hull of a ship that bleeds kinetic energy from the objects inside the field at a molecular level by absorbing Higgs bosons or some other subatomic plot device.  A liquid filled interior would certainly dampen the effects of inertia but the added mass would make every ship wallow like a barge filled with lead.  

In-game News?

If the Devs allow for HTML5 integration for scripting surfaces and javascript integration for adding Widgets linkingto predetermined sites on the internet in-game, we can get something like a screen playing certain player's Youtube Channel with the flip of a command and see the latest news reel of the day, or watch some tutorials or discussions or podcats in-game.

It would certainly add a lot of meta-game in the mix, as well as a place for a person to call home and a home without a TV, is not a home.

I mean, sure, you can have a terminal you use in-game to access the market on the area, but it could be used as a screen as well. 

Perhaps even having a faction having their propaganda reel playing on a loop in a giant screen in the mddle of the town. Who knows. If they add the ability to link youtube videos in-game, this could go anywhere

Already done brother, was just hoping for an early Christmas. :-)

Click the Notify Me button to sign up for the newsletter.  You'll be informed when the PayPal option comes on line.
http://www.dualthegame.com/

The most important ships to build in the beginning will be prospectors designed for the home planet.  I don't know if we'll be able to mount scanners directly on ships or if we'll have to get out of the ships in order to scan.  The design of the ship will depend on the range of the scanners if they are ship mounted.  We may also be able to build drone-mounted scanners so you get to a location then you deploy your drones and they run a pattern around your ship and draw a map for you... a lot will come down to the instrumentation we can build, the capabilities of the elements and so forth.  I know that mining itself is going to be a human-only activity as they don't want to allow ships or drones do it since that would result in planet-wide devestation.  
 
If we have the option of refining ore using a ship-borne refinery, we may have a prospector-refinery design so we don't want to fill our inventory with unrefined resources.  I know that we store resources in our nanopacks but I don't know what the inventory capacity will be.  Maybe we'll have room for a whole day's mining on our back.  Maybe your inventory fills up after half an hour and you need to head back, in which case having cargo capacity on your prospector ship will be very valuable.
 
I've read that there will be different scanners for different materials.  If these can be mounted shipboard, it may be convenient to have the full array of scanners available in the ship.  It may be that a crew of prospectors need to work together, one on each type of scanner, which would result in a much larger ship.  Or maybe we'll be able to script the scanners together so they fire in sequence and we can build a scanner map showing different kinds of resources.  We may want a ship to run the scans then land and send out vehicles with their own cargo capacities that the miners drive to their targets while the ship moves to scan the next hex.  
 
It all comes down to the business rules are for scanning for, mining, refining (if needed) and storing resources, and what elements are available.  Will we know the depth of the resources when we detect them?  Will there be deep resources that we have to dig down to even be able to scan for?  Will we have to have ships that can drop off a mining camp with basic defensive systems, then run back to base to fill up with security forces, then return with a load of ore... so the ship may not be specialized at all.
 
Basically I'm saying what's important in my philosophy as a designer and scripter will be building vehicles that respond to rules, conditions, economic realities and the military situation.  I think it's important to consider what will be possible and come up with some basic ideas for a variety of conditions so that as we discover the rules, capabilities and conditions, we'll be in a position to come up with efficient and cost-effective designs.  I'm going to want to be able to quote a Return on Investment for the equipment I design, for example, so that people will know what they're buying. 

Inertial dampers are also used in the Jack Campbell books.

"Flip and Burn" and "Speed Matching" will need to be scripted for each ship. Since ship mass and thruster placement are important, there's no way for anyone to know how the ship will fly, but the ship builder.

Dunning-Kruger was inspired by a study about a bank robber who thought that lemon juice would make his face invisible to security cameras because it's used as invisible ink.  To go straight to the Dunning-Kruger effect is to assume that this guy is in the bottom quarter of the general population IQ-wise, which seems a bit much.  It is true that nobody here knows your education and experience in gaming and game development.  Would you care to provide us with your credentials?  
 
I'm a software engineer with 17 years on the job and in my opinion, while realistic collisions would certainly make for better cinematics, there's a lot more to calculate than a simple bounce when two collision meshes intersect, and based on my experience in big data cloud environments (medical IT, not gaming), nobody can know what the server load would be unless we actually simulated 100,000 simultaneous collisions.  And the amount of coding to get there would delay a lot of other deliverables, so it would be a considerable risk.
 
The developers also said they don't want people creating ramming ships that are kamikaze'd into exquisitely engineered, well designed constructs because they think that would make the game a lot less fun, and that would make people stop paying for subscriptions, so in that regard, this is as much a business decision as it is a matter of judgement in design.  Even if characters didn't resurrect, there would still be a problem where players would create new characters who's reason for existence is to drive an iron brick with an engine and a cockpit into another ship while yelling "Leroy Jenkins!"  
 
This is a management-level decision as much as a design decision, and I really don't think this hill is worth dying on.  Collision damage would be fun, but so would weather, planetary rotation, agriculture, animals, alien biospheres, a survival system, a FPS aimed combat system and a hell of a lot of other things we're probably not going to get until later, if at all.  I'm not saying collision damage would be bad, or it couldn't be made to work, but computer science is partly the art of giving up something you want in order to get something else you want more.  Is collision damage the most important thing to you?

You are correct, however..from what I understand, you might miss if your targeting stats aren't as high as the opponent's evasion stats. I could be wrong, but that is how I understand it.

I can make a case that the OP is trolling
 
The status of the game is everywhere if someone took 5 minutes to look.

Consider the w,x,y,z coordinate of each person (w being the quaternion variable for rotation), you would only be able to provide the location of something like 15 clients PER TICK when using a 508 byte packet (the largest IPv4 packet that is guaranteed not to be fragmented).
 
Accounting for 1000 players would require 66 ticks to successfully be transmitted.  And this wouldn't account for dropped packets.  That means that each player position would be updated ONCE a second at 60 ticks/sec.
 
This doesn't account for anything other than positioning packets.  Any other type of packet will add to overhead.
 
To optimize this, JC has already indicated that players closer to you will be tranmitted more frequently, while those far away could update more slowely.  Possibly once every 2-3 seconds.
 
So, what needs to be done is to create a stream of packets.  This stream would look at queues of information and transmit that information according to priority, by filling that 508byte packet with as much information as possible. 
 
So you would have queues setup something like this:
 
Critical -> Transmitted immediately
HighPriority -> After Critical
PositioningClose -> Filling in the remainder of the 508 bytes after HighPriority
PositioningMedium -> Every 5 ticks or some other algorithm
PositioningFar -> every 10 ticks or some other algorithm
LowPriority -> every 60 ticks or some other algorithm
 
Say there are 60 players in PositioningClose, and no Critical or HighPriority "chunks of information". Packets 1, 2, 3, & 4 would be required for all positions to be updated.  If there were no other players, everyone would update approximately 15 times a second.
 
But once you add more players and start adding critical events, that positioning would be updated much less frequently.  That's where "Client Side Prediction" comes in.
 
If this were a shooter, there's no way, that many positions could be updated quick enough to provide a smooth an acurate transition.  But since this is tabbed targeting, it's not a problem.
 
Remember,  the bottleneck is not usually the server side.  It's the clients bandwidth.  Does the client have to acknowledge each packet?  Probably not.  If positioning data is incorrect, or not received it will receive a newly updated packet shortly.  The client just continues to use "client side prediction" to account for the lost packet.  And the server infrastucture "shouldn't" be the problem if it's designed properly.
 
As you can see... The server guy has his work cut out for him.  He could risk larger packets, at the risk of fragmentation.  Or he could use some other solution.  But at the moment, even the high end FPS shooters are only transmitting at 60 ticks/sec.
 
(btw.  This analysis is based off of gafferongames.com)

https://www.dualthegame.com/technology#cssc
 
"This involves what we call "Dynamic Space Splitting", server nodes are assigned to regions that are more densely populated, and these change the frequency of updates of remote entities to maintain a fluid experience for nearby entities."
 
As a database software engineer, this is what I'm getting from this:
 
When there's sufficient density, players will have a "primary" node assigned to them for rapid updates for them and anyone near them, so if you have 20,000 people in a city, everyone in that city will be on a single rapidly updating database instance.  That data will be replicated to all other nodes, but those updates will be less frequent than the "focus" instance for a given cluster of players.
 
Say that the fleet of 2,000 players on instance ABC123 is jumping into a system where the players are focused on instance XYZ789.  As they pass through the jump point (or their FTL drive brings them into proximity) their client machines will start sending updates to instance XZY789.  The last thing ABC123 hears from them is that they have moved out of that cluster.  
 
After that, ABC123 will still hear about the players in the fleet, but they'll hear about it every 5 minutes as a job replicates all updated data from all nodes on the continuous shard to all other nodes as opposed to updates from the focused clients which happen every 10 milliseconds or so.
 
Presumably there will be a designated failover node for any given node on a different physical server, so one of the non-focus instances is getting updates perhaps every few seconds rather than every 5 minutes.  If the focus node fails, the clients get a blank screen for a few seconds as they reset to the failover server and pick up where they left off.
 
It's a guess but I think it's a fairly educated one.

Well, from what I have learned this is new tech that they have been working on for years before they even started working on the game itself.  I doubt any of us would know too much about it except what they tell us at this point.  I have faith.  They don't seem like liars to me, so until they prove that they actually are, I will choose to believe it is possible.  Somebody is going to figure it out some time, so why not these guys?

I think you are right.  While most of us here can certainly wait until the right time to get CVC, not having it at launch will do nothing to entice new players into the game.  So it might be a slow start.  Hopefully they will have a lot of marketing planned just for the release of that expansion - as much, if not even more, than the actual live release.  
 
And I am also concerned about all of the more casual players who get used to living in relative peace in safe zones who will fight CVC once they start talking about launching it.  It will change the game and many will already be comfortable with how it is and will do their best to try to talk the Devs out of adding it in.  Seen it happen before.  
 
I'm in for the long-haul either way.  If this game ends up being half of what they plan on making it, I'll probably be very happy with the game.  I just hope the Devs don't buckle under pressure when the outcry comes. Seen that happen before too.

(Posted Friday 18th of September 2015 on the DevBlog)     Big news! We just finished designing and implementing one of the most critical and distinguishing feature of Dual: the capability to script any construct that you make. A construct is anything that you build in the game, it can be a ship, a building, a space station, or whatever. It is a physical object, it can move, collide with stuff and potentially include hundreds of "Elements", which are operational units that you can craft or buy, and freely position inside your construct to add functionalities to it. Examples of Elements are: propulsion engines, control units (computers), doors, weapons, batteries, containers, accelerometers, radars, targeters, drone bay, elevator, and many more. The way the construct orchestrates all these Elements is through scripts, and what we call "Distributed Processing Units". Let's dive into it, and see what it can do.   Warning: The following Blog Post implies you already have some basic programming knowledge. If you don't, some parts may seem a bit obscure or difficult to understand.   This is going to be a slightly more technical and longer post than usual, but I hope people interested in the topic will find it entertaining. In any case, remember an important point: you don't need to understand anything about scripting or ship building to actually buy a ship and fly it. You actually don't even need to use a ship at all if you don't want, there are plenty of activities to do besides this in the game. It's a bit like in real life: you don't need to be a mechanics to drive a car, and some people just never drive anyway, they take a taxi. It all depends on your playing style, and what you expect from the game. But if you are interested in creating your constructs and scripting their behavior, I hope you won't be disappointed by the deepness of the gameplay experience we propose.   So, let's summarize again what a "construct" is: in Dual, you can assemble chunks of matter (stone, wood, iron, kevlar, etc...) in any way you like, a bit like in Minecraft, but instead of simple cubes, you can forge almost any shape you like. The technology behind this is called "Dual Contouring". This can be used to build the hull of a spaceship, the walls of a castle or a gigantic statue. Up to you. Attached to this inert structural skeleton, you can add some components called Elements, which are actual gameplay components that you can deploy in your construct to make it functional. In a spaceship, you need propulsion engines, fuel tanks, navigation instruments, one or several cockpits, etc. All of these are Elements. The collection of all Shapes and Elements are what constitutes a construct, which is a whole that can be moved once created and is subject to the laws of physics (for example, it falls if dropped in a gravitational field). A construct can be owned, traded, copied, etc, but this is another story we will discuss in another post. Right now we will concentrate on one particular aspect: how do you orchestrate all the Elements so that they can work together? We will take the particular viewpoint of a spaceship, which is a good way to illustrate the concepts involved, but this can apply to anything you like, including a giant spaghetti monster robot or whatnot.   In terms of game design, we could opt for an easy strategy here. If you have the required number of engines in the right direction (no matter where they are), and you check the list of instruments needed, it would "magically" fly. With this approach, all ships would fly the same. Trying to put more engines, or optimizing their position would be more or less useless. Hoping to have an AI helping with automatic navigation would be up to the engineers of Novaquark only. Fancy a new way to drive your ship? Impossible. How about the weapons system? How about drones? All this would be predefined and more or less rigidly identical for all players. That's not what we have in mind for Dual Universe. While we will provide basic templates to start with, you?ll be able to engineer your construct the way you want. Engines are real (they physically push your ship where they are, with the power they have), gravity is real, weapons have to turn and target (which also requires a targeter). If you are smarter than others, you can get the job done in a better way, get an edge in battle, or in trade by launching the new Falcon X-42 superfighter and change the balance of game combat with new tactics and possibilities. It?s not only about how you can use the predefined capabilities of ships within a predefined classical game setting, but it?s also about how you can redefine these capabilities. We call it: emergent gameplay.   Each Element is an active unit. It can do basically two things: emit "events" and execute "functions". Let's give some examples: a radar unit can emit events like "new enemy detected at (x,y,z)", a jet engine can execute a function like "set thrusting power to 45%", a weapon can execute the function "fire", etc. Technically events and functions are described a bit the same way: a name followed by parameters written between parentheses. The above examples would become something like:   enemyAt(x,y,z) setPower(45) fire()   Events are emitted spontaneously by the Element when something happens for which it has been designed to react to, and functions are services that the element can fulfill when it is asked to by some external agent. When considering a particular Element, you want to know the list of events it can emit and the list of functions it can fulfill. This is entirely defining what this Element is, from the point of view of the gameplay. We call it its "Type".
  Now, how do you orchestrate the interactions between several Elements, each emitting events and reacting to them, fulfilling functions in return, etc? The central notion we introduce here is what we call a "Distributed Processing Unit", or DPU in short. A DPU is a bit like a computer program, an orchestrator. It has several slots in which it is possible to plug Elements, and it contains a list of event handlers that can react to events emitted by the Elements plugged inside its slots. The schema below illustrate this:     Events handlers are conceptually quite simple: they are "condition => action" managers. On one side, there is a conditional filter, which is a generalization of an event from a given slot, with certain parameters set to given expected values, while other parameters can take a variable "free" value. A particular event emitted by an Element in a slot will be examined by all event handlers, and it will trigger the event handlers if the event signature matches the event handler filter.   To give an example: suppose that we have a filter like ?enemyAt(x, 42, y)?, associated to the ?radar? slot. Now the radar slot emits the event ?enemyAt(11,42,66)?. This event matched the filter and so will trigger the event handler. If the event ?enemyAt(12,13,66)? is emitted however, it will not match the filter (because 13 is not equal to 42). The schema below illustrate this point:     On the other side of an event handler is the action that the handler can trigger when the filter is matched. This is where LUA really enters the scene. The action is simply a piece of LUA code. LUA is a very simple and efficient scripting language, for which you can get many tutorials online. You can try this for a start.   Now what kind of code will you write on the LUA side? Basically anything you want, but, as you guessed, it will ultimately contain some calls to functions among those provided by the Elements plugged in the DPU slots. The syntax will be something like: "self.engine2.setPower(42)". The "self" prefix is a requirement of LUA, then comes the name of the slot, and then the name of a function available from the Element in that slot, together with its parameters between parenthesis.   That's it. That's the basics of what a DPU is and how scripting works. Let me summarize: a DPU is an orchestrator, it has several slots in which you can plug Elements. You can then define event handlers to catch events emitted by these plugged Elements, and react by executing LUA code, which includes calls to functions taken amongst the set of available functions of your plugged Elements.   To be more precise, I have to refine this picture a little bit: I talked about customizing a DPU, but exactly what DPU are we talking about? Where is it? In fact, the DPU you want to customize is stored inside a special Element called a "Control Unit". The DPU is started when you activate the Control Unit (go next to it and press the activation key). Notice that there is no problem with having several Control Units (hence, DPUs) inside the same construct, potentially all activated at the same time.   Now, the DPU inside a Control Unit is special because you'll have a GUI to freely customize it (plug stuff into the slots, define event handlers, etc). Actually, you can do even more than what I just described: you can define a set of events that your DPU is capable of emitting (event emission is done via a special LUA syntax inside your scripts). You can also define a set of functions associated to your DPU, and the corresponding LUA code that should be executed when this function is requested. If you remember, I presented the type of an Element as the set of events and functions exposed by this Element when plugged inside a DPU. Actually, the truth is that there is in fact a DPU inside each Element (albeit not a customizable one), and the events and functions of this Element are actually the events and functions of its DPU. Now to the important conclusion: it is not really Elements that you plug inside the slots of your Control Unit's customizable DPU. It is in fact DPUs. It can be the DPU of Elements, when you plug Elements, but it can be more generic or abstract DPUs. More about this now.   One particularly important "abstract" DPU is the System DPU. This DPU is capable of emitting events when keys are pressed. You almost always want to plug the System DPU, because you want to control your scripts with keystrokes bound to actions. So, typically, you will have several event handlers in your custom DPU to catch action events emitted by the System DPU. The System DPU is also capable of emitting "timeout" events when a timer is due, or at regular intervals, and many other useful functionalities.   You know enough now to script a simple spaceship controller. You need to put a least one Control Unit in the ship, and customize its DPU. Inside this DPU, you will plug the System DPU (typically in the "system" slot), plus at least 3 engines pointing upwards to lift the ship, and 2 more engines at the back of the ship to make it move forward. You need also to plug a gyro (more exactly: an inclinometer), which is an Element that provides the getPitch and getRoll functions, to know about the pitch/roll angles of your ship. And that's it. Now you set a timer with the system DPU (call the system.setTimer(0.1) function to set the update every 0.1 second) and catch the corresponding timeout event. When caught, you can then associate the LUA script that will query the gyro about the pitch/roll and use these values to correct the intensity of thrust power in your motors (using the setPower function) to stabilize the ship tilting. And of course, you will also catch the action events from the System DPU to inform your script about the direction in which the player wants to stir the ship. The exact details of how this is done in terms of control and dynamics are beyond the range of this post, but it involves simple Newtonian physics about torques and forces.   This above custom made Control Unit DPU could be seen as a black box, a ?Stabilizer?, with 7 slots (5 engines, 1 gyro and the System DPU). You can move this black box in what we call a Component DPU, so that you can sell/exchange it. Now players possessing your ?Stabilizer? can plug it in their own Control Unit DPU along with their own Elements, and then connect these Elements in the Component slots, with a simple drag and drop interface, or a smart ?autoconfigure? system, making the whole process of scripting a ship very simple for those who don?t want to put their hand on code:     The DPU system goes ways beyond this simple ship stabilization example. Weapon control, whether in FPS direct view on a jet fighter, or in tactical overall view in a battleship, will be handled with DPUs. Scripting a drone can be done with DPUs. Setting the automatic defense mechanism of your castle can be made with DPUs. Factories can be automated with DPUs, etc. It's all about orchestrating Elements and Component DPUs via scripts that react to events and execute LUA code. The user interface is also scriptable to decide what happens when the Control Unit is activated, how Elements can display their status and give access to parameters (we will probably talk about this in another blog post).   Novaquark will be providing several useful "starter" Component DPUs to start with, as well as smart autoconfigure options to handle the most basic cases. You can get a ship to fly without knowing a thing about DPUs. But, if you are interested in this aspect of the game, it will be up to you to build from there and create the most amazing control system and contraptions, win the markets or the wars with them and leave your mark in the Dual Universe history of innovation and engineering!   JC Baillie, Project Lead.

Yeah I'm holding back on the cosmetic designs of my ship till I know exactly what a practical ship design will be. Right now I've got a rig ship sketched up (for space trucking ) but its a very basic, boxy design atm. Essentially It's just a sketch up of the basic ship they've shown with a cargo container on back which I've planned on placing our nano pack containers in. Also drew it with a quad engine with 2 fuel cell setup since I figured the added weight would need an extra push. This is all based off that ship building teaser I saw so I'm sure there is plenty of room for design improvement. Like I said though I wouldn't fall in love with your cosmetics for the ships till we have a better idea of whats capable. Wouldnt want the vehicle to move like a brick because of a few fancy prongs sticking everywhere.

Is it worth playing around with Space Engineers waiting for DU alpha to start up?

There will still be Avatar vs Avatar combat, and there is a strong likelihood that avatar weapons will be able to damage constructs. Combat is going to be very STRANGE, but there will be combat.
 
The biggest implication this has for me, is that as a builder we won't be able to really develop fighters until after the game has already been released. If avatar weapons can damage constructs, we may be able to build ships and structures that allow players to shoot from them at other constructs. For example, a fighter with a machine gun nest built in, where a 2nd player fires through gaps in the fighter's armor at other ships, or a bunker with firing slits.
If avatar weapons can damage constructs, than a ship could have its weapons disabled, and be subject to a boarding action if it is a large enough construct for it to have a control center.
 
But when proper CVC gets implemented, there will be a development frenzy of builders retrofitting existing constructs to allow for weapons. It will prevent alpha and beta players from having an advantage in holding military blueprints through wipe, and will dramatically alter player behavior at launch. There won't be an arms race (apart from avatar weapons), instead each org will be racing to get infrastructure in-place for producing military constructs, stockpiling resources, TU's, etc.
 
That notion is kind of exciting and could be used to build hype for release. Everyone will have an opportunity to get "set up" before it all hits the fan.
 
But again, they might raise enough funds through paypal to hit that goal post-kickstarter regardless.

I agree but i fear this will scare off new players from joining.
 
A space sci-fi game without space combat sounds crazy even if it has advantages.