MatzaJew

I'm only going to add this, to this what... 30th thread for pleading to not have P2P....
 
(This is on top of needing money to afford to pay for the servers / development without making it P2W)
 
If this is like Eve-Online...
-you pay for a sub and that pays for your ability to play the game
-you can optionally buy a "token" for more game time you can sell on the IN GAME MARKET...
     -where someone who mined minerals for weeks and sold all of it for in game money bought it and now they can play for free.
     -and now with the money acquired from selling the "Token" you can purchase all the minerals you needed to build that carrier, from that blueprint you have been researching on for months.
 
(With this model people who have more IRL money will be able to acquire in game items and materials faster yes, however this HAD to come from somewhere and WAS NOT JUST SPAWNED IN. Someone else had to do the dirty work or it just doesn't exist. On top of that you may be able to buy that carrier or Dreadnought with all the IRL money you spent.. but if you don't have the training to actually fly the darn thing,  you Cant use it. So only if they spent the time on a character to acquire proper training .. aka all that time spent In the game doing stuff to fairly obtain the ability to fly that ship.. will benefit from the extra player tokens. This is nerf to full P2W ... and NQ is made it clear there will be a character learning type system involved to invest your time in before you can use everything.

Hi everyone,
 
Just to clarify on this topic:
We totally understand that First Person Shooter gameplay would be more immersive.
However, we have to take everything in account. And when we do, then we have to make some compromise.
We want combat, but combat is not the main feature of the game. Only one of the main features, equally important with building, real massively multiplayer system in a single-shard universe, exploration, trading, etc. Once this was sorted out, it was logic that we wouldn't sacrifice things like the massively multiplayer aspect just to have the best First Person Shooter possible. In that case, even if it's not the best combat mechanics (we totally agree on that), target locking combat gameplay is the answer for the best compromise. So it's not a decision led by personal taste, but really the most relevant decision on the technical aspect in our case.
 
We totally understand that it won't appeal to every player.
We are aware that our game won't satisfy everybody, and it's the same for any game.
 
Best regards,
Nyzaltar.

K, first let me clear something up
I think that this suggestion of yours comes from the right place. Giving us a preview sandbox would be great to play in. 
And Trihxeen mentioned the legal ramifications of using an exterior editor to import to the game. Now while this is 100% part of my explanation I'd also like to add some more between the lines action.
1. The realist answer. While not extreme in development requirement, working on a complete editor to give us in the mean time while they develop the game, is time not spent developing the game. We're talking about, albeit large for indie, AN INDIE game company. If this were blizzard for instance making the early stages of Hearthstone, I would totally believe it would be possible to see an early development stage prototype for us to test. In which case that's just a Alpha / Beta stage build that is released for public testing.   
2. Practicality. There are a few people out there who would value an early game editor but honestly, If I told my friends "hey you can Kinda play the game right now","Your stuck in a room and all you can do is create voxel objects", "oh and anything you do in there is 100% just going to be a waste of time beyond just getting used to building with voxels". But hey it's early access. Almost all of em would just say its' 'OK' and they will wait till they can play open beta. Better to play a game they can experience the other 90% of what they intend the game to be than just a voxel editor. That and if they do play with it .. it would just be for maybe an hour at most.
3. Now on to the sociology effect. Like in the practicality answer, we human beings can be odd creatures. Give us a small taste of a good thing and we may want more. Some of us would get excited and wait for more, and others would feel sated in what they got and not even bother with the full product. The dev's wouldn't want to risk giving us a basic demo for fear of that issue. Yeah "You" may still buy the game but maybe I wouldn't (I still would =P) or maybe all my friends would get a bad impression and not get the game. Leaving me to play alone. Events like this can happen to over a potential million gamers, each with all their own unique situations. 
4. Legally speaking it is true that taking any assets from your own computer and transferring it to their servers, which in the eye's of the world is a business / consumer product, can have intellectual property rights issues. [space Engineers] workshop mods have this disclaimer, through Steam, to them to prevent the developer 'KSH' from being affected since mods are not something that is shipping with the release version of the game. VQ has stated that the game environment the player will be connected to is that of host client system. Meaning that your client is more or less just a portal to your character in-game that is creating the assets. That and the literal voxels are being created in the game, hosted on their server, owned by them, in their office building. To add conjecture to saying that perhaps make it to where the "demo" you receive never will be able to import the file to their server does solve the issue of them being legally liable for IP rights solves 1/2 the problem.
Adobe makes photo shop for instance, and they have a TON of legal coverage to prevent things created in the "Tool" they provided to you, prevents them from being legally liable for IP rights violations. It's kinda dumb actually to be able to be sued for that but it was a thing for a time years ago and a legal precedent to protect Adobe just didn't exist until then.
 
Final Verdict and Short version to all the Above:
For the Dev's to bother spending the development time making a demo product to reach such a smaller audience, inside of what currently exists as interest for the game, that could be very detrimental to the entirety of the full game, and could completely cripple them legally if they didn't invest in the time/money/coverage to protect themselves, is a VERY BAD IDEA.
On top of that I believe having a earliest outside of game ability to create whatever you wanted would give you an unfair advantage of me.... so   ... xP
 
I promise I'm not posting here to step on toes, I'm enjoying the topic actually, it's making me use my brain for once beyond my normal cave man work peon / wage slave speak. =D

K, first let me clear something up
I think that this suggestion of yours comes from the right place. Giving us a preview sandbox would be great to play in. 
And Trihxeen mentioned the legal ramifications of using an exterior editor to import to the game. Now while this is 100% part of my explanation I'd also like to add some more between the lines action.
1. The realist answer. While not extreme in development requirement, working on a complete editor to give us in the mean time while they develop the game, is time not spent developing the game. We're talking about, albeit large for indie, AN INDIE game company. If this were blizzard for instance making the early stages of Hearthstone, I would totally believe it would be possible to see an early development stage prototype for us to test. In which case that's just a Alpha / Beta stage build that is released for public testing.   
2. Practicality. There are a few people out there who would value an early game editor but honestly, If I told my friends "hey you can Kinda play the game right now","Your stuck in a room and all you can do is create voxel objects", "oh and anything you do in there is 100% just going to be a waste of time beyond just getting used to building with voxels". But hey it's early access. Almost all of em would just say its' 'OK' and they will wait till they can play open beta. Better to play a game they can experience the other 90% of what they intend the game to be than just a voxel editor. That and if they do play with it .. it would just be for maybe an hour at most.
3. Now on to the sociology effect. Like in the practicality answer, we human beings can be odd creatures. Give us a small taste of a good thing and we may want more. Some of us would get excited and wait for more, and others would feel sated in what they got and not even bother with the full product. The dev's wouldn't want to risk giving us a basic demo for fear of that issue. Yeah "You" may still buy the game but maybe I wouldn't (I still would =P) or maybe all my friends would get a bad impression and not get the game. Leaving me to play alone. Events like this can happen to over a potential million gamers, each with all their own unique situations. 
4. Legally speaking it is true that taking any assets from your own computer and transferring it to their servers, which in the eye's of the world is a business / consumer product, can have intellectual property rights issues. [space Engineers] workshop mods have this disclaimer, through Steam, to them to prevent the developer 'KSH' from being affected since mods are not something that is shipping with the release version of the game. VQ has stated that the game environment the player will be connected to is that of host client system. Meaning that your client is more or less just a portal to your character in-game that is creating the assets. That and the literal voxels are being created in the game, hosted on their server, owned by them, in their office building. To add conjecture to saying that perhaps make it to where the "demo" you receive never will be able to import the file to their server does solve the issue of them being legally liable for IP rights solves 1/2 the problem.
Adobe makes photo shop for instance, and they have a TON of legal coverage to prevent things created in the "Tool" they provided to you, prevents them from being legally liable for IP rights violations. It's kinda dumb actually to be able to be sued for that but it was a thing for a time years ago and a legal precedent to protect Adobe just didn't exist until then.
 
Final Verdict and Short version to all the Above:
For the Dev's to bother spending the development time making a demo product to reach such a smaller audience, inside of what currently exists as interest for the game, that could be very detrimental to the entirety of the full game, and could completely cripple them legally if they didn't invest in the time/money/coverage to protect themselves, is a VERY BAD IDEA.
On top of that I believe having a earliest outside of game ability to create whatever you wanted would give you an unfair advantage of me.... so   ... xP
 
I promise I'm not posting here to step on toes, I'm enjoying the topic actually, it's making me use my brain for once beyond my normal cave man work peon / wage slave speak. =D

The issue is that there is some progression in the game by building a ship in game with the available tools, if you allow outside meshes to be used this system is bypassed.
 
I work with 3D software (Cinema 4D mostly, some maya under my belt) and I can see the appeal. The issue is progression will be skipped, instead of people working from small to medium to large to capital ships, someone could just plunk down a death star...this would cause major imbalances in pvp and would essentially break the game.
 
Secondly. The game will have an in game market where the best designs (aesthetically and functionally) will sell, allowing for a mesh import would leave those who do not know 3D programs at a disadvantage. This would not be good for fair or balanced game play.

*This is exactly why I would love for this game to support VR, specifically the Vive for the ability to physically move around your creations. Creating anything would be more intuitive and immersive.

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

In the Q/A section of the website it was asked about Rift compatibility. And while they said this is on the distant roadmap, it probably wont be in the Earliest of Alpha's for sure. But as for which platform I would prefer to have the VR on, that would be the Vive. (By the way I don't own a VR headset yet, waiting for GTX 1080 Ti for that)
-You get way better tracking through the laser cameras around the room watching you.  
-Your able to walk around the room very easily
-2 Hand remotes vs a XBone controller. Imagine being able to use arm movements to create voxel elements (/Drooling)
-Vision pass through of the headset is nice to keep you from constantly taking off the headset to see things.
-Software support is WAYYYYY further along than the Rift. The Rift effectively has all 3rd party programs trying to duplicate what the Vive does out of the box.
 
