Category Archives: Roguelikes

Way too many changes at once

Oh man oh man it’s been far too long since I’ve published an update to Auto Fire. That’s a terrible thing I don’t want to happen very often, but I started to put in the quest updates and it made sense to get a number of additional features up to snuff in support of it.  

Worse yet, I sat on a hojillion changes in my source control before I checked everything in. I think it was like a month. Work was making me a little crazy, but that’s ridiculously bad form. On the upside, this update brings about a bunch of changes in a big sweep. 

My primary goal for this update was to add more exploration and stages to the boss fights and quests. For this I needed to support better quest state reporting, and make new emplacements to fight against to draw the boss out. Then I realized that the whole system fell apart when you left the area, so I had to improve how quests were maintained when you leave an area. Then I realized I wasn’t really saving data the way I should and basically had to improve the saves to be near-ready for cross-session saves (hopefully soon). Then I realized that spawning emplacements in random locations was really ugly and made them hard to find, so I added a content socketing system for bosses, emplacements, loot and hazards so that their placement could be more deliberate and hand-crafted.

Along the way I cleaned up the UI, added dynamic music, fixed some lingering physics problems (which caused invisible soldiers when the ragdolled out of the world, as well as making some tiles near rotated large objects to be un-enterable. I even stripped out some of the anti-aliasing that was making the game look muddy.

Quests

  • Entering a map occupied by a boss now requires the player to progress through the map and take out a number of strategic structures in order to coax the boss to face you.
    • Outpost maps are defended by armored watchtowers.
    • Ruined cities require you to take out fuel dumps.
  • The quest title is shown when entering and area, and updates are shown as the player achieves objectives.
  • The mini quest display is cleaned up and should update properly.
  • Quests are properly resumed when the player returns to a location.
  • Reviewing your quests that are in maps other than the current one is handled better.

Music

  • Added some post-apocalyptic music and a couple stingers.  Adjusted existing stingers.
  • Added dynamic music tracks for city and outpost tactical maps.
  • Dynamic music now escalates as the player takes out more emplacements and the enemy spawns get more intense, up until the boss is unleashed and the boss music is played.
  • Added boss-specific music, and adjust the intensity based on how close the boss is.

Visuals

  • Adjusted the anti-aliasing so the game isn’t blurry.  Temporal anti-aliasing can cause a smearing effect might work for realistic titles but ain’t great for games with precise information to dole out.

Combat/Systems

  • Added sustained fire bonuses that improve player accuracy after multiple attacks.
  • Painting an enemy with the radar will improve player accuracy against them.
  • Improved some targeting response elements by indicating which entities are people, cars, emplacements, etc.
  • Emplacements such as watchtowers have new aggro and play distinct spotted sounds.
  • Extended the aggro duration of enemies and made sure they don’t lose interest in the player while still in sight.

 Balance

  • Junkthrowers do 50% more damage. They were supposed to be scrub-tier weapons but they were just sooooo bad.
  • The Stallion now has a bolt rifle mounted front and two junkthrowers (one per side).  Its combat capability was depressingly terrible.
  • Mines have a lower cooldown again.
  • Significantly more cash is dropped from loot crates and enemies.  Killing a boss and getting $4 was definitely sub-awesome.
  • Zones have fewer garages.

Map Generation

  • Quest emplacements like watchtowers and fuel dumps are placed in sockets that are part of map generation.  Thus their placement is more crafted.
  • Loot crates and barrels also have specific hand-crafted sockets for various map generation tiles, for a less haphazard placement.  
    • Crates are off the beaten path, sometimes in nooks or dead-ends, but generally in a place somewhat thought out.
    • Barrels are placed in clusters around road hazards, fuel stations and large wrecks.
  • Loot and barrels now have a tunable target number placed per map.  Before it was a much wilder range of possibilities.

Progression

  • Population, quest progression and entity placement is now saved when exiting and returning to a map.
  • Entities, enemies, sites and pickups now save their state (when marked to do so) when leaving and returning.
    • This is not quite all the way to full savegames, but we’re very close.

UI

  • Improved the display of enemy misses somewhat.  Shots go wide and misses are pretty clear.
  • Cleaned up the “chrome” UI window borders.  They were originally photoshopped from actual chrome dashboards but that didn’t scale as well as I’d like.  Buttons have their own appearance now.
  • Improved some bugs with weapon targeting and the widgets over target vehicles.
  • Can now display entities as singular or plural for quest readouts.
  • Boss and targeting popup displays are now cleaner and, well, less terrible.

Bugs

  • Fixed the handling of rotating large objects… This means that there should no longer be any invisible barriers.
  • Improved some poorly-handled persistent effects such as oil jets and skids…  These are now handled with greater safety and more robustness.
  • Enemies no longer can get in a state of attacking inanimate objects or themselves.

Progress both Practical and Pretty

There has been a solid amount of progress on Auto Fire in the last month, though not everything has been visible.

Conditions

There’s a condition system now, where entities can be stunned, set on fire, made to skid, be blind, etc, and that will last a fixed number of turns before automatically removing themselves. Nothing super fancy, but it allowed me to do stuff like cause a vehicle to spin out when it hits an oil slick.

It also allowed me to give the player’s radar more functionality, because it now “paints” targets within a specific radius for a set amount of time. Ideally the player should be able to build up sustained fire on a single opponent, or race through a group (at high speed to avoid being shot) and hit everyone with a radar ping before swinging around and taking advantage of the higher hit rate (and eventually critical hits spurred by this).

There is a new icon system above vehicles to show their current conditions, which hopefully will teach players more about the advantages of speed and choosing targets.

Weapons!

I did a bit of work on weapon resolution to clean up some weirdness, as well as allow for effective area effects over various volumes. I can have weapons with blast radius at impact, cone effects, lines, and more. This gave me some vastly improved versions of scatterguns, flamers, and so on.

Scattergun

I also switched over my missiles to LeanTween (a great Unity package that’s freeeee, although the Editor that goes with is worth throwing a few bucks at) so that I could use more sophisticated arcs (splines, eases, etc) for the projectile travel. This gave me some great drunk missiles and so on.

A heavy rocket, follwed by a mini-missile salvo.

City Flow

A somewhat smaller bit of work but vastly important was looking into problems I was starting to see in my city layout.

A couple of years ago I put multiple months into a city generation method that took pre-crafted blocks and spliced them together, street-to-street, with props and so on. It worked pretty well… However, lately the cities seemed to have wayyyy too many skinny alleyways and dead-ends, even though I remember putting a fair amount of effort into reducing these.

Worse yet, I’d started to see some passability issues and unplayable maps, which I know I did checks for. Ugh. I love dusty Mad Max wastes, but the cities are just as important a part of the game and they weren’t fun.

I spent some time trying to re-learn what the hell the 2016 version of me had made. For a little bit I thought 2016 me was a bit of an idiot… but it turns out he was somewhat clever. It was 2018 me who introduced a number of bugs that caused loops to no longer form… that guy was a jerk. Specifically I had some code that overlaid roads over previously populated obstructions to create extra loops, and those no longer overlaid properly. In addition, my passability checks were not properly busting holes through the buildings and obstructions when needed.

I added a bit more two-lane roads and discouraged alleys from forming very often. In addition, I added some new block types to my definition that had fewer buildings, so some extra open spaces could be formed. I can pretty much make an infinite number of city block components, so I’ll keep adding ones that give some more driving freedom.

Battling some Ace Panthers in Old Custerton.

Onward

Anyway, I hope to have a new version out this weekend, it’s been too long. Wish me luck!

Tiles, tiles and Tools

I was just thinking about the challenges of generating a city map for Auto Fire and realized that I’ve accomplished a whole lot and haven’t really discussed it in a long while.

City layout workspace

Really early on in development I created some tools to generate block templates that get placed during map generation. This allows me to work with actual crafted sections of map (with variant buildings and other things that can be adjusted after the template is laid down). It’s more or less a requirement for cities since the classic “cave-style” procgen or even dungeon layout techniques don’t work as well as I’d like.

I create template patch objects that have a bunch of data attached to them such as exit points (for cities) as well as a variety of variable bits like spots for random decor and building styles (depending on the generation profile I’m using).

The block data that I save out actually even supports 9-slice scaling, so I can declare borders to be of a fixed size, but the center to be a repeating tile section that can be any size. It’s really useful in some situations like when I want a long crafted section of wall, or a large 4-lane boulevard on a city map.

For cities, however, I actually work mostly in blocks that are 4×4 in size, with street connectors that are 1, 2 or 4-lanes in size. If I want to make a larger block such as 4×8 or 12×16 I can do that as well. Getting the whole system to rotate blocks properly was probably the hardest part (you can see in the build right now that I have a few multi-tile objects that don’t yet collide properly… my work is never done).

I’ve got several workspace maps that I use to create these blocks of content (desert outpost, city, overworld, etc), and it’s a scalable system that could support a whole ton of layouts. When I say “damn I gotta work on content”, making 10x the tile variations and cities with specific flavors are ways that I could take advantage of the systems I’ve created.

Anyway, this approach isn’t particularly new but it works great for my needs… It deserves a more crunchy article dedicated to it, but it’ll have to go on the to-do list for sometime in the future. For now, hope the peek at the approach was a little interesting.

Roguelike Celebration 2018

This past weekend I attended the Roguelike Celebration, which I had heard was more of a fan gathering as compared to the developer-focused IRDC…  Still, it’s a pretty cheap flight down to SF so I decided to attend based on the recommendation of friends.  We thought it would be a good place to show off Auto Fire and gather good feedback from people that are dedicated to the genre.

What I wasn’t prepared for was that it was the single best developer’s conference I’ve ever attended, whether that was the focus or not.  Informative, entertaining, comfortable, stylish, professional… It was filled with some legendary creators and you’d be hard pressed to find even a shred of ego anywhere. Nothing but mutual respect and support, wall to wall.

These people were accessible and open.  They were humble and eager to learn themselves.  They shared openly.  Everyone was positive, whether we were discussing a text-based passion project with the classic @ for the player, or a high-falutin’ mass-market-friendly game using roguelike principles.  (Which is good, because I’m aiming slightly for the latter, although I want to stop short of making a “Roguelite”).

There was talk after talk after talk, and most of the presentations were pretty relevant to general game creation beyond Roguelikes.  In particular, Roguelike developers are intensely focused on two things…

The first is (of course) procedural generation.  This includes not just map generation, but encounter/trap creation, procedural storytelling, god/pantheon/myth/food/whatever generation, and so on.  What started as a passion for building noodly dungeon spaces has turned into a community dedicated to crafting entire universes through intensely clever processes.

The second is creating a flexible game architecture that allows for nearly infinite rule expansion.  A trademark of Roguelikes is that the creators just add on feature after feature for years and years, which lead to so many interconnected systems that have to elegantly support (for example) the player getting polymorphed into some new form that has extra arms, which allows you to wield more weapons, or being able to animate any world object including bookcases and walls, then charming them to becoming your faithful pets.

The approach for solving this issue mostly shakes out to a couple core philosophies, but the humility, willingness to learn, and eagerness to share was pretty amazing from these creators…  young or old, aspiring or legendary.

You can find the videos posted here.  Check ’em out.

At the end of the first day, they set us up in GitHub’s phenomenal common area with drinks and food and let whomever set up whatever they were working on and showing it off.  I had a potato-level laptop that barely ran Auto Fire at 2 FPS, but a fantastic soul named Jaxon (whose last name I unfortunately never discovered) was amazingly cool enough to let me use his super-baller laptop for the night.  Jim spectacularly scrounged up a giant TV and we were able to show it at around 100 fps x 55 inches.

It was a blast and tremendously inspiring to he feedback was awesome.  I got some really good comments on the game and came back with a big list of what sorts of things I wanted to take care of.

I am working on the skid model most of all. I just showed it at the Roguelike Celebration conference and got a lot of good feedback. I want players to be keenly aware of how close they are to skidding out, and to be able to better influence their skids once the tires break loose. I think a combination of feedback and control tweaks will help that.

I am eager to push into more content so that I get more of a game loop, but UI and feedback will be visited up front.  I want to get another update out before I head to Wisconsin next week.

Auto Fire Status Update – Oct 2018

Over the past several months I’ve been working through some significant issues to get Auto Fire up to snuff…  Good ol’ Jim talked me into going to the Roguelike Celebration 2018 in San Francisco this weekend so I could start showing my game to people more widely.  Pretty exciting!  Also pretty nerve-wracking given all the other stuff going on this summer.

Unfortunately there were a ton of things about my game that still drove me crazy…  For example I wasn’t able to save the state of maps between visits… which meant that the overworld in particular would regenerate every time you left a location.  I had to finally take the plunge and deal with that particular issue.

Man I hate two-years-ago me.  I did some real hack jobs to get that 7DRL challenge done, and I guess I wasn’t done paying off that technical debt. 😛

Luckily I got all the proper stuff to function, save off map states and basically am ready for honest-to-god savegames (although I don’t do save/load just yet.)  I’ve also made a whole bunch of quality-of-life improvements based on early player feedback:

This slideshow requires JavaScript.

  • The camera is now behind the vehicle at all times.  This way the WASD weapon keys are always consistent and understandable, and you don’t have to envision tank controls.  I had always suspected this would be a problem, but I think I was so used to camera-always-north that I didn’t have any trouble playing.  The added benefit is that the game has a fairly unique look as compared to other Roguelikes now.
  • Improved feedback for speed.  This is always a work in progress.  The player needs to know when they are speeding or skidding.  Putting the camera at a shallow angle and adding speed lines is my current strategy.  I also shake the camera a bit, but that may just be too much.  We will see where things go as feedback comes in.
  • Recolored environment.  A good friend did a paintover of a screenshot of my city environment a while back and it helped me gravitate towards dark ground surfaces, light obstructions, and bright colored gameplay elements.  This wasn’t the case with deserts (because, y’know, desert), but I’ve been darkening things quite a bit and trying to get the colors to pop.  Still a work in progress.
  • Revised balance and loot drops.  This isn’t really finely balanced, but I did make the early-play experience quite a bit easier so that people that wanted to try out the build could get a good idea of what the game was about quickly.  I also brought down the size of the average “loot pinata” that existed when I was testing loot out.  I really still need to do a huge push towards making content, maybe after the RogueCel.
  • Revised location names.  More on that next article!
  • New garages in the overworld and desert outposts.  I’m trying to make sure that the player has plenty of places to equip all the weapons and vehicle components I’m dropping.  That includes in hostile areas.  That will be a balancing act in the future.
  • UI improvements.  Again from feedback, I flash the weapon when you try to use it but can’t, and flash the grip meter if you are skidding and try to accelerate.
  • Music and sound improvements.  I got some new weapon sounds and hooked them up.  The quality is steadily improving there.  On the music front, I went back to Michael La Manna‘s excellent western apocalypse music… The quality is really high and fits the feel of the game really well.

My next step is to get the game out onto itch.io so that more people can play.  That will be sooner than you think!

Deluge of Definitions

Some days you take pleasure in the smallest of victories.

More and more of my time is spent messing with data rather than code.  A procedurally-generated game like Auto Fire has a lot of data to shuffle around, defining a nearly endless list of things.  These titles generally rely on complex rules to assemble what might be one-off creations in other games.  These rules are for things as varied as:

  • Map sectors, layout generation data, name generation data
  • Map Locations, loot tables, shops
  • Tiles, obstacles, decals
  • Enemies, squads, encounters
  • Cars, chassis types
  • Tires, engines, armor upgrades
  • Weapons, equipment, ram plates
  • Abilities, projectiles
  • etc etc

Luckily I was able to use a bit of code given me by a good friend as a framework for defining these.  Since I hooked the system in, the definitions have spread across 15 directories and 70 files, and that’s with not a lot of content defined as of yet.  By comparison, Dungeonmans has nearly 600 data files just for content definitions (nothing to do with actual art or audio content), plus god knows how many other little files squirreled away.

Creating the content itself is daunting, but nearly as tough is managing all this.  It can be hard to organize and keep straight.  A small victory this morning was when I improved comment support in my definitions, but more importantly I added inheritance.  This allows me to define a base definition and then overlay changes with another definition.   It cuts down on a lot of extra text and correction as I add new features to the game, and makes creating a whole line of related objects a quadrillion times easier.

For example, a vehicle’s chassis defines a lot of the weapons and equipment you can mount on it, as well as the model that is used for your vehicle on the battlefield.  You will ultimately be able to buy a new vehicle at a car dealer, and pick out the chassis that will serve your needs the best.

The Stallion is a line of muscle cars, each of which is beefier and sports a larger engine than the last.  With inheritance I can create a set of upgrades much more easily:

defThing chassis_stallion_L1
{
class adChassisData

prefab Vehicles/Stallion_body_L1

name "Econo Stallion"
manufacturer GrandMotors
logo UI/Logos/logo_tri
chassistype Coupe

level 1
value 2000

defense_base 0
health_base 100
handling_base 100
armor_base "100 100 100 100"
cargo_slots 2

Engine "None default engine_rank_1"
Tires "None default tires_base"
Armor "None default armor_base"
WeaponRam "None default wpn_ram_base"
WeaponFront Standard
WeaponRight Standard
WeaponBack Standard
WeaponLeft Standard
WeaponTurret None
Support1 Standard
Support2 Standard

flavor "The doors rattle a bit if you slam them, but you'll feel like a thousand bucks behind the wheel of any Stallion."
}

defThing chassis_stallion_L2
{
inherit chassis_stallion_L1

prefab Vehicles/Stallion_body_L2
name "Grand Stallion"
level 2
value 5000
cargo_slots 3

Engine "None default engine_rank_2"
Support3 Standard

flavor "Listen to the throaty purr of the Thundercat engine. Revel at the enhanced electronics package, and even stash more cargo! Welcome to the Grand Stallion."
}

It only took like 20 minutes to implement, I can’t believe I put it off so long. I guess my data was so in flux that I haven’t been creating a lot of content, just a lot of systems… Now I gotta go clean up my data.

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.