Category Archives: Unity

Garages and Fog Nerdery

Dang, I guess it’s been a few weeks and mostly I’ve been working on more of the inventory system.  I managed to get the Garage working fully and now they appear on the map as places you can load out your gear, repair and refuel.  

Working on infrastructure for this long gets a bit taxing, so I wanted to switch over to something more visual for a palette cleanser…  so I chose to noodle around with Fog of War (not the most fun thing, but better than weeks of UI noodling).

Nerd Alert inbound!

Image result for hazard tape

My Fog of War (that is, how I represent areas of the map you haven’t explored and/or can’t see) is currently implemented tile-by-tile.  I implemented it by creating a custom shader that fades out the individual tile models based on a fade value I feed each one.  This has a few drawbacks:

  • The edges are hard and look a bit amateur as a result.
  • The fade currently goes to black, which is fine for dungeons but not appropriate for all my above-ground venues.
    • (Large areas of black also look a bit “cheap” on 3D games, although that’s my own personal bias.  2D Roguelikes somehow look just fine with the very same thing, however!)
  • I can only fade per-mesh, so in order to support height-mapped terrain meshes, I’d have to write some wacky shader to handle it.
  • I have to put a custom material on every model, and write a shader for any weirdo material tricks that a specific mesh wants to use.

I did some experiments with non-black fade colors, which didn’t add a ton of complexity to the shader but still emphasized hard edges.  Also, I had to turn off screen space ambient occlusion (SSAO) to make it fade to the pure color, which is something I use for my terrain features to “pop” a bit more.  Not a huge loss, but it only reminds me about how my technique is impacting my rendering and asset management.

In the end, I’d like a fairly “soft” (and in my opinion, more pro-tier) representation of Fog of War.  For most 2D Roguelikes, the common technique is to place a huge planar texture between the camera and the world and draw areas of black and transparency over it to obscure undiscovered areas.  I had steered clear of this technique because my terrain is 3D and my camera is a perspective projection with a viewing angle of about 35 degrees…  this causes the Fog plane to parallax (obscure different areas based on the viewing angle)…

However, this can be solved with math…  I can scale and offset the fog of war plane to match a fairly flat map, so I’m going to try it out. Granted, using a plane will fail if the player ever drives up a hill (which is something I support, but only use in a few locations), but I think this technique should do well for all my current combat areas (not the adventure ones) for the short term.  Will see if I can get it rigged up tomorrow morning before work. Wish me luck!

 

Auto Fire Status Update – May 2017

In case you’re new to Auto Fire, here’s an overview.  If you are familiar with it, here’s a hint of what’s been happening over the past few months…

Overview

Auto Fire is a turn-based roguelike auto combat RPG set in the roads and cities of the shattered American west.  Enhance your vehicle, take on missions and build your name in a world where the only way to thrive is to drive.

Auto Fire is a deep, randomly-generated experience that combines the free-roaming adventure of games like Autoduel and FTL with the turn-based precision driving of games like Roadwar 2000 and the original Car Wars tabletop game.

An important part of the game is the player’s relationship with his or her car, and the ability to mount bigger and better weapons and equipment.

My Background

I’ve been a game developer for 24 years, both as a programmer and a designer.  In my past I have worked on titles like Heretic II, Jedi Outcast, X-Men Legends, and Dead Space 2 and 3.  These days I do design exclusively for my day job, and I miss programming.  I was also a big fan of the tabletop vehicle combat games of the 1980’s and want to create something worthy of that world.

Tools

I use Unity 5.6, Visual Studio, Adobe Photoshop.  Blender and Perforce when I get desperate.

Update

Over the past couple of months I’ve been reworking the weapons systems to allow for special attacks over time such as machinegun bursts and oil slicks.  An equipment system is in place that allows for secondary abilities to be mounted on the car such as radar sweeps and targeting computers.  These systems are coming on line as well as a new inventory system.

A city map can now generate complex environments with special boss arenas and repair stations.  The starting enclave has now been enhanced with new assets.  New music, vehicles and effects have worked their way into the build as well.

Here’s an update of what it looks like.

7DRL 2017: Day 1

7DRL Challenge Day 1: Unfortunately GDC lay me flat on my back for five days straight through the weekend, so I’m getting a really late start on my challenge. I guess I’m be aiming for submission late Sunday to get as many hours logged as possible.

Today I was able to re-acquaint myself with the ugly-ass 7DRL 2016 codebase and temp sprites. <Shudder> All I had time for was to start working on road generation and take a step in the direction of transforming my combat movement into strafes, accelerations and so on. Still got lots of work to do. Still, fun to see things moving forward.

Loops and destruction

