*** Vendetta 1.8.545
- New prototype UI for the Login, Character Select, and Options menus
available on Windows. The previous skin can be selected in Options ->
Interface -> UI Skin -> Platinum
- If a player's "Named" capship is destroyed and is not Enduring, the
name is reserved for 30 days for the player to use again, during which
it may not be taken by another player.
- Fixed an issue where the Strike Force would ignore a player's capship
when a TempKoS is placed on the player.
- Fixed issue with Vulkan driver not using the correct window size when
changing resolutions in window mode in Windows.
- Alt-Enter now works in the Vulkan driver in Windows.
- If the Vulkan driver crashes on Windows, the game will fail over to
DirectX 11 the next time it is run.

Login Dialog:


Character Select Screen:


Options Dialog:

***That mess in the top-left are plugins that I made that fit in the old interface.

If you use certain plugins that modify the options dialog, your game might crash. Some do, some don't - depends on the plugins!
Please remember that Incarnate isn't responsible for any game crashes caused by outdated plugins.

Known plugins to NOT WORK:
TCS (Instructions to patch below)

Please list more below if you find any, and we can add it to this list, so whoever can figure out a patch plugin that will let these plugins behave correctly again.

For TCS, if you edit the main.lua, you can comment out the line that reads:

    tcs.ui.InsertOption(tcs.ui.configb)

Just put two hyphens in front of it.

    --tcs.ui.InsertOption(tcs.ui.configb)

Fucken A.

I dig it

I've been really gratified that, from what I've heard, most people like it. That really means a lot to me.

It's very much a first-pass, trying to get handle on the new concepts and how we'll make them work, and then approaching each UI one-at-a-time as we have time.

Character Select is, by far, the most complex menu that I've re-designed yet. There are a lot of features that are intended in concept, but not yet implemented, like "character card" tags to show if you have unread Buddy Notes or Buddies Online or whathaveyou. It's all still pretty early.

I just came up with the entire concept of how this new export / prototyping-system works, only a few weeks ago, at the end of February. Ray had the first prototypes of the new Login menu working, roughly a day after I had the initial idea.

I wrote a little about the historical challenges of the UI at the end of the March Newsletter. There has always been a huge implementation gap between "design mockup" and "in the game", where it would leave me as a visually and usability-designed construct, but then end up in the game (after a lengthy and arduous implementation process) as a seriously mal-adapted trainwreck of various trade-offs over UI-system constraints (across various device sizes, aspect ratios, etc).

The technical issues, combined with the lengthy related development cycles, ended up making us a bit UI-avoidant. Definitely not ideal for a complex, cross-platform MMORPG, which really needs robust UI / UX; along with fast iteration as things are added or systems change.

I had spent a lot of time, over the years, researching other game UI solutions, which mostly use systems like Microsoft Blend to produce XAML output, which then can be scarfed into a system like Noesis (a paid middleware product). Or, even scarier, using EA's custom Chromium fork and actually integrating all of Chrome into the game. Which may then leads to all kind of exciting internal thread-contention and UI-framerate issues. UI performance impact gets pretty important when you're dealing with the high requirements of VR, and the like.

Systems like Dear ImGui and Nuklear seemed pretty cool and fast, but weren't always compatible with our requirements (specific Lua versions, for LuaJIT compatibility, or various implementation preferences), plus a lack of "designer" WYSIWYG tools that could be handed to an artist, as well as still making it a challenge to transition from one existing UI system to another (without redoing the entire game at once, which could be a multi-month process).

The webspace and "app" world uses a whole different set of tools, like Adobe XD and Sketch, but by and large those all just output "a website", which is not very helpful for a lightweight real-time UI. Again, unless one wants to bring in "all of @#$!ing Chrome", which I did not.

Our existing Lua UI, while extremely irritating to implement-for in some ways (around UI-scalability and such), is actually very fast and lightweight. So, finding a way to be able to get a better toolchain system for "importing" the UIs was the larger issue. If we could solve that, we wouldn't have to implement any other UI system, at all. We would also circumvent the need to really have to do much "custom implementation" on any given UI, as it would just import directly using established mechanics (plus, we would stop trying to "redesign-scale" anything, and just 16:9-or-letterbox the whole interface as a fixed construct).

So, the new system actually uses Photoshop to design everything, and saves out to SVG, and we work with the SVGs directly. Photoshop packages up images as PNGs and embeds them in the SVG, which are currently just loaded directly as uncompressed textures (part of why the prototype is Windows-only for the moment, and not on lower-overhead systems like mobile).

