Category Archives: Game Design

Auto Fire, Build Update, Game Design, Game Development

Auto Fire v0.6.02: Crits and Repairs

Leave a comment

I am rolling off of a bunch of updates by the first coder to touch Auto Fire outside of me… My friend Jim streamed his work this past Saturday and Sunday and helped get some cool functionality in that I hadn’t done before.

Along the way he also added some Quality of Life improvements to some of the code, for his convenience but of course it will be helping me even more. Friends are nice to have!

In particular, I’m looking to snarf some of that ram functionality to wrap it up into a couple vehicle gadgets: A Ram Piston and… a Bootlegger somethingorother. Plus it lays the foundation for me to knock enemies around as the result of player action… something that ramming desperately needs.

For the time being, the new build has some fancy new features:

Critical hits

Weaponry now has a critical hit functionality when fired…  By default a weapon has a 5% of delivering a critical hit, with a crit dealing 2.5x damage.  You can improve that crit chance by 25% by painting your targets with radar (the 1 key) before attacking.  Sustained fire does still improve your chance of hitting (as does radar painting) but only radar enhances crits.

Critical hits are a core method with which I want to handle skill improvements, electronic warfare, and general hit bonuses. Improvements to hit chances are also in there somewhere, but I don’t want to have a lot of shots missing in the game… that can be frustrating. Hopefully this will be a whole new angle by which players can decide what to do next.

Revised repair functionality

While gas and ordnance still cost cash to purchase, repairs to your car now need precious parts to fix up.  You can refill your resources and make repairs in 10-unit portions now, rather than in an all-or-nothing fix.

Resources will become all-important as time goes on, an cash will mainly be focused on acquiring new gear, doing deals, making bribes, and so on.

Improved smoke screens

Smoke screens are a staple of car combat, but to date it hasn’t really been effective at getting anyone off your tail. I already had wide smoke screens but decided that it should be the norm… you should feel good about spending your action using one if you are in trouble. These wide smoke screens will nearly fill a roadway, to help you make an emergency escape… It really can deliver the goods.

…and other stuff

  • Gas now informs you if you are full and can’t pick up any more.
  • Some improvements to UI and feedback
  • Menu/UI Usability improvements.
  • Links to the help page and Discord from within the game.
  • A few additional bugs fixed.
Auto Fire, Build Update, Game Design, Game Development

Auto Fire v0.6.00: A Smooth Startup

Leave a comment

It’s arrived… a big update, worthy of a full point!  Auto Fire has had a lot of work put into it over the last month, not the least of it being the revised onboarding (that’s fancy-pants dev talk for what a new player experiences).  A lot of players’ first experience with Auto Fire was tough, because there were some really dangerous enemies out there in the badlands, and you were just as likely to meet them while you were still trying out your training wheels as any other time.

In the spirit of making the game more playable and easier to understand, there’s now an intro that eases you into things a bit… and sets up the conflict against your (generated) rival down the road!  Clear out those bandits and get back to civilization!

The game also tailors that early experience when you’re stuck with a couple of junkthrowers and not a lot else, so that you are less likely to encounter enemies that want to come punch you in the fun bits right away. This way you can pick up some loot, head to the garage, and upgrade away!

In addition, the player can now customize their character more fully upon startup.  You can choose your portrait, and the dialogue (even the procedurally-generated stuff) will adjust for male, female, etc.

There are a ton of changes that came in, but a lot of it is nerdy stuff that only I care about… Oh, hey, here’s some cool stuff you might actually notice!

Campaign

  • There’s a new encounter system that extends the random encounters in the game previously.  You now can see your opponent, they can call you by name, and choose a course of action.
  • The game starts with some intro encounters that help give you a sense of what you’re doing there and what to do next.
  • Character customization has been extended to support player portraits as well as choosing gender.
  • Both enemies, players and any NPC can now be male or female.  Dialogue is set to use the correct language to address them as it comes up.
  • You now have a (soon to be) publicity agent and a rival that are generated on campaign start.  These are referenced and used throughout the game.
    • Agents are now handled outside of factions.  Thus agents (any NPC) can join you, an opposing faction, or be an independent operator like the player.
  • A story manager presents basic encounters that drive the initial experience forward.  This will hook in as more cause-effect things happen with the player.
  • Naming has been adjusted to better fit categories of civilians, punks, drivers and corporate suits.
    • Female names have also been added since we can generate those NPC’s now.

