One bit of feedback I got when showing the game to a friend recently was that it was fun to drive, but picking up loot was beyond terrible. That’s because you have to manage traction, speed and direction even when you’re just trying to hoover up whatever you found in a weapons cache you just blew up. It’s just a whole bunch of stunt driving to scoop of some stuff that might only be worth a few bucks.
“Got it covered,” I boasted… I’d already planned to add in a “radar pulse” that would do the triple duty of revealing hidden things on the field, “painting” targets for improved accuracy, and acquiring items in a small radius around the player’s car. Super-convenient when you are in between fights, but when you’re in the thick of it you do have to deal with its cooldown. There’s also the precious action that you have to use to activate it, rather than using it to shoot or turn.
Feeling smug about my clever solution, I recalled how long ago I decided on my solution. It was……….. over a…. year ago. For something like 15 months I’d been picking up loot in the worst way possible. Errr… awesome. Guess I should get that damn thing in.
It took an embarrassingly short amount of time given the sheer weight of procrastination behind it.
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
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:
name "Econo Stallion"
armor_base "100 100 100 100"
Engine "None default engine_rank_1"
Tires "None default tires_base"
Armor "None default armor_base"
WeaponRam "None default wpn_ram_base"
flavor "The doors rattle a bit if you slam them, but you'll feel like a thousand bucks behind the wheel of any Stallion."
name "Grand Stallion"
Engine "None default engine_rank_2"
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.
Over the July 4 holiday I managed to get a good, solid, 5-day weekend, which in turn gave me great blocks of time to work on Auto Fire. It felt great to get some really nagging things out of the way. There’s a bunch of stuff here that is new since last time I blogged about it:
Site System. I created a new structure for holding what I call “sites”, which is any point of interest on the map. This can include cities found in the overworld, highway entrances and exits, garages, and even regular landmarks and points of interest. The sites are what I use to guide road plotting, so roads can connect exits, cities, garages and even just weird old non-functional shacks out in the desert, which I constructed from groups of tiles. It gave me a system for sprinkling them into a map from a table, which adds more life to most maps.
Encounter System. The encounter system is something that I’ve wanted to do for a while, to allow the player to deal with random stuff that they meet along the way. Call it FTL-style, although I associate the concept with pen and paper games as well as wayyyy back to ancient games like Odyssey on the Apple II. This allows players to consider some simple risk-reward propositions, or to choose between acts worthy of fame or notoriety.
Stylized Visual Effects. I took some of the realistic visual effects for weaponry, explosions and smoke and returned them to the stylized versions I had used a year ago. I found that these stylized VFX had extra punch and grabbed the player’s attention among a lot of noise, but more importantly, fit the oddball scale of the world in Auto Fire. With buildings and cars and chests all coming in at unrealistic sizes when compared to each other, I found that realistic visuals just made that mismatch even more pronounced. Somehow having unrealistic smoke and fire just helped with the suspension of disbelief, and I think it can look just as compelling.
Walled Outpost Generator. One of the biggest things I got done over the holiday was to finally prepare enough ramshackle walls, dirt roads, windmills and metal-roofed buildings to create a special generator for badlands outposts. This is a heightmapped terrain map that sets aside a center section as the “core”, where buildings and certain visual points of interest will lie. Around the perimeter is a wall made of scrap, cars, wood, and anything else… I had to make a version of my patch generator that would stretch and rotate this wall in any direction with repeating motifs. Dirt roads are then stretched to the various sites around the map. I’m really happy with how it came out.
Smoother Driving Feel. One thing I did fix in recent months came from feedback I got from right after the 7DRL that spawned Auto Fire… For some players the movement felt stuttery and halting. Part of that is unavoidable with a turn-based game, but some of it was fixable. There is no longer a single-frame stop between various units executing their turn, and if the player cues up multiple moves, it executes smoothly if possible. The movement from square to square in slightly slower than it was as well, creating an subtle improvement that I feel when running the new build versus an old one.
Wall Deflection. This last one feels intangible as well, but I implemented it because the more I played, the more I felt cheated that the mechanic did not exist. If the player is heading diagonally towards a wall at high speed, he or she can get deflected off the wall and into a new movement path parallel to the wall. This is a fairly common occurrence in the city maps in particular, and even lets players use it to their advantage if they wanted to keep shooting rather than steer (this is an option in Auto Fire!)
Okay, so there’s a lot more work to do. I feel that I’ve hit some fine polish points, but I mainly need to assemble content together into something more playable, to have more of a reason and tension in the overworld. All that will hopefully come next.
I’ve been quiet since the holidays, but it certainly isn’t for lack of activity. For my day job, February marked the release of Brass Tactics, a real time strategy game reinvented for VR headsets. The creation of Brass was really a fascinating adventure, one of the most interesting and invigorating creative challenges I’ve had in a lot of years.
Oculus gave us pretty much carte blanche to recreate a real-time strategy game that took advantage of the Rift platform as well as the Touch controllers. This allowed us to kick off the process with a delightful freedom on how to make the controls of an RTS feel tactile and engaging. We started with crazy-woop-woop-nuts ideas, but honed the game down to something that felt familiar yet fresh.
I’ve written a couple of blogs about this process on the Hidden Path website: The first blog post talks about our discovery of how we wanted to represent the world and how the player might interact with it. We started from a very wide set of possibilities that explored how to show the most information to the player with the most comfort. What we ended up with was quite clean, and felt comfortable for most people. Here’s the first ugly prototype reel.
The second blog was about how the player interacts with their troops, both selecting them and issuing orders. This seems simple but we went through a long process to figure it out. What we ended up with feels familiar, like using a mouse, but definitely embraces the physical nature of Touch. Directing your troops becomes like being a symphony director calling out orders fluidly, a dance that makes war happen. It was an achievement that we’re very proud of. Even more ugly here!
I still have one more prototype video that I need to accompany with a blog post. Luckily the pressure’s been off lately so I’ve been able to get back to working on Auto Fire. I’ll try to update y’all with where that’s been going shortly.
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.
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…
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.
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.
I use Unity 5.6, Visual Studio, Adobe Photoshop. Blender and Perforce when I get desperate.
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.
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.
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 Fire. Auto 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”. 🙂