next »

[Vertigon]

Auto Fire is a reinterpretation of the great auto combat games of the 1980’s:  Car Wars, Autoduel, and Roadwar 2000.  It combines the tactical combat planning, dynamic world-generation, and player advancement of Roguelikes with outlaw landscapes, decked-out cars and the ongoing quest for fame. Refine your vehicle, take on missions and build a name for yourself in a world where the only way to thrive is to drive.

• Play in-progress at Itch.io!
• Wishlist us on Steam!
• Vertigames Blog
• Twitter: @autofiregame
• Discord: Auto Combat Zone

In Auto Fire the player drives a weaponized vehicle through the untamed badlands, battling bandits and mutants, and acting as a lifeline between the walled cities that humanity has retreated into. Over time, you can build your notoriety and your name among the bored populace, turning you from a curiosity to celebrity to legend.





My Background
I’ve been a game developer for 30+ 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.  I even worked on one of the earliest LAN-based vehicle combat games, a title called Necrodome.  These days I do design exclusively for my day job, but I do miss programming.  I was also a big fan of tabletop vehicle combat games back in the 1980’s and want to create something worthy of that world.

Tools
I use Unity 2022, Rider, Adobe Photoshop.  Also, Blender and Perforce when I get desperate.  I'm not a great artist, however, so I do rely on purchased assets when I can.

[Zireael]

Looks amazing!

[UmutD]

This is looking great! I have very nice memories of heretic 2 from my childhood, it is amazing that you're still working in games

[Vertigon]

Thanks!  The game industry hasn't killed me yet!

[ragnor]

This looks great! I'm posting this so i can follow the development .

I love the tile based, kinda board gamey look of the game.

[Vertigon]

Some more info about what I've been up to in the past many months:

Driving Mechanics
Back in the 80's I was a big fan of Car Wars... When Autoduel came out on the computer I had some mixed feelings about it... It delivered the world of Car Wars pretty well, and it was fun to work my way up through the ranks and deck out my car into a wrecking machine. But, in as an action game it fell a bit short of the gadgetry and careful maneuvering that Car Wars could be about.

I also knew that a game with the mechanics of Car Wars would probably be too cumbersome to use for a campaign-level experience. Speed action tracks, handling charts, individual tire damage, many actions per second, all these things are great for skirmishes but I felt it wasn't quite right for the amount of combat I was hoping for this title.

To me, turn-based roguelikes deliver such great opportunities for careful tactics in a fairly digestible format. I wanted to make sure that acceleration and handling could play a part, yet I wanted to maintain the "one input, one action" aspect of roguelikes.

So the model I established in the 7DRL was the ability for the player to accelerate so that they could take 2,3, or even 5 moves per second. However, there is a grip meter that drains when maneuvering at high speed, so the player must fight for control as they put their foot on the gas. This means the player can lose control and skid out if their grip runs out.  


Since the player can act more times per second at higher speeds, there is a possibility for weapons to be fired more than once per turn... I consider it the "adrenaline" from the player's increased speed. BUT! Each weapon has a cooldown that must be managed. So, the player has weapons mounted on multiple sides, they can take advantage of their increased speed to fire multiple times, but they can't maneuver on the same action, so the car plows forward as you turn your attention to weapons.

The overall experience feels pretty good, although I'm still working on getting as much feedback on speed as I can. I've found that stuff like Akira-style tail light trails can help as indicators if they scale based on speed.


Randomized Cities
It was important for me to be able to generate fairly compelling city landscapes, which meant that I had to explore a bit deeper into worldgen than I expected. I couldn't just use the most common RL generation techniques, which were good for rando-looking dungeons or caves... but there is a technique using crafted rooms that has been colloquially called the "Crown Royal bag" which you can see my buddy Jim talk about here:

.

Crafting components is important for cities, since I wanted streets and intersections with multiple lanes. I wanted street signs and lights on the correct side of the road. I wanted plazas with statues and gas stations, as well as neat tactical arrangements and boss arenas.

In the end I crafted a variety of map blocks varying in size from 4x4 to 12x12. This provided a fairly open-ended amount of intersections, bends and straight pieces, with road widths of 1, 2, and 4 lanes. They could of course be placed in any of 4 cardinal directions during generation.


The roads, props and buildings were selected from randomized tables. More still needs to be done to make sure that I can have a lot of variety within even a single crafted block.

Since the player is driving a car and has momentum, I didn't want too much of a tree structure with a lot of dead-ends... Loops are key to a really fun driving, and I wanted to make sure the generation algorithm closed a fair number of them. To service that, many blocks were marked up with spots where a crafted "hole" could be punched in a wall and a crafted intersection could be overlaid... If a branch of the tree is adjacent to another branch, it would sometimes bust through the wall and create a loop.

I stuck some Perlin noise destruction on top of that since this is a somewhat wrecked city... This breaks off avenues as well as creates new ones. The result has so far been pretty satisfactory.


There's a bit more information here and here on some of the work.

Onward
Plenty more going on including some work on boss arenas and abstracting weapon systems, but I'll talk about it next time.

[Vertigon]

At the wire, here's the June update for Auto Fire...

Tricking Your Ride




