"More than just programming"

VECTORLORD Visual Style and Supporting Photosensitive Players


NQ Transmission: BLINKY LIGHTS

Hola, Aloha, Bonsoir, Etc. NQDevon here.. and I'm going to write a bit about some of the visual design elements of VECTORLORD and how we're making it accessible for a couple different classes of users who might otherwise have trouble playing it.

Basics: Gamestate & Rendering

So starting with some concepts ... what is gamestate? why do we render "gamestate"? Even text adventures have a "renderer" of some sort, invoked you type "look" or "inventory". We render the game to show the player what's going on in the gamestate - which is really just some area of memory in the computer that describes everything in play.

A chunk of gamestate might look something like this:

struct character { int health = 99; int anger = 50; int stun = 20; };

In this case we have a chunk of data describing a few numbers. You can imagine that there's a whole array of these character structures sitting in your computer's memory somewhere. So the computer knows about these, but the player does not yet.

Photosensitivity: Part A.

For those who don't know or don't remember the Pokemon Shock of the late 90s - certain visual effects -- flashing and strobing -- became popularly known to trigger seizures in sensitive individuals.

We somewhat suspected - thought had not done the research yet - that VECTORLORD could have the potential to cause these seizures, due to how we intentionally visualize.

So what's the problem?

So back to that gamestate thing...

In our pre-VECTORLORD prototyping, it became somewhat obvious to me that it was rather fun from both a player position and a programmer position to visualize as much state as possible. At this point, there was no real design to VL, just a collection of mechanics that had been loosely arranged into a series of levels with some narrative. This game looked very different from the VECTORLORD of today.

In order to turn this nebulous sandbox into a product, with a deliberate design, we started to conceptualize and brainstorm about our game and our audience. Very early on, I came up with a simple mantra: In VECTORLORD: game state must always be visualized.

Another way of thinking about this, is that for every "event" in the game which has relevance to the player, we will visually express that in some way. A particle effect. A flash. A strobe. Information is not "hidden" from the player in any way, we lay it all out there on the playfield. (Sometime indirectly, , but it's always there.)

During one of our design-heavy phases, a couple of us working on the design were playing an awful lot of pinball. These games really inspired a lot of use of flashes and strobes to communicate information.

Wait... a flash... a strobe... where have I heard about this before....

Accessibly Blinky Lights

The thing is, we don't want to give people seizures if we don't have to, but we also want to make an extremely visually stimulating game.

So when approaching this, we had a few of goals:

  1. Refine our research on what constitutes a PSE (Photosensitive Epilepsy) trigger.
  2. Understand other aspects of our visual presentation that might be problematic.
  3. Figure out practical ways to minimize anything problematic without sacrificing gameplay or experience, and minimalize what we can globally
  4. Anything which we aren't comfortable changing for the global experience, but doesn't break the design too much should be implemented moved into a "Photosensitive" mode.

For research we looked at a few sources:

We also used our own collected feedback from playtesting, which covered a broad range of backgrounds, gaming experience and ages. Some people loved the crazy graphics. Others felt distracted, unable to pay attention or overwhelmed. In fact, we already had started balancing for this way back in September. Reading through the accessibility guidelines gave us a clue as to what might be going on here: It appears pretty clear that we had not just a potential PSE issue, but likely had an ADD issue as well which was alienating some players.

Fortunately, there's some pretty clear guidelines we can use to make sure VECTORLORD is at least safe. The pixel values expressed in the web guidelines can be easily extrapolated to whatever monitor resolution and you can use them as a guideline for regional flashing.

Fixing Flashes with The Magical Low-Pass Filter

One of the first things we did, was eliminate 80-90% of the areas where hard-frame-cuts were used in state-transitions. I.e., never having a light go from being 100% on the first frame, to being at 0% on the second frame. For certain game events like laser gates and collision glows. Universally we implemented this using low-pass filters anywhere hard visual state transitions were used.

A low-pass filter is a filter that removes high frequency content from a signal. An instantaneous state change (from 0% one frame, to 100% another frame) has effectively "infinite" frequency because the change happens immediately. One of the simplest things to do is just add another variable to keep track of things and use some simple math to create what's called an Infinite Impulse Response(IIR) Low-pass filter which looks like this: filtered = (input * a) + (filtered * (1 - a))

So if "a" is set to 0.1, then 10% (10/100 == 0.1) of the input signal will be added to 90% of the filtered state. The out come of a filter like this is that instead of going from 0 to 1 instantaneously - it gradually changes to whatever input is, but over a series of frames with a rate we can control with a. If you're astute you might notice that filtered will never actually reach impulse, it will get progressively closer and closer always cutting the gap by 10% but never reaching its target, which is why this type of filter is called an Infinite Impulse Response filter.

There are Finite Impulse Response(FIR) variants that could be used as well, but IIR filters are effective and simple to program.

The downside of filtering, is that we have introduced some output lag - which is something we generally want to avoid, so for actual active elements (stage hazards etc.) sometimes the "damage" region had to be tuned to better match what was appearing. In other case, the effected flashes are "secondary" information, that informs the player about an action they have invoked, but is not critical to making their next move.

Animation Speed

Originally we thought this would be a PSE issue, but based on our research this applies more to users with ADD related issues.

While in some cases animation priority is used a lot of the gameplay in VECTORLORD does not really care what frame a particular piece of scenery looks like. A lot of the "secondary animation" in VECTORLORD mostly happens through its particle system. Here we had an interesting option availble to us - we can find non-essential animations, and increase their animation divisor. The way this works is sort of like the "step division" you'd find in a Music Tracker.

We can even make it a bit "smarter" but having the divisor increase more as the objects get further away from the player.

Photosensitive Mode

When all was said and done, here were the changes we implemented for our Photosensitive Mode which we hope will allow more player to enjoy playing VECTORLORD:


Even before we implemented these changes VECTORLORD passed in testing with PEAT. Honestly, this surprised me but I am unsure how to verify if the program is working as expected. It was unable to read AVIs created from our OBS captures, so instead we utilized its built in "capture" tool to capture VLC playing back our FLVs. It forced VLC into a smaller frame, and could not capture VLC until I changed its rendering mode to the very old GDI fallback.

While I'm fairly sure it did capture succesfully (as on analysis it shows thumbnails), I suspect that this tool is not capturing at 60FPS, and can't really rely that it's able to analyze some of the rapid frame sequences in VECTORLORD which would effectively "disappear" in aliasing if sampled at anything less than 60FPS.


05-23-2020 -- VECTORLORD 1.1 Economy Update
05-01-2020 -- Why All Coordinate Systems Suck
04-22-2020 -- VECTORLORD OST
04-05-2020 -- AntHive
03-10-2020 -- VECTORLORD Visual Style and Supporting Photosensitive Players
03-08-2020 -- NerveQuake Introductions
03-06-2020 -- Transmission
NerveQuake Software Inc.