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. 

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.

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.

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.

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

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.

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:

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.

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.  

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).

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.

Updating the turrets with more detail. The tricky part to this is getting the detail baked into a low poly dome. After some testing, I have gotten the low poly's to 48 triangle faces. Currently in the process of fixing the uv map so the texture bake looks closer to the high poly model. 

The pictures descending down the line is the process.

We've reached a turning point in the development of R:WM. Until this week, to one degree or another, we've been creating a foundation. As of our most recent play test the foundation and superstructure of the game all exist, and are ready and waiting to be filled in with game play. Not that there isn't plenty of game play already: in addition to the space combat, which we've had for a while, we can build cities and buildings, use those cities to produce resources, both raw resources and ships and research in our tech web, and we can start to strategize based on our available assets and the behavior of enemy corporations. As you can see in our play test we got zerg rushed by the AI, and were not, as a collection of players, familiar enough yet with the game play to react as well as we might have like. However, now the game play is all available throughout the game, in both single and multiplayer mode, and we actually had people playing in the background as Arthur introduced all the new features that have been hooked up since the last test.

This all sounds lovely, but why does it matter? Well, this is the moment that everything we're doing changes from an answer to the question of "what?" to a question of "why?" It is no longer enough to present the available research options and have a mechanism for them to be researchable by the player, for example. We now need to build spcifically in response to game players; if we provide method A of doing research, but all the play testers prefer method B, we will need to go back and implement method B, no matter how cool it is; it may be cool, but if it doesn't fit the play experience, it will have to go. Not every change will be this drastic by far, of course. Most changes will be much smaller, more on the order of tweaks as we refine and refine and refine, looking for the optimal possible game balance. In other words, we've now reached the point where we need to stop being game developers and start being game players who are developing a game.

Hi all. This is your UI/UX Artist Paul. This week I have the Multiplayer Lobby screen to show off for overhaul. This time I borrowed design elements from an older screen I had made, the Asset Screen, for its wide bands of tightly clustered horizontal text frames. Keeping in with the Config Screen, the Multiplayer Lobby isn't exactly a "themed" screen as the in-game screens such as the Factory, Research, and Asset Screens are, and so a neutral, machine gray was selected for the text backdrops.

Below is the old version of the lobby, scheduled to be replaced once the new one has been finalized. There are still finishing touches to be added, but over all, the new face of the Multiplayer Lobby is coming along nicely.

Creating weapon launchers that can be customized to ships. As usual I'm starting out with silouhettes. The ends of the models will be rounded or capped off so even if the launcher passes through the ship's model, it'll look intentional and blend with the design.  Also added are some concepts for the next ship to be created. 

The Multiplayer has expanded a great deal.  While building buildings might be nothing new, what you are seeing in the screen shot is the AI building buildings during multiplayer!  

As the title says, it is almost in parity with the single player experience.  What does that mean?  The last multiplayer test livestream on youtube we were testing out missiles in multiplayer.  The reason that was such a milestone was having something AI controlled that could spawn in after the initial gamestate was sent.  While it might sound that should be easy, it isn't.  Mostly because the gamestate makes sure everything is all hooked up to each other, so making sure something created has everything needed took a large bit to get running. Getting buildings running in multiplayer required so internal fundemental shifts.  Mostly of ownership of different things that should have moved a long time ago.  So it was either finally moving them or do a lot of crazy work arounds, which isn't a good idea in the long run.  Current, building the city works, and whoever put down the first building owns that city in the same faction/corporation.  Power distribution works, as does research...mostly.  I'm still working out a few syncronization issues.  Shouldn't take long.  The last big thing would be to have factories working.  I would expect the mines and refineries to not be a problem.  I hope to have all this resolved by the next multiplayer test!  That will be a giant milestone since the main game in multiplayer will finally be realized!

Please check out our youtube channel and if you want to contact us, we do have a discord of course!

Hello, this is your UI/UX Artist Paul here. Another small update but one that's undeniably useful nonetheless. Today I have Faction Logos! 

With a whole solar system full of hostile parties constantly leveling against you in real time (and multiplayer support coming along nicely) it is important to be able to distinguish friend from foe. Hence, the corporate/faction logos. When you're trying to take over the local star, gang signs are a part of the package. A reticle over a ship in your cockpit viewport alone doesn't say much. And if you've seen the multiplayer tests or screenshots here, that view port gets messy quick. The logos will serves as an easy way to quickly establish who's who, especially when there's more than one "who." How they will be implemented is where things can get a little creative. Maybe they will overlay the reticle at a distance? Maybe they will appear in the targeting computer. Maybe they will appear as decals on the hulls of the ships themselves. It doesn't stop at ships however. These logos can appear on any object or piece of technology. An abandoned research lab? A derelict satellite lingering in orbit around a moon? An exotic engine of unknown design found crashed into the sandy dunes of Mars? A strongly worded ultimatum with an insignia for a "Sincerely, ____" at the end? Anything man-made can make both practical and creative use of these logos.