Over the past several weeks I've been putting a lot of work into designing and implementing Auto Fire's vehicle loadout system. Much of this work involved designing and working and adjusting the equipment system to reach the feel I wanted. Having spent years playing Car Wars I knew that the raw number-crunching of that game wouldn't be particularly great for a game where salvaging weapons and equipment would be fairly commonplace, and I've been mulling over alternatives literally for decades. I spent a lot of time navigating a grid loadout system that I'll spare you some of the gory details on, but you can check out a pretty extensive rundown on my blog. In the end I homed in on different system that admittedly has a lot of similarities to decking out an RPG character, but I was able to supplement it with some nuances that should feel very 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.

[Vertigon]

It’s been a few weeks (too long! but the weather's so nice in Seattle this month!) 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).

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.

As always, join me at http://www.vertigames.com/ to follow the progress.

[kinnas]

At first this looked like a pimped up Death Rally with arena levels and my immediate reaction to the visuals and menu design was "Oh shit this is like the childhood dream game, if I was 12 and saw these pictures in a PC magazine this is what I'd be talking about with classmates for the coming months.". Especially the menus have that look and feel that games don't have any more - the feeling of open possibilities.

but then I saw the roguelike tile-by-tile action with inertia and turning and I'm like...

dude..

this is interesting. This looks really cool.

[Vertigon]

  Heh heh thanks...  I love all the real-time car combat arena games out there but there's really no shortage of them.   A true real-time Interstate 76-style romp would be great also, but it doesn't deliver the tactical options I want to give the player.  Someday I'd love to try additional takes on the same core...  One thing at a time! 

The truth is that all the real-time games miss the nuance I love about games like Car Wars, but true strategy treatments put too much detail in the experience for long adventures.  I tried doing RPG-style adventuring with Car Wars back ye olde 1980's when I was younger and dumber but it just took so damn long to resolve a single fight... 

Thanks for coming by!  I feel confident that no matter what else is going on in the car combat space (or in Roguelikes for that matter) this remains something unique. (Fingers crossed!)

[Vertigon]

Auto Fire is continuing to look better these days.   I got rid of the object-based fogging and returned to the old-school concept of putting a 2D plane between the camera and the world.  You'd think it would look obvious but with a little fancy math I can scale and position the plane so that users are (more or less) none the wiser.  I was able to add some perlin noise and give the fog two colors (defined per map) that makes everything smoother and more pro.



I put more effort into the overworld as you can see above.  Those roads are generated now, as well, followed by a smoothing step that places the correct road tiles in the correct locations.  There are still a few specific intersections that I neglected to create tiles for (mostly diagonals to other diagonals) but the overworld is now guaranteed passable and locations have roads between them.   The roads make the overworld far more simple to navigate and find out-of-the-way locations.

I still have to finish off some of the world connections and then optimize the hell out of the world generation (currently coming in at 15 seconds) but it should be pretty quick and easy to trim all the low-hanging fruit (I don't cache the passibility of each tile yet when calculating paths for example).  Always more to do...

[Pixel Noise]

This looks super cool already - the menu design is slick and satisfying, and I really like what you describe for gameplay in the overview. And it's not too often you see a devlog by someone with AAA experience, so will be following this for sure! 

[Vertigon]

A few more updates coming in, slow but sure.  I'm adding props to fill out the desert, and working a bit more on my road networks.

It’s funny how I spent all this time to make a pretty versatile prop distribution system, created tiles and various features to randomize and space out various tiles but never have the time to really find good models to populate the map with...   so sometimes I play on a fairly empty map.

I spent the morning digging up some reasonably non-terrible assets to build tiles out of, and the results are luckily pretty good:





As a programmer I'm always stressing about function and feel, and there's always an infinite amount of that kind of stuff to do.  It's easy to feel a little guilty when I'm working on content, such as filling in a weapons table, adding new city or prop assets to the project, doing UI or making effects...  It's the fun stuff, and I always feel happy because things look better, but at the same time I feel guilty that I’m not working on function...  Content is hard!

[Vertigon]

Ohhhhh mannnnn, it's been a lonnnng time since I've updated here.  BUT it's not from lack of effort...  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.thy 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.
• Western Music.  I took a break from the (really fantastic) western/post-apocalyptic soundtrack by Michael La Manna to try something different, namely an Ennio Morricone-flavored Western soundtrack I found.  I really do love La Manna’s cool-as-ice Badlands music, but those stingers and jaw harps just got me in the feels.  I’ll be playing around with various configurations as time goes on, not sure which way to go.
• 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!)

[Tusky]

Looks really interesting!

Love the effects. I'm a fan of Ennio Morricone's soundtracks so am keen to hear what you end up with

[Vertigon]

How do you feel it compares with the older stuff like in this video?  I'm torn.  The older stuff is slightly more pro-tier, more polished sounding, but the Morricone stuff has more character to it I think...

[Tusky]

Yeah the newer stuff is way better. I may be biased though since I'm a fan of the more melodic.
You're right that has a lot character

[Pixel Noise]

Love giving the player the choice to engage or pass by random encounters! Nice to see you post again 

[Vertigon]

Yeah!  Back in action!

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(!!) for its 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:

Code:

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.

[Janionano]

It seems that the game is going to be really cool.
I was curious about your code, is this language Scala?