XIXBLOG

Wow, it’s 2018, time to update this thing!  I had a good year in 2017, one of my favorite projects was working with GameCo and Steve Aoki on Neon Dream.  It’s an infinite runner for skilled-based casino consoles.  It’s a brand new market and a pretty interesting space and unique design challenges.

I’ve improved both the visuals and the rendering speed of the renderer since the ‘first pass’ post.  Initially I was using projected-grid rendering and doing a lot of work in the pixel shader (noise calculations, sampling 3 heights to get the normal,etc).  It looked good, but a bit noisy/gritty since the pixel shader couldn’t take advantage of sub-pixel sampling that can be achieved with texture lookups.

I moved away from projected grid rendering to ‘patch’ rendering where I essentially draw a grid of polygons in front of the camera, and then fade the waves heights to a flat poly that extends to the horizon.  This gets rid of the artifacts that were appearing in the mid to far distance when the camera moved in the projected-grid system.

The next big change was to offload much of the pixel shader work to texture lookups.  This would have the visual benefit of sub-pixel sampling and mipmapping to reduce visual noise and a large reduction in pixel shader render time.  

To generate the texture data, I essentially render out a height map of the repeating perlin noise function + gertsner wave calculation that the vertex shader uses.  The pixel shader matches up the texture scale to the waves that are generated in the vertex shader, and scales it down/rotates it appropriately for each octave of waves that are generated.  I might do another post on this as I recently had to do another pass on this code to get a CPU-based height lookup to match up with the GPU noise function.

An actual height lookup texture is below, it’s not super high quality and I had to try many seed values for the very simple noise hash before it spit this out.  It works well enough that it’s not noticeably worse than higher quality noise that I’ve used. 

Lastly, I added specular highlights and a very simple sub-surface scattering effect that isn’t quite accurate, but is effective anyway - see the bottom-left for some sss overkill:

It’s been a looong time since I’ve last posted!  I have made some progress with DieselWars, but largely have been taking a break to pursue some shorter-term projects.  One of them that has turned out to be promising is an ocean renderer that I created to test out the Unity Asset Store market.  Above is the first pass prototype that I created to see if I could create something that looks good in realtime.

The realtime water is a continuation of the work that I did on the non-realtime game, Extrasolar (shown above).  (Extrasolar is a ground-breaking experience and it’s free so you should check it out here!).  I wrote about how I made the water for it here.  For the realtime prototype I kept with the projected grid technology that I used on Extrasolar, but changed the wave code so that it is more complex and turns noise into Gertsner waves rather than using almost pure noise like I did on Extrasolar.  

800 bloody lines of code.  That's what it took to properly add bridges to my city road algorithm.  That's nearly double the code to produce the rest of the map including the water and writing it to disk!  In my previous post about this, I hoped that I had found a simple way to connect all the parts of the city by 'snaking' a road around the map.  It worked in general, however when it got to the nitty-gritty, the coverage was patchy and I would have had to resort to flood-filling in the blocks to the neighborhoods.  That would have required more analysis and then I was right back where I started, only with worse coverage.

I decided to keep the original algorithm - an AABB tree where I simply removed roads and blocks that were near water.  This results in great coverage of the land mass, I just needed to analyze the roads and try and find places where a bridge would be appropriate.  

The basic algorithm for this is as follows:

1) Pick a starting point on a path node (one of the 4 corners)

2) Test a path to one of the path nodes in each neighborhood node in the AABB tree

3) IF a path cannot be found then loop through the adjacent neighborhoods and see if a path can be found by connecting the target neighborhood with an adjacent one.

4) IF a path can be found, then add a bridge if a good connection spot between neighborhoods will work.

5) If no bridges can be made, try a different starting point

It's a simple algorithm, but there are an impressive amount of places where things can go wrong!  I think it's pretty solid now, but I haven't tested many of the billions of possible seeds.  I'm considering setting it up so that every night the program churns out hundreds of city maps that I can look over in the morning.

It's been a struggle for the last few weeks to come up with an algorithm that I'm happy with for a procedural city road system.  In fact I still haven't got there yet, but I'm hoping that I'm close with the new one I'll show below.

The objective is to have good coverage, bridges/choke-points, and have the algorithm be simple and fast enough that it requires little to no second passes or post-creation fix ups.  And also be somewhat realistic and visually pleasing.  

My first attempt was to use an AABB tree and just overlay it over the map that had the water in place and then fill it out as much as possible for max coverage.  It works pretty well except for one thing: bridges.

I was relying too much on the edges of the AABB boxes to happen to cross the waterways in order to have a path over them.  If they didn't do that - then the player had no path to certain parts of the map, no good!  As you can see in the image below, there's no path to the eastern 1/3 of the map!

I started to work on doing a second pass to add bridges, and it became a mess of special cases and then I realized that I still could not guarantee a path to every part of the map without some type of path-finding analysis anyway.  So I started on a new algorithm that attempted to guarantee a pathway to every neighborhood that it populated.

The basic pathway for this map looks like this:

The algo basically grows out from a central point and goes out as far as it can in each direction while avoiding water at corners and making sure that it maintains a minimum space for small neighborhoods between each line.

Here is an image that shows the main pathway and the neighborhood/block splits that happen off of it.  Each time the main path turns, it creates a 'halfspace' sort of like a BSP, and I can fill those halfspaces out pretty easily once properly defined:

Things have slowed down a bit as I've been traveling a bunch in November and December.  For my 40th birthday I decided to cross off something on my bucket list and went to Australia to dive the Great Barrier Reef.  Big thanks to my wonderful girlfriend Serina who pushed hard to see as much as possible while we were there and boy did we ever!  We also spent some time in Hawaii on the way there and back so I was on vacation for almost 3 weeks, I think the longest vacation of my life.

About two weeks after that I flew out to Boston to spend the holidays with my parents and my sister's family.  I was out there till year's end, and I got to spend more time with them then I usually do, so the end of 2014 was really great in terms of personal stuff!

While on vacation I thought a lot about DieselWars and the higher-level aspects of the game.  I decided to pull the trigger on something I've been thinking about for a while - procedural levels.  I'll write another blog on why I decided to go that way, but part of it also was to make it a roguelike-like.  I think it will fit the theme and it goes along well with procedural levels.  

Here's a crude early look at the road system that I'm working on for cities and one of the types of waterways that will break them up:

When building the current "look" for DieselWars, I wanted to make sure that the tiles, the road in particular, did not look repetitive.  I was hoping to do it using shaders, but eventually decided against it as I did not want to rewrite the entire renderer.  The solution I chose is pretty simple, but unfortunately takes up a lot of tile space.

I basically created large repeatable texture that extends out on both x and y axes such that it repeats across 5 tiles instead of 1.  In the image above, where you see the same single tile repeated on the street, I just used the upper left tile, and in the second image, I used the 5x5 tile:

I use the (free and awesome) map editor Tiled to create my maps (at least until they are procedural).  One of the many nice features of tiled is that you can select multiple tiles from the tile picker and then stamp them all out at once, or flood fill, which is what I'm doing in the image below: