Post
Wed Jan 01, 2014 6:11 pm
#19
by OanMkvenner
Hey there,
Now first off: I just watched the "Limit Theory Development Update #11" on Youtube and this is pretty much ALL information i got so far on this game, but it looks promising and the node-system grabbed my attention. After completing this post here i will most likely start getting some more on this game, so bear with me if i am talking in weird, cloudy terms like "regional map", "own finances". I really have no idea yet, what this game is all about and what will be in and what not.
That beeing said, in the following text words bracketed like this: *word* means that its supposed to be a node. Also when i am talking about you i am talking to the developer(s ?) of this game. Enough of the pre-talk, lets get to my comments:
(1)
I am a big fan of customizability and thus a way to change the position of the nodes onscreen (e.g. via pressing ctrl-shift and dragging them around) would be nice. Maybe i like the map better on the left side rather that the right. Maybe i like the save-button (or rather save-node) on the left side and the load-node on the right side.
(2)
Furthermore being able to create a custom-Node-selection would be a plus; not just for selecting multiple ships, as described before by other people here, but rather for collections of submenus.
One person might prefer having *Regional Map*,*one specific ship, you tend to interact with often*,*own cargo*,*own finances* as subnodes of one node, while another one might prefer having *galaxy map*,*own weapon fitting*,*Fleet commands*,*Trading screen* in a custom node. Or you want only 3 specific *regional maps* in one node, because you have all your assets in this 3 regions.
Also these custom created notes should be reachable via specified hotkeys.
(3)
Another way of doing this would be to not just enable changing the positioning of the nodes, as described by me in (1), but also their structuring. This would most likely require an extra node-editor, since i cant see a convenient way of doing that within the Node-tree itself.
There would obviousely be quite some constraints for that (you cant instantly choose *weapons* if you haven't chosen a specific *ship* beforehand) but other than that you would be free to do wahtever you like. Maybe you want the *Regional map* in the *ship selection* screen, since you tend to jump between them regularely, or maybe you want to have the *trading screen* there as well. Maybe you DON'T want to see all ships in your ship-list, you might be able to cut a few out so you wont get to see them anymore. Maybe you dont need a trading-node at all, since you are just into fighting.
Being able to temporarily revert all these changes to find an option, you accidentaly or intentionally have hidden would be neccessary as well.
This would also help with the possible cluttering that might occur, once you have too many subnodes to one node. Just cut out the ones you rarely use and only show them on a button-press.
(4)
These shortcuts - and possibly all sorts of shortcut-nodes, you might implement at some point - have a common issue: Where do you go, when you go upwards after choosing a shortcut? Do you go back to where the shortcut sits, or do you go to one node higher, than where the shortcutted node originaly sits? (e.g. when you have a shortcut to the *map-node*, and you choose it, and then go back outside of the map again. Do you switch back to the place of the shortcut-node or to the main-menu, where the map is normally accessed from?)
Either you (Josh) just choose one of these two ways (but consider my (5)), or the user gets a choice in the settings or you implement a way of choose inside the node where you want to go to, when going upwards. (only in these special cases obviousely and only on demand, there should always be a quick standart action on right click (i guess that's going upwards in the tree right now?))
(5)
This last thing is just one hint - or rather request - overall: If you have to make a tough decition between two (easy to programm!) UI-matters in some way whatsoever, thinking that both would be liked by the community; implement both and let the user make his choice, on what to use :=)
Well actually that doesn't just go for ui-matters, as long as its not taking up too much time for you to implement both.
Cheers, Oan