But now for more reasons I'd love VR in this game. 
Being able to virtually grab the throttle control and joystick in-game instead of using a proxy joystick IRL, pull your ejection handle in emergencies, hold your welder / grinder physically in front of you while looking in different direction (weld and recon). Being that its a voxel based game, being able to create objects 3 dimensionally in the air infront of you is akin to the Iron Man films where Tony Stark creates his suits via hologram before making one for real. To me its like using a paint brush on canvas. Using your whole body instead of limiting yourself to just the accuracy of a mouse click. 
This Could be Awesome!

Are you telling me I should also be doing my business at certain times? pls, no. haha XD

I assume the game will use realtime instead of fast-forward daycycle, so it would be realistic if you need your 3 meals a day, what would result in one meal per game session for the average player.
 
I think it could work so:
You will need food but only once all 8 hours, depending on your activities this could be more or less. An example: if you mine the whole time, then you need food more frequently approximately all 3 - 4 hours, because its exhausting, but if you're offline (sleeping) this changes to a 12 hour cycle, should you not be online if food needed, it will automatically consume food from your inventory. Should you be longer offline, for a week or even a month, there could be the possibility to reenter the cryostasis.
 
With this system i see two ways for players,
first, the lazy one, you stack simple rations in your inventory wich will automatically consumed as you go.
Second, the more realistic, you cook or buy yourself a real meal and you consume it manually. If you using this method i would give little bonuses like +10hp for the next hour, nothing really drastic, but a small reward for your effort.

