Category Archives: Game Design

Tricking Your Ride

The Seattle summer has finally gotten into full swing and it’s harder to stay inside, but in spite of this I’ve pulled together some time to work on Auto Fire’s core player systems…  and this involved a lot of time with Photoshop and Word as well as with Unity and Visual Studio.

As a rule, I design in a a very top-down way…  Visuals, mockups, and models are very important for me to get my head around the design as well as to communicate it to others for feedback.   My objective with Auto Fire was to keep the spirit of the deep car customization from games like Car Wars, but to streamline it for a smoother play experience.

I was a  huge fan of Car Wars back in the eight-e’s, but building a car for the game involved a wholllllle lot of pencil lead and eraser nubs…. like, blackened rubber crumbs all over the damn place. Players had to choose their body style, chassis, engine, tires, armor, weapons and equipment, all while balancing out limited space, weight and engine power to push everything forward.  It was great, but it was a solid half-hour (more or less depending on your experience) to make a good build…  If it helps you get a feel, think of the time investment of rolling up a new pen-and-paper character or, say, building a new Magic deck.

Incorporating mechanics for hardcore things like weight and spaces wasn’t impossible to pull off, but things like switching out weapons or changing gear can feel like something of a chore…  I felt I could do better.  For years and years now I toyed with the idea of applying a Diablo-style inventory grid, perhaps combined with the damage grid system from a number of FASA titles (I personally was a fan of the Renegade Legion series).  The idea had some promise, in that players had to find space on their vehicle for various weapons, and make tradeoffs to clear space for special equipment, huge engines, or cargo.  In addition, damage could be allocated square by square, penetrating into the car and damaging components as it reached them.

Being a top-down designer, my preferred way to hash out problems like this is to mock up the interface, move parts around, and visualize how it will feel for the player.  As I played with the parts I started to realize that applying “damage templates”, is really a kind of magic made for pencils and templates and the tension of rolling locations and hoping the template doesn’t include your driver or engine.  In a digital product where you don’t color in the squares yourself, it threatens to descend a bit into indecipherable noise.  In addition, when rearranging a car into different configurations, the spatial rules of vehicles started to clash with the system…  often the only extra room for a driver or engine was in the back corner or something.  It just didn’t feel like a vehicle the way I wanted.  Finally, I really wanted to incentivize the player to socket in new equipment as it is encountered, acquire new cars and choose various ones to meet the specialties for specific missions.  Ideally buying a new car gets you more than just a new set of numerical stats and grid layout.  “Vehicle loadout Tetris” still fascinates me and I’d love to try a PnP version of it or implement it into a arena-based game, but I’m steering away from it for this particular project. (See what I did there, wakka wakka).

Sooooooo in the end I went back to something a little more akin to decking out gear in an RPG, but there are some nuances that I believe will feel fresh when applied to vehicle loadouts.  When decking out a vehicle, the starting point is always the Chassis.  This is the body that everything else is built upon…  The player can acquire them at car dealerships, receive them as mission bounty, or salvage them in the wilds as loot.   Each chassis has some base stats that any equipment will modify, such as handling, armor, and fuel capacity.  It also has some built-in equipment as well as slots that can be customized…  Each vehicle body ultimately sports a fairly unique configuration.

Some chassis can sport large engines, but have limited handling.  Some can hold huge amounts of armor, but can only mount a large tank weapon in the front.  Some might have a turret mount, but the armor cannot be upgraded.  Some have a slower engine that cannot be replaced, but can haul an amazing amount of cargo.

Chassis and equipment can be found with mods that add additional bonuses and abilities that make finding loot interesting.  Weapons can be placed on any side of most vehicles, but heavy weapons need special mounts to be used, and turret slots are fairly rare.  Ram Plates can have explosive charges or sharpened edges for added effects.  Engines define a vehicle’s top speed, but it can also have acceleration benefits or a larger fuel capacity.  Tires can improve handling, but they can also resist damage from spikes or add to stealth properties.  An Armor Frame can boost a car’s armor, make it fireproof or laser-reflective, or even add mounted blades to slash on-foot enemies when driving adjacent to them.

Cargo Capacity is one of the most important reasons for players to change up their rides, as each chassis has a different number of cargo slots.  Most found equipment can be picked up without concern for weight or space (again, I didn’t want being out in the waste recovering gear to be a hassle), but cargo slots are used to hold major items for courier jobs like scientific gear, or priceless art, or passengers.  Rather than always running at capacity, however, a smart Driver may leave an extra space available in their vehicle during a run. This way they are prepared in case they run into special salvage out in the wilds, or a civilian who needs transport to safety…  for a hefty price, of course.  And if you find a crate of priceless military tech as you pick your way through a wrecked convoy and have no room…?  Well, you can always kick that sorry bastard to the side of the road to make space.

