0.4 Cockpit Discussion

[sinewav]

friends/enemies — I've never figured out the point of this.

Did you actually want an explanation? I'm guessing you don't.

[Ratchet]

...
speed — Unnecessary. Speed is relative, a number doesn't mean anything.
framerate — Yes.
* I neglected to vote for clock. Add one to the total.

Just to be that guy: if speed is unnecessary because it is relative, shouldn't framerate be under the same umbrella? I mean, it's pretty obvious when your FPS is shitty, you don't need a number to prove it

On a more serious note, I agree that I don't much rely on any speed indications. Is the goal here to chop out as much as possible?

@ Lucifer: Thanks for the historical background.

[Rain]

sinewav asked me in another thread to give my input on cockpits, which I believe is more relevant here to answer. As for why my cockpit looks like it does, refer to the original thread.

Disclaimer: this is going to be philosophical: I mean it.

Glad to see you back, Rain. I would love your input on cockpits since yours has been pivotal in shaping popular designs.

My father-in-law once told me that the post-modern man is no longer able to call himself into question. Everything has become personal and as such, subjective. We welcome everything which makes us feel powerful or right and we reject everything which makes us feel weak or guilty. Whenever we are questioned, directly or indirectly, we feel personally attacked, and we impetuously strike back.
That generation tends to be full of shit about how everything was better… when it was worse (I say), but he had a good point about this social trend.

Veritas is by definition objective, and I am using the latin here because truth is in fact "faithfulness" etymologically. The reason we invented mathematics is we do not trust each other, the reason we kept using it is we do not trust ourselves. It is a mean to bypass our own fallibility in collecting, describing, computing and making use of facts.

Fortunately not everyone is a scientist obsessed with proving man wrong. Actually I would say most progress originates outside academia and then is absorbed, structured and legitimised by it. And that is probably because research in a subject need very specific knowledge, and since no man can acquire all the knowledge, sometimes a more superficial but broader knowledge can connect things together and somehow generate new knowledge. But I have wandered off…

Still, being right is not part of our nature. If we were machines we would output a choice, a thought or a statement, based purely on available information and processing capabilities. But we are not. And most of the times we do not collect information, we just pick up trends.

A trend, etymologically "the way something bends”, is something we are exposed to for long enough that we become familiar with it. It bends us towards it. Familiarity is built through repetition, and repetition is what makes us learn things. And guess what? We trust what we have learnt and we defend what we consider family.

Unlike mathematical statements, we do not need proof. The experiences we durably store in our memory are the most repetitive ones, regardless of their validity. And when we are faced with a choice, a preference, a task, etc., we recall and use them. We think what we are programmed to think. That is why advertising works and democracy does not: or at least not as one would expect it to.

But there is really nothing wrong per se. That is just how we work: and we work quite well considering what we have achieved. Also, you can counteract the programming you are subjected to and even program yourself.

Think of practicing something. You repeat it until you are able to perform it with the accuracy you seek. You are literally programming yourself. What you are really doing is strengthening certain synaptic pathways in favour of others, so that when the neurons fire the wave spreads exactly as you wanted it to. Or most of the times at least.

In gaming this is even more evident: there is no time to think of a proper reaction, only the time to react, so you need a set of pre-established reactions responding to certain patterns you recognise.

This brings me back to topic: human-computer interaction. You need proper tools to make you recognise those patterns, and proper tools to transfer your reaction into the machine. The latter being outside the scope of this writing.

That is exactly where familiarity stands in the way. The rightness of which tools should be displayed and how is not necessarily subjective. On the contrary I think there is probably one very specific setup which would bring out the full potential of most players in a given gameplay. But the familiarity with another setup and the learning curve of the proposed one would easily discourage most AA players, who are notoriously impatient and nostalgic dickheads.

Moreover, they would hardly understand the point in the first place, because it is counterintuitive that something you are used to and you feel comfortable with is not the best for you.

Some may claim they cannot do without a brake gauge meter, others may swear any meter is useless, or that they cannot do without a mini-map, but make it toggle-able!

What would we discover if we hacked into players’ webcams and eye-tracked them while playing? Would their claims stand true?

A corpus of aesthetic and functional preferences does not lead to insight, just to confusion, or blunder. Especially if the statistical significance of it is unprovable, thus null. The relevant questions to be asked should be why, how and when certain tools are being used. And not with a statistical intent, but with the ambition to integrate all the answers into a singular consistent design idea. Because sometime, engineers like it or not, you have to reinvent the wheel to make it roll better.