There are probably just going to have to be constructs of some sort that can be modular to whatever design you can come up to use them. The end result food can just be "sucked" into your suit storage like mentioned in the (Part 1-5) of the Backstory. Before that is food grown from pre-determined in game objects Aka Seeds. Seeds would need to be planted in sufficient soil by liters cubed and watered sufficiently during the life cycle. So all we would need to do as the player is create a complex voxel object that satisfies that process. 

There are probably just going to have to be constructs of some sort that can be modular to whatever design you can come up to use them. The end result food can just be "sucked" into your suit storage like mentioned in the (Part 1-5) of the Backstory. Before that is food grown from pre-determined in game objects Aka Seeds. Seeds would need to be planted in sufficient soil by liters cubed and watered sufficiently during the life cycle. So all we would need to do as the player is create a complex voxel object that satisfies that process. 

Have you heard or MREs? Something equivalent would be possible.
 
As for something to grow in space? I've heard hydroponics make things a little easier to grow, manage, and manipulate(like its shape). 

This reminds me of Hive ships from Stargate Atlantis. I like the idea.

Thinking that one way this could be implemented as a hull reinforcement.
Say you build just the frame work for a ship. Then plant seeds or place organic material in various places and it grows around the frame work. Kinda reminds me of the "Wraith" ships in Stargate: Atlantis. Ship regrows as damaged and generates new matter as needed so long as the power supply is able to sustain it. 
Benefits:
-Ship hull regeneration 
-Ease of ship manufacture (Just frame it then let it grow)
-Very hard to destroy 
 
Disadvantages:
-Can only grow as big as say 70% of max power output
     -Requires more power to just run basic systems vs just sustaining hull integrity
-More susceptible to bio engineered attacks for lower tech level organic development (Max level not 100% perfect but could be adaptable if attack is survived)

While posting on another thread i realized that im not certain how the game will take into effect that we are humans and that we would need to eat and drink to survive. I think somewhere in another thread or devblog something was mentioned about going out and hunting after we leave the ark ship.
 
 
But i just wanted to get everyone's opinion on if they believe this should be a mechanic in the game or not.
 
Personally id like to see it as it adds a very intriguing level of immersion into the game. especially for long space flights and wars far from your home system

It would definitly be fascinating, it would offer new careers like farmer and hunter, additional there are the possibilitys for hardcore roleplayer, imagine somone who is happy with playing a life sim as farmer.
 
