So nobody likes the idea of using the "use" key to bring up some sort of circular mouse menu that lets you easily pick a phase gate destination for the next time you use a pg? Also with coloring, shows you the primary phase gate (commander selected), and possibly when one is taking damage? It's fully dynamic, and the menu can even be designed in numerous ways.
swalkSay hello to my little friend.Join Date: 2011-01-20Member: 78384Members, Squad Five Blue
<!--quoteo(post=1892176:date=Dec 31 2011, 12:47 AM:name=Kalabalana)--><div class='quotetop'>QUOTE (Kalabalana @ Dec 31 2011, 12:47 AM) <a href="index.php?act=findpost&pid=1892176"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->So nobody likes the idea of using the "use" key to bring up some sort of circular mouse menu that lets you easily pick a phase gate destination for the next time you use a pg? Also with coloring, shows you the primary phase gate (commander selected), and possibly when one is taking damage? It's fully dynamic, and the menu can even be designed in numerous ways.<!--QuoteEnd--></div><!--QuoteEEnd--> No thanks, that would delay me each time I have to go through a PG.
<!--quoteo(post=1892194:date=Dec 30 2011, 09:11 PM:name=swalk)--><div class='quotetop'>QUOTE (swalk @ Dec 30 2011, 09:11 PM) <a href="index.php?act=findpost&pid=1892194"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->No thanks, that would delay me each time I have to go through a PG.<!--QuoteEnd--></div><!--QuoteEEnd-->
What would be more efficient? Other than simply removing the ability to choose a destination?
swalkSay hello to my little friend.Join Date: 2011-01-20Member: 78384Members, Squad Five Blue
<!--quoteo(post=1892199:date=Dec 31 2011, 05:10 AM:name=Kalabalana)--><div class='quotetop'>QUOTE (Kalabalana @ Dec 31 2011, 05:10 AM) <a href="index.php?act=findpost&pid=1892199"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->What would be more efficient? Other than simply removing the ability to choose a destination?<!--QuoteEnd--></div><!--QuoteEEnd--> Let me quote myself, just for you. <!--quoteo(post=1891980:date=Dec 28 2011, 08:30 PM:name=swalk)--><div class='quotetop'>QUOTE (swalk @ Dec 28 2011, 08:30 PM) <a href="index.php?act=findpost&pid=1891980"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Just make as simple as the commander turns off undesired teleporting from specific phase gates. You press a phase gate, press turn off in the selection menu/hotkey. Press again to turn on.
I wouldn't like any menu's or other systems for people on the ground, it should be down to the commander to make the right decision. Such systems make it both annoying and slower to use the phase gates.<!--QuoteEnd--></div><!--QuoteEEnd-->
The phase gate commander menu system could work as follows:
Upon the selection of a phase gate in the field of play a graphical menu expands into view. As seen in the example image, a list of all the currently built phase gates appears within the graphical menu where the currently selected phase gate is highlighted (for purposes of helping a commander differentiate between multiple phase gates within the same room/area). <img src="http://1.bp.blogspot.com/-jBtDyl_gRLw/Tv8BzWg-BCI/AAAAAAAAAEc/3iiqHtinSQg/s1600/Phase+Gate+Mockup.jpg" border="0" class="linked-image" /> The list is broken down into two parts; a phase gate icon per phase gate (in reality the icons should probably be smaller to allow for more gates) and a text field that indicates which room the phase gate resides in.
The images indicate the current state of the phase gate; on (green shade) or off (red shade). By clicking on any of the the phase gate icons, the associated gate is toggled between the two states.
To quick jump and center the commander view onto any desired phase gate, the commander can click the text field correlating to the appropriate gate. This helps with identifying which phase gate is which in the list as well as provide another means of accessing "quick views". A nice touch would be to allow for custom text by means of right clicking the text to aid in organizational and interpretation of the which gate is which.
By default, a newly built phase gate would be added to the bottom of the list. Thus, in this example, if a sixth phase gate were built, it would appear below the fifth phase gate. The phase order would follow exactly as the list displays. In the simple interface, there would be no reordering of phase gates.
For more advanced control I would propose two possible solutions. 1.) A simple reordering of a single cyclical path. 2.) A complex reordering that would allow multiple cyclical paths.
In addition to this, the issue that should be addressed is whether paths should be self repairing in the event that a gate is turned off. In the simple interface this would seem like a natural thing that should be done. But, what about under advanced control?
Let's elaborate on option 1. Still taking a look at the simple interface, a reorder would be accomplished much like rearranging icons on a smart phone (I personally don't have one). Click and hold on the phase gate text field and then drag above or below to the desired location. The icons would shift to make room for the new order, thus changing the order of travel through the phase gates.
As gates are turned off, in an self repair setting, the system would reassign "temporarily" the next gate in line. For example, if gate 2 was turned off, then gate 1 would be rerouted to gate 3 automatically.
From: 1 2 3 4 5 To: 1 3 4 5
Option 2 is a bit more complex. This is the where a refined amount of control can be granted to the commander allowing complex phase situations like multiple cyclical paths or gates with multiple points of entry to emphasis key area of the map for better control.
Take a look at the second mockup image. With a button press, either on the GUI, keyboard, or a settings change that allows advanced controls an additional segment of the phase gate menu appears. <img src="http://3.bp.blogspot.com/-ebn89vr880Q/Tv8BzczEy5I/AAAAAAAAAEs/ytE_J8Fg-Gw/s320/Phase+Gate+Mockup+-+Advanced.jpg" border="0" class="linked-image" /> There are two components to the addition; control buttons (blue dots) and phase links (green lines).
As in the previous example, the phase order runs from top to bottom and as new gates are built they are added to the bottom of the list.
Lets create a scenario:
The commander builts two phase gates.
1 2
Then builds another.
1 2 3
We find that they follow the traditional phase gate route. The commander then decides that he would like 1 to go to 3 instead of 2. By click and dragging the blue dot from 1 to 3, a ghost line indicator appears until he releases the mouse. Visually, 3 will swap with 2 and the lines are automatically reconstructed. The system should automatically assume that 3 would then go to 2 because it would fall next in line.
1 3 2
The commander then builds another two phase gates.
1 3 2 4 5
Instead of having one cyclical path, he wants two smaller paths. So he drags the dot from 2 to 1 indicating that he wants 2 to teleport to 1. But, the commander is not done. 4 goes to 5, good. But, 5 is still programmed to go to 1 (the original path), so the commander drags the 5 dot to 4 creating a mini two gate path. (Picture 2)
1 3 2 4 5
Later on, the commander needs to shut down gate 2. With a self repairing system (currently in place), 3 is automatically rerouted to 1 until further customization is done to completely circumvent 2, 2 is turned back on, or is destroyed. Now, I wouldn't completely rule out the possibility of advanced controls not autorouting. The point where it is "useful" is for balancing by making phase gates more of a time investment, losing gates more detrimental, or for any other 'con' that may be needed to balance the game out.
1 3 /2 4 5
As the game progresses the commander turns gate 2 back on and then decides that there is a matter of importance to monitor gate 3. So he grabs gate 5 and tells it to route to gate 3. Now, whenever a marine enters the 4/5 route, they will inevitably enter the 132 loop. Think of it like a Q. 45 is the tail, that when followed, leads to 132, or the circle portion of Q.
This is all fine and good, but what about for the marines? As suggested visual cues on the phase gates (text like a bus route... maybe even the custom text that the commander put in. Gate 4 would show Gate 5 text) themselves may provide clarity on where the gate is going. As the game progresses from two to several gates it may be slightly intuitive for experienced players what the commander has done. But, I would vouch to have a means of clarify if a Q route develops suggested. A billboard, like in a subway, would be nice, but seems goofy... but definitely nothing that pops up in your face each time you want to phase.
<!--quoteo(post=1892207:date=Dec 31 2011, 01:50 AM:name=swalk)--><div class='quotetop'>QUOTE (swalk @ Dec 31 2011, 01:50 AM) <a href="index.php?act=findpost&pid=1892207"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Let me quote myself, just for you.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes I read that, I made the mouse menu comment on the basis that I believe a marine should be able to choose his exit location, you think he shouldn't.
Neither of us is right or wrong.
Deactivating PG's is not going to happen at all, that's a cop out. My original post in August accounts for everything you want, even if you choose to remove the ability to choose an exit location.
What can I say, I already addressed this issue months ago.
Cataclysm, forget turning of PGs, they don't need to be turned off, you also do not need a special new menu. Like in my original suggestion, all you need is for the commander to select a phase gate, and in it's comm menu should be a single button that lets it be set as the primary PG destination.
Again, turning off phase gates is not needed. Turning off phase gates is not needed. There are much more intelligent ways to handle this, without the need to turn off phase gates. Your "self-repairing" system, is also basically a rehash of my own, but needlessly more complex. As I had posted, the PG system works exactly as normal when a default destination is selected, or the marine picks a destination.
Also, I haven't seen anyone address another issue I resolved in my original post, yet most of your proposed solutions will have this problem, but nobody's foreseen it yet.
Come on guys, if you're going to make your own solutions, and ignore mine, at least get up to speed. Piggy back off of mine, I don't care, just get up there.
1. Commander-specified phase-gate destinations: Features: - Retains 'walk through phase gate' - Depending on implementation, lock and unlock phase gates, or re-route phase gates (to varying degrees) - Depending on implementation, phasegate UI button, re-routing on map or phase-gate listing (cyclical, re-orderable) Pros: - The way the game is "meant to be played": commander making decisions - The way the game is "meant to be played": walking-through matches the "gateway" art - The way the game is "meant to be played": retains movement (simply walking into the gate), and does not cause a shift in control or perspective (different control scheme using number keys or mouse selection; using UI elements*) *already present with Armory purchase menu anyway, so there is precedent. - Streamlined phasing Cons: - Commander micromanagement can be overwhelming - Does not match what the ground player necessarily wants - Can be slow to reach desired destination (multiple phases required)
2. Player-specified phase-gate destinations: Features: - Requires "using" phase gate, followed by a selection - Depending on implementation, selection on map (a la BF series spawning) or phase-gate listing (select number) Pros: - Reach desired destination in one phase - Depending on implementation (map selection a la BF series spawning), no ambiguity about destination Cons: - Breaks movement (press "use" instead of walking into the gate), and causes a shift in control or perspective (different control scheme using number keys or mouse selection; using UI elements*) *already present with Armory purchase menu anyway, so there is precedent. - Depending on implementation (phase-gate listing), confusing destination - Un-streamlined phasing
Personally, I think that all issues can be sufficiently solved or disregarded by a good implementation of either solution, and (the bottom line is that) it comes down to whether players want (personally prefer) destinations to be specified by the commander or by the players themselves. Once we get past that decision, we can work on figuring out a good implementation.
Good way to put it, Harimau... since you have a methodical approach to the solutions can you please do the same for the problems. It seems that some of us are getting a little heated over the solutions because different problems are being addressed.
I actually have been making my proposals from the standpoint that there is no problem, but after re-reading the first page a bit I do see that people are asking more for additional features rather than a solution to a problem.
<!--quoteo(post=1891785:date=Dec 26 2011, 08:26 PM:name=scotty)--><div class='quotetop'>QUOTE (scotty @ Dec 26 2011, 08:26 PM) <a href="index.php?act=findpost&pid=1891785"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->An idea could be to implement a function to either deactivate or lock the phase gate. As a comm i find this idea very helpful to redirect those marines to the front lines.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1891789:date=Dec 26 2011, 08:42 PM:name=Techercizer)--><div class='quotetop'>QUOTE (Techercizer @ Dec 26 2011, 08:42 PM) <a href="index.php?act=findpost&pid=1891789"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'd like to see some additional Com control over the PG network, either by being able to redirect phase gates at will or shut down gates that aren't in use.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1891793:date=Dec 26 2011, 08:53 PM:name=scotty)--><div class='quotetop'>QUOTE (scotty @ Dec 26 2011, 08:53 PM) <a href="index.php?act=findpost&pid=1891793"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I would find it more frustrating to have to teleport to 6 other phase gates before i got where i wanted. This isn't about herding sheep, it's about saving time / res.<!--QuoteEnd--></div><!--QuoteEEnd-->
Now, I for one, like features that expand the playability without detracting from the atmosphere. In my mind (maybe somewhat twisted) I see advanced user interfaces available to the commander... not that the marines can't have one... but, it is the responsibility of the commander to manage his buildings. Really, the only cons to that are reduced field visibility (while the menu is open) and a degree of micromanagement (but, then again, the commander can always leave it to its default route with no interaction).
On the other hand, I could see a whole new line of management where the marines not only build the buildings, but "program" them as well... but, that does not seem to be the direction this game is going. (but, who knows?)
<!--quoteo(post=1892239:date=Dec 31 2011, 12:29 PM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Dec 31 2011, 12:29 PM) <a href="index.php?act=findpost&pid=1892239"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The way the game is "meant to be played": commander making decisions - The way the game is "meant to be played": walking-through matches the "gateway" art - The way the game is "meant to be played": retains movement (simply walking into the gate), and does not cause a shift in control or perspective (different control scheme using number keys or mouse selection; using UI elements*) *already present with Armory anyway<!--QuoteEnd--></div><!--QuoteEEnd-->
Harimau - excellent breakdown, thanks for laying it out for everyone to see. The only bit I don't understand is what I quoted above, where did you see that these three points are 'The way the game is "meant to be played"'?
Personally I don't think point 1 or 2 hold up. 1- Where you go when stepping through a phase gate is directly important for you the FPS player, and only in-directly important to the commander. The commander may have told most players to go to one phase, but some other players to a different phase. I don't think limiting players to a single phase will ever be a good idea - it is taking away too much control from the player. <b>Intelligence should drive where a player goes, not lack of choice.</b>
2- Just because I'm of the "using a phase gate" mentality doesn't mean I don't think the player should literally walk through the gate. Nor do I think a UI either on the gate somewhere, or in the HUD of the FPS player would be off putting at all. Phase gate option: its a high tech piece of equipment which transports living material across space. HUD option: the marines have a screen which is projected in front of their eyes - they literally have a screen they are looking through at all times. Having a menu on that screen would be no problem - just like weapon selection, or mini-map display, etc. Both options could allow for some kind of menu. You could also transport players to a ship in orbit / awaiting nearby where they have to phase back from.
There are many ways to keep the 'using phase gate' in style of the game, the thing I'm really getting at is that stepping through phases is - and has always been - an annoying process.
Point 3 is a VERY good point, and limiting it to be the least distracting or jarring as possible is essential in my opinion too.
The reason I suggested keys is because after getting used to it, it is the quickest method I have seen and enjoyed. Even though you're removing the current use of keys (weapon selection) and replacing it with PG selection, since you're only pressing a button once there is little chance of inappropriate button pressing - and if you do, its easy to fix. Plus you are ready to press these keys anyway due to wasd.
Bringing up a map which you have to click on is.. OK, retains elements which the player is used to and just asks them to click somewhere. I just don't like that it removes the ability to look around while you're using the menu and blocks your vision. Though a combination of this and the above using keys I think could work well.
Scrolling the mouse wheel - which was suggested above - I'm fairly against, I can't tell you how finicky my mouse wheels have been in the past - sometimes one click (of the wheel) corresponds with one move on a selection list, sometimes is 3 clicks, sometimes its 5; sometimes mouse wheels are reversed; sometimes a false signal is sent that an extra click happened or the wheel is stuck between clicks; and almost always, the mouse wheel is usually the first part of a mouse to die. Moving a control (the wheel) on a moving control (the mouse) has always a persnickety task, at least for me it has, and I usually avoid using the mouse wheel in an fps at all.
<!--coloro:#00FF00--><span style="color:#00FF00"><!--/coloro--><b>botchiball</b>:<!--colorc--></span><!--/colorc--> I put "meant to be played" in <b>quotations</b> precisely because I recognise that they are subjective opinion - although a commonly-held or commonly-accepted opinion.
The first point is partially a hold-over from the Natural Selection days - that the commander should get last say in everything: he used to distribute weapons. This is perfectly valid because of the simple fact that there is a commander - one who commands, gives direction. <b>However</b>, in this case it may (depending on implementation) be unneeded or unwanted by both the commander and the players (covered by the first two "Cons"), but I'm listing it there as a "Pro" because it is. Any feature or detail can be a pro, a con, or simultaneously a pro and a con.
The second point is perfectly valid, though entirely thematic: it is a vertical gateway - gates are to be walked through horizontally; other games (and non-interactive media) have teleporters where one stands on top of the teleporter platform and then teleports, possibly with a raised panel for selection. Not just other games, in fact, Natural Selection 2 (and NS1) has it already in the form of Infantry Portals (and phase-gates as well, in the case of NS1). In this case however, we've got a literal gate, and in games (and non-interactive media) gates are something to be travelled (walked, driven, flown) through (case in point: Stargate). Actually, I'll make one amendment to what I just said: this consideration is not entirely thematic alone, but also intuitive. It would require (or at least be strongly recommended) that the gate be re-modelled into the aforementioned teleporter platform, or perhaps some sort of cage or enclosure (and possibly renamed). For example, it could be a square platform with two arches intersecting at cross-angles forming four "open walls", with a raised panel along one of the walls. Or it could be a circular platform like the infantry portal, with a raised panel at one point. I wish they had "whiteboxed" the development of the phase-gate so that we could focus on the function, and let form follow function; but in this case, the function is following the form.
Since the third point is not really disputed, I won't attempt to justify it.
However, I will discuss it in terms of its relation to the player-specified phase-gate destination idea, since that's what you've begun doing. First of all, I'll just list the features, pros and cons again: <!--quoteo(post=1892239:date=Jan 1 2012, 01:29 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 1 2012, 01:29 AM) <a href="index.php?act=findpost&pid=1892239"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->2. Player-specified phase-gate destinations: Features: - Requires "using" phase-gate, followed by a selection - Depending on implementation, selection on map (a la BF series spawning) or phase-gate listing (select number) Pros: - Reach desired destination in one phase - Depending on implementation (map selection a la BF series spawning), no ambiguity about destination Cons: - Depending on implementation (phase-gate listing), confusing destination - Un-streamlined phasing<!--QuoteEnd--></div><!--QuoteEEnd--> In retrospect, the third point we (didn't) discussed above should have also been placed as a con for this idea. I'll go edit that.
Changing of control schemes and perspectives can be jarring to the player and the experience, and should be discouraged. However, as already noted, there is a precedent with the Armory purchase screen. So this *could* be acceptable, and I will continue based on the assumption that it is:
These are the features that I would require for a player-specified destination phase-gate implementation:
+ Reworked graphics: a <u>base</u>/platform similar to the infantry portal, with a raised <u>panel</u> for selection.
- Two modes! of selection, dependent on which part of the phase-gate is "used": !1. "using" the raised <u>panel</u> would pop up a menu^ allowing you to select the destination and teleport to it; !2. "using" the <b>base</b>/platform would instantly teleport you to the pre-determined (or possibly pre-selected*) "default" destination * "default" destination could simply be either: the standard cycling we have now, the destination that the previous player selected (ease of following), or specified by the commander in some way (a compromise between player-specification and commander-specification)
^ The menu must be the same as the map with all the same information, but highlighting the phase-gates.
^ "Using" the panel once will not lock the view or provide a cursor, pressing "use" (or some other button, e.g. left-clicking with the mouse) while the map-menu is already up (i.e. pressing "use" twice, or pressing "use" then left-clicking with the mouse) will lock the view and free the cursor, allowing for manual selection of the phase-gate destination with the mouse.
^ Each phase-gate will be numbered# and clearly labelled on the map-menu. Pressing that number (or number combination) will instantly teleport you to that location. #1. EITHER 1, 2, 3, 4, 5, 6, and so on. This allows up to 10 phase-gates, but unfortunately spans the entire width of the keyboard. #2. OR 11, 12, 13, 14, 15, 21, 22, 23, 24, 25, 31, and so on. This allows up to 5x5 (25) phase-gates, and limits key-presses to the left-hand side of the keyboard, but unfortunately requires an extra key-press (e.g. 1, then 1).
So, <i>for example</i>:
Player1 <walks up to the phase-gate>, <"uses" the <u>base</u> of the phase-gate>, and teleports to the next available phase-gate by default OR the phase-gate selected by the Commander. <<2 actions.>>
Player2 <walks up to the phase-gate>, <"uses" the <u>panel</u> on the phase-gate>, <presses a numbered hotkey> ((or: <presses a numbered hotkey>, then <presses a numbered hotkey again>)), and teleports to the selected phase-gate. <<3 or 4 actions.>>
Player3 <walks up to the phase-gate>, <"uses" the <u>panel</u> on the phase-gate>, <"uses" the map menu, or left-clicks with the mouse>, <moves the cursor and clicks on a phase-gate> ((alternatively: <moves the cursor> and <clicks on a phase-gate>)), and teleports to the selected phase-gate. <<4 or 5 actions.>>
Player4 <walks up to the phase-gate>, <"uses" the <u>base</u> of the phase-gate>, and teleports to the phase-gate selected by Player3 OR the phase-gate selected by the Commander. <<2 actions.>>
(This can be contrasted with the <<1 action.>> <walk up to the phase-gate> action that the purely commander-specified phase-gate destination allows for.)
Personally, I think that all issues can be sufficiently solved or disregarded by a good implementation of either solution, and (the bottom line is that) it comes down to whether players want (personally prefer) destinations to be specified by the commander or by the players themselves. Once we get past that decision, we can work on figuring out a good implementation.
I think the idea I have described above is a good implementation, though there are two obvious disadvantages: the potential number of actions (it's a choice), and the requirement for new art assets (or you could just hack it in). The number of options (there are three: Player1/Player4's approach, Player2's approach or Player3's approach) could also, ostensibly, be overwhelming, confusing or not readily-apparent, but I think this could be easily solved by simply giving players the right information in-game.
<!--coloro:#FF00FF--><span style="color:#FF00FF"><!--/coloro--><b>Cataclyzm</b>:<!--colorc--></span><!--/colorc--> Regarding specifying the problems, it's kind of an inversion on what I've already stated with the two major sets of solutions, and the problems are rather dependent: Some solutions solve some problems, don't solve some problems, and create others. I'll try, though:
<u>Interdependent problems with different phase-gate solutions:</u> (CS = Commander-specified, PS = Player-specified, phase-gate destinations.)
1. (Default) No commander-control over destination. [1] Solved by using CS (leading to 2., 3., 4. and 5.).
2. (Default) No player-control over destination. [2] Solved by using PS (leading to 5., 6., 7., and 8.).
3. (Default) Player, potentially slow to reach desired destination (requires too many phases). [3] Solved by using PS (leading to 5., 6., 7., and 8.).
4. Commander, micromanagement. [4] Solved by NOT using CS (by extension, using PS), [4] and solved to some degree by using a very streamlined interface or simple controls (such as the drag-and-drop cyclical order suggestion, the lock/unlock phase-gate suggestion, and the re-route all phase-gates to this one phase-gate suggestion - though contributing to 1.).
5. Player, ambiguous destination. [5] Solved by using map-menu-selection under PS.
6. Player, un-streamlined phasing (requires too many actions and decisions). [6] Solved by NOT using PS (by extension, using CS), [6] and solved to some degree by using a very streamlined interface with multiple options (see my suggestion above).
7. Player, disconnect on a control/perspective level. [7] Solved by NOT using PS (by extension, using CS), [7] and solved to some degree by providing options to the player (base or panel; then hotkey or cursor; see my suggestion above).
8. Player, disconnect on a thematic/intuitive level. [8] Solved by NOT using PS (by extension, using CS), [8] and solved by creating new art assets (leading to 9.).
9. Requires new art-assets. [9] Solved by NOT using PS (by extension, using CS), [9] and solved by ignoring thematic and intuitive concerns (ignoring professionalism and internal consistency aka realism).
As Swalk had said already, any sort of delay, or PG menu/panel at the physical PG location is a mistake. While I agree, I also believe that marines need to be able to also choose PG locations easily and quickly. The deactivation or 'locking' of any PG is also a mistake, as there are models that work without the need to resort to punishing/restrictive game conditions.
When there are more than 3 PGs, a user may at any time, at any place select the PG he would next like to exit from (marines will want this amount of control). An efficient and intuitive approach to this may be achieved by a mouse wheel menu, due to the dynamic nature of placing PGs, and how a wheel can be organized statically to accept dynamic elements (PG locations), this feels like an ideal solution. This allows users to know how PG locations will be organized regardless of PG placement. This creates familiarity for the menu from game to game, and map to map (very important). This menu could be a hologram that pop's up from the marine's left arm or something, and only functions while holding "E"; your use key in a non-interactive situation (there's nothing 'use' interactive in your immediate vision), or a double tapping of the key as it allows you to use this menu in all situations, including ones where you may want to use the menu while repairing someone's armor, or building a structure. This pop's up the menu, you flick the mouse in any direction to select a PG location, and you're set, you've just picked a PG location while running to the PG, or while building that robotics factory- completely non-intrusive and incredibly easy to use. (After exiting a PG to a user selected location, that user's PG exit selection is reset.) This is incredibly fast to do, and your hands are still in proper k+m placement the entire time.
Again, commanders may pick a primary PG, which at that occurrence supersedes all user selected locations as the default location. (no need to lock other PGs whatsoever). Also, when a user selects a location after a primary PG has been set, it supersedes the commander's selection once.
Now for the problem of of PG cycling when a primary PG location is set. For example, I just phase to Heli because it's the commander selected primary exit location, and I run back into the PG, where do I go? Well, all the proposed models need a grace period, from which on exiting a PG you may re-enter it to cycle to the next in the build a-la vanilla phase mechanics, this is a recursive process from phase gate to phase gate until a user does not re-enter one within the grace period, at which, the PG system resets for that player. This allows the old system to work as it does currently, so new players, as either a marine or commander may play unaffected and learn the advanced nuances at their own rate.
As for the mouse wheel menu, each PG gets a dynamic entry on the menu, which lists it's location, and possibly it's build order. The color of the menu item for each PG is one of 3 depending on whether that PG is the commander selected primary, user selected exit, or just a regular PG. Having a PG menu item flash red as it takes damage is also an option for increased team transparency (more of this is better in tactical games like NS). As for the wheel's static construct, imagine the circle overlaying the mini-map, for summit, pg locations on this minimap correspond to their locations on the pg menu wheel, and are dynamically sized/placed. This allows menu familiarity that is preserved from game to game despite the dynamic nature of structure placement.
Simple, intuitive, <u>does not break the current model at all</u>, with full functionality, annnnnnd, for all the nay sayers of my proposed mouse wheel selection system, you don't have to use it as it is non-intrusive. ;)
As a commander in late game, I'd like to be able to have my players actively navigate the PG network on their own, as efficiently as possible, my time and resources should not be spent monitoring and maintaining an overly and needlessly complex PG network, it's literally not needed at all. Those 3 guys that are watching DC can now spawn and 1 PG to it every time, rather than having me set up some special conditions for them to do so, and then do it again for the next guys, and then back to DC again for those guys, and then to crev for another group of guys -> you see where I am going with this.
<!--quoteo(post=1892315:date=Jan 1 2012, 07:28 PM:name=Kalabalana)--><div class='quotetop'>QUOTE (Kalabalana @ Jan 1 2012, 07:28 PM) <a href="index.php?act=findpost&pid=1892315"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->As Swalk had said already, any sort of delay, or PG menu/panel at the physical PG location is a mistake.<!--QuoteEnd--></div><!--QuoteEEnd-->
Er, why?
The whole point of phase gates is that they are time savers, it doesn't matter if it takes a couple of seconds to use one, it's still dozens of times faster than walking.
PGs already have delays, you have to find amd go to the phase gate, you usually have to go through it once or twice to get to your destination, and you have a second or two of disorientation from the teleport.
Putting a map selection in will actually take time off of the last two parts, as you always go where you want to go, and showing your arrival location on a map will help you plan out ahead of time where you will emerge, so it shouldn't add any significant delay to using them.
The whole point of phase gates is that they are time savers, it doesn't matter if it takes a couple of seconds to use one, it's still dozens of times faster than walking.
PGs already have delays, you have to find amd go to the phase gate, you usually have to go through it once or twice to get to your destination, and you have a second or two of disorientation from the teleport.
Putting a map selection in will actually take time off of the last two parts, as you always go where you want to go, and showing your arrival location on a map will help you plan out ahead of time where you will emerge, so it shouldn't add any significant delay to using them.<!--QuoteEnd--></div><!--QuoteEEnd--> Nonsense. Phase gates are time savers, true, but it <b>does</b> matter if it takes an extra second to get through it when you have to defend it. Adding a menu for people on the ground is a real time waster, instead, have the commander organize it in some way or another. Good players orientate themselves by looking at the map before going through the phase gate, that way it's possible to find your targets faster when using a phase gate.
<b>Kalabalana</b>: I honestly don't think that's intuitive because you have to pop up a separate menu that is very specific to a situation (phase gates) when it does not match the context at all (you aren't necessarily near or facing a phase-gate), and I don't feel that it saves time because, instead of time spent at the phase-gate, you simply have time spent before the phase-gate. If there were a specific phase-gate key then that would be fine, but I would advise against it because players shouldn't have to learn so many keys, especially for a practically niche function. Now, if there were a key for a soldier menu (it was right-click in NS1), under which people could perform many functions INCLUDING specifying the next phase-gate exit point, then I think it could work really well.
It seems like, more than implementation, people just can't agree on whether we should have exit points specified by the commander or by the players themselves.
I am leaning towards a hybrid system - where the commander gets first say (with one manner of specification or another) but the soldier, if they wish, gets last say. So I proposed the following system: <!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->These are the features that I would require for a player-specified destination phase-gate implementation:
+ Reworked graphics: a <u>base</u>/platform similar to the infantry portal, with a raised <u>panel</u> for selection.
- Two modes! of selection, dependent on which part of the phase-gate is "used": !1. "using" the raised <u>panel</u> would pop up a menu^ allowing you to select the destination and teleport to it; !2. "using" the <b>base</b>/platform would instantly teleport you to the pre-determined (or possibly pre-selected*) "default" destination * "default" destination could simply be either: the standard cycling we have now, the destination that the previous player selected (ease of following), or specified by the commander in some way (a compromise between player-specification and commander-specification)
^ The menu must be the same as the map with all the same information, but highlighting the phase-gates.
^ "Using" the panel once will not lock the view or provide a cursor, pressing "use" (or some other button, e.g. left-clicking with the mouse) while the map-menu is already up (i.e. pressing "use" twice, or pressing "use" then left-clicking with the mouse) will lock the view and free the cursor, allowing for manual selection of the phase-gate destination with the mouse.
^ Each phase-gate will be numbered# and clearly labelled on the map-menu. Pressing that number (or number combination) will instantly teleport you to that location. #1. EITHER 1, 2, 3, 4, 5, 6, and so on. This allows up to 10 phase-gates, but unfortunately spans the entire width of the keyboard. #2. OR 11, 12, 13, 14, 15, 21, 22, 23, 24, 25, 31, and so on. This allows up to 5x5 (25) phase-gates, and limits key-presses to the left-hand side of the keyboard, but unfortunately requires an extra key-press (e.g. 1, then 1).
So, <i>for example</i>:
Player1 <walks up to the phase-gate>, <"uses" the <u>base</u> of the phase-gate>, and teleports to the next available phase-gate by default OR the phase-gate selected by the Commander. <<2 actions.>>
Player2 <walks up to the phase-gate>, <"uses" the <u>panel</u> on the phase-gate>, <presses a numbered hotkey> ((or: <presses a numbered hotkey>, then <presses a numbered hotkey again>)), and teleports to the selected phase-gate. <<3 or 4 actions.>>
Player3 <walks up to the phase-gate>, <"uses" the <u>panel</u> on the phase-gate>, <"uses" the map menu, or left-clicks with the mouse>, <moves the cursor and clicks on a phase-gate> ((alternatively: <moves the cursor> and <clicks on a phase-gate>)), and teleports to the selected phase-gate. <<4 or 5 actions.>>
Player4 <walks up to the phase-gate>, <"uses" the <u>base</u> of the phase-gate>, and teleports to the phase-gate selected by Player3 OR the phase-gate selected by the Commander. <<2 actions.>>
(This can be contrasted with the <<1 action.>> <walk up to the phase-gate> action that the purely commander-specified phase-gate destination allows for.)
I think the idea I have described above is a good implementation, though there are two obvious disadvantages: the potential number of actions (it's a choice), and the requirement for new art assets (or you could just hack it in). The number of options (there are three: Player1/Player4's approach, Player2's approach or Player3's approach) could also, ostensibly, be overwhelming, confusing or not readily-apparent, but I think this could be easily solved by simply giving players the right information in-game.<!--QuoteEnd--></div><!--QuoteEEnd--> <i><b>In summary</b></i>, we have: - Commander specifies default exit point*: Press 'use' on the <u>base</u> to instantly phase. This would barely take any more time than the current system. - Player specifies exit point**: Press 'use' on the <u>panel</u> to bring up a map-menu to select an alternative exit point. This would take some time, and there are different options, but it gives the player full control.
* Having said that, I do think there's value in a "follow the leader" mechanic. (That is, rather than the commander specifying the default exit points, the last-specified exit point by any player becomes the default exit point.) It would naturally mean that the players behind phase to the same location as the players in front.
** This could actually be compatible with Kalabalana's suggestion, as an addition. A player could pre-specify what their exit point is, while en route to the phase gate itself, press 'use' on the <u>base</u> and instantly teleport there.
In fact, inspired by the mousewheel idea, we could further expand my map-menu idea so that: After pressing "use" on the <u>panel</u>: 1. Player uses numbered hotkeys to select destination and instantly phase there, or 2. Player uses mousewheel to cycle through and highlight their destination, and left-clicks to instantly phase there, or 3. Player presses right-click to lock the view and free the cursor, and left-clicks on a destination to instantly phase there. These options in addition to: 4. Player individually pre-selecting the exit point, pressing use on the <u>base</u> of any PG to instantly phase there, or 5. Player pressing 'use' on the <u>base</u> without pre-selection, instantly phasing to the commander-specified default exit point OR the last player-specified exit point.
Lots of options to let players choose the one they're most comfortable with (or the one best suited to the situation), but all have the exact same effect (with the exception of 5).
<!--quoteo(post=1892343:date=Jan 2 2012, 05:07 AM:name=swalk)--><div class='quotetop'>QUOTE (swalk @ Jan 2 2012, 05:07 AM) <a href="index.php?act=findpost&pid=1892343"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Nonsense. Phase gates are time savers, true, but it <b>does</b> matter if it takes an extra second to get through it when you have to defend it. Adding a menu for people on the ground is a real time waster, instead, have the commander organize it in some way or another. Good players orientate themselves by looking at the map before going through the phase gate, that way it's possible to find your targets faster when using a phase gate.<!--QuoteEnd--></div><!--QuoteEEnd-->
Then why would the good players be delayed by the map appearing then? If they look at it anyway.
And no, a second does not make any signficant difference. The number of situations where a second is the difference between winning or losing is so infinitesimal that it is not worth considering. Simple statistical analysis would tell you that. Given that it takes about 30 seconds to destroy a phasegate, and several players could go through it at any time during that 30 seconds, and any one of them could kill the thing destroying it, and the destruction of any given phase gate could very easily not be a signficiant factor in the battle, and the situations where a second would matter are just so few that it's laughable.
Furthermore, it is far more probable that the commander would not react in time to enable or disable a phase gate when a player needs to use it or needs to bypass it, which means that commander control is almost certainly going to be far more troublesome than player control. Not to mention it smacks of stupid busy work and power grabbing for anal retentive commanders who don't feel like they are pro enough unless they can micromanage every last second of the marine experience.
I'm not mentally deficient, I don't need the commander to tell me what phase gates I can and can't use.
^ Hence why I suggest two modes of selection*: *needs new art assets (base/panel), or just bull###### it.
::1:: Pressing 'use' on the base of the PG teleports you instantly to whatever is selected by the commander as the exit point.
::2:: Pressing 'use' on the panel of the PG allows you to select your own exit point*. *2 or 3 different methods to do so
Additionally, adapting Kalabalana's idea: ::3:: Pre-selecting (with a soldier menu) the next exit point for a PG, then pressing 'use' on the base/panel* of the PG teleporting you instantly to your pre-selected exit point. *unsure if :1: or :2: should take precedence (or neither).
Just to have it mentioned since I didn't spot it yet in this thread... I also don't want to make it difficult for when I flee through a phase gate in panic with a fade blinking after me. Granted, that could be a balance trait to inhibit quick escapes.
I think user selected destinations should be added to the game, but it has to be done in a very simple and easy way. Having any sort of physical location to which you must be at to select a PG is inferior to an always available pop-up menu, especially one that can be used while building something, or running (You're not wasting any time). Binding phase gates to keys is another problem, both in the limit of keys, and the hassle of selecting them on the keyboard, also, the organization of the pg's over keys would be different every game, which would be very bad. Having commanders controlling which phase gates are active and the pathing between them again is too much work, the commander does not need to worry about this, and the benefit of doing such is basically null on the marine end of things.
So all in all based on responses in this thread, I think it's looking to be impossible to satisfy everyone.
<!--quoteo(post=1892529:date=Jan 4 2012, 12:47 AM:name=Kalabalana)--><div class='quotetop'>QUOTE (Kalabalana @ Jan 4 2012, 12:47 AM) <a href="index.php?act=findpost&pid=1892529"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think user selected destinations should be added to the game, but it has to be done in a very simple and easy way. Having any sort of physical location to which you must be at to select a PG is inferior to an always available pop-up menu, especially one that can be used while building something, or running (You're not wasting any time). Binding phase gates to keys is another problem, both in the limit of keys, and the hassle of selecting them on the keyboard, also, the organization of the pg's over keys would be different every game, which would be very bad. Having commanders controlling which phase gates are active and the pathing between them again is too much work, the commander does not need to worry about this, and the benefit of doing such is basically null on the marine end of things.
So all in all based on responses in this thread, I think it's looking to be impossible to satisfy everyone.<!--QuoteEnd--></div><!--QuoteEEnd--> Why?
You're operating under the assumption that there can only be one solution that everyone has to use. There's no reason to think like that, since these options don't really affect the gameplay on a small scale (it's not like the skulk view rotation vs no view rotation argument). It is perfectly acceptable (perhaps imperative, in this case) for players to have many different options to perform the same function (phasing "somewhere"). It follows the same logic as key re-binding.
In this case, no solution is objectively superior or inferior, only subjectively superior or inferior. So why not have the best of all worlds?
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->^ Hence why I suggest two modes of selection*: *needs new art assets (base/panel), or just bull###### it.
::1:: Pressing 'use' on the base of the PG teleports you instantly to whatever is selected by the commander as the exit point.
::2:: Pressing 'use' on the panel of the PG allows you to select your own exit point*. *2 or 3 different methods to do so
Additionally, adapting Kalabalana's idea: ::3:: Pre-selecting (with a soldier menu) the next exit point for a PG, then pressing 'use' on the base/panel* of the PG teleporting you instantly to your pre-selected exit point. *unsure if :1: or :2: should take precedence (or neither).<!--QuoteEnd--></div><!--QuoteEEnd--> The commander does not need to specify exit points, but he can. Players do not need to spend time selecting their own exit points, but they can. Players do not need to pre-select their own exit points using a pop-up menu, but they can. Players do not need to use hotkeys, but they can. Players do not need to use the mousewheel, but they can. Players do not need to use the cursor, but they can.
Are you implying that having only one solution is objectively better than a choice of multiple solutions? Or that one solution will be discovered as objectively better than any other solution? If so...
That's not applicable.
Does your OS look and work the same as everyone else's, and do you use it the same way as everyone else? I know mine doesn't, and I know I don't. Maybe if you use a Mac... Apple are big on standardisation. But even that has options and customisation.
When I want to move a file to another folder, I have several different options: - Drag and drop between different windows. - Select the file, right click, click cut, change folder, right-click, select paste. - Select the file, ctrl-x, change folder, ctrl-v.
Do I use any option to the exclusion of all others? No. There's a time and a place.
<!--quoteo(post=1892599:date=Jan 4 2012, 12:04 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 12:04 AM) <a href="index.php?act=findpost&pid=1892599"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Are you implying that having only one solution is objectively better than a choice of multiple solutions? Or that one solution will be discovered as objectively better than any other solution? If so...<!--QuoteEnd--></div><!--QuoteEEnd--> No. I just believe that simplest solution that satisfies all the needed conditions is what we should use.
The problem is, everyone thinks their own idea is the best, but regardless of how good an idea is, we should be able to see which presented models are the simplest (we can). Compare the models on your own, and see which have the simplest answers. The focus is on the end-user, and how easy it will be for them.
For example, my model allows both a commander and the marine to do absolutely everything required in a single step. Whether it's picking an exit location, or setting a primary exit location. Other models require multiple steps to achieve the same goal(s), this is not optimal, and will only affect the game negatively, especially when you play at the competitive level.
I think you've got an ideal, and it's a good ideal, but it isn't practically applicable to this situation.
If I understood your suggestion correctly, there are a number of "issues" with it: - The pop-up menu potentially obscures parts of the view of the game-world. (This is common to all suggestions except where it's commander-specified-only. This is less of an issue with usable panels or interfaces e.g. the Armory, because by moving towards one you are naturally already having your view obscured by the object.) - The pop-up menu is specific to phase-gates alone, leading to an extra key that needs to be learned and used. - This extra key seems unwarranted, because it is a function that is not used from the start of the game or for the entirety of the game. - The pop-up menu is not at all context-sensitive, and therefore less intuitive. - The pop-up menu requires cycling through a list of phase-gates with a mouse-wheel, which is not the most ergonomic or accurate controller. - In no other feature (or game) is this style of menu available, so it is not easily accessible. - The list of phase-gates do not visually represent the phase-gates, and so do not convey focused, important information and will be ambiguous and can be confusing or lead to information-overload (like this sentence). - The commander gets no direct input to marine exit points.
These are the advantages that you propose: - Giving players the ability to specify exit points. This is also present in other suggestions. - A somewhat more streamlined approach than other suggestions. Either holding a key or pressing a key, and selecting (and pressing the key again, if it was a toggle); followed by walking into a phase-gate. This is less streamlined than commander-specified approaches, but more streamlined than other player-specified approaches. However, rather than time spent at the phase-gate, it merely becomes time spent before the phase-gate. - Mobility and ability to react while doing so. Reacting ability is mitigated in part by the fact of view-obscurity. Mobility is less needed in panel/interface-selection because you are already standing still, and less needed in general when you consider that you are about to exit that location anyway. - Less bottle-neck at phase-gates since all marines will walk through phase-gates. This issue could be mitigated in other suggestions by allowing more than one marine to occupy a phase-gate at once, just as the Armory can be, as well as forced phasing of people who take too long (a likely rare occurrence).
In conclusion, I see no reason not to have the benefits of your suggestion, along with the benefits of other suggestions, since by doing so, we can fit each method to different playstyles or situations, and mitigate any imperfections a single method might have through the choice of different methods.
<b>- I mean how many phasegates are build in an average game?</b> Guess its around 2-5 1 for each techpoint/hive location, 1 in the main base...
Assuming it takes around 2-3 seconds to jump from phasegate to phasegate its 10-15*s make a full circle with 5 phasegates. Thats 8-12* seconds to get were you want to in a worse case scenario...
*missing the time you need to get to the first phasegate
<b>- Should it be ok to spam phasegates, or should there be a downside to this?</b> There should be a downside, and the downside is - the more you have the longer the traveltime gets because you have to jump from phasegate to phasegate to phasegate. Either optimize by recycle or live with it.
______________________________
I think the current pg system is ok, but we could add an
<u><b>EMERGENCY REDIRECT</b></u> button... In case of an emergency you can activate this on a pg (pg portal color changes to red on this pg)
Every phasegate on the map will redirect you to this phasegate. (tho it disables jumps to somewhere else after you went trough it, so you cant save yourself and jump back for the time this is active)
- This could cost a fixed amount of tres, pres or energy and have a fixed timer... (~15-30s) - Or it could drain Y tres/pres or energy on that phasegate for every Z seconds it is activated... (with a minimum of X for the activation) - i like this better. (i kinda like the idea that you cant jump away after this is activated... so if the commander disables the redirect it takes another 5-10s until you can go into this pg again - coming out is possible at anytime, just going in takes this extra amount of time after the redirect is disabled)
edit: this could also make some cool sound and message in the player ui similar to distress beacon. edit2: energy is a crappy resource... so i really would like to see it cost tres or pres along with other stuff like beacon. (but thats another topic, isnt it? :P)
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The pop-up menu potentially obscures parts of the view of the game-world. (This is common to all suggestions except where it's commander-specified-only. This is less of an issue with usable panels or interfaces e.g. the Armory, because by moving towards one you are naturally already having your view obscured by the object.)<!--QuoteEnd--></div><!--QuoteEEnd--> While this is true, the menu would be transparent, and realistically will only be visible for a fraction of a second as players get used to it. Also most games can produce their comma rose usually very visually open.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The pop-up menu is specific to phase-gates alone, leading to an extra key that needs to be learned and used. - This extra key seems unwarranted, because it is a function that is not used from the start of the game or for the entirety of the game.<!--QuoteEnd--></div><!--QuoteEEnd--> This functionality can be stacked on top of the current use key, for most that is "e". The double tapping, or holding down of this button brings extra functionality without requiring any extra keyboard Olympics, or the use of a new key. Maybe holding the jump key would be a better choice.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The pop-up menu is not at all context-sensitive, and therefore less intuitive.<!--QuoteEnd--></div><!--QuoteEEnd--> The menu elements can be placed in the same place dynamically retaining familiarity despite unique placement over different games. Menu elements also will use up as much visual real estate as possible, so in the early game, 3 phase gates are going to have 120 degree portions of the wheel. Also, imagine the comma rose overlapping the minimap, that is how the PG locations will be placed in the same way, transcending different games.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The pop-up menu requires cycling through a list of phase-gates with a mouse-wheel, which is not the most ergonomic or accurate controller.<!--QuoteEnd--></div><!--QuoteEEnd--> No, it does not, I think we have a bit of a broken telephone thing going on here, what I'm proposing is a mouse menu wheel, it does not use the mouse wheel at all. It pops up something that looks like a doughnut, that along it's circumference overlaps the map, so a DC pg will always be on the right side of this circle with which you just flick the mouse to the right to select. Here's more information to illustrate the mouse wheel concept. <a href="http://www1.pcmag.com/media/images/226191-circle-dock-after.jpg" target="_blank">1</a> <a href="http://images.wikia.com/masseffect/images/1/19/Powerwheel.jpg" target="_blank">2</a> <a href="http://www.goalqpc.com/dotcom/images/ElephantWheel.jpg" target="_blank">3</a> <a href="http://i54.tinypic.com/2u89frm.jpg" target="_blank">4</a> <a href="http://xboxoz360.files.wordpress.com/2011/05/oxcgns-brink-review-oxcgn-5-class-change.jpg" target="_blank">5</a>
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- In no other feature (or game) is this style of menu available, so it is not easily accessible.<!--QuoteEnd--></div><!--QuoteEEnd--> The mouse menu, or comma rose, is in several games, BRINK, Battlefield, Mass Effect, etc.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The list of phase-gates do not visually represent the phase-gates, and so do not convey focused, important information and will be ambiguous and can be confusing or lead to information-overload (like this sentence).<!--QuoteEnd--></div><!--QuoteEEnd--> I did not adequately convey to you the idea I had proposed, so I understand where you are coming from, but from above now you know what I mean.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The commander gets no direct input to marine exit points.<!--QuoteEnd--></div><!--QuoteEEnd--> Yes, when he sets a primary phase gate exit location, it resets all current marine selections, and as such, all PG travel will now go to that phase gate (unless a marine specifically picks a new location after this point). This does make marines feel forced to hit a location, but if a commander wants, he can keep setting the primary location, effectively disabling the marine's ability to ignore going to that location. Realistically though, there are exceptions, and even though you may want most of your team going to a point, you will still have men on the side doing jobs at other locations, these marines should remain unimpeded.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->These are the advantages that you propose: - Giving players the ability to specify exit points. This is also present in other suggestions. - A somewhat more streamlined approach than other suggestions. Either holding a key or pressing a key, and selecting (and pressing the key again, if it was a toggle); followed by walking into a phase-gate. This is less streamlined than commander-specified approaches, but more streamlined than other player-specified approaches. However, rather than time spent at the phase-gate, it merely becomes time spent before the phase-gate. - Mobility and ability to react while doing so. Reacting ability is mitigated in part by the fact of view-obscurity. Mobility is less needed in panel/interface-selection because you are already standing still, and less needed in general when you consider that you are about to exit that location anyway. - Less bottle-neck at phase-gates since all marines will walk through phase-gates. This issue could be mitigated in other suggestions by allowing more than one marine to occupy a phase-gate at once, just as the Armory can be, as well as forced phasing of people who take too long (a likely rare occurrence).
In conclusion, I see no reason not to have the benefits of your suggestion, along with the benefits of other suggestions, since by doing so, we can fit each method to different playstyles or situations, and mitigate any imperfections a single method might have through the choice of different methods.<!--QuoteEnd--></div><!--QuoteEEnd--> By no means do I think my idea is the best for the game, but trust me, it will work very well in game, especially with the comma-rose/wheel menu selection process I am suggesting. Which has two main strengths, ease of selection due to using the mouse, and it's coupled with the natural ability to place structures according to their location(s) on this menu, such that you'll basically be able to pick PG locations blind. The only downfall I see in this model, is for PG's placed in the middle of a map, but I believe they can occupy another circle in the middle of the comma rose wheel. Also of note, selecting locations along the comma rose wheel does not require perfect mouse control, you just need to create a vector from the center of the menu to the end location of the mouse, and which ever border element it intersects would be your selection. This allows for a pop-and-slide functionality, where as the menu comes up, you can simply just 'flick' your mouse in the direction of the PG, or area you want to select. This can be done extremely quickly on the fly.
<!--quoteo(post=1892621:date=Jan 4 2012, 05:35 PM:name=Koruyo)--><div class='quotetop'>QUOTE (Koruyo @ Jan 4 2012, 05:35 PM) <a href="index.php?act=findpost&pid=1892621"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Do we really need complex systems?<!--QuoteEnd--></div><!--QuoteEEnd--> According to this thread: Yes. That is the entire premise of this thread.
...and then you proceed to make your own suggestion. I'm no expert on irony, but...
Kalabalana: So you were talking about a "radial menu", not the physical mouse-wheel. Got it. That clears a lot up.
You shouldn't use the use key because the use key is for context-sensitive actions, and this would be the exact opposite. Also, as I've mentioned, PG exit point specification is a very niche setting that is not present for the entire duration of the game or from the start of the game at all - so it cannot warrant its own control (pressing "use" in the middle of nowhere does qualify as the PG function having its own control). The jump key is even worse: you should never re-tool a movement key to another function; it also plays havoc with jetpacks, and well, jumping in general. Linking it to a sub-function of an existing menu would be fine. For example, a soldier menu (like we had in NS1), the communications menu (which I would say should be a radial menu), or the map key (combine the interface) this may also address the following concern:
"- The list of phase-gates do not visually represent the phase-gates, and so do not convey focused, important information and will be ambiguous and can be confusing or lead to information-overload (like this sentence)." You've still misunderstood me. Even radial menus still do not convey the proper information. Anything that does not represent it visually (i.e. correspond to the map) will not convey the proper information. How can you easily tell which PG icon is linked to which PG? They don't easily correspond to the map.
I dislike your implementation of commander specified PG exit points. I believe the commander should have all the say (he sets all the exit points, and players have to live with it), OR players should have all the say (and commanders can only "advise" - through the use of waypoints and setting default PG exit points). Doing it your way means the commander can effectively take something that is normally available away from the players.
The biggest problems with your suggestion as it is, is that it will not easily conform to actual PG locations on the map, and that even if they approximate it, one will still not know how it corresponds to the map (or if they indeed want to travel to that location) because they are two separate interfaces.
Another issue would be the dynamic nature of the radial menu (even though this is supposed to be a plus). People will get used to swinging the mouse in a certain direction to correspond to a certain PG. Then a PG gets destroyed, or the commander builds a new PG, and the radial menu will necessarily change, and what people were used to a moment ago is no longer relevant - they may not even have the feedback that what they were used to is no longer relevant since they haven't seen the map and neither has the game informed them. Even if they remembered the positions of the 3 different PGs, perhaps now 2 of those PGs are in different locations, and not only do the radial menu options not necessarily correspond to physical locations, the menu has just shuffled itself around: This information is not easily available to the player, and so this information (the control/selection for each PG) is newly obfuscated every time a PG goes up or down.
Do you see what I'm getting at here?
I do have some ideas about trying to improve on your suggestion, to help mitigate some of these issues. - The first is that the player gets the last say as to their next exit point: the commander can only encourage it by setting default exit points. - The second is that we'll keep the radial menu, but it will be a sub-function of the map key (haven't worked out how best this would be done; probably by pressing the map key, then holding left-click to activate the PG-selection sub-function); when the PG-selection sub-function is active, each radial menu option will have an arrow that leads to the corresponding PG on the map. When hovering over a radial menu otion, that corresponding PG and its radial menu option will be highlighted while all other options will be subdued. - When a PG is used, the selection is immediately cleared. - Leaving the mouse in the centre of the screen when using the radial menu will clear (cancel) any selection. - Every time a PG goes up or down, upon opening the map next, it will flash: to unambiguously illustrate to the player that the PG locations have changed; and that they have to clear their assumptions. As a bonus, this would, by extension, also indicate when the first PG goes up.
What issues still remain? 1) Temporary obscuration of a somewhat significant portion of the screen. 2) Temporary lack of mouselook. 3) Not the most optimally streamlined: requires pressing (or maybe holding) the map key, then holding the left mouse button. 4) This particular implementation (3) would also mean you couldn't fire since the left mouse button would be occupied (on the other hand, with the lack of mouselook (2), why would you?)
Issues 1 and 2 are necessary, but at least on temporary. Issues 3 and 4 (the control scheme) can possibly be improved on.
To be honest I hadn't thought of phase gates being destroyed, and their radial menu elements being removed. You're right, that would effect what people are used to.
The problem with a menu I see, is that there will not be an efficient implementation of marine chosen phase gates without a visual menu. So what would be the best one?
Absolutely no player should have any power to restrict the movement of any other player, this is just general game design, this is why I feel the most power a commander should have is picking the default gate position for exit, and marines can still trump this (they are not forced to do anything).
The button issue is a real one, I haven't had that realization of any perfect implementation, I'd like to add extra functionality to another key, but again, I don't know which one. Maybe flashlight, since it's only used in single click situations? It will now have dual functionality, quick press toggles light, hold brings up menu?
I had no clue it was called a radial menu, I just had an idea in my mind, and didn't know the name to place on it, thank you for that.
So what can we do? Given all the suggestions, we should be able to figure out what will be the best implementation?
EDIT: Would love a audio and possibly HUD confirmation of location selected, maybe the game will say the pg location like "Data Core" in that Unreal tournament narrator voice or something similar. As for a visual cue, maybe a very small streamlined box, or line of text artistically attached to a side of the minimap shows your current next pg location, based on proximity to nearest pg showing marine selection, commander selection, or next in cycle.
Also, to clarify on my radial menu, and how elements are added to them, I imagine we can add menu items based on locations on the map, they become 'seeded' on this wheel accordingly, and the size of each selection is dynamically determined based on how much radial wheel space is available on either side the button. This allows optimal sizing while retaining the 'feel' of a location corresponding to it's physical placement on the map.
Again, the way that the radial menu corresponds to the map is not immediately obvious, and this is the biggest issue - this is because the map and the radial menu are mutually exclusive. Even if a player perfectly memorises the locations of PGs on the map, then opens the radial menu for PG selection, he'll still have to do some mental gymnastics to determine which radial menu option selects which. This is exacerbated when PGs go up or down, and this perfect-memory player hasn't assiduously checked the map prior to every time he opens the radial menu. That's why I think that whatever menu we do use for PG selection - radial menu, map menu (BF-series style spawn locations) or otherwise - it should be linked to the map, since that is the easiest way to overcome ambiguity and directly convey the appropriate information.
The flashlight is not <b>as bad</b> as the jump key idea, but follows along the same lines. It is a "game world" key, not a "HUD/interface" key.
I honestly think we have only 3 options: - Tie it as a sub-function of the communications menu. - Tie it as a sub-function of a soldier menu (like we had in NS1, which also served as the communications menu). - Tie it as a sub-function of the map view, which would be the best implementation for reasons previously stated.
In terms of default keys, I think we have the following options (omitting all movement keys): - Q(last used weapon key), E (use key), R(reload key), T (chat key), F (flashlight key), G, Tab (scoreboard key), Shift (can't, sprint key), Alt -> Realistically, we have G and Alt And some secondary options (harder to use): - ~, 1*, 2*, 3*, 4*, 5, 6, Z, X, C, V, B (*weapon slot keys) -> Realistically, we have ~, 5, 6, Z, X, C, V, B Of the primary options, G and Alt are, I don't think, used for anything else (alt-tab used for switching windows, I guess) - so I would make one of these the combined Map/PG-Selection key, and the other the Communications key.
Regarding the commander restricting the players - that's precisely why I prefer that commanders get no final say, or all the final say: - if players are used to being able to move between PGs at will, then taking that ability away from a player is a bad idea, which is why in this case, the commander should only be able to specify 'default' PG exit points, and the player can override that at will - however, on the other hand, if players are used to going where the commander allows them to go, this isn't exactly taking the ability away from the player, since they never had that ability to begin with Having said that, I am currently leaning towards the former (player-specified with commander-specified-defaults) rather than the latter (commander-specified-only) implementation.
EDIT: Actually, it appears you posted before I finished editing my post - I had some suggestions as to how to improve on your idea, and may have edited part of the bits prior to that as well.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->...and then you proceed to make your own suggestion. I'm no expert on irony, but...<!--QuoteEnd--></div><!--QuoteEEnd-->
So what is complex? Adding my idea? (which only adds a button on phasegates for the commander) Or yours? (which is changing the whole mechanic on phasegate travel)
If you dont like my idea - ignore it, or make a proper answer why you dont like it, and why we need your mechanic for average 3-4 pgs in a game.
Comments
No thanks, that would delay me each time I have to go through a PG.
What would be more efficient? Other than simply removing the ability to choose a destination?
Let me quote myself, just for you.
<!--quoteo(post=1891980:date=Dec 28 2011, 08:30 PM:name=swalk)--><div class='quotetop'>QUOTE (swalk @ Dec 28 2011, 08:30 PM) <a href="index.php?act=findpost&pid=1891980"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Just make as simple as the commander turns off undesired teleporting from specific phase gates.
You press a phase gate, press turn off in the selection menu/hotkey. Press again to turn on.
I wouldn't like any menu's or other systems for people on the ground, it should be down to the commander to make the right decision.
Such systems make it both annoying and slower to use the phase gates.<!--QuoteEnd--></div><!--QuoteEEnd-->
Upon the selection of a phase gate in the field of play a graphical menu expands into view. As seen in the example image, a list of all the currently built phase gates appears within the graphical menu where the currently selected phase gate is highlighted (for purposes of helping a commander differentiate between multiple phase gates within the same room/area).
<img src="http://1.bp.blogspot.com/-jBtDyl_gRLw/Tv8BzWg-BCI/AAAAAAAAAEc/3iiqHtinSQg/s1600/Phase+Gate+Mockup.jpg" border="0" class="linked-image" />
The list is broken down into two parts; a phase gate icon per phase gate (in reality the icons should probably be smaller to allow for more gates) and a text field that indicates which room the phase gate resides in.
The images indicate the current state of the phase gate; on (green shade) or off (red shade).
By clicking on any of the the phase gate icons, the associated gate is toggled between the two states.
To quick jump and center the commander view onto any desired phase gate, the commander can click the text field correlating to the appropriate gate. This helps with identifying which phase gate is which in the list as well as provide another means of accessing "quick views". A nice touch would be to allow for custom text by means of right clicking the text to aid in organizational and interpretation of the which gate is which.
By default, a newly built phase gate would be added to the bottom of the list. Thus, in this example, if a sixth phase gate were built, it would appear below the fifth phase gate. The phase order would follow exactly as the list displays. In the simple interface, there would be no reordering of phase gates.
For more advanced control I would propose two possible solutions.
1.) A simple reordering of a single cyclical path.
2.) A complex reordering that would allow multiple cyclical paths.
In addition to this, the issue that should be addressed is whether paths should be self repairing in the event that a gate is turned off. In the simple interface this would seem like a natural thing that should be done. But, what about under advanced control?
Let's elaborate on option 1. Still taking a look at the simple interface, a reorder would be accomplished much like rearranging icons on a smart phone (I personally don't have one). Click and hold on the phase gate text field and then drag above or below to the desired location. The icons would shift to make room for the new order, thus changing the order of travel through the phase
gates.
As gates are turned off, in an self repair setting, the system would reassign "temporarily" the next gate in line. For example, if gate 2 was turned off, then gate 1 would be rerouted to gate 3 automatically.
From: 1 2 3 4 5
To: 1 3 4 5
Option 2 is a bit more complex. This is the where a refined amount of control can be granted to the commander allowing complex phase situations like multiple cyclical paths or gates with multiple points of entry to emphasis key area of the map for better control.
Take a look at the second mockup image. With a button press, either on the GUI, keyboard, or a settings change that allows advanced controls an additional segment of the phase gate menu appears.
<img src="http://3.bp.blogspot.com/-ebn89vr880Q/Tv8BzczEy5I/AAAAAAAAAEs/ytE_J8Fg-Gw/s320/Phase+Gate+Mockup+-+Advanced.jpg" border="0" class="linked-image" />
There are two components to the addition; control buttons (blue dots) and phase links (green lines).
As in the previous example, the phase order runs from top to bottom and as new gates are built they are added to the bottom of the list.
Lets create a scenario:
The commander builts two phase gates.
1 2
Then builds another.
1 2 3
We find that they follow the traditional phase gate route. The commander then decides that he would like 1 to go to 3 instead of 2. By click and dragging the blue dot from 1 to 3, a ghost line indicator appears until he releases the mouse. Visually, 3 will swap with 2 and the lines are automatically reconstructed. The system should automatically assume that 3 would then go to 2 because it would fall next in line.
1 3 2
The commander then builds another two phase gates.
1 3 2 4 5
Instead of having one cyclical path, he wants two smaller paths. So he drags the dot from 2 to 1 indicating that he wants 2 to teleport to 1. But, the commander is not done. 4 goes to 5, good. But, 5 is still programmed to go to 1 (the original path), so the commander drags the 5 dot to 4 creating a mini two gate path. (Picture 2)
1 3 2
4 5
Later on, the commander needs to shut down gate 2. With a self repairing system (currently in place), 3 is automatically rerouted to 1 until further customization is done to completely circumvent 2, 2 is turned back on, or is destroyed. Now, I wouldn't completely rule out the possibility of advanced controls not autorouting. The point where it is "useful" is for balancing by making phase gates more of a time investment, losing gates more detrimental, or for any other 'con' that may be needed to balance the game out.
1 3 /2
4 5
As the game progresses the commander turns gate 2 back on and then decides that there is a matter of importance to monitor gate 3. So he grabs gate 5 and tells it to route to gate 3. Now, whenever a marine enters the 4/5 route, they will inevitably enter the 132 loop. Think of it like a Q. 45 is the tail, that when followed, leads to 132, or the circle portion of Q.
This is all fine and good, but what about for the marines? As suggested visual cues on the phase gates (text like a bus route... maybe even the custom text that the commander put in. Gate 4 would show Gate 5 text) themselves may provide clarity on where the gate is going. As the game progresses from two to several gates it may be slightly intuitive for experienced players what the commander has done. But, I would vouch to have a means of clarify if a Q route develops suggested. A billboard, like in a subway, would be nice, but seems goofy... but definitely nothing that pops up in your face each time you want to phase.
Yes I read that, I made the mouse menu comment on the basis that I believe a marine should be able to choose his exit location, you think he shouldn't.
Neither of us is right or wrong.
Deactivating PG's is not going to happen at all, that's a cop out. My original post in August accounts for everything you want, even if you choose to remove the ability to choose an exit location.
What can I say, I already addressed this issue months ago.
Cataclysm, forget turning of PGs, they don't need to be turned off, you also do not need a special new menu. Like in my original suggestion, all you need is for the commander to select a phase gate, and in it's comm menu should be a single button that lets it be set as the primary PG destination.
Again, turning off phase gates is not needed. Turning off phase gates is not needed. There are much more intelligent ways to handle this, without the need to turn off phase gates. Your "self-repairing" system, is also basically a rehash of my own, but needlessly more complex. As I had posted, the PG system works exactly as normal when a default destination is selected, or the marine picks a destination.
Also, I haven't seen anyone address another issue I resolved in my original post, yet most of your proposed solutions will have this problem, but nobody's foreseen it yet.
Come on guys, if you're going to make your own solutions, and ignore mine, at least get up to speed. Piggy back off of mine, I don't care, just get up there.
1. Commander-specified phase-gate destinations:
Features:
- Retains 'walk through phase gate'
- Depending on implementation, lock and unlock phase gates, or re-route phase gates (to varying degrees)
- Depending on implementation, phasegate UI button, re-routing on map or phase-gate listing (cyclical, re-orderable)
Pros:
- The way the game is "meant to be played": commander making decisions
- The way the game is "meant to be played": walking-through matches the "gateway" art
- The way the game is "meant to be played": retains movement (simply walking into the gate), and does not cause a shift in control or perspective (different control scheme using number keys or mouse selection; using UI elements*) *already present with Armory purchase menu anyway, so there is precedent.
- Streamlined phasing
Cons:
- Commander micromanagement can be overwhelming
- Does not match what the ground player necessarily wants
- Can be slow to reach desired destination (multiple phases required)
2. Player-specified phase-gate destinations:
Features:
- Requires "using" phase gate, followed by a selection
- Depending on implementation, selection on map (a la BF series spawning) or phase-gate listing (select number)
Pros:
- Reach desired destination in one phase
- Depending on implementation (map selection a la BF series spawning), no ambiguity about destination
Cons:
- Breaks movement (press "use" instead of walking into the gate), and causes a shift in control or perspective (different control scheme using number keys or mouse selection; using UI elements*) *already present with Armory purchase menu anyway, so there is precedent.
- Depending on implementation (phase-gate listing), confusing destination
- Un-streamlined phasing
Personally, I think that all issues can be sufficiently solved or disregarded by a good implementation of either solution, and (the bottom line is that) it comes down to whether players want (personally prefer) destinations to be specified by the commander or by the players themselves. Once we get past that decision, we can work on figuring out a good implementation.
I actually have been making my proposals from the standpoint that there is no problem, but after re-reading the first page a bit I do see that people are asking more for additional features rather than a solution to a problem.
<!--quoteo(post=1891785:date=Dec 26 2011, 08:26 PM:name=scotty)--><div class='quotetop'>QUOTE (scotty @ Dec 26 2011, 08:26 PM) <a href="index.php?act=findpost&pid=1891785"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->An idea could be to implement a function to either deactivate or lock the phase gate. As a comm i find this idea very helpful to redirect those marines to the front lines.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1891789:date=Dec 26 2011, 08:42 PM:name=Techercizer)--><div class='quotetop'>QUOTE (Techercizer @ Dec 26 2011, 08:42 PM) <a href="index.php?act=findpost&pid=1891789"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I'd like to see some additional Com control over the PG network, either by being able to redirect phase gates at will or shut down gates that aren't in use.<!--QuoteEnd--></div><!--QuoteEEnd-->
<!--quoteo(post=1891793:date=Dec 26 2011, 08:53 PM:name=scotty)--><div class='quotetop'>QUOTE (scotty @ Dec 26 2011, 08:53 PM) <a href="index.php?act=findpost&pid=1891793"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I would find it more frustrating to have to teleport to 6 other phase gates before i got where i wanted. This isn't about herding sheep, it's about saving time / res.<!--QuoteEnd--></div><!--QuoteEEnd-->
Now, I for one, like features that expand the playability without detracting from the atmosphere. In my mind (maybe somewhat twisted) I see advanced user interfaces available to the commander... not that the marines can't have one... but, it is the responsibility of the commander to manage his buildings. Really, the only cons to that are reduced field visibility (while the menu is open) and a degree of micromanagement (but, then again, the commander can always leave it to its default route with no interaction).
On the other hand, I could see a whole new line of management where the marines not only build the buildings, but "program" them as well... but, that does not seem to be the direction this game is going. (but, who knows?)
- The way the game is "meant to be played": walking-through matches the "gateway" art
- The way the game is "meant to be played": retains movement (simply walking into the gate), and does not cause a shift in control or perspective (different control scheme using number keys or mouse selection; using UI elements*) *already present with Armory anyway<!--QuoteEnd--></div><!--QuoteEEnd-->
Harimau - excellent breakdown, thanks for laying it out for everyone to see. The only bit I don't understand is what I quoted above, where did you see that these three points are 'The way the game is "meant to be played"'?
Personally I don't think point 1 or 2 hold up.
1- Where you go when stepping through a phase gate is directly important for you the FPS player, and only in-directly important to the commander. The commander may have told most players to go to one phase, but some other players to a different phase. I don't think limiting players to a single phase will ever be a good idea - it is taking away too much control from the player.
<b>Intelligence should drive where a player goes, not lack of choice.</b>
2- Just because I'm of the "using a phase gate" mentality doesn't mean I don't think the player should literally walk through the gate. Nor do I think a UI either on the gate somewhere, or in the HUD of the FPS player would be off putting at all. Phase gate option: its a high tech piece of equipment which transports living material across space. HUD option: the marines have a screen which is projected in front of their eyes - they literally have a screen they are looking through at all times. Having a menu on that screen would be no problem - just like weapon selection, or mini-map display, etc. Both options could allow for some kind of menu. You could also transport players to a ship in orbit / awaiting nearby where they have to phase back from.
There are many ways to keep the 'using phase gate' in style of the game, the thing I'm really getting at is that stepping through phases is - and has always been - an annoying process.
Point 3 is a VERY good point, and limiting it to be the least distracting or jarring as possible is essential in my opinion too.
The reason I suggested keys is because after getting used to it, it is the quickest method I have seen and enjoyed. Even though you're removing the current use of keys (weapon selection) and replacing it with PG selection, since you're only pressing a button once there is little chance of inappropriate button pressing - and if you do, its easy to fix. Plus you are ready to press these keys anyway due to wasd.
Bringing up a map which you have to click on is.. OK, retains elements which the player is used to and just asks them to click somewhere. I just don't like that it removes the ability to look around while you're using the menu and blocks your vision. Though a combination of this and the above using keys I think could work well.
Scrolling the mouse wheel - which was suggested above - I'm fairly against, I can't tell you how finicky my mouse wheels have been in the past - sometimes one click (of the wheel) corresponds with one move on a selection list, sometimes is 3 clicks, sometimes its 5; sometimes mouse wheels are reversed; sometimes a false signal is sent that an extra click happened or the wheel is stuck between clicks; and almost always, the mouse wheel is usually the first part of a mouse to die. Moving a control (the wheel) on a moving control (the mouse) has always a persnickety task, at least for me it has, and I usually avoid using the mouse wheel in an fps at all.
I put "meant to be played" in <b>quotations</b> precisely because I recognise that they are subjective opinion - although a commonly-held or commonly-accepted opinion.
The first point is partially a hold-over from the Natural Selection days - that the commander should get last say in everything: he used to distribute weapons. This is perfectly valid because of the simple fact that there is a commander - one who commands, gives direction. <b>However</b>, in this case it may (depending on implementation) be unneeded or unwanted by both the commander and the players (covered by the first two "Cons"), but I'm listing it there as a "Pro" because it is. Any feature or detail can be a pro, a con, or simultaneously a pro and a con.
The second point is perfectly valid, though entirely thematic: it is a vertical gateway - gates are to be walked through horizontally; other games (and non-interactive media) have teleporters where one stands on top of the teleporter platform and then teleports, possibly with a raised panel for selection. Not just other games, in fact, Natural Selection 2 (and NS1) has it already in the form of Infantry Portals (and phase-gates as well, in the case of NS1). In this case however, we've got a literal gate, and in games (and non-interactive media) gates are something to be travelled (walked, driven, flown) through (case in point: Stargate).
Actually, I'll make one amendment to what I just said: this consideration is not entirely thematic alone, but also intuitive.
It would require (or at least be strongly recommended) that the gate be re-modelled into the aforementioned teleporter platform, or perhaps some sort of cage or enclosure (and possibly renamed).
For example, it could be a square platform with two arches intersecting at cross-angles forming four "open walls", with a raised panel along one of the walls.
Or it could be a circular platform like the infantry portal, with a raised panel at one point.
I wish they had "whiteboxed" the development of the phase-gate so that we could focus on the function, and let form follow function; but in this case, the function is following the form.
Since the third point is not really disputed, I won't attempt to justify it.
However, I will discuss it in terms of its relation to the player-specified phase-gate destination idea, since that's what you've begun doing.
First of all, I'll just list the features, pros and cons again:
<!--quoteo(post=1892239:date=Jan 1 2012, 01:29 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 1 2012, 01:29 AM) <a href="index.php?act=findpost&pid=1892239"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->2. Player-specified phase-gate destinations:
Features:
- Requires "using" phase-gate, followed by a selection
- Depending on implementation, selection on map (a la BF series spawning) or phase-gate listing (select number)
Pros:
- Reach desired destination in one phase
- Depending on implementation (map selection a la BF series spawning), no ambiguity about destination
Cons:
- Depending on implementation (phase-gate listing), confusing destination
- Un-streamlined phasing<!--QuoteEnd--></div><!--QuoteEEnd-->
In retrospect, the third point we (didn't) discussed above should have also been placed as a con for this idea. I'll go edit that.
Changing of control schemes and perspectives can be jarring to the player and the experience, and should be discouraged. However, as already noted, there is a precedent with the Armory purchase screen. So this *could* be acceptable, and I will continue based on the assumption that it is:
These are the features that I would require for a player-specified destination phase-gate implementation:
+ Reworked graphics: a <u>base</u>/platform similar to the infantry portal, with a raised <u>panel</u> for selection.
- Two modes! of selection, dependent on which part of the phase-gate is "used":
!1. "using" the raised <u>panel</u> would pop up a menu^ allowing you to select the destination and teleport to it;
!2. "using" the <b>base</b>/platform would instantly teleport you to the pre-determined (or possibly pre-selected*) "default" destination
* "default" destination could simply be either: the standard cycling we have now, the destination that the previous player selected (ease of following), or specified by the commander in some way (a compromise between player-specification and commander-specification)
^ The menu must be the same as the map with all the same information, but highlighting the phase-gates.
^ "Using" the panel once will not lock the view or provide a cursor, pressing "use" (or some other button, e.g. left-clicking with the mouse) while the map-menu is already up (i.e. pressing "use" twice, or pressing "use" then left-clicking with the mouse) will lock the view and free the cursor, allowing for manual selection of the phase-gate destination with the mouse.
^ Each phase-gate will be numbered# and clearly labelled on the map-menu. Pressing that number (or number combination) will instantly teleport you to that location.
#1. EITHER 1, 2, 3, 4, 5, 6, and so on. This allows up to 10 phase-gates, but unfortunately spans the entire width of the keyboard.
#2. OR 11, 12, 13, 14, 15, 21, 22, 23, 24, 25, 31, and so on. This allows up to 5x5 (25) phase-gates, and limits key-presses to the left-hand side of the keyboard, but unfortunately requires an extra key-press (e.g. 1, then 1).
So, <i>for example</i>:
Player1 <walks up to the phase-gate>, <"uses" the <u>base</u> of the phase-gate>, and teleports to the next available phase-gate by default OR the phase-gate selected by the Commander. <<2 actions.>>
Player2 <walks up to the phase-gate>, <"uses" the <u>panel</u> on the phase-gate>, <presses a numbered hotkey> ((or: <presses a numbered hotkey>, then <presses a numbered hotkey again>)), and teleports to the selected phase-gate. <<3 or 4 actions.>>
Player3 <walks up to the phase-gate>, <"uses" the <u>panel</u> on the phase-gate>, <"uses" the map menu, or left-clicks with the mouse>, <moves the cursor and clicks on a phase-gate> ((alternatively: <moves the cursor> and <clicks on a phase-gate>)), and teleports to the selected phase-gate. <<4 or 5 actions.>>
Player4 <walks up to the phase-gate>, <"uses" the <u>base</u> of the phase-gate>, and teleports to the phase-gate selected by Player3 OR the phase-gate selected by the Commander. <<2 actions.>>
(This can be contrasted with the <<1 action.>> <walk up to the phase-gate> action that the purely commander-specified phase-gate destination allows for.)
Personally, I think that all issues can be sufficiently solved or disregarded by a good implementation of either solution, and (the bottom line is that) it comes down to whether players want (personally prefer) destinations to be specified by the commander or by the players themselves. Once we get past that decision, we can work on figuring out a good implementation.
I think the idea I have described above is a good implementation, though there are two obvious disadvantages: the potential number of actions (it's a choice), and the requirement for new art assets (or you could just hack it in). The number of options (there are three: Player1/Player4's approach, Player2's approach or Player3's approach) could also, ostensibly, be overwhelming, confusing or not readily-apparent, but I think this could be easily solved by simply giving players the right information in-game.
<!--coloro:#FF00FF--><span style="color:#FF00FF"><!--/coloro--><b>Cataclyzm</b>:<!--colorc--></span><!--/colorc-->
Regarding specifying the problems, it's kind of an inversion on what I've already stated with the two major sets of solutions, and the problems are rather dependent: Some solutions solve some problems, don't solve some problems, and create others.
I'll try, though:
<u>Interdependent problems with different phase-gate solutions:</u>
(CS = Commander-specified, PS = Player-specified, phase-gate destinations.)
1. (Default) No commander-control over destination.
[1] Solved by using CS (leading to 2., 3., 4. and 5.).
2. (Default) No player-control over destination.
[2] Solved by using PS (leading to 5., 6., 7., and 8.).
3. (Default) Player, potentially slow to reach desired destination (requires too many phases).
[3] Solved by using PS (leading to 5., 6., 7., and 8.).
4. Commander, micromanagement.
[4] Solved by NOT using CS (by extension, using PS),
[4] and solved to some degree by using a very streamlined interface or simple controls (such as the drag-and-drop cyclical order suggestion, the lock/unlock phase-gate suggestion, and the re-route all phase-gates to this one phase-gate suggestion - though contributing to 1.).
5. Player, ambiguous destination.
[5] Solved by using map-menu-selection under PS.
6. Player, un-streamlined phasing (requires too many actions and decisions).
[6] Solved by NOT using PS (by extension, using CS),
[6] and solved to some degree by using a very streamlined interface with multiple options (see my suggestion above).
7. Player, disconnect on a control/perspective level.
[7] Solved by NOT using PS (by extension, using CS),
[7] and solved to some degree by providing options to the player (base or panel; then hotkey or cursor; see my suggestion above).
8. Player, disconnect on a thematic/intuitive level.
[8] Solved by NOT using PS (by extension, using CS),
[8] and solved by creating new art assets (leading to 9.).
9. Requires new art-assets.
[9] Solved by NOT using PS (by extension, using CS),
[9] and solved by ignoring thematic and intuitive concerns (ignoring professionalism and internal consistency aka realism).
The deactivation or 'locking' of any PG is also a mistake, as there are models that work without the need to resort to punishing/restrictive game conditions.
When there are more than 3 PGs, a user may at any time, at any place select the PG he would next like to exit from (marines will want this amount of control). An efficient and intuitive approach to this may be achieved by a mouse wheel menu, due to the dynamic nature of placing PGs, and how a wheel can be organized statically to accept dynamic elements (PG locations), this feels like an ideal solution. This allows users to know how PG locations will be organized regardless of PG placement. This creates familiarity for the menu from game to game, and map to map (very important). This menu could be a hologram that pop's up from the marine's left arm or something, and only functions while holding "E"; your use key in a non-interactive situation (there's nothing 'use' interactive in your immediate vision), or a double tapping of the key as it allows you to use this menu in all situations, including ones where you may want to use the menu while repairing someone's armor, or building a structure. This pop's up the menu, you flick the mouse in any direction to select a PG location, and you're set, you've just picked a PG location while running to the PG, or while building that robotics factory- completely non-intrusive and incredibly easy to use. (After exiting a PG to a user selected location, that user's PG exit selection is reset.) This is incredibly fast to do, and your hands are still in proper k+m placement the entire time.
Again, commanders may pick a primary PG, which at that occurrence supersedes all user selected locations as the default location. (no need to lock other PGs whatsoever). Also, when a user selects a location after a primary PG has been set, it supersedes the commander's selection once.
Now for the problem of of PG cycling when a primary PG location is set. For example, I just phase to Heli because it's the commander selected primary exit location, and I run back into the PG, where do I go? Well, all the proposed models need a grace period, from which on exiting a PG you may re-enter it to cycle to the next in the build a-la vanilla phase mechanics, this is a recursive process from phase gate to phase gate until a user does not re-enter one within the grace period, at which, the PG system resets for that player. This allows the old system to work as it does currently, so new players, as either a marine or commander may play unaffected and learn the advanced nuances at their own rate.
As for the mouse wheel menu, each PG gets a dynamic entry on the menu, which lists it's location, and possibly it's build order. The color of the menu item for each PG is one of 3 depending on whether that PG is the commander selected primary, user selected exit, or just a regular PG. Having a PG menu item flash red as it takes damage is also an option for increased team transparency (more of this is better in tactical games like NS). As for the wheel's static construct, imagine the circle overlaying the mini-map, for summit, pg locations on this minimap correspond to their locations on the pg menu wheel, and are dynamically sized/placed. This allows menu familiarity that is preserved from game to game despite the dynamic nature of structure placement.
Simple, intuitive, <u>does not break the current model at all</u>, with full functionality, annnnnnd, for all the nay sayers of my proposed mouse wheel selection system, you don't have to use it as it is non-intrusive. ;)
As a commander in late game, I'd like to be able to have my players actively navigate the PG network on their own, as efficiently as possible, my time and resources should not be spent monitoring and maintaining an overly and needlessly complex PG network, it's literally not needed at all. Those 3 guys that are watching DC can now spawn and 1 PG to it every time, rather than having me set up some special conditions for them to do so, and then do it again for the next guys, and then back to DC again for those guys, and then to crev for another group of guys -> you see where I am going with this.
Er, why?
The whole point of phase gates is that they are time savers, it doesn't matter if it takes a couple of seconds to use one, it's still dozens of times faster than walking.
PGs already have delays, you have to find amd go to the phase gate, you usually have to go through it once or twice to get to your destination, and you have a second or two of disorientation from the teleport.
Putting a map selection in will actually take time off of the last two parts, as you always go where you want to go, and showing your arrival location on a map will help you plan out ahead of time where you will emerge, so it shouldn't add any significant delay to using them.
The whole point of phase gates is that they are time savers, it doesn't matter if it takes a couple of seconds to use one, it's still dozens of times faster than walking.
PGs already have delays, you have to find amd go to the phase gate, you usually have to go through it once or twice to get to your destination, and you have a second or two of disorientation from the teleport.
Putting a map selection in will actually take time off of the last two parts, as you always go where you want to go, and showing your arrival location on a map will help you plan out ahead of time where you will emerge, so it shouldn't add any significant delay to using them.<!--QuoteEnd--></div><!--QuoteEEnd-->
Nonsense.
Phase gates are time savers, true, but it <b>does</b> matter if it takes an extra second to get through it when you have to defend it.
Adding a menu for people on the ground is a real time waster, instead, have the commander organize it in some way or another.
Good players orientate themselves by looking at the map before going through the phase gate, that way it's possible to find your targets faster when using a phase gate.
If there were a specific phase-gate key then that would be fine, but I would advise against it because players shouldn't have to learn so many keys, especially for a practically niche function.
Now, if there were a key for a soldier menu (it was right-click in NS1), under which people could perform many functions INCLUDING specifying the next phase-gate exit point, then I think it could work really well.
It seems like, more than implementation, people just can't agree on whether we should have exit points specified by the commander or by the players themselves.
I am leaning towards a hybrid system - where the commander gets first say (with one manner of specification or another) but the soldier, if they wish, gets last say.
So I proposed the following system:
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->These are the features that I would require for a player-specified destination phase-gate implementation:
+ Reworked graphics: a <u>base</u>/platform similar to the infantry portal, with a raised <u>panel</u> for selection.
- Two modes! of selection, dependent on which part of the phase-gate is "used":
!1. "using" the raised <u>panel</u> would pop up a menu^ allowing you to select the destination and teleport to it;
!2. "using" the <b>base</b>/platform would instantly teleport you to the pre-determined (or possibly pre-selected*) "default" destination
* "default" destination could simply be either: the standard cycling we have now, the destination that the previous player selected (ease of following), or specified by the commander in some way (a compromise between player-specification and commander-specification)
^ The menu must be the same as the map with all the same information, but highlighting the phase-gates.
^ "Using" the panel once will not lock the view or provide a cursor, pressing "use" (or some other button, e.g. left-clicking with the mouse) while the map-menu is already up (i.e. pressing "use" twice, or pressing "use" then left-clicking with the mouse) will lock the view and free the cursor, allowing for manual selection of the phase-gate destination with the mouse.
^ Each phase-gate will be numbered# and clearly labelled on the map-menu. Pressing that number (or number combination) will instantly teleport you to that location.
#1. EITHER 1, 2, 3, 4, 5, 6, and so on. This allows up to 10 phase-gates, but unfortunately spans the entire width of the keyboard.
#2. OR 11, 12, 13, 14, 15, 21, 22, 23, 24, 25, 31, and so on. This allows up to 5x5 (25) phase-gates, and limits key-presses to the left-hand side of the keyboard, but unfortunately requires an extra key-press (e.g. 1, then 1).
So, <i>for example</i>:
Player1 <walks up to the phase-gate>, <"uses" the <u>base</u> of the phase-gate>, and teleports to the next available phase-gate by default OR the phase-gate selected by the Commander. <<2 actions.>>
Player2 <walks up to the phase-gate>, <"uses" the <u>panel</u> on the phase-gate>, <presses a numbered hotkey> ((or: <presses a numbered hotkey>, then <presses a numbered hotkey again>)), and teleports to the selected phase-gate. <<3 or 4 actions.>>
Player3 <walks up to the phase-gate>, <"uses" the <u>panel</u> on the phase-gate>, <"uses" the map menu, or left-clicks with the mouse>, <moves the cursor and clicks on a phase-gate> ((alternatively: <moves the cursor> and <clicks on a phase-gate>)), and teleports to the selected phase-gate. <<4 or 5 actions.>>
Player4 <walks up to the phase-gate>, <"uses" the <u>base</u> of the phase-gate>, and teleports to the phase-gate selected by Player3 OR the phase-gate selected by the Commander. <<2 actions.>>
(This can be contrasted with the <<1 action.>> <walk up to the phase-gate> action that the purely commander-specified phase-gate destination allows for.)
I think the idea I have described above is a good implementation, though there are two obvious disadvantages: the potential number of actions (it's a choice), and the requirement for new art assets (or you could just hack it in). The number of options (there are three: Player1/Player4's approach, Player2's approach or Player3's approach) could also, ostensibly, be overwhelming, confusing or not readily-apparent, but I think this could be easily solved by simply giving players the right information in-game.<!--QuoteEnd--></div><!--QuoteEEnd-->
<i><b>In summary</b></i>, we have:
- Commander specifies default exit point*: Press 'use' on the <u>base</u> to instantly phase. This would barely take any more time than the current system.
- Player specifies exit point**: Press 'use' on the <u>panel</u> to bring up a map-menu to select an alternative exit point. This would take some time, and there are different options, but it gives the player full control.
* Having said that, I do think there's value in a "follow the leader" mechanic. (That is, rather than the commander specifying the default exit points, the last-specified exit point by any player becomes the default exit point.) It would naturally mean that the players behind phase to the same location as the players in front.
** This could actually be compatible with Kalabalana's suggestion, as an addition. A player could pre-specify what their exit point is, while en route to the phase gate itself, press 'use' on the <u>base</u> and instantly teleport there.
In fact, inspired by the mousewheel idea, we could further expand my map-menu idea so that:
After pressing "use" on the <u>panel</u>:
1. Player uses numbered hotkeys to select destination and instantly phase there, or
2. Player uses mousewheel to cycle through and highlight their destination, and left-clicks to instantly phase there, or
3. Player presses right-click to lock the view and free the cursor, and left-clicks on a destination to instantly phase there.
These options in addition to:
4. Player individually pre-selecting the exit point, pressing use on the <u>base</u> of any PG to instantly phase there, or
5. Player pressing 'use' on the <u>base</u> without pre-selection, instantly phasing to the commander-specified default exit point OR the last player-specified exit point.
Lots of options to let players choose the one they're most comfortable with (or the one best suited to the situation), but all have the exact same effect (with the exception of 5).
Phase gates are time savers, true, but it <b>does</b> matter if it takes an extra second to get through it when you have to defend it.
Adding a menu for people on the ground is a real time waster, instead, have the commander organize it in some way or another.
Good players orientate themselves by looking at the map before going through the phase gate, that way it's possible to find your targets faster when using a phase gate.<!--QuoteEnd--></div><!--QuoteEEnd-->
Then why would the good players be delayed by the map appearing then? If they look at it anyway.
And no, a second does not make any signficant difference. The number of situations where a second is the difference between winning or losing is so infinitesimal that it is not worth considering. Simple statistical analysis would tell you that. Given that it takes about 30 seconds to destroy a phasegate, and several players could go through it at any time during that 30 seconds, and any one of them could kill the thing destroying it, and the destruction of any given phase gate could very easily not be a signficiant factor in the battle, and the situations where a second would matter are just so few that it's laughable.
Furthermore, it is far more probable that the commander would not react in time to enable or disable a phase gate when a player needs to use it or needs to bypass it, which means that commander control is almost certainly going to be far more troublesome than player control. Not to mention it smacks of stupid busy work and power grabbing for anal retentive commanders who don't feel like they are pro enough unless they can micromanage every last second of the marine experience.
I'm not mentally deficient, I don't need the commander to tell me what phase gates I can and can't use.
*needs new art assets (base/panel), or just bull###### it.
::1:: Pressing 'use' on the base of the PG teleports you instantly to whatever is selected by the commander as the exit point.
::2:: Pressing 'use' on the panel of the PG allows you to select your own exit point*.
*2 or 3 different methods to do so
Additionally, adapting Kalabalana's idea:
::3:: Pre-selecting (with a soldier menu) the next exit point for a PG, then pressing 'use' on the base/panel* of the PG teleporting you instantly to your pre-selected exit point.
*unsure if :1: or :2: should take precedence (or neither).
I also don't want to make it difficult for when I flee through a phase gate in panic with a fade blinking after me. Granted, that could be a balance trait to inhibit quick escapes.
So all in all based on responses in this thread, I think it's looking to be impossible to satisfy everyone.
So all in all based on responses in this thread, I think it's looking to be impossible to satisfy everyone.<!--QuoteEnd--></div><!--QuoteEEnd-->
Why?
You're operating under the assumption that there can only be one solution that everyone has to use. There's no reason to think like that, since these options don't really affect the gameplay on a small scale (it's not like the skulk view rotation vs no view rotation argument). It is perfectly acceptable (perhaps imperative, in this case) for players to have many different options to perform the same function (phasing "somewhere"). It follows the same logic as key re-binding.
In this case, no solution is objectively superior or inferior, only subjectively superior or inferior. So why not have the best of all worlds?
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->^ Hence why I suggest two modes of selection*:
*needs new art assets (base/panel), or just bull###### it.
::1:: Pressing 'use' on the base of the PG teleports you instantly to whatever is selected by the commander as the exit point.
::2:: Pressing 'use' on the panel of the PG allows you to select your own exit point*.
*2 or 3 different methods to do so
Additionally, adapting Kalabalana's idea:
::3:: Pre-selecting (with a soldier menu) the next exit point for a PG, then pressing 'use' on the base/panel* of the PG teleporting you instantly to your pre-selected exit point.
*unsure if :1: or :2: should take precedence (or neither).<!--QuoteEnd--></div><!--QuoteEEnd-->
The commander does not need to specify exit points, but he can.
Players do not need to spend time selecting their own exit points, but they can.
Players do not need to pre-select their own exit points using a pop-up menu, but they can.
Players do not need to use hotkeys, but they can.
Players do not need to use the mousewheel, but they can.
Players do not need to use the cursor, but they can.
That's not applicable.
Does your OS look and work the same as everyone else's, and do you use it the same way as everyone else? I know mine doesn't, and I know I don't. Maybe if you use a Mac... Apple are big on standardisation. But even that has options and customisation.
When I want to move a file to another folder, I have several different options:
- Drag and drop between different windows.
- Select the file, right click, click cut, change folder, right-click, select paste.
- Select the file, ctrl-x, change folder, ctrl-v.
Do I use any option to the exclusion of all others? No. There's a time and a place.
No. I just believe that simplest solution that satisfies all the needed conditions is what we should use.
The problem is, everyone thinks their own idea is the best, but regardless of how good an idea is, we should be able to see which presented models are the simplest (we can). Compare the models on your own, and see which have the simplest answers. The focus is on the end-user, and how easy it will be for them.
For example, my model allows both a commander and the marine to do absolutely everything required in a single step. Whether it's picking an exit location, or setting a primary exit location. Other models require multiple steps to achieve the same goal(s), this is not optimal, and will only affect the game negatively, especially when you play at the competitive level.
If I understood your suggestion correctly, there are a number of "issues" with it:
- The pop-up menu potentially obscures parts of the view of the game-world. (This is common to all suggestions except where it's commander-specified-only. This is less of an issue with usable panels or interfaces e.g. the Armory, because by moving towards one you are naturally already having your view obscured by the object.)
- The pop-up menu is specific to phase-gates alone, leading to an extra key that needs to be learned and used.
- This extra key seems unwarranted, because it is a function that is not used from the start of the game or for the entirety of the game.
- The pop-up menu is not at all context-sensitive, and therefore less intuitive.
- The pop-up menu requires cycling through a list of phase-gates with a mouse-wheel, which is not the most ergonomic or accurate controller.
- In no other feature (or game) is this style of menu available, so it is not easily accessible.
- The list of phase-gates do not visually represent the phase-gates, and so do not convey focused, important information and will be ambiguous and can be confusing or lead to information-overload (like this sentence).
- The commander gets no direct input to marine exit points.
These are the advantages that you propose:
- Giving players the ability to specify exit points. This is also present in other suggestions.
- A somewhat more streamlined approach than other suggestions. Either holding a key or pressing a key, and selecting (and pressing the key again, if it was a toggle); followed by walking into a phase-gate. This is less streamlined than commander-specified approaches, but more streamlined than other player-specified approaches. However, rather than time spent at the phase-gate, it merely becomes time spent before the phase-gate.
- Mobility and ability to react while doing so. Reacting ability is mitigated in part by the fact of view-obscurity. Mobility is less needed in panel/interface-selection because you are already standing still, and less needed in general when you consider that you are about to exit that location anyway.
- Less bottle-neck at phase-gates since all marines will walk through phase-gates. This issue could be mitigated in other suggestions by allowing more than one marine to occupy a phase-gate at once, just as the Armory can be, as well as forced phasing of people who take too long (a likely rare occurrence).
In conclusion, I see no reason not to have the benefits of your suggestion, along with the benefits of other suggestions, since by doing so, we can fit each method to different playstyles or situations, and mitigate any imperfections a single method might have through the choice of different methods.
<b>- I mean how many phasegates are build in an average game?</b>
Guess its around 2-5
1 for each techpoint/hive location, 1 in the main base...
Assuming it takes around 2-3 seconds to jump from phasegate to phasegate its 10-15*s make a full circle with 5 phasegates.
Thats 8-12* seconds to get were you want to in a worse case scenario...
*missing the time you need to get to the first phasegate
<b>- Should it be ok to spam phasegates, or should there be a downside to this?</b>
There should be a downside, and the downside is - the more you have the longer the traveltime gets because you have to jump from phasegate to phasegate to phasegate.
Either optimize by recycle or live with it.
______________________________
I think the current pg system is ok, but we could add an
<u><b>EMERGENCY REDIRECT</b></u> button...
In case of an emergency you can activate this on a pg (pg portal color changes to red on this pg)
Every phasegate on the map will redirect you to this phasegate. (tho it disables jumps to somewhere else after you went trough it, so you cant save yourself and jump back for the time this is active)
- This could cost a fixed amount of tres, pres or energy and have a fixed timer... (~15-30s)
- Or it could drain Y tres/pres or energy on that phasegate for every Z seconds it is activated... (with a minimum of X for the activation) - i like this better.
(i kinda like the idea that you cant jump away after this is activated... so if the commander disables the redirect it takes another 5-10s until you can go into this pg again - coming out is possible at anytime, just going in takes this extra amount of time after the redirect is disabled)
edit: this could also make some cool sound and message in the player ui similar to distress beacon.
edit2: energy is a crappy resource... so i really would like to see it cost tres or pres along with other stuff like beacon. (but thats another topic, isnt it? :P)
While this is true, the menu would be transparent, and realistically will only be visible for a fraction of a second as players get used to it. Also most games can produce their comma rose usually very visually open.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The pop-up menu is specific to phase-gates alone, leading to an extra key that needs to be learned and used.
- This extra key seems unwarranted, because it is a function that is not used from the start of the game or for the entirety of the game.<!--QuoteEnd--></div><!--QuoteEEnd-->
This functionality can be stacked on top of the current use key, for most that is "e". The double tapping, or holding down of this button brings extra functionality without requiring any extra keyboard Olympics, or the use of a new key. Maybe holding the jump key would be a better choice.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The pop-up menu is not at all context-sensitive, and therefore less intuitive.<!--QuoteEnd--></div><!--QuoteEEnd-->
The menu elements can be placed in the same place dynamically retaining familiarity despite unique placement over different games. Menu elements also will use up as much visual real estate as possible, so in the early game, 3 phase gates are going to have 120 degree portions of the wheel. Also, imagine the comma rose overlapping the minimap, that is how the PG locations will be placed in the same way, transcending different games.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The pop-up menu requires cycling through a list of phase-gates with a mouse-wheel, which is not the most ergonomic or accurate controller.<!--QuoteEnd--></div><!--QuoteEEnd-->
No, it does not, I think we have a bit of a broken telephone thing going on here, what I'm proposing is a mouse menu wheel, it does not use the mouse wheel at all. It pops up something that looks like a doughnut, that along it's circumference overlaps the map, so a DC pg will always be on the right side of this circle with which you just flick the mouse to the right to select. Here's more information to illustrate the mouse wheel concept. <a href="http://www1.pcmag.com/media/images/226191-circle-dock-after.jpg" target="_blank">1</a> <a href="http://images.wikia.com/masseffect/images/1/19/Powerwheel.jpg" target="_blank">2</a> <a href="http://www.goalqpc.com/dotcom/images/ElephantWheel.jpg" target="_blank">3</a> <a href="http://i54.tinypic.com/2u89frm.jpg" target="_blank">4</a> <a href="http://xboxoz360.files.wordpress.com/2011/05/oxcgns-brink-review-oxcgn-5-class-change.jpg" target="_blank">5</a>
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- In no other feature (or game) is this style of menu available, so it is not easily accessible.<!--QuoteEnd--></div><!--QuoteEEnd-->
The mouse menu, or comma rose, is in several games, BRINK, Battlefield, Mass Effect, etc.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The list of phase-gates do not visually represent the phase-gates, and so do not convey focused, important information and will be ambiguous and can be confusing or lead to information-overload (like this sentence).<!--QuoteEnd--></div><!--QuoteEEnd-->
I did not adequately convey to you the idea I had proposed, so I understand where you are coming from, but from above now you know what I mean.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->- The commander gets no direct input to marine exit points.<!--QuoteEnd--></div><!--QuoteEEnd-->
Yes, when he sets a primary phase gate exit location, it resets all current marine selections, and as such, all PG travel will now go to that phase gate (unless a marine specifically picks a new location after this point). This does make marines feel forced to hit a location, but if a commander wants, he can keep setting the primary location, effectively disabling the marine's ability to ignore going to that location. Realistically though, there are exceptions, and even though you may want most of your team going to a point, you will still have men on the side doing jobs at other locations, these marines should remain unimpeded.
<!--quoteo(post=1892613:date=Jan 4 2012, 02:43 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 4 2012, 02:43 AM) <a href="index.php?act=findpost&pid=1892613"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->These are the advantages that you propose:
- Giving players the ability to specify exit points. This is also present in other suggestions.
- A somewhat more streamlined approach than other suggestions. Either holding a key or pressing a key, and selecting (and pressing the key again, if it was a toggle); followed by walking into a phase-gate. This is less streamlined than commander-specified approaches, but more streamlined than other player-specified approaches. However, rather than time spent at the phase-gate, it merely becomes time spent before the phase-gate.
- Mobility and ability to react while doing so. Reacting ability is mitigated in part by the fact of view-obscurity. Mobility is less needed in panel/interface-selection because you are already standing still, and less needed in general when you consider that you are about to exit that location anyway.
- Less bottle-neck at phase-gates since all marines will walk through phase-gates. This issue could be mitigated in other suggestions by allowing more than one marine to occupy a phase-gate at once, just as the Armory can be, as well as forced phasing of people who take too long (a likely rare occurrence).
In conclusion, I see no reason not to have the benefits of your suggestion, along with the benefits of other suggestions, since by doing so, we can fit each method to different playstyles or situations, and mitigate any imperfections a single method might have through the choice of different methods.<!--QuoteEnd--></div><!--QuoteEEnd-->
By no means do I think my idea is the best for the game, but trust me, it will work very well in game, especially with the comma-rose/wheel menu selection process I am suggesting. Which has two main strengths, ease of selection due to using the mouse, and it's coupled with the natural ability to place structures according to their location(s) on this menu, such that you'll basically be able to pick PG locations blind.
The only downfall I see in this model, is for PG's placed in the middle of a map, but I believe they can occupy another circle in the middle of the comma rose wheel. Also of note, selecting locations along the comma rose wheel does not require perfect mouse control, you just need to create a vector from the center of the menu to the end location of the mouse, and which ever border element it intersects would be your selection. This allows for a pop-and-slide functionality, where as the menu comes up, you can simply just 'flick' your mouse in the direction of the PG, or area you want to select. This can be done extremely quickly on the fly.
According to this thread: Yes. That is the entire premise of this thread.
...and then you proceed to make your own suggestion.
I'm no expert on irony, but...
Kalabalana:
So you were talking about a "radial menu", not the physical mouse-wheel. Got it. That clears a lot up.
You shouldn't use the use key because the use key is for context-sensitive actions, and this would be the exact opposite. Also, as I've mentioned, PG exit point specification is a very niche setting that is not present for the entire duration of the game or from the start of the game at all - so it cannot warrant its own control (pressing "use" in the middle of nowhere does qualify as the PG function having its own control).
The jump key is even worse: you should never re-tool a movement key to another function; it also plays havoc with jetpacks, and well, jumping in general.
Linking it to a sub-function of an existing menu would be fine. For example, a soldier menu (like we had in NS1), the communications menu (which I would say should be a radial menu), or the map key (combine the interface) this may also address the following concern:
"- The list of phase-gates do not visually represent the phase-gates, and so do not convey focused, important information and will be ambiguous and can be confusing or lead to information-overload (like this sentence)."
You've still misunderstood me. Even radial menus still do not convey the proper information. Anything that does not represent it visually (i.e. correspond to the map) will not convey the proper information. How can you easily tell which PG icon is linked to which PG? They don't easily correspond to the map.
I dislike your implementation of commander specified PG exit points. I believe the commander should have all the say (he sets all the exit points, and players have to live with it), OR players should have all the say (and commanders can only "advise" - through the use of waypoints and setting default PG exit points). Doing it your way means the commander can effectively take something that is normally available away from the players.
The biggest problems with your suggestion as it is, is that it will not easily conform to actual PG locations on the map, and that even if they approximate it, one will still not know how it corresponds to the map (or if they indeed want to travel to that location) because they are two separate interfaces.
Another issue would be the dynamic nature of the radial menu (even though this is supposed to be a plus). People will get used to swinging the mouse in a certain direction to correspond to a certain PG. Then a PG gets destroyed, or the commander builds a new PG, and the radial menu will necessarily change, and what people were used to a moment ago is no longer relevant - they may not even have the feedback that what they were used to is no longer relevant since they haven't seen the map and neither has the game informed them. Even if they remembered the positions of the 3 different PGs, perhaps now 2 of those PGs are in different locations, and not only do the radial menu options not necessarily correspond to physical locations, the menu has just shuffled itself around: This information is not easily available to the player, and so this information (the control/selection for each PG) is newly obfuscated every time a PG goes up or down.
Do you see what I'm getting at here?
I do have some ideas about trying to improve on your suggestion, to help mitigate some of these issues.
- The first is that the player gets the last say as to their next exit point: the commander can only encourage it by setting default exit points.
- The second is that we'll keep the radial menu, but it will be a sub-function of the map key (haven't worked out how best this would be done; probably by pressing the map key, then holding left-click to activate the PG-selection sub-function); when the PG-selection sub-function is active, each radial menu option will have an arrow that leads to the corresponding PG on the map. When hovering over a radial menu otion, that corresponding PG and its radial menu option will be highlighted while all other options will be subdued.
- When a PG is used, the selection is immediately cleared.
- Leaving the mouse in the centre of the screen when using the radial menu will clear (cancel) any selection.
- Every time a PG goes up or down, upon opening the map next, it will flash: to unambiguously illustrate to the player that the PG locations have changed; and that they have to clear their assumptions. As a bonus, this would, by extension, also indicate when the first PG goes up.
What issues still remain?
1) Temporary obscuration of a somewhat significant portion of the screen.
2) Temporary lack of mouselook.
3) Not the most optimally streamlined: requires pressing (or maybe holding) the map key, then holding the left mouse button.
4) This particular implementation (3) would also mean you couldn't fire since the left mouse button would be occupied (on the other hand, with the lack of mouselook (2), why would you?)
Issues 1 and 2 are necessary, but at least on temporary.
Issues 3 and 4 (the control scheme) can possibly be improved on.
The problem with a menu I see, is that there will not be an efficient implementation of marine chosen phase gates without a visual menu. So what would be the best one?
Absolutely no player should have any power to restrict the movement of any other player, this is just general game design, this is why I feel the most power a commander should have is picking the default gate position for exit, and marines can still trump this (they are not forced to do anything).
The button issue is a real one, I haven't had that realization of any perfect implementation, I'd like to add extra functionality to another key, but again, I don't know which one. Maybe flashlight, since it's only used in single click situations? It will now have dual functionality, quick press toggles light, hold brings up menu?
I had no clue it was called a radial menu, I just had an idea in my mind, and didn't know the name to place on it, thank you for that.
So what can we do? Given all the suggestions, we should be able to figure out what will be the best implementation?
EDIT: Would love a audio and possibly HUD confirmation of location selected, maybe the game will say the pg location like "Data Core" in that Unreal tournament narrator voice or something similar. As for a visual cue, maybe a very small streamlined box, or line of text artistically attached to a side of the minimap shows your current next pg location, based on proximity to nearest pg showing marine selection, commander selection, or next in cycle.
Also, to clarify on my radial menu, and how elements are added to them, I imagine we can add menu items based on locations on the map, they become 'seeded' on this wheel accordingly, and the size of each selection is dynamically determined based on how much radial wheel space is available on either side the button. This allows optimal sizing while retaining the 'feel' of a location corresponding to it's physical placement on the map.
The flashlight is not <b>as bad</b> as the jump key idea, but follows along the same lines. It is a "game world" key, not a "HUD/interface" key.
I honestly think we have only 3 options:
- Tie it as a sub-function of the communications menu.
- Tie it as a sub-function of a soldier menu (like we had in NS1, which also served as the communications menu).
- Tie it as a sub-function of the map view, which would be the best implementation for reasons previously stated.
In terms of default keys, I think we have the following options (omitting all movement keys):
- Q(last used weapon key), E (use key), R(reload key), T (chat key), F (flashlight key), G, Tab (scoreboard key), Shift (can't, sprint key), Alt
-> Realistically, we have G and Alt
And some secondary options (harder to use):
- ~, 1*, 2*, 3*, 4*, 5, 6, Z, X, C, V, B (*weapon slot keys)
-> Realistically, we have ~, 5, 6, Z, X, C, V, B
Of the primary options, G and Alt are, I don't think, used for anything else (alt-tab used for switching windows, I guess) - so I would make one of these the combined Map/PG-Selection key, and the other the Communications key.
Regarding the commander restricting the players - that's precisely why I prefer that commanders get no final say, or all the final say:
- if players are used to being able to move between PGs at will, then taking that ability away from a player is a bad idea, which is why in this case, the commander should only be able to specify 'default' PG exit points, and the player can override that at will
- however, on the other hand, if players are used to going where the commander allows them to go, this isn't exactly taking the ability away from the player, since they never had that ability to begin with
Having said that, I am currently leaning towards the former (player-specified with commander-specified-defaults) rather than the latter (commander-specified-only) implementation.
EDIT: Actually, it appears you posted before I finished editing my post - I had some suggestions as to how to improve on your idea, and may have edited part of the bits prior to that as well.
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->...and then you proceed to make your own suggestion.
I'm no expert on irony, but...<!--QuoteEnd--></div><!--QuoteEEnd-->
So what is complex?
Adding my idea? (which only adds a button on phasegates for the commander)
Or yours? (which is changing the whole mechanic on phasegate travel)
If you dont like my idea - ignore it, or make a proper answer why you dont like it, and why we need your mechanic for average 3-4 pgs in a game.