So all of this has to come together into a playable whole, of course.  I’ve got a lot of the core systems and definitions together for dozens of pieces of gear, but the next step is to implement the garage interface where players can buy and sell equipment as well as reconfigure their loadouts.  And there’s much more to do to make sure that decking out your car is as interesting as it possibly can be.  It’ll be an interesting summer.

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.

7DRL 2017: Westbound and Down

This is my third 7DRL, and this year I’m hoping to kill two birds with one stone by exploring some alternate gameplay concepts I first explored in last year’s entry, Auto FireAuto Fire introduced car combat and exploration of a (poorly-rendered) cityscape and in the ensuing year has been extended to 3D, with richer generation, an overworld countryside, and a variety of superior UI and tools.  None of which I’m going to use this week, see below.

This year, with Westbound and Down, I want to explore some of the “Convoy” style aspirations that I have yet to put into Auto Fire…  Traveling from town to town and taking on cargo missions between outpost cities in a post-apocalyptic western U.S.  Instead of exploration combat, the player must drive “blocker” for a convoy of trucks that is continually harassed by bandits and other road hazards.  Upgrade your car and convoy vehicles, hire drivers, maintain your stock of ammo and fuel, and take on loads with higher risks for greater rewards.

The tough part of this year is that even though I’ve progressed quite a bit with Auto Fire’s codebase over the last year…  in the spirit of making this a fresh 7-day effort, I’m working from the code from 2016’s 7DRL and seeing what I can construct within those confines.  I hope to create an alternate movement model (forced directional movement, with most of the maneuvering involving lane-changes and acceleration/deceleration), a regional highway map, a cargo quest structure, some interfaces for cargo and hireling loadout, and hopefully some FTL-style dialogue encounters which could lead to bonus salvage or ambush.  That’s a fair amount of stuff, but I’m hoping I’ve got enough to build from…  and if I have to hack up my code a bit to try something, that’s okay, I can take any successes and work them into Auto Fire later, hopefully the “right way”. 🙂

CityGen – Making it fun

I managed to carve a good chunk of time working on city generation over the 4-day Thanksgiving, but I wish I were done.  My core accomplishments was in creating single-wide alleys, more crafted patches for both 2-lane and alley roads, and most importantly:  Allowing patches to be rotated when placed.

This allows me to create more variety, not just because things look different when rotated, but also because I can spend my time on crafting unique areas without having the create four direction rotations of them.  It’s getting there…citylayoutweekend2a

The biggest problems beyond variety is playability.  The most interesting maps should have some interesting tactical spaces, and more importantly enough loops that give the players a better sense of exploration as well as not punishing them as much for getting some speed going (which dead ends can completely wreck).  Typical Roguelikes (Dungeonmans included) introduce at least a few loops so that exploring the map doesn’t force endless backtracking.

A whole bunch more work is needed, including:

  • Make additional large patches with interesting tactical features such as open areas, wide runways and so on.  This will help keep the game from just being a bunch of corridors.
  • gen
    A strange street flow perhaps, but I just wanted to try some more interesting tactical layouts.

    Create an evenlarger 4-lane road type and seed the map with a couple of large roads.  This should present some neat places to build up some speed.

  • Checking patches before they are laid down to make sure that they are not blocking off an adjacent road (this leads to a series of roads that lead to nowhere).
  • When the map has been expanded as far as it can be (usually a set value, such as 1000 attempts at placing a patch), make sure that all the “unexplored” road tiles are capped with dead ends or are connected up to their neighbors.  (Again, this avoids road connections that terminate abruptly.
  • Add some “overlay” rules and tagging that allows for “optional” entrances into a block.  This way if I try to lay down a block next to another block, I can more easily “bust a hole” between the blocks as needed.  This will be huge for generating loops.
  • Create a few rules to evaluate a “good” map, including if there is enough space to explore and that there are areas suitably deep in the city where boss areas can be placed…  and if those criteria are not met, throw the whole map out and start over.

I basically need to take this as far as needed until it’s fun, and then step away from it and worry about making it perfect later.  Something like this could take all of my time for many months if I let it.  Over time I’ll try to add new models, streetlights, textures, buildings and so on, but I need to work towards something I can play again.

Once the map generates well (hopefully in another week), I’ll need to properly populate it with encounters, and create a boss area fairly far from the entrance that players need to play towards.  Once I’ve got that I’ll be back to having a game loop and can push to sharing a build out.  That’s something I really want to get done before the holidays.

 

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.

Overworld Madness

I’ve had some pretty great results so far with generating my terrain and dynamically placing road decals as needed.  The Easy Decal 3D solution ended up being pretty great.  The folk at &u Assets were super-helpful, and with clever use of their baking and decal combine features my roads went from 20 fps to 200 fps.  So, basically solved, and it’s worked out pretty well for putting interesting terrain features when staring down at splat-mapped Unity terrain starts to get tiresome.

I feel pretty good about the look and feel of my overworld, as well as the scale (which was a concern since it’s extremely exaggerated, even though I wanted a gritty feel).  I still have a ways to go before I can finish up my core loop and release a build, but things have leveled up a fair amount.

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