NQ-Nyzaltar

Hi Kongou,
 
Character Avatar Design is something we consider as very important.
We can't give you many details on it right now.
But we can already say that:
 
As the team is currently working on photorealistic in-game environment, in order to have a consistent artistic direction, characters can't be cartoonish or even semi realistic. This wouldn't match with the work in progress. It's still too early to present you anything relevant about character avatars, but as soon as we'll have something, be assured that you will be among the first to know, if you follow us on Twitter and/or Facebook (or if you keep visiting regularly our forum  ) 

Not necessarily with Dual Contouring.
But I think it will become clearer when we will show you some screenshots

Hi Kiklix!
 
You're totally right. The smaller the voxels are, the more performance issues you have.
We had to make some tough choices, and we think we have come to a good compromise:
- Voxels on any planet will have a size around 100 centimeters.
- Constructs made by players will be composed with 25 centimeters Voxels permitting better precision.
Granted, this is still bigger than Landmark, but in exchange you have mobile constructs 
And for the planets, well, you will have some up to 100 km radius (which means a bit more than 125 000 km2 !)

@ Saffi:
 
All our condolences for your loss
 
To answer to your questions, there will be indeed a name for the game account, and a name for each of your characters. For security reasons, it might be impossible to have the same name for the account and for one of your characters. We can't tell you yet what will be the limitations in terms of character naming freedom. But if we can go with one surname (or even two) and a family name for each character, that would be ideal indeed. I'm adding this to the list as an official suggestion, to avoid seeing that forgotten along the roadmap.
 
Making an Imperial Senate will be possible, as long as enough players are interested to make it real. We will provide the tools to build it through the organisation system but it will be up to the players to design the rules running in this political organization.
 
@Ellegos:
 
Nice blog post!
 
Indeed dictatorships in games where PvP has a deep impact on the world/universe (changing frontiers, controlling territories, changing the landscape, etc) seem to be the political system the most widely used. But we want to let players complete freedom about choosing, building and/or improving the political system they want. And who knows? Maybe someone will invent some sort of democracy efficient even in time of (virtual) war?...

About color customization on existing textures:
We would like to implement it, we are looking into it

 

About the possibility of uploading an organization (clan/corporation/guild/alliance) emblem after having gone through a validation process:
This would be a much lighter process than allowing the upload of new textures. So there are a lot more chance for this to be accepted.

I will keep you informed on this matter!
 

Hi Kongou,
 
Character Avatar Design is something we consider as very important.
We can't give you many details on it right now.
But we can already say that:
 
As the team is currently working on photorealistic in-game environment, in order to have a consistent artistic direction, characters can't be cartoonish or even semi realistic. This wouldn't match with the work in progress. It's still too early to present you anything relevant about character avatars, but as soon as we'll have something, be assured that you will be among the first to know, if you follow us on Twitter and/or Facebook (or if you keep visiting regularly our forum  ) 

Hi Kiklix!
 
You're totally right. The smaller the voxels are, the more performance issues you have.
We had to make some tough choices, and we think we have come to a good compromise:
- Voxels on any planet will have a size around 100 centimeters.
- Constructs made by players will be composed with 25 centimeters Voxels permitting better precision.
Granted, this is still bigger than Landmark, but in exchange you have mobile constructs 
And for the planets, well, you will have some up to 100 km radius (which means a bit more than 125 000 km2 !)

As Comrademoco stated, technically, nothing will prevent you to build giant mechs
About the limits of ingame programming, I can just tell you for now that all the coding allowed will be in LUA and should limited to automatize some basic things (like elementary AIs for droids, autopilots for spaceships, automatized defense systems and such things). More on this matter will be revealed in the future

@TheSlaxx:
Thanks for pointing all these typo/errors
As we are planning a new version of the website, all the corrections will be implemented in this new version
Thanks again for the help!
 
@Silvligh:
About procedurally generated flora, just to be 100% clear:
It's the way flora is spread on a planet surface that is procedurally generated.
The flora species aren't procedurally created (though we might think about that in a distant future, but it's not on the roadmap for the time being).
I hope there wasn't any misunderstanding here.
 
