Category Archives: Game Development

Auto Fire, Build Update, Game Development

Auto Fire – Version 0.5.7

Leave a comment

Some smaller updates to Auto Fire today… But since a good friend put the game through its paces on his stream, I discovered a number of bugs that I wanted to squash but quick:

Watch TANGLEDEEP PASSED LOTCHECK let’s play games from PlayDungeonmans on www.twitch.tv

Visuals/Fluff

  • All menus use standardized buttons and fonts now
  • Music for the garage
  • Screen darkens behind popups, drawing your attention to the UI when necessary
  • Adjusted the vehicle view in the UI to reduce visual noise.

Bugs

  • All cars now have everything socketable and swappable.  Locking equipment slots with fixed components is a feature, but not something I wanted to lay onto players at this early stage.
  • The equip popup now has a functional scrollbar, so you can use whatever you pick up.
  • Fixed hover information getting stuck if you exited the menu from the inventory screen
  • Fixed boss taunt popup issue

As always, it’s free right now, so go check it out on Itch!

Auto Fire, Build Update, Game Development

Auto Fire Update: v0.5.6

Leave a comment

Some new Auto Fire coming in! Check out what’s new:

New Equipment:

  • Mines: When anybody (including you!) moves adjacent to one, it arms and then explodes 1 second later. Be careful!
  • Oil Slick: Lay down a strip of this, and any cars that hit this immediately lose their grip… perfect for tight quarters like the city.
  • Flaming Oil:  Leave behind a trail of flaming death. Sets whatever enters it on fire.
  • Wide Smokescreen: Create a whole volume of smoke, 3 across

Gameplay:

  • The player can choose one of three cars at start with different weapon and equipment loadouts:
    • The Stallion has 3 Junkthrowers, a smokescreen and an oil slick. Good starter vehicle if you’re just getting familiar with the firing arcs
    • The Panther puts 2 Bolt Rifles, one front and back, as well as a minedropper and smokescreen. Its longer range makes for stronger hit, but you’ll need to pay a bit more attention to your facing.
    • The Cricket is small but has a short-range machinegun on its front. It also can spray flaming oil behind it. Good vehicle if you wish to stay mobile.
  • Things can now be set on fire, for continuing DOT. Right now just hooked to the Flaming Oil, although other weapons including the flamer will definitely be dealing this out.
  • There are now two sizes of cities… There’s a medium-sized 64×64 city, and the old huge 100×100 city (which is much rarer). The appearance of the smaller city in the overworld map is different.
  • The default boss is far less overpowered now. Sorry ’bout that!

User Interface:

  • Automap icons for exits and garages
  • Title screen popup allows player to enter name and choose starting vehicle.
  • Health and armor UI over various enemies only appear when that component is damaged… reduces UI spam overall.
  • Took a unifying pass on my amateur-hour HUD, so that everything has a more consistent look. Thanks to my developer friends for the feedback!
  • The vehicle display is now unified with weapons and armor in a single location.
  • Weapon names now pop up on the vehicle display so you are clear what weapon (and what side) you’re firing.
  • Updated icons for some equipment
  • Status icons are larger and more attention-grabbing.

Audio:

  • New sounds for rockets, flamers, and cannons.
  • Stingers and music now doesn’t start until a map is fully loaded.
  • Ram and explosion sounds are replaced with less terrible ones.
  • Vehicle acceleration (and visual effects) only play when speed is actually gained, rather than when you press forward (so it adjusts to “coasting” once you hit max speed).

Visuals:

  • Rockets have new effects and sound
  • Car body shakes when moving at high speed, camera shakes less.
  • Overworld cars now visually swerve and arc like the cars in tactical maps.
  • The borders on terrain maps look a hair better.

Bugs:

  • Fixed some elements of map generations on height-mapped terrain (although there still is a bug in there).
  • The Homestead and Walled City (both of which were ugly temp maps with very little functionality) cannot be entered. Will be replacing them soon. They are marked as not being able to be entered in the overworld.
  • The Boss site in the city (which announced, temporarily and rather cheesily, “Here Comes the Boss”) no longer can be seen. It was intended to be a marker for system use, not player facing.

I’m starting to enhance the equipment now, and am looking forward to new usable items and updating the inventory for its use. The future is bright!

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, 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, 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.