UI/UX Artist: Nav Screen Graphical Updates

Hi all. This is your UI/UX Artist Paul. I've been busy tackling the Navigation Screen's visual design overhaul. Facelifting this screen is proving tricky. This screen more than any other will be subject to an overwhelmeing level of visual activity due to its nature as a real-time 3D RTS screen. For that reason I have a few experimental prototypes, and further evolutions of the look and style will be inevitable. On one hand the interface has to be visually legible so that it doesn't blend in with the action happening in the displayed worldspace. At the same time it can't get in the way either. Stylized UI and minimalist UI need to be balanced particularly well in this case.

UI/UX Artist: Nav Screen Graphical Updates

One prototype reuses the hexagon theme, albeit at the cost of being the clunkiest model.

UI/UX Artist: Nav Screen Graphical Updates

Another opts for a mirror reversal of the previous backdrop screens, highlighting the bezels in glass blue (of which there won't be a lot of on Mars) while letting the screen fill sink into ambience with a soft transparent gray.

UI/UX Artist: Nav Screen Graphical Updates

The most minimalist of the prototypes forgoes borders and shapes completely, and uses light gradients to backdrop the various ingame grids.

Navigation screen (RTS) gets more love

Navigation screen (RTS) gets more love

The Navigation screen (the RTS screen) is the heart of the RTS side of Rank: Warmaster.  With the terrain updates and other screens being updated, it was time for this side of the game to get worked on.  One of the larger problems with the RTS screen was the lack of coherent controls, so the player doesn’t fight the game to do simple things.  Part of the reason why it can be complicated is in a typical RTS, the units either don’t move very quickly, or in general they stop and then attack.  With the units being slow or stopped allows the player to easily select their units or to click to attack the enemy units or structures they wish to.  Rank: Warmaster, because it’s a true 3D real-time environment, a typical battle will devolve into a constantly moving furball of ships all dancing with each other and intermingling.  While lovely to watch, it makes it impractical to click on your own ships, let alone the enemy ships to target them.  Clicking on these ships is still possible, and to help keep a relative frame, the game automatically scrolls (and zooms out) to track what you have selected and keep what you have selected on screen.  While this helps, this isn’t enough to quickly find what you are looking for.  To that end, I’ve added a series of on-screen buttons (with keyboard equivalents), which will likely get refined as they are play tested, that allow a quick selection (and centering with a double tap) of yourself, your ships, idle ships, builderbots, cities and of course, the enemy.  The idea being that one could simply hit “all my ships”, then the attack button, then select “enemies” and then execute, and you just gave an order of all your ships to attack the enemy.  Generally, at least with the enemies, it selects what enemy ships are on screen, while the other “friendly” selections are more geared to finding your ships, on and off screen.  This will likely be tweaked, of course.
               Another addition is far more usable keyboard shortcuts on WASD (QE) for scrolling the display (Q and E are up and down), with holding the SHIFT key to have the WASD change the pitch and heading of the display, with Q and E changing the scaling.  This makes navigating the battle area FAR easier than before with only mouse controls or on screen buttons.  Good controls are what makes or breaks a game, and so improving the controls for the Navigation screen is my current goal.

We will be testing these new controls on this week’s livestream!  We will be livestreaming to twitch this time, and a later video upload to youtube.  Please join us!

Gun assets

Gun assets

Progress of the gun assets. 

Full story »

Behind The Scenes

It's been a busy couple of weeks, despite not having any new pictures to show. We've done quite a few bug fixes based on our multiplayer testing. For example, it turned out that players made assumptions about how something as simple as trading assets back and forth that didn't match the assumptions I'd made when originally setting up that system, which required streamlining that entire process in code to match how players wanted to use the feature. For another example, as soon as players were able to start building installations, they tried quite reasonably to build multiple factories to speed up ship production. But the factory screen was originally built over a year ago, and we hadn't been able to test it properly at the time, so we discovered to our dismay that not only were ships waiting to be built not displayed the same on every player's computer, but multiple build queues very much did not display correctly. The good news is that fixing those bugs have made not only the factory screen but some of the back end code better and more stable. Stay tuned for even more progress to come!

UI/UX Artist: Multiplayer Join Screen

UI/UX Artist: Multiplayer Join Screen

Hey everyone. This is your UI/UX Artist Paul. I've been adding more elements to the Multiplayer Screen. Now we have the Join Screen, which is essentially the vestibule to the Lobby Screen where players select which server they will be joining. Password entry as well as other settings will also be handled here. 

The Terrain is finally fixed! Load/Save in Multiplayer and more!

The Terrain is finally fixed!  Load/Save in Multiplayer and more!
The Terrain is finally fixed!  Load/Save in Multiplayer and more!
The Terrain is finally fixed!  Load/Save in Multiplayer and more!
The Terrain is finally fixed!  Load/Save in Multiplayer and more!

It's been a very long time coming, but the Terrain (at least visually) is finally fixed.  No more gaps, or very obvious triangles, so the weaving is correct.  Some of the equations still need some tweaking functionally, but visually it's fixed.  It also supports "tiles" of height maps so expect at some point more interesting terrain rather than the perlin noise generated one here.  The terrain is one of those things that is never done, so other things will eventually be added, perhaps shadows, and certainly a better tweaking of the Level of Detail on the mountains based on distance. 

Another major enhancement that can't be seen on screen shots is the Terrain generator now is on a different processor.   While this forced creating a secondary buffer for the terrain, there are no longer lag spikes when the terrain needs updates.  While the lag spikes were tolerable, it became obvious it needed to be addressed.   I look forward to moving other major processes to other CPU cores too.   The image loading and decoding was done a LONG time ago with massive improvement.  I hope to eventually move the movement and weapons fire routines to other cores to speed up processing, to handle far more ships without a performance hit.

There have been a lot of improvements and bug fixes behind the scenes.  The MAJOR improvement is the ability to Load and Save in Multiplayer!  This is huge since now it is possible to have a continious game, and even handle issues better if there is a crash, just load where the autosave left off!

More to come soon!  Please visit us on the Multiplayer tests on our youtube channel!  A crowd funding campaign will be starting soon!  Be on the look out for it!

 

Low Poly Guns

Low Poly Guns

New 3d creations to share this week are low poly guns for players to place on ships. Like with the turret model, these also need to be a low poly count. I have some new texture brushes that will really push these forward as limited low polys. 

New Screen: Self-Damage (& More)

New Screen: Self-Damage (& More)

We only have a few more screens to add to Rank: Warmaster, and here's a preview of one of them: the Self-Damage screen. Its most important function is, of course, to provide a detailed view of how the ship you're piloting is faring, but when complete, it'll also do a fair bit more. For example, it will also provide an access point for scans of enemy ships, in addition to your own. On top of that, you'll be able to set a variety of controls related to the experience of piloting your ship, such as power subsystems priority or, as seen below, weapon tick settings. Weapon ticks will allow you to set which controls activate your weapons fire: your keyboard controls, your joystick controls, and so forth.

New Screen: Self-Damage (& More)

These are preliminary versions of this set of screens, of course. Stay tuned as we finalize them and create and roll out custom graphics sets!

UI/UX Artist: Multiplayer Lobby Update

UI/UX Artist: Multiplayer Lobby Update

Hi all. This is your UI/UX Artist Paul. The Multiplayer Lobby is coming along nicely! Screen real estate is being better prioritized and certain elements have been reduced accordingly, as can be seen with "Game Types" being removed and the Player Listing taking a front row center seat.

Fixing Spheres and Planets

Fixing Spheres and Planets

As you may have noticed, when a sphere (including a planet) was presented in previous screen shots, the poles were always black.  This was a cosmetic issue for the most part, so wasn't high priority to fix.  Since landing on planets is becoming more important, that little dark spot can go for miles.  So the idea was to fix the sphere issue, along with the "seam" issue that happens when trying to wrap a sphere in a single pass.  This happens because the triangles at the edge of the texture want to wrap around, but they wrap backwards.  So if the left of the triangle is on the right most side of the texture wrapping the sphere/planet, the right most side of the triangle should wrap to the left side of the texture.  And it does.  Via going completely backwards through the whole texture makes a nasty looking seam.  Again, since it was cosmetic, it wasn't high priority.  However, that has now also been fixed.  The answer is to create "dummy" points that duplicate those wrap around positions with greater than 1. positions on the texture (0.0 meaning left side, and 1.0 the right side).  This cleans up the spheres.

Fixing Spheres and Planets
Fixing Spheres and Planets
Fixing Spheres and Planets
Fixing Spheres and Planets
Fixing Spheres and Planets
Fixing Spheres and Planets
Fixing Spheres and Planets

The next problem that really needed to be addressed in the Terrain Engine was the "MegaTriangles" were very obvious and exposed. 

Fixing Spheres and Planets

Meaning, the edges while linking up, the heights are the boarder didn't match up and created cliffs all over the place with the obvious pattern that it was the larger MegaTriangle borders.  (See the left side of the screenshot).  This was a cosmetic AND functional issue, so needed to be addressed.  The main issue this occurred was because I hated how a single rectangular texture wrapped around a sphere, that the poles got so distorted.

Fixing Spheres and Planets

While a properly projected texture, such as what I'm using to wrap Mars compensates for this, that doesn't help things like height maps.  So I use an isohedral layout of the sphere which means it's made up of equilateral triangles exclusively.  This solves the stretching problem, but it doesn't solve the fact that textures and height maps come in rectangular form.  There is a solve for this, of course.  There is a concept called sphering the cube (or cubing the sphere).  Which means taking a unit cube and mapping it to a unit sphere (unit meaning a shape with a radius of 1).  For my purposes, I needed to go the opposite direction and go from sphere coordinates to cube coordinates, where most of what I have seen commonly done is going from a cube to a sphere.  Because I already have the sphere well mapped out, I needed a way to figure out positioning on the cube that represented the current spherical coordinate.  If you simply extend a line from the center of the sphere to the edge of the sphere out to a cube, while it does map, it creates a nasty distortion.  However, there is  way to distribute that distortion so that the squares on the edge of the sphere cube and the middle are the same volume.  While there is a slight distortion, which can't be helped, it's far better than the alternative.  And here are my results:

Fixing Spheres and Planets



Fixing Spheres and Planets
Fixing Spheres and Planets
Fixing Spheres and Planets

I used the same grid texture I used for the white screenshot above for my tests.  I color coded the sides of the cube so I could tell what was what.  I had a small issue happen from equations failing because of the inaccuracies of floats versus doubles, but I won't get into that.  As you can see, the volume size of the squares towards the middle of a "side" of the sphere are about equal to those along the edges.  The "seams" you are seeing at those edges are the same ones and for the same reasons there were seams in the single texture on the sphere example I mentioned earlier.  While I could fix it, there isn't a point.  The way the terrain engine works, it wouldn’t' matter, although I'm sure some tweaking will be needed.  What this has let me do is arrange the height map and associated textures in a clean way with no apparent seams.   Or so I thought.

Fixing Spheres and Planets


 

So now you can see distinct squares.  I couldn't understand what was happening at first.  So then I was back where I started with "cliffs" at the edges, just in square form rather than triangle form.  

Fixing Spheres and Planets

Then I found out the "improved" perlin noise I was using failed at it's purpose, which was procedurally creating a tileable texture/height map.  Tileable means, the top/bottom and left/right match seamlessly so in a tiled layout while you can see a repeating pattern, you can't see where the texture/tile itself starts and stops.  Before you could distinctly see the borders, because they didn't match up.  So to test my theory, I switched out the texture and repeated a stock texture I used that I KNOW is tilable.  You see the result, since I used it normal mapping.  While looking too vivid, the border lines were removed, so it proved the issue was the "improved" perlin noise tiling.  So I went back to my older perlin noise code which I proved was tilable.

After some adjustments, I was able to achieve the below.  Now the Terrain doesn't have obvious artifacts at the MegaTriangle borders (which the MegaTriangles are still there, they just aren't visible).

Fixing Spheres and Planets

There are still some issues, like the MegaTriangles aren't spun right to mesh up seamlessly when their resolution changes.  Basically, you never know when something doesn't actually work until everything else works as it's supposed to and exposes it never worked.  I know the "sewing" does work, this is just an issue of the MegaTriangles being spun incorrectly.  Basically, the code that compensated for how things were laid out originally now has to be disabled since now it's causing issues. Such is life.  But the main terrain is FAR better than it was, as you can see.  It also supports custom height map tiles, that I hope to see from the artists to break up the repeating tiles that is currently being used.  Mind you, a "tile" is 5 miles across, so it's big, but still, it is better to have terrain with more features on it.