There's still some degree of customization, obviously, things like the Character Select panel have "output fields" defined for things like text-displays and the spinning-ship, which are done via "rects" (rectangular polygons). We also embed some metadata into the SVGs themselves.

So far it's been quite nice for the rapid prototyping, and that's really what I'm all about. I want to have a system where we have the flexibility of something like Photoshop to make it "look" however we want, and then drop it in, and have it actually look exactly the same (or, "very close"). I never again wanted to have that period of "and now it gestates through an implementation process, and comes out horrible and totally different!" (or takes forever to make it work as-intended).

There are various on-going challenges around font scaling/sizing and localization and so on, but, so far so good, overall.

Moving forward, I'll be focusing on interfaces here-and-there as we figure out how to best use the new system, and keep adding to it. I'll be focusing primarily on the early-game (like the new user experience) and the login stages and such, most likely. Eventually I will tackle the grand mess that is the "primary game UI", but that's a significant undertaking and we'll want to have a lot of the generalized mechanics established first.

The system will also be upgraded to integrate better with our game-asset mechanics, so during a "release package" process, PNGs will be extracted from SVGs and placed onto "texture atlases" (single texture, containing many images), which is then compressed, and so on. We'll still be able to fast-prototype with SVG, but the final results will be more efficient for production use.

But, that'll happen a bit later. The UI is light enough on memory that we aren't too concerned about effectively "prototyping in Windows production" in the meantime.

In the long run, when things are a bit more standardized, I'm hoping we can expose the entire system to the userbase, because through this the whole UI can be changed around pretty easily by people, in ways far more elaborate than what was possible with just "skins".

I know people have asked about general API access into the new UI, for plugins and the like. And we'll take a look at that when we can. But, for now, my primary target is "make game look better, more usable".

I hope that's all.. interesting.. to someone..

I wish I could see it, but I don't own a Windows (virtual) machine.

Incarnate said:
because through this the whole UI can be changed around pretty easily by people, in ways far more elaborate than what was possible with just "skins".

I've been able to change around the existing UI in some pretty elaborate ways already. *big cheshire grin*
But, yes, I agree. It's not always obvious or easy to get exactly the look you want.

you guys use photoshop itself? Wow; I was envisioning that you guys had built your own tool more like dreamweaver - you could place constraining bounderies for an "object" somewhere on a 'dialog' and then define a behaviour for it, either from a preset or linking it to a seperate file, and then you would just have that tool compile the dialog into lua iup code.

Now THAT’S a sexy UI.

I've been able to change around the existing UI in some pretty elaborate ways already. *big cheshire grin* But, yes, I agree. It's not always obvious or easy to get exactly the look you want.

Yeah, obviously there are people like you who have the skills (and patience) to make that work, but it's a bit convoluted, right? I think it would be cool if it could be done by someone who might not have that depth of technical expertise.

you guys use photoshop itself? Wow; I was envisioning that you guys had built your own tool more like dreamweaver

Generally, it's much, much better to use an industry-standard tool, that is well-established and well-known amongst potential designers and artists.. than it is to build some entirely-new thing that has to then be "designed" to be usable, has to be maintained and updated regularly, and has to be learned by any new person who is added to the team.

We do have a lot of custom, in-house, elaborate tools, and in some cases it's unavoidable. But, I would much rather avoid it if possible, otherwise you go down this road where you end up becoming a "tools company" just to be able to build things for your game.

Plus, if one wants the coolest potential interfaces (and I'm not saying that's mine, this was just a simple first-pass), you want to give the artist as much opportunity to directly export exactly what they want. And, artistically speaking, it's pretty hard to beat Photoshop, in terms of industry-standard tools of high capability.

If we had made some kind of DreamWeaver type thing, you'd have to export your images (out of, most likely, Photoshop) and then load them into some other thing and.. work with the elements and so on. Then you're back to Microsoft Blend and outputting to XAML. Which is an entirely viable solution (a number of big shops are using Noesis now). But, I have a suspicion that using the Photoshop -> SVG route directly is much better for rapid prototyping and easily realizing concepts.

The SVG aspect also leaves open the possibility of rolling our own entirely-custom tool down the road, if at some point that makes the most sense, in terms of time and flexibility. We can still pack whatever vector and bitmap data we want into the format, fairly simply, along with embedding metadata for the functionality of the menus.

Good thing i've been holding off on touching any of my skin projects.

teeeheeheee!