Interface is looking great, Josh .

But alpan has a point about the interface content I'd like to elaborate on:

alpan wrote:As much as I loved this update, I have to admit that out of all the updates so far, it was also the most opaque. It felt almost like awesome fan service, for those of us who have been following the dev logs daily, but I can imagine some distant backer watching the video and scratching his/her head about WTF is going on with the supposedly "great" interface (and all the data field names, et cetera) and how the AI apparently works. Not to mention complete outsiders.

Now I'm not sure if this is an actual concern -- it is after all a development update, the topics discussed are complicated and deep, and layman comprehension should not be a focus anyway. But I felt like airing the tiny voice just the same.

There is a mix of various data in the "deeper" nodes,

• Some obviously interesting to the player while doing things in space, such as the current contents of the cargo hold or the amount of remaining ammunition. Presumably somewhere under the "Inventory" node seen at 05:48 in the sub-nodes of "Ship". Edit: around 5:30 it is actually shown
  Side note: Seeing the remaining ammo count may be urgent enough to justify bypassing the node-based UI and put it somewhere in the HUD.
• Some that might be interesting to the player while docked and planning things, such as the "Hardpoints" node. Because it tells you what free installation options you have on your ship for new toys .
• And finally some that are presumably only interesting to modders, such as "Pilotable" or "Explodable". I think we are seeing some object properties here that are meant only for the engine, not for direct interaction during gameplay.

So I think the UI should have a notion of what category each property belongs to. And offer views where some categories are filtered out. I think most players won't want to review the "BoundingBox" property while organizing a trade run or a battle. On the other hand, people like Gazz might be very interested in "Detectable" when introducing stealth fighters .

Right now the UI is in all out "development console" mode.

Naturally a lot of the technical gibberish (like the colour of a laser projectile) will be hidden in "play" mode.

And the strict hierarchical structure will probably melt a bit in places so that your gun doesn't just show an ammo property... that you can expand to have it show the number 27.

Instead, an ammo-using weapon might display like
Finagle Discombobulator
(27 / 30 / 312)

In a UI, not all information that belongs together can be found at the same level of the object hierarchy.
The 312 rounds in the cargo bay are very relevant to the operation of the weapon but they are not a part or child of the weapon object.

Gazz wrote:Right now the UI is in all out "development console" mode.

Naturally a lot of the technical gibberish (like the colour of a laser projectile) will be hidden in "play" mode.

And the strict hierarchical structure will probably melt a bit in places so that your gun doesn't just show an ammo property... that you can expand to have it show the number 27.

Instead, an ammo-using weapon might display like
Finagle Discombobulator
(27 / 30 / 312)

In a UI, not all information that belongs together can be found at the same level of the object hierarchy.
The 312 rounds in the cargo bay are very relevant to the operation of the weapon but they are not a part or child of the weapon object.

Exactly.

Sorry, I failed to explain that the data shown in the UI was, largely, just a test of the new node engine. I have yet to design real interfaces for it, the universe map being the only real exception.

None of that dev data will be accessible in the normal course of play (except as a dev-console-like feature) There will be user-side interfaces for hardpoints, items, etc.

And, as Gazz says, certain properties will be lifted directly to parent nodes for usability purposes. E.g., when you look at a weapon item, you'll see all of the stats directly, you won't need to go any deeper just to gather individual statistics.

HowSerendipitous wrote:Was that round thingy a space station?

I saw that too. Very nice!

Just arrived here. Awesome interface, data mining style. As always, you are doing an amazing job!

However, think about also providing a flattened, filterable list or tree representation, with ways to merge in super and sub-nodes. While there is no "mathematical" reason for this (on the contrary, half the problems seem to express nicer as graphs, at least when you look at them as a whole), lists or trees appear to somehow work better for many people (notably even including many comp.sci people). It's a transformation that -as you certainly know- always can be done starting from a graph; you wouldn't have to really wreck your work.

Besides, merging levels in the hierarchy to display them as one virtual, merged level (so that you can "combine" the information into one view) is probably easier to realize in a tree or list. That will be useful if you ever have an interaction that happens between three distinct sections of a graph, no? Not that I can think of any great example right now, but maybe the player wants to keep an eye on two ship's missile inventories and health points, giving him 4 different levels in the graph to watch simultaneously...? Oh, and in a tree/list, you can also conceptually hide ("fold") entire intermediate levels you don't want to look at a bit easier.

Your current use of 3D might even allow a hybrid view, with the ability to toggle between the graph view and a list or tree at will for individual levels (even including currently merged in sub- or superlevels).

Gazz wrote: Instead, an ammo-using weapon might display like
Finagle Discombobulator
(27 / 30 / 312)

As a "short form", icon-based may be even better. Consider this example (from EVE Online):
http://blog.weflyspitfires.com/wp-conte ... ine_ui.jpg
That UI shows a really huge amount of information on a small screen area. For each weapon, activation state, loaded ammo type, remaining ammo in gun and time to next firing are compressed into one icon (the bullet and missile symbols on right lower screen).

Of course, that type of UI implies a limitation to a finite number of weapon and ammo types, because

• the player has to learn the icons
• and the icons are designed traditionally, so no cheap gazillion of icons from procedural generation

But it works so well that it may be worth the tradeoff. Unless Josh has an even better idea

Rabiator wrote:Of course, that type of UI implies a limitation to a finite number of weapon and ammo types, because

• the player has to learn the icons
• and the icons are designed traditionally, so no cheap gazillion of icons from procedural generation

But it works so well that it may be worth the tradeoff. Unless Josh has an even better idea