Best Regards,
Nyzaltar.

Hi everyone!
 
@TheSlaxx:
About the typing errors in the FAQ and Dev blog, could you point me where you found them?
That would be really a huge help. I will correct this as soon as possible.
Thanks in advance!
 
@All: 
About the forest screenshot:
As said in another thread, this is what we aim for as the graphics quality goal to reach, as it is technically possible.
But keep in mind that we might have to lower a bit graphics to make the game playable, with a decent FPS, especially for VR.
Voxel-made planets and landscape procedurally generated on a large scale (the forest example was procedurally generated on a small scale) are already two factors that impact significantly on the FPS. We might prioritize FPS over ultimate graphics. But that doesn't mean we drop the ball: we will do our best to have a smooth FPS experience and good graphics! 
 
@TheSlaxx & Vylqun:
 
If we got a forest for now, it's just because this is one the basic biome you can encounter and easily reproduce (along with desert and polar biomes) as we already have examples on Earth. However, it is also planned to have more alien-like biomes
 
Best Regards,
Nyzaltar.

@TheSlaxx:
Thanks for pointing all these typo/errors
As we are planning a new version of the website, all the corrections will be implemented in this new version
Thanks again for the help!
 
@Silvligh:
About procedurally generated flora, just to be 100% clear:
It's the way flora is spread on a planet surface that is procedurally generated.
The flora species aren't procedurally created (though we might think about that in a distant future, but it's not on the roadmap for the time being).
I hope there wasn't any misunderstanding here.
 
Best Regards,
Nyzaltar.

Hi everyone!
 
@TheSlaxx:
About the typing errors in the FAQ and Dev blog, could you point me where you found them?
That would be really a huge help. I will correct this as soon as possible.
Thanks in advance!
 
@All: 
About the forest screenshot:
As said in another thread, this is what we aim for as the graphics quality goal to reach, as it is technically possible.
But keep in mind that we might have to lower a bit graphics to make the game playable, with a decent FPS, especially for VR.
Voxel-made planets and landscape procedurally generated on a large scale (the forest example was procedurally generated on a small scale) are already two factors that impact significantly on the FPS. We might prioritize FPS over ultimate graphics. But that doesn't mean we drop the ball: we will do our best to have a smooth FPS experience and good graphics! 
 
@TheSlaxx & Vylqun:
 
If we got a forest for now, it's just because this is one the basic biome you can encounter and easily reproduce (along with desert and polar biomes) as we already have examples on Earth. However, it is also planned to have more alien-like biomes
 
Best Regards,
Nyzaltar.

@TheSlaxx:
Thanks for pointing all these typo/errors
As we are planning a new version of the website, all the corrections will be implemented in this new version
Thanks again for the help!
 
@Silvligh:
About procedurally generated flora, just to be 100% clear:
It's the way flora is spread on a planet surface that is procedurally generated.
The flora species aren't procedurally created (though we might think about that in a distant future, but it's not on the roadmap for the time being).
I hope there wasn't any misunderstanding here.
 
Best Regards,
Nyzaltar.