Gameplay

  • Chests now break open when moved onto in the overworld.
  • Weapons now start with a higher amount of damage (junkthrower starting around 10) but don’t increase as drastically (the maximum is about 250% of the minimum, rather than the former 1000%)
  • Weapons have less of a randomized spread in their damages (used to be 70-130%, now is 80-120%)
  • Armor for the player’s vehicles have correspondingly been increased, from 100 per side to 150.
  • Armor repair kits now repair 15 per side rather than 10.
  • When the player is ambushed into a battleground, they start in the middle of the map rather than near the entrance.

UI

  • There’s a new intro cutscene that sets the situation when the campaign is started.
    • Because I know dying would be a chore if it couldn’t be, these can be skipped.
  • Encounter text also has a teletype-style reveal, which again can be skipped if the player is impatient.
  • Portraits can show or not show in encounters, and can even show as a transmission.
  • The loading screen shows hints and has a spinner so you know if the game is live.
  • The cursor keys have been remapped to work properly within menus.  Key navigation of menus still needs improvement, but it should be better than it was.
  • Fame/Prestige is displayed properly on character and city menus.
  • Adjusted a bunch of buttons to be more visually interesting.

Visuals

  • Cars now don’t kick up much dust when travelling on roads.
  • The gas can in the world is now red, matching the icon(!)
  • There is a quick stint of slow-motion when cars are destroyed, and the same effect is back when the player died.

Audio

  • Revised some of the stingers when entering maps.
  • The turn-end sound was revised to be less in-yo-face.
  • Button presses have more audio feedback in more cases.

This coming month will be all about adding variety and continuing to improve the interface.  If I demonstrate the game at a show, what will draw players in? What will it take for them to understand what’s going on? What last flourishes or abilities would really sell the whole package?

Auto Fire, Build Update, Game Design

Auto Fire v0.5.15: Overworld Overlords

2 Comments

When expanding the feature set of Auto Fire,  an important element was to finally make the overworld play more of a role in the game.  As a first step, the badlands now have roaming gangs that run convoys from place to place (having an agenda that will grow over time).  These clouds of dust have an unknown number of cars in them, and eventually they will hold a variety of characters within, including lone drivers, hit squads, innocent settlers and good ol’ cargo convoys. 

Each roaming enemy gang has a generated miniboss that runs it.  If they see you, they’ll interrupt what they’re doing and come after you.  If they reach you you’ll be dragged into full combat with their crew… but if you take down the boss you’ll earn yourself some extra fame.  Make sure you defeat them or they’ll come back to haunt you…

Some other changes with this build:

Overworld

  • Created overworld bosses (as described above).  These roam the world using a FSM via the Unity Animator (unorthodox but seems to work fine).
  • Added a lot of infrastructure to make free bosses and track the player’s kills in each faction.
  • Bosses now have a “spotted” shout that occurs both in the overworld and in combat.

Controls

  • Cleaned up the UI for weapon aiming.  The player can’t accidentally advance the clock by targeting empty ground.
  • Buffer keystrokes now so that the player cannot target when the enemy is still in the middle of its move.  The result was a bunch of misses due to bad UI… Ugh it was driving me nuts! Fixed now, yay!

Combat

  • Revised the combat hit resolution from an older system, which was Diablo-like (and tended to create more misses and less impact due to bonuses), to one that is more of an opposed roll with positive and negative modifiers (more like D&D).  It creates a more distinct feel to good and bad weapons and situations.
  • The new equation:
    • Attack Rating (AR) = accruacy + gunnery
    • Defense Rating (DR) = rangeMult(1) * range + speedMult(2) * speedAboveOne + defenseVal
    • Bonus = paintBonus + sustainedBonus – targetingPenalty
    • Hit chance = 100% + (AR – DR + bonusMult(2) * bonus) * 10%
  • Junkthrower is more powerful, which makes the starting Stallion less terrible to use.
  • Turned down the difficulty of some boss encounters, since they were a brutal step above regular cars to fight.

