Auto Fire, Game Development

Content Flow

Leave a comment

Not a lot of talk coming from me lately, but Auto Fire is coming along as always.  I’ve been trying to bind all these systems I’ve created into some structure that pulls the player through the game more effectively.  Driving around and blowing things up is great, but there’s no goal yet.

I’ve been working on a faction system that allows various groups to occupy each location and sector on the map.  These factions have unique names and a variety of bosses under their employ, and each owns a location.  Various types have different types of bosses and relationships with other factions, etc etc.

On the upside, I was able to mess around with some more procedural generation and come up with boss names and even randomly-generated quotes.

In addition, I realized that I was going to hate playing through progression without having an automap, so I set down to work on that last night……..

It took all of two hours.

Dammit, I should have done this a year ago.

I owe everyone a build, and I’m hoping that a real content flow will warrant that.

Auto Fire, Build Update, Game Design

Auto Fire Update v0.5.01

Leave a comment

I had a bit of a weird week because I was coming off the RoguelikeCel, but after the feedback I got I knew just what to focus on for this new update.

Get Auto Fire v0.5.01 on Itch.io

Enemy Cars

  • Enemy cars can shoot again!
    • Yeah sooooo I recently added some infrastructure so that player vehicles can have unique loadouts that are independent of the model of car itself.  …annnnd while I got it all working for player vehicles, I broke the ability of enemy cars to have their own weapon loadouts too.  So they didn’t actually have any weapons mounted. :-P  Fixed!

Health Bar

  • The existing health post attached to vehicles in the world was straight up and down, and hence blocking the view of important info such as the state of the front weapon, or your speed when reversing.  The style of the health bar is now adjusted to be a bit less disruptive.

Speed UI

  • The speed indicator was pretty rough, hard to see, and clunky to look at.  A few things were done to improve this:
    • Smoothed out the speed indicator angle so it rotates more gracefully.
    • Improved the speed chevrons (both the green and red) to be more visible.
    • Added grip indicator for the player on top of the speed indicator, for the player car only.
    • Speed arrows and grip indicator grow in a more visually pleasing way.

Skidding functionality

  • So the previous model of vehicle skidding either gave you complete control or zero control.  It never felt good since people’s instinct is to push against a skid in various ways to try to influence it.
  • I wanted skidding to be fun and also kind of do what you expect.  So, it got a heavy overhaul:
    • The speed indicator now has a display of “hazard levels” beyond the speed itself.  A broken chevron means that you are skidding more out of control.
    • The “hazard skid” levels supplement the standard “grip down to zero with a red speed indicator” style of skidding.
    • If you have a hazard skid, you can turn but can’t influence your movement.
    • If you are skidding but do not have any hazard skid levels, you can influence your movement by 45 degrees by accelerating to the side.  Thus a skidding vehicle can still trace wider arcs.
    • You can accelerate or decelerate your skid by pushing towards or away from the direction of skid.
    • Skidding and grip now recharges more reliably based on whether you are facing in the direction of the skid.

So that’s it for now.  I’m adding a little more info on the Itch page about the systems that Auto Fire (in its current state) will support for now.  Someone asked for a 32-bit version, although I’m not sure I’d recommend older machines until I slim down some of my meshes.  In the future I’ll put more work into optimization and alternate OS’es like Linux.

Auto Fire, Game Design, Game Development

Roguelike Celebration 2018

Leave a comment

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, Build Update

Auto Fire v0.5 build posted!

2 Comments

What’s that?  A work-in-progress build of Auto Fire is up on Itch.io?  Check out version 0.5 here!!

Don’t worry, you don’t have to donate to try it out.  It’s still got a lonnnnng way to go.

Recent improvements:

  • Camera now behind the vehicle in both overworld and combat.
  • Dynamic camera and VFX based on speed.
  • Map state is saved when when returned to.
  • Revised environment visuals for clarity.
  • More garages everywhere to install your loot.
  • UI improvements for better feedback on weapon state and skidding.
  • Updated sound and music.

In the future:

  • Improved progression arc.  No real balance as of yet.
  • More weapons, equipment and enemies.
  • Special maneuvers like bootleggers and charge rams.
  • Encounters on the overworld map.
  • Boss fights that clear out a hostile area when defeated.
  • Citadels as a destination for weapon and vehicle stores, cargo missions, arena duels, and a bar for rumors.
  • Fame and skill progression tracking, with media coverage of select combats.
  • Target painting, sustained fire, and other ways to increase or decrease the chances of.

As always, feedback is so, so, so very welcome.  Let me know what you think!

Auto Fire, Game Development, Video

Auto Fire Status Update – Oct 2018

2 Comments

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!

Article, Brass Tactics, Game Design, Game Development, Video, VR

Brass Tactics Postmortem Complete

Leave a comment

Brass Tactics was a really invigorating project to work on and I felt that we as a company (and I personally) learned a tremendous amount about VR in general as well as general player interaction and behavior.  Over the past several months I’ve brought the key takeaways and posted them on the Hidden Path website.

Since them I’ve cleaned them up as a series of blog/articles on Gamasutra.  I also will be giving a talk at the XRDC conference at the end of the month talking about some of our particular solutions in more detail.

Part 1:  Designing the map and player navigation

Learn about our experiments and pursuit for the most physical environment in this Gamasutra article.

The accompanying video can be seen here:

Part 2:  Designing the command interface

Learn about how we started with some traditional control models and eventually created something that felt closer to dancing in this  Gamasutra article.

The accompanying video can be seen here:

Part 3:  Designing the economy and additional interactions

Learn about some of the general interaction experiments we tried, and why we did or did not pursue them in the final game in this Gamasutra article.

The accompanying video can be seen here:

After my talk at XRDC I will probably be pestering y’all less on Brass Tactics.  I do still make the occasional update but at home my focus in almost entirely on Auto Fire.  It’s been fun!

Auto Fire, Game Design, Game Development

Scooping the Loot

Leave a comment

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.

Auto Fire, Game Design, Game Development, Other Games

Deluge of Definitions

Leave a comment

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.