And this would add more strategic aspects to ship design and deepspace fleet operations. should there be sufficent hydroponics for food on every ship or is it better to have one giant agricultural ship accompanying the fleet? Or maybe even a combination?
 
And then the hunger and thirst mechanic, will your sourroundings influence how fast you get hungry and thirsty?

My thought was that it will discourage pvping to some degree. but not in a negative way. You would have to plan the logistics of long warfare for a large force or plan and build an agricultural ship that can supply the fleet. Which just adds another target during wars. gotta take out the agriculture ship as well as the one with the RN on it. But I see this as just another reason that people wont aimlessly start wars and such which i think people who are not interested in the pvp side may actually like.
 
My thought on the mechanics on your surroundings is that the suit would house a kind of camel back with water and it depletes at a certain rate at idle and while doing different types of actives it would deplete at a faster rates. The food part im not sure how that would be taken care of. i would assume that you would have to store food in your pack unless its processed into a paste that you drink through a straw in your suit. which honestly doesn't sound great lol
 
 
 
 
 
 
 
 
 
edited for a typo i saw

After reading the lore(parts 1-5), I think they allude to game mechanics that the devs are hoping for. I could see food and water(or beverages) as being something to help with energy(which might come back on its own) or help you get health back faster. This way you are limited to things like health packs and stim packs. Would make the game more immersive, without making it a requirement.

Is there going to be a pre-made interface for creating these types of clans? Like a log in a menu, or something in game to see member lists? I know this is still too early for them to have something like this made. Just curious if there has been talk about it.
 
I think to make the game more immersive, we could have a phone or personal tablet of sorts that allow us to access different types of information. I could see the interface for the clan having a background of the planet or space station they are centered on. With an emblem somewhere on the top of the page. With information like, planet/station name, and star system. As well as having the top members of the clan list with pictures and any other public information they want to share. I may try to throw something together to help shape this idea.
 
Clan members would have access to more information, such as locations of other members. It could also list locations of hubs/embassies, store/shop locations(if that becomes a thing), housing areas, mines and etc.
 
It could also be cool to have things set up where different clans are part of one large conglomerate. For example, United Space Guys could be the "umbrella name" with clans like Space Pirating Kitties, Mineral Masters, Space Faring Clan, Wufu Cookery & Bakers and TUMS Galactic Hospice being part of said conglomerate. This would make them allies, without having to have the same vision shared clan wide. Similar to alliances from EVE.
 
Ideas and thoughts? 
 
I'm kinda big on feedback if anyone has noticed.
 
-TrihXeen
 

Yea you would, haha. J/K! Welcome to the forums!(lol, even though we are sitting in TS together lol)

Hi, I'm MatzaJew, And I'm Super stoked about this game!
I'm a member of the NinjaClanFu  that Trihxeen mentioned in his intro. Read about him here
This game has just about pinned down every major aspect I have wanted. Progressive game-play, voxel based, large scale multiplayer, 
MMO game. Take the shard style mechanics of Eve online, the voxel creation of EverQuest Landmark, and the mechanics of SpaceEngineers to make a single game where creativity meets action. 
Looking forward to this game hitting Alpha / Beta Builds to try my hand at it!
-My gamer skill set is very broad and am generally very good and building / strategy / or FPS
My Gaming History:
Diablo 2
FreeLancer
MechWarrior (Most of Them)
EVE Online 2004-2010 (Main: Ro' LoPok)
World Of Warcraft 2007-2013 
Starcraft I & II
Halo (All of Them)
EverQuest Landmark
SpaceEngineers 
Overwatch
Minecraft
etc etc
 
Personal Background:
I have an Associates of Applied Science in Multimedia and Design, and progress on two bachelors in Game Design. 
 
 

Hi, I'm MatzaJew, And I'm Super stoked about this game!
I'm a member of the NinjaClanFu  that Trihxeen mentioned in his intro. Read about him here
This game has just about pinned down every major aspect I have wanted. Progressive game-play, voxel based, large scale multiplayer, 
MMO game. Take the shard style mechanics of Eve online, the voxel creation of EverQuest Landmark, and the mechanics of SpaceEngineers to make a single game where creativity meets action. 
Looking forward to this game hitting Alpha / Beta Builds to try my hand at it!
-My gamer skill set is very broad and am generally very good and building / strategy / or FPS
My Gaming History:
Diablo 2
FreeLancer
MechWarrior (Most of Them)
EVE Online 2004-2010 (Main: Ro' LoPok)
World Of Warcraft 2007-2013 
Starcraft I & II
Halo (All of Them)
EverQuest Landmark
SpaceEngineers 
Overwatch
Minecraft
etc etc
 
Personal Background:
I have an Associates of Applied Science in Multimedia and Design, and progress on two bachelors in Game Design.