I like your idea, and the solution is pretty straightforward. There will be a finite number of different types of weapons (and other items) that Josh will decide on, and each will have a unique icon associated with it. Procedural generation of items occurs within the confines of their type; you'll find many variations of lasers in the game that are procedurally generated, and each will be associated with the "laser" icon and stats appropriate for lasers. You won't find any hybrid-laser-torpedoes.

Josh
I was thinking, for doing operations such as "drag and drop" a 3d interface can be quite hard. Espceially if you only have the one window.

And draging and droping nodes or connecting noodles ( lines ) to another node would probably be a necessary thing during gameplay.
Since we will not only need to change the value of a node but also sometimes change its "parrents" and so on.
(for example when you buy a gun, or transfer some cargo).

But having multlple translusent windows on top of eachother can get very confusing.
kinda like what happend at 14:35 in the video.

So what do you think about doing some "tiling window management" for the nodal interface?
You know kinda like what happens when you type ":split" in vim, for example.

That way during a a big battleship-fight you might spawn a seperate window/viewport for each enemy ship, and one for your own weapon-hardpoints.
That way you could easily specify which of your big bulky beam weapons on your big carrier targets the thruster-hardpoints on the enemy battleship.
And which of your weapons targets the smaller ships. And so on.

...and split-screen multiplayer. *runs away cackling maniacally*

rickisen wrote:Josh
I was thinking, for doing operations such as "drag and drop" a 3d interface can be quite hard. Espceially if you only have the one window.

And draging and droping nodes or connecting noodles ( lines ) to another node would probably be a necessary thing during gameplay.
Since we will not only need to change the value of a node but also sometimes change its "parrents" and so on.
(for example when you buy a gun, or transfer some cargo).

But having multlple translusent windows on top of eachother can get very confusing.
kinda like what happend at 14:35 in the video.

So what do you think about doing some "tiling window management" for the nodal interface?
You know kinda like what happens when you type ":split" in vim, for example.

That way during a a big battleship-fight you might spawn a seperate window/viewport for each enemy ship, and one for your own weapon-hardpoints.
That way you could easily specify which of your big bulky beam weapons on your big carrier targets the thruster-hardpoints on the enemy battleship.
And which of your weapons targets the smaller ships. And so on.

Shhh!! Stop!! Stop giving away my future plans

Yes. :sp and :vs are coming soon in the nodal interface

Wait. Now I'm all confused and stuff.

My impression has been that there'll be a game, and we'll have in-game interfaces to do everything we need to do in-game... and that (now) there will additionally be an interface that lets those so inclined see and modify the data and some of the code and their structures that define the inner workings of the game.

So, yes, you probably could use the editor to change the number of missiles in a ship in an active game. But why would you want to do it that way when you're just playing the game normally?

I absolutely like the idea of the node editor being able to show me the state of the data in an active game. And it's nice to be able to change that data with the editor.

But I thought the editor was primarily being thought of as a modding tool -- not as a primary game control interface.

Am I wrong?

Flatfingers wrote:Wait. Now I'm all confused and stuff.

My impression has been that there'll be a game, and we'll have in-game interfaces to do everything we need to do in-game... and that (now) there will additionally be an interface that lets those so inclined see and modify the data and some of the code and their structures that define the inner workings of the game.

So, yes, you probably could use the editor to change the number of missiles in a ship in an active game. But why would you want to do it that way when you're just playing the game normally?

I absolutely like the idea of the node editor being able to show me the state of the data in an active game. And it's nice to be able to change that data with the editor.

But I thought the editor was primarily being thought of as a modding tool -- not as a primary game control interface.

Am I wrong?

No you're not, that's all correct. What was shown in the video was mostly the data editor (except the universe map, which was a "real" game UI).

The key is that the regular interfaces will also use (a much-improved and heavily-modified) version of this node tech. But they'll of course be much more to-the-point and usable in terms of how they allow you to control your assets.

I've really done a good job of confusing many people with this I think But the node-based interface tech is completely separate from the data editor concept now. In other words, the data editor in the latest video was just implemented with the node-based interface to provide a demonstration of how a system that uses it might look.

The "real" game interfaces have not been implemented yet, but they too will use this tech. Like I said, I will be spending a lot of time trying to figure out how to effectively lay out the normal interfaces in this way (nodally). Imagine if, in the universe map, instead of a "typeinfo" wheel popping out, you got a node that said stuff like "inventory - orders - hardpoints - hangar - crew - ..." and the corresponding subnodes were representative of real game interfaces.

Good? Bad? Confusion?

Ahhhhhhhh. MY confusion, then.

And less of it now. I think.

Thank you, sir! (And for the comments on my earlier questions as well.)

Flatfingers wrote:Ahhhhhhhh. MY confusion, then.

And less of it now. I think.

Thank you, sir! (And for the comments on my earlier questions as well.)

Everyone's confusion, I think

I will await your evaluation of the "real deal" when I finally implement some real game interfaces with it

This is so cool ! It seems like exploring in an alive creature's mind . Literally, mind blowing.

Here is my understanding and question, correct me if I am wrong.
The node here is linked with everything in the sub relationship with that node. But will there be a way for me to quickly switch to another node that is in parallel with that node?
For example, I'm checking the weaponry under my Frigate X, and I want to quickly switch to the info under Frigate Y.
I just cannot figure how the 'compare' function will be presented in the node based UI. Hope you can shed a light on it.

Apologize ahead if I misunderstood anything here. I only heard this project several days ago and I'm shocked by the ideology and beauty of it. Just want to know more about it.