Systems

  • Minor Unity and API upgrades.
Auto Fire, Build Update, Game Design

Auto Fire v0.5.14: Hitting the Big Time

Leave a comment

I’ve made some pretty good progress on Auto Fire, finally steering to towards a new phase of its development…  The prestige and reputation systems. These are more important than you might have originally thought to the future of the game.

You see, the world of Auto Fire is not the dreary low-tech wasteland that it appears to be so far…  Yes, the world did undergo a dreadful catastrophe, but that was many years ago.  Life goes on.  The corporate citadels around the badlands are packed with people living out their lives in relative monotonous comfort… Wage slaves in a company town.

It’s dangerous for the average person to travel and gas is extremely scarce, so few people ever leave the shelter of the city they grew up in.  Meeting new people is a rare delight.  Entertainment is limited to whatever the can find within the walls or by watching vids.

Life is pretty boring in the citadels.

By contrast, things are pretty rough out in the badlands, but it’s a lot more interesting.  City folk are eager for any tales from the outland.  Drivers are their reality stars, and sometimes even their heroes.  As a driver, your reputation is everything, so you’ll have to do whatever you can to build it.

More about this to come in the future, but for now here are the changes to version 0.5.14 (Download now!):

  • Weapons have been rebalanced to make one-turn cooldowns the norm.  This helps people get a better feel for turns, and hey, it’s more fun.
  • Action pips have been added to the HUD above the grip meter.  This shows how many actions you have in a given turn based on your speed, and counts off as you use them.
  • When the player moves diagonally, the movement between squares takes longer (reflecting the 1.4x distance between them).
  • Resources now visually fly from where they are collected to their location at the bottom of the screen.  Juicy!
    • Gas now has a maximum that is definable per car chassis.  Yes, better cars have bigger gas tanks.
  • There is a new Fame System being tracked on the player.
    • Completing missions and killing enemies will gain you Fame.
    • Fame will also visually fly from where it is collected to its home in the top left corner of the screen.
    • Fame will cause your Prestige Rank to level up when you hit specific boundaries.  There are ranks from 0 (Nobody) to 20 (Immortal).
  • The player’s portrait now lives at the upper left, reading out the current fame.
  • The enemy boss portraits now have a lot more variety, with a cleaned up style.
  • Fixed a bug with light trails when cars are killed.
  • VO added to introduction.  The intro is now 33% more gravelly.
  • Lots and lots of code cleanup (good for me, fewer bugs for you!)
Auto Fire, Game Design, Game Development, VR

BIG WEEK! Big Week!

Leave a comment

This has been an exciting week for me… As Hidden Path puts the final digital shrinkwrap on my most recent VR title Raccoon Lagoon, I’m bidding the classic nine-to-five a temporary adieu. As of yesterday, I’ve started focusing my full attention on Auto Fire! It is my hope to get it into solid, pro-tier shape over the summer, and see what happens!

In celebration of this moment, I’ve put together an early trailer, complete with some pro-tier voice acting:

Auto Fire needs a lot of work yet. I need to make the interface more approachable, flesh out the content, and improve the basic art so that the game starts turning heads. I need to deliver on the fantasy of driving a combat car… that’s skidding, shooting, hauling convoys, maybe even launching from jumps? The possibilities are endless!

Adding gamepad support should help people get comfortable with it quickly, and improving the mouse interface will hopefully do the same. Anything that helps people ramp up and be gripped by the promise of a muscle car bristling with chromed-out weapons.

As an inaugural step for my all-in on Auto Fire, I’ve been deeply examining my turn model… something I haven’t touched in like two years. The way it used to work is that each team would execute their moves when the timeline reached it, so that if you were moving at 60 mph (3 moves per turn), and the enemy was moving at 40 mph (2 moves per turn), the simulation would resolve with:

  • You move (progressing to 0.333 seconds)
  • They move (progressing to 0.5 seconds)
  • You move (progressing to 0.666 seconds)
  • They move (progressing to 1.0 seconds)
  • You move (progressing to 1.0 seconds)

