I really enjoyed the demo. Even in it's current state, it looks like maxseer has a lot of potential. I do want to report that most of the text was read through system tts, but every now and again, a string or two would be read by NVDA instead. Maybe I was pressing something to switch them, but I'm not sure. The wall system is great. (and nice on the ears in my opinion even though they are represented by constant tones) I was able to find my way around for the most part, but I had a hard time understanding the pathfinder. What would it take to begin looking into placing this on top of an existing game?

This is because of a known bug in NVDA that causes it to not say text if you're pressing down on certain keys. Since most NVDA applications are based on key presses instead of key holds (like moving around a room), this usually doesn't cause any issues. As a workaround, it switches to SAPI. I will reach out to the NVDA developers when the max-engine gains more momentum.

The pathfinder is a bit broken. Basically, it makes a grid where there are collisions and forms a path if it can find one. However, sometimes it makes the grid incorrectly and can't find paths properly. When it does make a path properly, you can hear it move away from you in a certain direction. When you follow the path, it makes a constant steady tone, but when you move against the path it makes a more jagged tone.

I tested the pathfinder last night and found some areas (especially in the Foyer) have issues with the pathfinder so I'll be investigating that on the next release.

In this example, when data is read from the XML file, it creates two kinds of data:
- Maxseer info data
- Map data (if necessary).

Lets look at collisions as an example since they're used by both. The object that stores the collision data before being loaded onto the map is here:

https://gitlab.com/labadore64/maxseer/b … ionData.cs

Collisions in maxseer only need polygons to define their boundaries so it loads the same polygon data as the collision does, and it creates the collision and adds the maxseer collision at the time of being loaded. Likewise, when the map is unloaded, maxseer's map data is cleared.

Also, maxseer's listener position is updated whenever the player changes position:

https://gitlab.com/labadore64/maxseer/b … er.cs#L122

While this demo is very simple, you could add these components to any object. For example, lets say you have objects defined in an xml file, you could add a property that allows you to add a label onto that object, so every time that object is spawned, a maxseer label is also spawned. There is a lot of parameters that allow the end user to customize behaviour, such as whether or not labels are added to the navigation menu, ect. Then, when a dev creates an object, he just has to add its accessible name and description, and bam, the label is loaded with the object.

Also, devs can define their own maxseer classes for custom interfaces if they need to, by inheriting the maxseer interfaces. In fact the SoundController is an interface so that it can be redesigned with a custom engine.

So basically, devs take their currently existing collision data shapes and transform it into an array of polygons, and feed those polygons into the maxseer engine, to load the collisions.

Maxseer is not a game engine by itself, it's a module that builds a map with features loaded from a game engine (such as collision data) to automate accessibility features regarding navigation. Also it had an input manager which comes with keybinding out of the box.
So basically it automates certain accessibility functions and has out of the box tools for various needs.

It has a small game in the repo it's attached to. It actually imports it as a nuget package.

What I'm doing is building a game, and converting certain parts of it into modules, maxseer is the first one. People can attach these modules to their project and interface with them through their code.

More importantly though, because the modules are not part of the engine's source code, custom modules can be built and as long as they contain the same methods they can be used for all sorts of custom purposes. This has nearly unlimited potential for certain accessibility problems. For example, of you wanted to customize inputs, you just need to make a custom version of maxseer that accommodates these inputs and allows the user to define these functions instead of the engine.

Also, a major difference from most game engines is that the released components are open source, but I'm still debating on the exact license. It's actually very different from most game engines because it's designed as a bunch of parts to be assembled or even attached to other engines.

A major reason why I'm doing this is a startling level of lack of ability to build games without depending on Middleware software, along with the high modding potential games made with these components.

The demo is just an example of how to implement maxseer into a game. The demo is not really for release but I made the source code available for reference.