In the past few days I’ve managed to add a whole bunch of loops to the city generation.  This was achieved by adding optional exits to the blocks that I lay down…  These are invisible overlays that, if a road tries to enter a block that doesn’t have an entrance on that side, can be stamped down over the existing block to let it link back.  It helps a lot with the four-lane highways in particular, which would act like a barrier that didn’t integrate into the rest of the street maze if I didn’t allow it to reconnect.

citylayoutweek3

More loops are important because driving and having to turn around is fairly bad…  the fewer dead ends the better.

Once the map is complete, I put down more obstacles and overgrowth.  Then finally I take some Perlin noise to the map and add destroyed swaths, both rubble and driveable stuff, just to add interest.

I think I can move beyond generation for the time being.  Now it’s time to get fog of war back in so that the map feels more mysterious and ready to explore.  Then I’ll lay out a boss battle fortress…  woo!

Hiiiiiighway

I’ve made more progress in sealing up road connections, adding more variety and, most of all, creating 4-lane roads!  I’ve still got to work on seeding out the highway before the map is built, so we have a big thoroughfare in there.  Pretty soon I should be far enough to start getting Fog of War back in (which was ditched when I made the move from 2D to 3D back in May).

Also, Unity has had some nice sales lately and I stumbled onto this, which I jumped on.  At first glance the pack seems to be selling a bunch of muzzle flash VFX and so on, but it also includes this sweet modular turret system which includes a bunch of different weapons that can be separated from their turret bases.  How cool is that?

weapons

I was starting to make plans towards learning some basic 3D modeling so that I could make weapons like this…  typically they are attached to the side of a vehicle or something.

In my case I want the player to be able to see the weapons in their inventory, and then place them out on a grid.  So, while I will still need to find or create some of the more unusual models (what does a smoke screen sprayer look like?), I can get pretty far with these guys.

So Many Datafiles

Yes, Technical Debt is still rearing its ugly head.  One of the things that any procedurally-generated Roguelike has is a ton of different files that hold profiles that define how to generate cities, landscapes and enemy encounters.  And tables, so many randomized tables!

sceneinspectorDuring the 7DRL I found an expedient solution that worked for the challenge and a fair amount of time afterwards.  I baked data right into each Unity scene that I saved out, imagining that I could just make a scene for each type of scenario or terrain profile I wanted.  I could bake in components that had all the predefined information I needed and just load them as needed.  I could even drag-n-drop the appropriate prefabs for everything I wanted to spawn.  How simple.  Sure, it nagged at me that it wasn’t super extensible, but scenes were cheap to make and I was interested in how far it could get me.

Wellll, it turned out it was pretty far, but eventually it started to haunt me.  The more scenes there were, the harder they all were to maintain, even if all the common information was kept in Unity prefabs.  Oh god, the prefabs…  they are great sometimes, but they also can puke all over themselves if I moved files around or a metafile got invalidated somehow.  Also, any time I wanted to choose something randomly, it felt like I was writing new code to deal with it each time.

I also used the serializer for a number of structures, but there was always a desire to have more flexibility when reading data.

Anyway, I knew I needed to up my datafile game.  My friend Jim’s amazing RL Dungeonmans has something like 500+ datafiles holding anything from name generation to encounters to tile definitions, with weighted randomization tables and tables that reference other tables.  How slick!  He spent many years refining his data methods and he encouraged us to reuse his approach in our own games.

So last weekend I finally bit the bullet and built a datafile system around some of the same concepts and in the end my format is virtually the same as Dmans.  This way I can build a sector with a pretty flexible format:

defThing sector_basic
{
 class adSectorData
 scene Overworld

 biome Desert
 nametable sector_name_chart
 treasuretable sector_treasure_table

 music mus_desperado

 basic_city_table 1d2
 sector_outpost_chart 2d4
 sector_town_chart 2+1d3
}

And these tables have some handy reference capabilities (recursing through each table referenced) and weighting for randomized results:

defTable "sector_name_chart"
{
 #t1 "sector_place_types"
 #t2 "place_nouns"
 #t3 "sector_adjectives"

 "The [t1] of [t2]" 10
 "The [t3] [t1]" 10
 "The [t1] of [t3] [t2]" 10
}

