Category Archives: Game Development

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.

Auto Fire Rides Again

I should own up to not finishing my 7-Day Roguelike challenge this year…  it was tough to admit defeat after two fairly successful years in a row.  I had started up the Jam with plans to take last year’s 7DRL code and work in a campaign and convoy mechanics, as a way to prove out some things that I’d been considering for Auto Fire.  However, I found it nothing but discouraging to work on such old decrepit code, trying to make something for a game that was so much farther along.

In the end it just made me want to push towards realizing those ideas in the current codebase of Auto Fire instead.  Sooooo…  I’d been working on tying up loose ends and prepping the driving feel and visuals of Auto Fire.  Take a quick look:

Next up are my plans for improving the inventory and rounding out the campaign into a compelling loop.  It should provide some much-needed depth, which will make me more happy to share my work more widely once it’s in.  Wish me luck!

Brass Tactics unveiled!

I just spent the week down in San Francisco showing my new game at Hidden Path Entertainment called Brass Tactics.  It’s a real-time strategy game built from the ground up for VR.  The reception has been quite good from the press and developers, and I think we’ve created something special.  Looking forward to finishing it off this fall!

Hidden Path Entertainment: Brass Tactics Info

Tom’s Hardware: ‘Brass Tactics’ Brings Tabletop RTS Gaming To VR Battlefield

Endgadget: ‘Brass Tactics’ is a VR RTS that puts you in a clockwork battlefield

Ars Technica: Finally, VR has a legitimate RTS contender in Brass Tactics

 

Skate Knight Update

(Formerly Cardinal Cell)

Quick update for now:  Over the past month I’ve been getting a lot of base functionality in:

  • Dwarves knock enemies around in addition to stunning them.
  • Items and monsters are flung from the sides of the screen at Stage start.
  • Bonus gold is awarded for kill chains.
  • The gold collected is tallied at the end of a level and each survivor grants a gold bonus.
  • The player earns stars based on the amount of gold collected.
  • The moon arcs over the sky from the start to the end of the night, because that is the length of our hero’s prison sentence.
  • I can lay out a custom level for each individual venue, with 12 “hour” stages each now.  The player can select from a set in the main menu and try for a high score in each.

Forgive the temp sprites…  We’re still nailing the look.

Some work in progress

The Power of Art

I had a lot of fun last weekend with my game Cardinal Cell.  It was pretty fun in the end but it was ugly enough to make babies cry because I cobbled together the art on my own.  I could have maybe increased the quality another quarter-point on my own before finishing off the 48 hours…  I could have chosen a style.  I could have smoothed out the busy textures.  However, I was focused on closing the book with features-features-features.

I’m pretty confident that it was a mistake on my part…  while I go through other people’s games I constantly have to tell myself to not let an ugly game influence my assessment of its fun… or let a pretty game get away with dull gameplay.  Maybe it’s not fair, but that’s the way the world works.  Those of us with weaker art skills have a challenge to overcome.

Because the game looked so bad I did a quick reskin this weekend to use some pixel art and audio that I had handy.  I think the gameplay stands well on its own, but the revamp makes a difference in my opinion.  A friend offered up some real art and we’re going to rebrand it as…  wait for it… Skate Knight.

If you’re interested in seeing what a few hours of stock graphics and sounds can do for a game, check out the game on itch.io below.

 

Break for Ludum Dare 37

In a frenzied less-than-48 hours I cobbled together an entry into this weekend’s Ludum Dare.  I’d been wanting to play with the idea of fantasy battles using the mechanics of 2048.  The result isn’t pretty, but I do Ludum Dares primarily so I can doodle on an idea without giving a damn about how ugly it comes out. 🙂

CARDINAL CELL

After a night of heavy drinking in a foreign land, you are captured by local law enforcement and forced to stand trial for heinous crimes you have no memory of.   You are sentenced to 24 hours in the CARDINAL CELL. If you survive, you will be set free.   The help of your former drinking buddies is the only assistance you can hope for… because the Constable is rounding them up and throwing them in after you.

Click on the image to give it a shot and enjoy!  Maybe even throw me a vote… 😉

Back to CityGen

Another big gap between the last update and this one.  Part of it was a good thing (two-week vacation to Japan) and part of it was a bad thing (two weeks of airport-spawned sickness after going to Japan). Then for the last month I continued to purge that damn technical debt.

datafilesIt turns out there were a lot of things that the game generated (including things I wrote this summer when creating the overworld) that was mired in sub-awesome way of storing things.  I can’t say things are perfect now, but my Perforce  tree is starting to fill up with all the datafiles I can now create, search and copy to my heart’s content.

The datafile system (again, inspired by the one used in Dungeonmans) allows me to use tables to reference other tables, as well as arbitraily roll dice for whatever I want.   I still have entities to squeeze into the system but I think everything else is in a pretty good state.  Now I just have to train Notepad++ to parse them just a hair better and I’ll be in a great place for editing.

One thing I won’t be converting into text files is the Patch System I wrote for my initial attempt to create cities.  I wrote that system to integrate well into the entity editor, and I can drop in a bunch of tiles into an object and then drag the object right into an info panel to bake it out.  I’m not great at tools but I’m pretty happy with that one.  I’ve only just started to fill out variety with it but I think it can produce some really crafted setpieces in the midst of the pile of procgen that a Roguelike generally has.

patches

Coming back to working on the generation of a quality city, I decided to double down on the value of Patches and try a generation system that capitalizes on it.  We colloquially call it the “Crown Royal bag” method, once again inspired by Dungeonmans (Jim mentioned in his talk at last year’s international Roguelike conference).  It was actually first written about by Mike Anderson on RogueBasin.  The idea is to keep a list of all your legal walls that can hold doors in a list and draw randomly.  Pick one of those walls and consider busting a door into the side.  Then pull a precrafted “room” from your virtual Crown Royal bag at random and see if it fits onto that particular doorway.  If it doesn’t fit, throw it out and start over.  For hundreds of draws you might only place 40-50.

tilepatchesThere are number of issues using this for a city.  First of all, as you can see here, my tiles are created with entrances and exits built in…   I had to create an entrance and exit tagging system to figure out what tiles were valid connections to each exit.  That wasn’t too hard luckily, although I have to create connections now for single-lane roads and just plain asphalt and dirt, which are more interesting alleys and short cuts than the core big, two-lane roads.

Second, the technique basically creates a tree rather than a nice, playable dungeon with loops.  I’ve got a ton of ugly dead ends and roads that lead up to other roads but don’t connect.  It’s important for the proper feel that intersections look right and create nice setpieces with crosswalks and driveways and stop signs and such.  To accommodate this I need a more sophisticated system, in particular a way to overlay roads onto other roads and have them convert to intersections.  That actually means that I’d be heading into creating a road link system instead of relying on handcrafted patches, but I think I can integrate some smart tagging on my tiles to handle this.

cityloops

The battle continues…  Trust it’ll look better soon.

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