I believe a game interface should be designed, not assembled and decorated. And by design I mean: define the tools needed and their qualities, and then compromise to achieve an identity: if you start with the identity, you will find yourself drawing pictures, not designing tools.

If we want the outcome to be a proper design, a team of competent designers (or the most akin the community can offer) should be assigned the task.

[Ratchet]

Rain,

Your post was very insightful. I like your style of writing, it was a pleasing read. But, I must admit, I didn't gain much knowledge or become enlightened from your post. I think suggestions work better than mysterious advice.

Disclaimer: I'm tired as shit and others might interpret your words better than I

[sinewav]

What would we discover if we hacked into players’ webcams and eye-tracked them while playing?

I'm glad you mentioned this. It is something I have been thinking about as I design. Mostly, I think players are looking a suitable distance ahead of their cycle. The camera causes this area to arc around the screen. There is also a little bit of object comparison going on, "is that cycle behind me or ahead of me?"

Does this mean cockpit objects should be lined along the edges of such boundaries? Should they intersect with them or be encapsulated within them? It's hard to say and I think the rules are different for each kind of information. Something like a rubber gauge provides continuous information, while other elements like score or ping are more static and can be toggled away on command.

Lucifer's Playroom cockpit has continuous information to the lower left and right of the cycle, which some people might find distracting. But there is no reason we can't put toggleable right next to, above, or even on top of the cycle as an overlay. Which brings me to another point I will make soon.

I've been meaning to make a larger post regarding screen elements in other games. I'll start working on that tonight.

EDIT: There is another idea to consider, and I haven't tried it to see if it works, but I can't imagine why it wouldn't. That is, to have a toggle "move" a group of widgets from one place to another. This should be easy enough to do by assigning each group to the same key then setting one group to "default off" and the other to "default on." See how that works?

[Rain]

Ratchet, it is either insightful or mysterious.


sinewav, your drawing feels very realistic. Good job.

I agree with most of your considerations, but I do not agree with the approach. I think we should take a backward step and define the qualities of these tools (or objects as you call them) before we decide where to put them in the default cockpit, and if.

This thread gives you an idea of what players value the most, (read: what they are familiar with). We should ask them object by object: why they use it, how they use it, when they use it. But I am repeating myself.

We could start another more structured thread, but I fear we would not have much input. We need to gather information from the grid, store it here and give it a thought.
Would the ladles be of any use for this? We could interview the winners and the most scoring players and make a sort of pro players secrets column, it would be highly profitable for new players too.

To give it a serious try today I filmed myself while playing and I think that with better lighting and resolution I could easily extrapolate the eyes movements. With both the camera and AA recording we would be able to prove or disprove your theory, but more importantly to gather the aforementioned really relevant information. If I find a good setup are you willing to try it and share the outcome? Is anybody else?

I see no reason to let cockpit objects move around if we find the perfect spot for them. Is this thread implicitly announcing the discontinuance of custom cockpits? I do not think so. I, for certain, will stick with mine, and maybe adjust it after the insights we will reach with this study. But I do not see this kind of flexibility in the default game interface as beneficial, the reason is explained in my previous post.

I look forward to that larger post.

[sinewav]

Is this thread implicitly announcing the discontinuance of custom cockpits?

The goal is to come up with something that is both functional and attractive for the next release. That's all. Users can still roll-their-own cockpits.

I really love the idea of de-constructing the user experience and tracking eye movement and all that other stuff. Unfortunately, I think we will be stuck with simply making a "good" cockpit, not "ground-breaking" one. There isn't a lot we can do in this volunteer network. Those users who have high opinions about cockpits can simply make their own and those who don't know how to make one usually don't contribute to the design process, other than saying "ugh, stupid mini-map!"

This topic can easily have me writing a dozen more pages on design philosophy, but rather than talk I'll use some time this week to draw some sketches. I'm actually working on a second post for this thread right now, so possible double-post before the end of the night.

[sinewav]