Guh. This might sound sensible if you are a realism fan, but when many entities are moving at different speeds, the turns all interleaved and the player never knew who was going to move when. It was confusing and could get frustrating as an enemy vehicle suddenly drove right into your path or out of your line of fire.

The new model is pretty simple: Each turn you execute your moves, then the rest of the world executes their moves. So in the above example, you’d get your 3 moves, then they would get their two. It’s basically X-com style, but you know what?

It ended up playing exactly the same.

Yeah, you can’t really tell there’s any difference at all, it flows great. And while I was worried that you’d be irritated by that long pause for your opponents to do their thing during your fancy driving , it actually feels a lot better than when your opponents interrupted you at odd, unpredictable times during your turn.

This is an important breakthrough because if I can make the player keenly aware of what a “turn” is, I can help them understand what acceleration does (more moves per turn) and how weapon cooldown works (most weapons can only be fired once per turn). I might not need a hojillion progress bars (a weapon is either available or not). Since the core goal is to make the game more accessible and less math-y, I’m optimistic that this is a good step that doesn’t sacrifice the core gameplay.

Finally, along with this exploration I started experimenting with better shaders using Amplify for Unity. It’s another useful step, because there will be a lot I want to convey in-world and good shader control will help me make better 3D and mouse-driven interfaces. Things are looking up!

Auto Fire, Game Design, Game Development

Progress both Practical and Pretty

Leave a comment

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!

Auto Fire, Game Design, Game Development

Noodling the Numbers

Leave a comment

Been working on creating some better combat mechanics and options for Auto Fire lately. One of the factors I was working on was tangibly having hit chance be affected by tactical choices such as “painting” a target with radar for more accuracy, or on the other side moving faster to avoid getting hit. I got those systems in but it didn’t really seem to matter.

I had to seriously think of how I’m dealing with accuracy, range and speed. My initial version of the combat system in Auto Fire was inspired by the system in Diablo II. It used this sort of calculation:

Chance =200% * AttackRating /

(AttackRating + DefenseRating)

Consider AttackRating to include things like gunnery skill, weapon accuracy, and other targeting bonuses. DefenseRating in contrast is stuff like range, target speed, and target size.

Multiplying the value by 200% gives the player 100% hit chance whenever the Attack Rating is more than 50% the Defense Rating… So in the average case the player is guaranteed a hit. This was the system I used in X-Men Legends, and it feels pretty good in an action game where you are directly controlling your character and only want to have misses when your opponent clearly outclasses you.

The problem with this method is that the chance to hit tapers off because it never reaches zero… Thus, I was finding that there’s only a small sweet spot where hit bonuses mattered between 100% chance and maybe 60% chance.

If you like numbers, here are the results of that sort of calculation.

I made some changes and pushed the system more towards a classic “opposed totals” method more akin to D&D or most pen and paper games.

Chance = (base + AttackRating – DefenseRating) * 10%

It’s not original, but what it did was make each bonus you earn through improved targeting, or sustained fire (or penalty from moving fast) has a pretty chunky impact on the hit result.

Here’s that table if you’re feeling nerdy.

I do put a minimum hit chance of 10% just so it’s not worthless to attack, and I’m not sure what increasing the miss chance is going to do to the feel of the game.

I have a mechanic where excess above 100% is used as a critical chance (That is, 130% chance is an automatic hit with a 30% crit chance). I might consider doing the same on the bttom so a “miss” is a glancing blow that still does a little damage, progressing to a real miss based on the percentage. (For example, -30% is a 30% chance of a real miss and a 70% chance of a glancing blow).

I’m wrapping that back into weaponry definitions and looping back around to where I can try the new system in the wild. From there we’ll see what happens.

Auto Fire, Game Design, Game Development

Tiles, tiles and Tools

Leave a comment

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.