(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.

(Posted Sunday 17th of August 2014 on the DevBlog)
 
 

 
 
We have been asked several times what the actual typical gameplay of Dual Universe would be, how it would be played, in a very practical way. It's of course too soon to give a lot of details about the numerous activities that will be possible within the game, but we thought it would be nice to go through like five typical minutes of the kind of gameplay you could experience on the surface of a planet. To start with, let's talk a bit more about what we have in store for the alpha version, which will be made available next summer.
 
(Update Tuesday 17th of March 2015: The alpha version has been postponed. We will give more information on this subject as soon as possible)
 
In the alpha version, you wake up inside the arkship, which is still on its way towards the planet where you are to establish a new civilization with your fellow colonists. You have been woken up early from cryosleep, because you are a member of the alpha team, a set of special operatives that will be given a pre-training in the basic ways to run your future new life on the new planet, and be able to coordinate actions when the time will come (when the beta will be out). And this pre-training will be done through... a simulation (within the simulation, yes, where does it end?). So basically, you are still in your cryosleep vat and the ship’s AI is plugging you on a sort of Oculus Rift-like super neat simulator and here you go.

You step out of the arkship already loaded with blueprints, materials, skills, etc. The simulation is meant to put you in a situation which would correspond to where you are after a few months of playing and skilling already, so that you, the player, can experience it right away and test the core of the game. Generally speaking, it is a difficult thing to show “the” gameplay of Dual, because we expect that there will be many gameplays possible and, more specifically to the sandbox experience, we expect the gameplay to evolve over time, as players master more and more technologies and expand into the world. Think of it as a sort of live version of Sid Meyer’s Civilization, entirely player-driven!

OK, so you are in the alpha simulation. The game is going to be a FPS, and depending on our budget and time, we will also provide some TPS view, especially in combat. The FPS view is important for immersion and also because we have Oculus Rift and similar devices in mind, so it would not make sense to offer only TPS view in any case. So, looking through your virtual eyes, the arkship stands proud and high in the sky behind you and you are facing a large empty crater that was created by the ship impact, followed a bit further by a dark and deep forest on your left, and a large mountain chain on your right, with white snowy tops. It looks very familiar, the planet’s atmosphere is similar to the one on the Earth, and the cloud patterns you can see in the distance are also recognizable. It’s not exactly like on Earth, but familiar enough. Some planets will look much less friendly than this when you’ll start to explore the universe, but for the moment, it’s OK.

Your first task will be to create a safe house to protect yourself from the cold of the night, as the temperature differences on this planet are much stronger than on the Earth. You got a quick briefing from the arkship’s AI, so you know that already. The arkship can be a protection for a while, but it won’t host a lot of people as the space inside it is limited (all goes to fuel – now empty containers, but not meant to be lived in – and to cryosleep vat support technology. More about the arkship in another blog post). The simplest thing to do is to head for the forest, and get a bit of wood and stone to start building your safe, and create a fireplace inside it for the night.

You come equipped with a very powerful and central tool, rigged right into your arm: the nanoformer. This tool uses incredibly sophisticated nanotechnology to allow you two things: to collect materials and store them in a nanopack (think of it as a super backpack, with space and gravitational compression capabilities), and to release these materials in various forms anywhere you want in your environment. Very convenient! Inside the forest, you have no difficulty to find wood, cutting large trees and gathering stone materials when you find them on the ground. Soon, your nanopack gets filled with various materials and you can start to think about building your first shelter. The process is very similar to Minecraft at this stage, but you will have many more possibilities to carve the structures you want to build into almost any shape. Still, we believe in the simplicity of some elementary geometric shapes, at least as a start, to make the process of 3D construction less cognitively demanding.

At this stage, it is not clear if we will have enough time until the alpha to implement NPC animals to come and bother you during the night, as well as serve as hunting preys. But that’s the idea, because you will need to feed yourself, and the nanoformer cannot make wood-based lunch for you!

The nanoformer can also be used as a very primitive weapon, projecting materials or energy towards your opponent. But nothing really more than a punch in the face. If you want to deal some damage, you’ll need a weapon. It turns out that you have various blueprints in your inventory, which are in fact weapon recipes. All you need to assemble them is to find the raw materials, which means: start mining and digging, Minecraft style! Once you have found the precious ingredients, just set your nanoformer to run a given blueprint and here you go, you can see the item forging itself in front of you. You will also have various recipes for armor, mining tools and various useful items (why aren’t these simply available in the arkship, you might ask? You know the story about telling a man how to fish, rather than giving him a single fish? I think the conceptors of the arkship had this idea in mind!).

I did not talk much about energy at this stage, because it is still under discussion. But the nanoformer, and of course more powerful tools or weapons, will need energy sources. For the nanoformer, it could simply be your body heat, so all you need to do is to (h)eat. We would need to get some serious future pseudo-science to explain that however, because the Watts available will be rather limited!

The next experience for you will probably be to try and build one of the construct blueprint available in your inventory. Like, for example: the hover car, or the balloon powered explorer vehicle, or… the rocket! More about the construct building in another post, but all this will require that you gather more or less difficult-to-find materials, and energy sources. You might want to start a trade post to exchange resources, tools or weapons with other players. Gathering into organizations will also be a good idea, as well as start to claim territories to secure your property. You don’t have to worry about PvP aggression as long as you remain inside the security zone managed by the arkship (see the Arkship security blog post), but if you wander further (about 20km away), you might also start to need to organize your defense and establish an outpost.

Each of these topics probably will be treated in dedicated blog post, so I won’t go any deeper at this stage. To summarize, we’ve seen a very short preview of the FPS style gameplay that will be available in the game: you can gather resources and construct houses, buildings, items. You can also create more dynamics constructs like vehicle or rockets (actually, space ships or space stations, there is no limit in size). We are also thinking about farming and hunting, because you will need food. You can team up with other players, or compete with them, through economy, politics, manufacturing, territory control and a lot of other emergent gameplay elements. One of the challenges we have as we design the alpha version is to find a way to make all these aspects of gameplay easy to learn and quite naturally flowing from the player’s experience. We are working on it

JC Baillie,
Project Lead

I think it's more Silvligh's speculation, as there was no statement about that:
We don't expect all the alpha testers to build corporations. Some will most likely just join existent ones or even be famous "lone wolves"
   
That could be an interesting idea, indeed.
This will be discussed with the rest of the team soon.
Thanks for the suggestion!
 
Best Regards,
Nyzaltar.

Nothing is set into stone yet, but here what we have currently in mind for alpha testers:
While we'll try to avoid giving anything which could become a gameplay advantage, we plan to give something (most probably a cosmetic item) to early testers/backers enabling them to show "yes I was there at the beginning". For now, we thought about an "Alpha Team" outfit.
This is just an idea, and we would like to know what you think about it
 
Best Regards,
Nyzaltar.

How do you intend to go about the colonization process in DU? 
 
 
As Klatu already said above: the process will be managed through Territory Units.
 
 
The goal is not to have all the worlds inhabitated by players.
Players will gather naturally only on the most interesting planets. Other planets will have a low population, just for resource extraction purposes.
 
 
At the moment, there's no NPCs planned anywhere else than the Arkship starting zone (to guide players in their first steps). 
Don't expect to see NPCs popping from nowhere in cities built by players. I had already answered partly this question in this thread:
 
"Social interaction will be at the center of the game. It will be the players who will decide what is considered as an Empire and what is not. If your organization gathers hundreds or even thousands of players and achieve important things in the game, then the organization will likely be labelled as an Empire. If you will be less then ten players in your organization, then you will have a hard time to be considered as an Empire. Not impossible, but very very difficult. Also, even if you will be able to have NPCs (probably droids) helping in automatized tasks, don't expect to have thousands of NPCs under your command."
 
And as said Klatu above: Players won't build cities to leave them as ghost towns afterwards. Players will most likely build only the cities they need.
But we'll see for sure only when the game will launch. Should ghost towns appear, the team will think of ways to adapt to the situation.
 
 
If there is something we are well aware, it's the impact of server location and lag issues. It's always a sensitive topic for single-shard MMO games. We're currently evaluating several possibilities right now. But it's too soon to say "we will go for this solution". However rest assured: we won't forget american players
 
 
For the time being, nothing prevents it, if you have smart enough machines (with a "home made" LUA script) able to use a Factory Unit (as described recently on Facebook and Twitter). However, we might limitate the possibilities on this field, for game balance purposes. But this is still an ongoing internal topic in the team.
 
Best Regards,
Nyzaltar.

Hi everyone!

I'm Nyzaltar, the Community Manager for this Sci-Fi epic adventure known as "Dual Universe"!
If you have any question or suggestion on the game or anything related (forum, website, the team, etc), don't hesitate to contact me.
I will be more than happy to answer!

Also, as many of you, I'm a huge fan of Sci-Fi Themes and a passionate MMO gamer.
Eve Online, Landmark, to name a few... but far from being limited to these.

I hope you will enjoy this forum as much as we, the Novaquark Team, hope!
Also I will be around on the forum during this week-end, to answer topics that have already been posted

Best Regards,
Nyzaltar.
 

Hi Ellegos,
 
About scripting, there will two options for players:
- If a player don't want to be bothered by this advanced aspect of construct customization, he will be able to use pre-made scripts.
- If a player feels motivated to make awesome new scripts then yes, he will have a wide array of possibilities using advanced Units, called DPU (Distributed Processing Unit). All in all we try to find a way to make the whole process more user-friendly without removing possibilities in scripting. But as you can imagine, this is quite challenging.
 
It's still a bit early to talk about it, but you can expect the next Blog Post (in a few weeks) to be on LUA script and the DPUs
 
@Saffi:
While we plan to do our best to give creativity freedom, this won't work exactly like "Turtles" in ComputerCraft (the aforementioned Minecraft Mod).
You will have scripts attached to "Units" (like the Computers, Monitors and Turtles in this mod), but the similarities stop there.
I apologize if one of my previous answer was ambiguous and generated confusion on the matter.
 
Best regards,
Nyzaltar.

As Comrademoco stated, technically, nothing will prevent you to build giant mechs
About the limits of ingame programming, I can just tell you for now that all the coding allowed will be in LUA and should limited to automatize some basic things (like elementary AIs for droids, autopilots for spaceships, automatized defense systems and such things). More on this matter will be revealed in the future

Hi Vylqun & Michael,
 
No mini-games are planned yet.
But I will transmit the idea to the team.
We are all for social interaction so in the essence, this idea goes in the right direction.
However we have to set priorities. As we have already an impressive amount of features to develop, if the idea is accepted, it will be most likely a stretch/optional goal for the crowdfunding campaign. And if the stretch goal is met, it will be most likely a feature implemented after the official release of the game. I will come back to you as soon as the team will have discussed the subject
 
Best regards,
Nyzaltar.

No worry Silvligh.
Misinterpretation happens, and it's not a big deal here
 
Well... my thoughts can't be seen as an objective point of view as I'm a member of the team.
The only thing I could say is: if I'm part of this adventure, it's pretty much because I have felt many similar things you have described (not just you but other members too) on the forum since its opening. The Dev Team have made some impressive progress in the last months, and it sometimes hard to resist sharing some news the community, even when it's clearly "not yet ready for communication"
 
And what do you mean about me being too formal ? It seemed to me I was already way less formal than many CMs on big IPs 
Is this because I always end my replies by "Best Regards" ?

No worry Silvligh.
Misinterpretation happens, and it's not a big deal here
 
Well... my thoughts can't be seen as an objective point of view as I'm a member of the team.
The only thing I could say is: if I'm part of this adventure, it's pretty much because I have felt many similar things you have described (not just you but other members too) on the forum since its opening. The Dev Team have made some impressive progress in the last months, and it sometimes hard to resist sharing some news the community, even when it's clearly "not yet ready for communication"
 
And what do you mean about me being too formal ? It seemed to me I was already way less formal than many CMs on big IPs 
Is this because I always end my replies by "Best Regards" ?

Hi everyone,
 
I respected Silvligh wish (until now) to avoid participating in this topic.
But it seemed important to clear any possible confusion: I confirm that Shadow is not me.
I have, of course, another profile than Nyzaltar as a gamer. 
 
But I won't use it to post on this forum (unless I state clearly it's my gamer profile) for ethic reasons:
- If I want to discuss with any member of the community I can already do that with my official profile Nyzaltar.
- Using another account could be perceived as an attempt to deceive members of the community and I definitely don't want to risk any misinterpretation or loss of trust, as it's completely contradictory with the job of community manager. I know some CMs who played with this kind of things, and it has always, sooner or later, backfired painfully.
 
To put it simply, I have no good reason to use another account to communicate with everyone on a Dual Universe topic 
 
Best Regards,
Nyzaltar.