defTable "sector_adjectives"
{
 "New" 10
 "Old" 10
 "Dry" 10
 "Frosty" 10
 "Winding" 10
 "Hewn" 10
 "Locked" 10
 "Winding" 10
 "Ancient" 10
     ...

…and bingo, my world generation becomes 10x more flexible and powerful.  I’m dyin’ to get back to the drive-shoot stuff, but this was so worth it.

namegen

Late Night Asset Store Addiction

The Unity Asset Store is a great temptation at all times, cleverly one click from my development environment.  When you’re stuck in the dregs of some less-than-glamorous code snarl, it becomes the devil.  An Asset Store 24-hour sale are basically late-night Ronco TV ads for game developers.  Just 10 bucks for the next 2 days!  30% off!  But hey, this might be just the thing your game needs to be awesome…

Recently I bought a Volumetric Clouds package, hoping that I could get some cool, turbulent cloud cover with shadows over my landscape as the player wanders around.   Looks pretty good, but my poor frame rate just couldn’t handle it, especially at high resolutions.

Clouds

The solution involves a sweet technique of rendering many layers of a noise texture so it piles into a volumetric shape.  It seems to run pretty well for ground scenes looking up at the sky, but for my particular situation it didn’t quite fit.  Maybe I can’t use it for Auto Fire, but it’s a clever enough solution that looks great in a lot of cases, so I don’t feel too bad supporting the creator.

I don’t want to obscure the map features anyway, so just shadows would probably do the trick.  I might be able to do an extremely cheap version of the shadows with some some screen space projection instead…  but there are a hundred other things to do first.

I stumbled on another Unity sale recently that dangled a plugin called Beautify in front of me.  “Add a pro look!  Punch up your colors!  See the detail!”  I couldn’t help but bite, because I’m always wondering what I can do to eliminate the muddiness that I sometimes get with Unity, especially when I shrink assets that are intended to be experienced at realistic sizes.

A good chunk of what Beautify does is apply a sharpen post-process, along with some LUT’s to enhance some coloring.  I must admit there’s an appeal to seeing those shrunken assets appear sharper against the terrain or ground surfaces.  (You’ll probably have to click to see the difference).

Before
Before
After
After

It punches everything up and everything gets a nice feel in comparison.  However, it uses a sharpen filter, so I have to balance its use versus all the work built-in antialiasing does.  So, while it helps eliminate some of the muddy appearance (something I equate with unpolished products), it adds a lot of shimmer and harsh pixels (something I equate with unpolished engines).  In the end I probably just need some lighting help from a real artist. 🙂

Anyway, I can turn down the sharpen or nix it if I want, which is good because I like the results Beautify gives me with color.  It’s also got sweet bonus night vision and thermal views.

Nonetheless, I’m still looking for the right combination of lighting and filters to attain the pro look I’m after.  The quest continues…  and my wallet fears the night.

Patches and the Depth of Cities

This past week I’ve been polishing a new feature for procedural generation, patches.  This allows me to hand-create a collection of assets (both single-tile and multi-tile) that gets placed down in a singular area by the terrain/city generator.  It can be a solid square or only fill some of the squares within.  I can import any patch by dragging in a group of objects from a sample scene.  The tile system already converts the patches into the tileset currently in use by that map, and mixes in variants as they are available to the tileset.

Autofire_Patch_demoThe patch system has a lot of additional features yet to do.  For example, allowing the definition of patches in a nine-slice style where I can scale them to an arbitrary size with consistent edges.  This would allow me to create arbitrary-sized plazas, but more importantly, I can create a road patch that has signs, lights and various elements on it, that scales according to the length (and width if desired) of the road.

I also want to put in randomized prop points:  object stubs that will randomly place a specific prop in that spot, anything from a trashcan to a stain to an ambient effect.  It also allows me to place variants of an existing entity, such as a destroyed version.  This will be important so that my generated city doesn’t look all pristine the way it does above.

AutoFire_EditorsI didn’t expect to get dragged into city decor so early in AutoFire’s development.  It’s certainly a topic of interest to me, but the push in that direction really came from trying to find props for the game.  My 7DRL city was fine, it was basically a dungeon.  A dungeon can be a twisty maze of passages and hallways don’t necessarily need a specific direction of travel defined.  However, it felt like 90% of modern-day props required placement with some thought…  You can’t just sprinkle in mailboxes, street lights and stop signs via Random.Range(0, size)…  There needs to be established clusters and strips of materials.  I can construct hand-built areas anyway, but to extend everything into procedural town I’m pushing the limit of my limited home-grown tools.

Rolling from all this, I’ve also discovered as my game’s scale gets better established that I’m reaching a point where my single-square building assets are looking weirder and weirder…  I want the cars to be big and bold, and characters in the world to be larger than life also, but right now they are about two stories tall.  I was okay with something more abstract and representational when I was in 2D, but working in 3D makes that scale a bit more important.  Aaaaaand the only way to get my building “walls” closer to the “correct” size is to come up with a system for merging building squares into larger structures.  That will take a whole new post-process that…  I’m going to wait on.

DoomCarI’m quite aware that I’m running the risk of entering a bottomless pit of effort…  Making a city look like a city is hard, and many games make that their only thing, whereas I have
so much more to do.  So, I’m going to finish up this patch functionality and pull back to environments that are a bit easier to generate, such as frontiers, shanty towns, junkyards, and so on.  This way I can push back into mission generation and create some assassination missions and encounters.  This will finally lead me back to the promised land:  the refinement of driving mechanics, combat and its associated UI.

Glad all this is so fun. 🙂