(*not the UI component)
In EVE-online we have, for years now, clung to the joke “EVE has sound?”.
While EVE most definitely does have sound and some freaking great music, the joke persists because many players consistently play without sound, the reason for this is singular and simple:
The audio environment in EVE is not sufficiently informative to warrant it’s use.
This is not just a problem with the audio however, the difficulty of keeping track of the changing situation around you in EVE can be challenging, at the very least it is usually demanding of the player. Keeping track of changing conditions via the overview becomes increasingly taxing as the number of entities on your overview increases. Players have over the years developed ways to circumvent some of this strain by customizing their overviews to certain tasks (such as, for example, limiting your overview to certain ship classes). But it remains difficult to be aware of… everything.
Any PVP oriented player (and not just in EVE) will happily confirm that situational awareness is one of the key aspects of winning more fights than you lose in PVP encounters. Knowing when you are about to get jumped on by reinforcements, knowing what your enemies are actually attacking, having good information on the status of your allies; All of these things are significant contributing factors to victory, or defeat.
EVE is an unusual beast in the MMO world due to the fact that the amount of data it’s players are required to parse is very large, much larger than other MMO games. This has resulted in some issues in conveying the data to the user in an informative way. We have the (much maligned) overview as our primary UI element precisely because there is no convenient way to display such an amount of data in any form other than tabulation… or is there?
This is where, in my opinion, sound design (and some additional window-dressing and a change in UI paradigm) can come in.
The goal here is to provide the user with a significant boost in how easy it is for them to become aware of changes in the environment around them, this will also have the additional beneficial side-effect of enhancing immersion; and let’s face it, immersion is awesome.
Part I: Sound as a UI element.
In this first section we are going to look at some of the current sound design in EVE, and examine a number of scenarios where sound could be used to bring information (which might have otherwise gone unnoticed) to the pilot’s attention. Most of these ideas follow this logic: “When X happens, Y is visible in the UI AND Z is the corresponding audio cue for the user”
The case for using sound.
But why, really, would you want to have sound elements to go with certain interactions? People play the game just fine without sound after all right?
While the above might be true, this does not mean players are enjoying the game as well as they might like, and there are quite some compelling cases for using audio. Developments in this area are currently in use in many vehicles we use in real life, and for good reason!
1) Prevent information blockage by adding additional channels.
Much like any information system, the human brain has several channels through which it can receive data, but each of those channels has a bandwidth which is determined by the limit on the speed at which the receiving organ at the end of that channel can absorb data. While I would not recommend having tactile feedback added to internet spaceships right now (Though I am quite positive Torfi would love that… in a scary way) we are currently using primarily the eyes as a receiver.
Now, how much data you can absorb from the screen to your eyeballs is limited to how much you can actually read, per second. The fact is that you will quickly get bogged down this way, once the overview grows too long to see without scrolling additional delays in the form of searching for more info than fits on the screen using your mouse and keyboard aggravates the already taxing rate at which you need to read. You eventually reach the point where, automatically, you begin to stop paying attention to certain changes because your bandwidth is completely saturated with what you are doing at the time.
We can utilize the additional channel of hearing to convey cues and critical information to the user, this information will not be stopped by the data-processing blockage the user is experiencing and should (in most cases) make it through to the brain, whether or not the user then ACTS on this information is a different story and is subject to the situation and their training/ability to make decisions.
2) We can make information that was previously only deduced by logic directly available
A lot of being aware of your surroundings in EVE currently revolves around knowing who is in system, who and what is on grid with you, and noticing when these factors change. This information is only available to you from a secondary source; You need to watch your primary data sources (overview, local in this case) for changes and then deduce or compute from these changes what has actually happened.
Human brains are not terribly good at doing this on the fly, when my overview suddenly grows by X entities, I cannot tell you how large X was just from seeing the visual change.
Imagine however, a situation where these changes are communicated via audio cue, I can now keep doing what I am doing (following primaries, looking at where I am actually flying etc.) while still being alerted that 15 new contacts have landed on grid, and quite possibly I need to get my cowardly pirate behind to safety.
3) It massively enhances Immersion
EVE is, despite many things, a roleplaying game. And it is no surprise that roleplaying games become better and more enjoyable as your immersion in the universe increases. Currently this player to game interaction takes place mostly outside the actual gameplay. It expresses itself in the choices people make regarding their activities, ships, allegiances and even how they see themselves (nobody is just “an eve player”. They identify as a specific type of player, like a Pirate or an Industrialist or even a Goon). We can improve on the immersion in the gameplay part of the game by enveloping the player with UI elements (both visual and aural) which resemble things that would logically exist in the universe.
Many players I’ve spoken to remember their initial interactions with Aura in the tutorial with fondness, Aura is a part of the universe and through her the universe is talking to you. This pulls you into the game. By enhancing the user interface to feel more like a part of the universe, rather than a layer which exists between the player and the universe we can make EVE more real.
The following is a collection of examples where audio could be used to improve on the UI, not all (read: none) of these are fully developed due to time constraints (I do have a day job you know!) but they should prove useful to demonstrate at least the core of the idea.
EVE does have some audio cues right now, firstly: you have warnings for low shield/armor/hull, which are useful and can be adequately configured to suit your tastes .
Secondly you have a set of audio cues which either tell you that a command you have given is being executed, or CANNOT be executed because of some external factor.
The implementation of the second set of audio cues is, in my view, ineffective. It’s fine to get an audio confirmation of an action you are taking, but it’s much less useful to hear you cannot warp because you are being scrambled, or that you have no capacitor because someone has neuted you.
You need to be aware of these things before you’d even engage the action they prevent.
First case: Electronic warfare
Electronic warfare is a big part of EVE, a relatively recent addition to the visual UI is indicators which allow you to tell when you are being targeted with ewar modules (and by whom). This has been a fantastic boon to players (especially newer ones), but it could still be improved.
As a start, due to the amount of bandwidth saturation already experienced visually in fights, it becomes very easy to not notice that one opponent has a 75km scram pointed at you. You will find out too late if Aura tells you you can not warp when you really want to warp. It’s disheartening to discover these things when the time where you could actually do something about it has already passed. Instead, Aura should tell you WHEN somebody initiates tackle or other ewar on you.
The script for this could be something along these lines:
[Trigger] Ewar module(s) is/are activated on the player’s ship
We can split these warnings into two segments
1. Individual (single) Ewar notifications
— “you are being [Warp scrambled, Webified, Neuted, Target Painted, Tracking Disrupted]”
These notifications could be more in-universe to allow the player to differentiate between the types of Ewar without breaking immersion, for example:
Scrambled: “Warp drive disabled”
Webbed: “Propulsion Inhibited”
Tracking Disrupted: “Targeting subroutines impeded”
Jammed: “Sensors disabled”
2. Multiple Ewar notifications
–“Ship functions impeded”
Specific combinations of Ewar could perhaps be combined if they frequently occur together (i.e. web/scram)
“Warpdrive and propulsion systems disrupted”
Obviously there needs to be some logic in place to prevent abuse cases or audio overload in scenarios where you are being targeted with a large amount of Ewar, a single “Ship functions impeded”, perhaps repeated 30s later should suffice to alert the player that something is wrong with his ship.
Second case: Grid Awareness
Knowing who is on grid is normally a function of looking at the overview. As previously mentioned rapid changes in grid population due to new arrivals (be they via warp of cyno) are extremely hard to parse by looking at the overview (which you have set to alphabetical anyways, because you need to find those primaries!). This can be made easier and more immersive by being alerted to changes by Aura.
[Trigger] New ships on grid
As before there are a few different scenarios here.
1. Single new arrival on grid
— “New contact”
2. Multiple ships (2-10) are going to arrive on grid within the next X seconds
— “Two/Three/Four/…/Ten new contacts”
3. Multiple ships 10-30 are going to arrive on grid within the next X seconds
4. Multiple ships 30-60 are going to arrive on grid within the next X seconds
5. Multiple ships 60+ are going to arrive on grid within the next X seconds
The granularity of these messages is naturally open for debate, but the guiding principle here is that the audio cue not only informs the player that something new is landing near him, but also give at least some indication of the numbers that are arriving. This information should be available to the systems, as the server knows where players are warping and which grid they will end up in. The message should be played during the “grace period” where the ships are rendered as dropping out of warp.
These audio notifications should additionally be accompanied by a new visual effect to show the player where the new contacts are in his viewport. This effect should be somewhat similar in function to the (excellent) new damage-dealer indication circles you see when someone is shooting at you. The new contacts would be marked out by a green or orange glowing circle which starts large and contracts while blinking to a small circle around their bracket. The effect should linger for a few seconds before fading and perhaps be accompanied by a subtle sound effect (count the beeps!).
This combination should lead to the following sequence of events from the perspective of someone on grid:
1) Audio warning notifies pilot of a change in grid
2) Pilot can decide by the numbers indicated by the warning whether or not he needs to look at this
3) If needed the pilot can look around and easily determine the position of the new arrivals by their temporary visual effect
Another frequent topic in the grid awareness section is the presence of Cynosural fields, specifically when they are being lit. When a Cyno goes up in a bigger fight it is very possible to not notice the single new line on the overview, especially if the Cyno is lit some distance away making the visual effect hard to see.
[Trigger] New Cyno on grid
–“Gravitational distortion detected”
Optionally there might be a specific cue if multiple cynos are lit in short succession/at the same time.
Third case: Target status
Audio cues can also be useful in helping the player understand changes in, and provide information about their target.
[Trigger] Target is destroyed
[Trigger] Lose lock on target (but not destroyed)
The astute reader will note that if you lose lock because you are jammed, you will get two audio cues: “sensors disabled, target lost”. This is intended, you will only ever hear the quote by itself because the target is out of your lock range or has warped.
[Trigger] Target is attempting to warp
–“Target has engaged warp”
This particular bit of info is very useful to pilots in gangs to tell them the target is NOT scrambled, or that the player has lost point themselves.
Fourth case: Modules
[Trigger] Attempting to engage a module on a target that is out of range
–“Target is out of range”
[Trigger] Module deactivates because target is out of range
–“Target has left range”
[Trigger] One or more modules is/are 90% damaged from overheating
–“Heat levels critical”
Fifth case: Self-awareness
Not the enlightened kind, but the kind of information that pertains to your ship during battle on a larger scale than being hit with some form of Ewar
[Trigger] You are being locked
— Locking sound effect, but adjusted in pitch/tone to differentiate from your own locking sound
[Trigger] You are being fired upon
–“Incoming enemy fire”
Part II: Managing sound and accessibility
There is a very important thing to remember when moving some notifications into the audio realm, or creating new audio cues for events not explicitly covered by the visual UI already: We need to remember that not everyone can hear. (and that, arguably some folks should not have to if they don’t feel like it).
Additionally, it’s important that we give players the option to customise the information presented to them both visually and by sound. To this end I propose a panel where the player can control what sounds the client will play to him, and perhaps what thresholds certain notifications occur at (much as the shield/armor/hull warnings already have). This panel will also control the new Event HUD (more on that later) and whether or not to display certain visual prompts centered around the enemy ship’s bracket (more on that later as well).
Ideally we would allow for a number of presets to be saved by the player, so they can quickly select a preset suited to their current activity.
The event HUD
The event HUD would be a new visual UI element to enhance (or perhaps replace) the current combat messages which are of limited use due to the complete lack of sorting.
The event HUD should (preferably) be rendered as a 3D object so as to benefit from a proper HUD-like transparency effect and the ability to display a wider range of visual effects. On the event HUD all events that occur with an audio cue (other than losing target) are displayed in a user defined colour and brightness. The user can also control how long certain notifications last. The event HUD should be somewhat reminiscent of the old user-created UI mods on other MMORPGs for alerting players of events in complex encounters with things such as raid bosses (or intense pvp action).
Why would we go back to something made in WoW? Because, frankly, it works.
By allowing the user full control over what information he finds pertinent enough to appear in BIG RED TEXT and what information the user wants to see in orange, yellow, and so forth the user can manage the flow of information.
I’ve included a quick little photoshop here to get the idea accross.
The idea here is to divide the combat notifications into categories of importance and to attach to them an appropriate size/hue as the user sees fit.
Additional “threat rings”
The (relatively) recent addition of red rings around ships that are trying to murder you with lasers, railguns, missiles and what have you has been a pretty nice, if not terribly noticeable, addition to both the awareness and immersion aspects of the game.
I would propose to augment this with additional indicators in a similar format to help the player quickly deduce (in a spatial sense) who is jamming them, scramming them, neuting them and so forth.
- This would be accomplished by augmenting the damage rings with a separate threat circle that pulses in an appropriate colour whenever an ewar module is engaged upon you, and every X seconds after that if it remains active.
Naturally I’m not sure how feasable this is from a technical perspective, but I quietly hope it is as doable as the damage indicator circles were (perhaps the same code can be reused)
I know I’ve gone on at some length (consider yourself lucky, I cut almost half the examples in my post) I apologize for making your eyeballs bleed, but I do believe this subject is important.
The UI is one of the most maligned parts of EVE, and sometimes the reasons for this notion are actually sound (ha. ha.). And speaking of sound; if your players continually make the joke that your game has none, clearly there is an opportunity there to do more with it! I feel that making EVE a more audio-centric experience, and backing that up by enhancing the visual UI cues that go with the audio information we can make playing EVE more immersive and have more important information directly and clearly available to the player.