I find it helpful to look at element layouts in other games to see what works (or doesn't) and why. It is interesting to see how different developers approach the same problem. One thing you will notice in the examples below is the lack of chat. Armagetron chat is dominant, and some people prefer it that way, though it does create design limitations.

GTA, COD, HALO

Each of the screenshots above show designs that maximize visibility and push widgets to the corners. It is important to note the map in Armagetron is much more functional than in other games. You can play Arma using the map alone. I'm sure that why some like the map front and center. While I don't think design choices should be made by majority rule, users should get what works best for them, and if the majority of Arma players want the map tucked in a corner, that's fine.

GTA Mobile uses transparency well and perhaps this is something we can learn from. If a widget needs to be closer to the action without interfering, perhaps it can be ghosted?

Star Wars Battlefront, Descent: Underground

Battlefront has an elegant look, IMO. The widgets are simple and bold, though they seem heavily influenced by modern "flat" design (I wonder if it will look dated in the future). The placement is how you might expect, a hierarchy of important, continuous information close to the center of action and less important, static information pushed to the periphery. Like the GTA/COD/HALO above, SWBG incorporates a few icons. I've considered such a thing for Armagetron, but I'm not sure of an appropriate use at this time.

The currently unreleased "Descent: Underground" has a really sharp cockpit design with widgets for everything imaginable. This is possible in a game where the entire focus is on the player's reticle. That said, there have been numerous complaints on the D:U forums about the lack of readability, so this might be a problem of too much fashion, not enough function. Let's try to avoid this by picking a solid information hierarchy and color scheme.

TRON Franchise

Tron games are a mess with no cohesion. The only thing that keep them unified is the garish neon glow of every damn thing. At one point in my life I could truthfully say that I had played every lightcycle game ever released, but no more. There are just too many of them. Here is a list of games in the screenshot, most have only been around since Legacy:

• Tron 2.0
  Evolution
  Legacy (Flash)
  Legacy (iPhone)
  Tron (Unity Web)
  Evolution Battlegrids
  Legacy Mobile
  Legacy (Nokia)
  Game Grid Champions
  Lightbike 1 & 2

Lightbikes appears to be the most popular lightcycle game on mobile, AFAIK. However, most Tron games look hideous (except the extremely obscure "Game Grid Champions"). Visually, Lightbikes is an instant headache. Very few people capture the aesthetic of Tron properly.

A lot of those screenshots are from mobile games, which present their own problems with limited real estate. Again, none of these have a huge amount of screen space dedicated to chat like Arma does. While we might be able to squeeze something into Arma's upper-right corner (map perhaps?), we are pretty much left with draping widgets along the bottom.

There is a second discussion that needs to be had. We can't just talk about widgets and where to put them. Armagetron should capture an art style and that sets it firmly apart from the other lightcycle games. We have seen Arma skined as a number of things from trains to fish to other video games. We need a new skin that captures the future. What does it look like?

[Word]

We need a new skin that captures the future. What does it look like?

Art deco I'll try to think of something when I have time. For starters, I'd love to have a leaf-shaped rubber meter.

edit: Tada.

[Lucifer]

Ok, first, I pulled out the discussion of a unifying style and made a post (too lazy to link here). I'm thinking we should focus this discussion on what information to display and where, and worry about the style of the cockpit to be decided in that thread, where all style will be decided (assuming it goes anywhere).

Second, I like the idea of tracking player's eyes and seeing where they're actually looking. I don't think it's unreasonable to find a screen recording that can highlight where the eyes are pointing based on the camera. Hell, I have a phone (my second one that can do this) that tracks my eyes to decide how much to backlight everything, or even if I'm looking at the screen. The software *should* be there. To do this, we'd need a few volunteers, not many, maybe like 3 or 4, that would use several different cockpits, and we'd correlate where their eyes are pointing to how badly they're being pwned on the grid. So, if we can get the right setup, we don't need many volunteers, but we do need to test different cockpits.

Third, where your eyes point is actually going to be changed by the cockpit. So we can't just watch people play and check their eyes, we need to move the gauges around and see how their eyes work on that. We'd want the most efficient cockpit possible, which means it's both non-intrusive and easy to check gauges. There are many ways we can debate exactly how that looks, and the whole checking eyes thing would be an excellent way to measure such things.

As for how other games have done it, I've seen few games that did it right, in my view. The focus is usually on pushing the gauges off and maximizing visibility for what you're seeing. But in my experience playing various flight simulators, being able to quickly glance at the gauges is quite an advantage. I found the 0.2.7.0 gauges to be nearly useless, and the ones I found useful were tucked away. There's a reason I put the mini-map where I did in my own cockpit, and also the other gauges. Now, the exact placement I picked is probably not ideal for everyone, but the fact that I don't have to move my eyes very far to read my gauges, and additionally that I read my gauges regularly while simply following the action on the screen is indisputable. That's the benefit of my cockpit.

I'd like to achieve that for everybody, if it's possible, without having anybody whine about how gauges are blocking the action. Smallest eye movement to read the gauges, with nobody whining that they can't see what's behind them (even though you can easily see the other light cycles in my cockpit, heh).

Yeah, I'm a big advocate for my own cockpit. I use it, I've pwned all of you while using it. I studied my own eye movements (without a camera tracking them) to figure out where to place things, and I spent a lot of time thinking about how I would actually use it. There's a lot of "I" in there, though, so we need to do a lot more of "we" instead of "I", but stick to the same philosophy. Smallest eye movement, don't intrude on the action. Also, my cockpit is optimized for smartcam, but a lot of players don't use smartcam. Some custom cam players would find my cockpit unusable. So the default cockpit has to fit that philosophy and also server most custom cam users, not just smartcam users. That's a weakness of my cockpit, but you know, I made it for me.

So the ideas I used should be recycled again, but a wider audience has to be considered.

[Rain]

http://forums3.armagetronad.net/viewtop ... 60#p296860

[Word]

Happened to have another idea while sleeping (yep, I actually dreamed of Lucifer's post, although this is far from a final version that takes everything he proposed into account), so I got out of bed again for a few minutes. I thought it might be a good idea to have a more self-explanatory cockpit, since some new players don't seem to get what rubber is. In my draft, the bike is meant to hit the rubber bar like a wall, and the wheels are shown to heat up and emit sparks (I also added some sparks between the rubber bar and the bike).

One more idea. Since Yellow Submarine has been one of the most popular servers for years, wouldn't it make sense to have a cockpit/moviepack in the Hippie-style of the animation film? I don't think there are copyright issues if it's fan-made and non-commercial...and I bet we'd get tons of Beatles-fans to download the game, hahaha. This is what I'd like the rubber, brake and speed meter to look like.

Good night.

[sinewav]

In my draft, the bike is meant to hit the rubber bar like a wall, and the wheels are shown to heat up and emit sparks (I also added some sparks between the rubber bar and the bike).

Brilliant, really. I don't believe the cockpit can handle animation or sprites, but the general concept is great. I sketched up a version below. The cycle itself can be the speed gauge and fill up with color. In my drawing, the rubber meter fills as the cycle approaches the wall, narrowing the space between the bike and needle. Really, this is what rubber does at a network level. It's an artificial slowing of the cycle, but on the screen the bike appears stalled.

One more idea. Since Yellow Submarine has been one of the most popular servers for years, wouldn't it make sense to have a cockpit/moviepack in the Hippie-style of the animation film?

Haha. Ok, you draw it, I'll code it. Deal?

Jeez, I could start a side business making custom cockpits for players.

[Word]

Brilliant, really. I don't believe the cockpit can handle animation or sprites, but the general concept is great. I sketched up a version below. The cycle itself can be the speed gauge and fill up with color. In my drawing, the rubber meter fills as the cycle approaches the wall, narrowing the space between the bike and needle. Really, this is what rubber does at a network level. It's an artificial slowing of the cycle, but on the screen the bike appears stalled.

Thanks, I was sure you'd come up with something that looks better! As for the animation of my proposal, I thought maybe it's possible to just switch between a few transparent .pngs to achieve that effect, but I don't know either whether Armagetron can do that and how fast that image can be loaded so it won't show up too late for the player. Then the changing fill of rubber/brake/speed bars and arrows would have to be put in a layer behind that, of course.
Anyway, I think it's more feasible to show it in the way you did, because in your draft that animation is handled by the visually changing component of the rubber meter itself (the colored shape that is either growing or shrinking).

Haha. Ok, you draw it, I'll code it. Deal?

Deal. Give me a few months though!

[Phytotron]

Just to be that guy: if speed is unnecessary because it is relative, shouldn't framerate be under the same umbrella? I mean, it's pretty obvious when your FPS is shitty, you don't need a number to prove it

I didn't say anything about knowing framerate being necessary or even useful for gameplay; I just wanna know it. I find a speed indicator completely useless in that regard.

But have it enabled if you want, I don't give a damn. I don't know why you're arguing with my answering a poll about what works for me, anyway; I didn't say anything about other people not using it.

gibbering gobbledegook