Category Archives: Other Games

Deluge of Definitions

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.

Holiday Talisman – Now with Pay 2 Win

We have a New Year’s tradition among some local friends of playing the Talisman board game.  This is no casual gathering, but an all-out annual quest for questing…  with nearly every expansion the game becomes a behemoth that barely fits on the dining room table.  The Monopoly-like board of the base set is extended in every direction with dungeons and towns.  Tiny little special encounter and item decks are stacked everywhere…  The main adventure deck, swole with expansion cards, is so massive that we break it into three piles so it won’t topple over.  

There’s a delightful insanity to Talisman’s hodge-podge of fantasy themes, like Tolkien and Gygax thew up in a Milton-Bradley factory.  Werewolves.  Faeries.  Dragons with swords for scales.  It’s also completely unbalanced and random as hell.  Did I say it’s the best game?  It’s also the worst game!  Every roll of a six-sider or draw of a card could result in a game-winning boon or a soul-crushing return to square one.  And the behemoth keeps growing…  people keep buying new expansions, so by now a game takes at least six hours…  Hence the once a year tradition.

Jim, the owner of this pile of cardstock insanity, was looking for ways to make these evenings of hilarity even more memorable.  How could we make Talisman even worse?  The answer was clear:  Pay to Win

Pay to reroll a die!  Pay to stop on a square!  Escape a dungeon!  Cheat death!  We embraced the pain and proceeded on our long evening of questing.

The game was just as random as ever.  People would gather massive arsenals of equipment, just to be turned into a toad and drop it all on the ground.  Talismans (Talismen?) were gained both through mighty deeds and by randomly tripping over one.  The dragon fight at the end to gain the Crown of Command was the usual madness, and as usual an unbeatable card combination helped seize the day.

I gotta admit though, all these little one-dollar kicks to the privates actually made Talisman a bit better.  We could fix our random failings.  Sure, sometimes we put a couple bucks in and got a worse result, but that was part of risk-reward.  Around 2AM we staggered home, some 30 bucks filling the money jar, paying forward into the next game night.   However, I’m not sure how we can top this next year:  Loot boxes?

E3 Greenery

E3 has hit once again and with it we’re seeing a new raft of games punctuated by the return of a favorite series of mine: God of War.  But wait I’m sensing a trend over the past few years in game controls and setting:

So I love free-roaming adventure and I’m a fan of over-the-shoulder third person controls.  I’m also unbelievably thrilled that lush landscapes are possible in modern games and that we are past our “green and brown” stage. Vegetation punctuated by ruined structures can be endlessly fascinating to explore.

However, the first three God of War games were pretty rad in their settings and control scheme.  I’m sure I will play the hell out of the new one.  But I do like it when not every game evokes Sky-Zero-Charted-Cry-Raider when it comes time to make another one.

Ironically, the lush greenery used to be the exception, not the rule…  la différence.  Now I’m totally interested in what never-seen fresh place games will take us next.

Variety is nice!

So Many Datafiles

Yes, Technical Debt is still rearing its ugly head.  One of the things that any procedurally-generated Roguelike has is a ton of different files that hold profiles that define how to generate cities, landscapes and enemy encounters.  And tables, so many randomized tables!

sceneinspectorDuring the 7DRL I found an expedient solution that worked for the challenge and a fair amount of time afterwards.  I baked data right into each Unity scene that I saved out, imagining that I could just make a scene for each type of scenario or terrain profile I wanted.  I could bake in components that had all the predefined information I needed and just load them as needed.  I could even drag-n-drop the appropriate prefabs for everything I wanted to spawn.  How simple.  Sure, it nagged at me that it wasn’t super extensible, but scenes were cheap to make and I was interested in how far it could get me.

Wellll, it turned out it was pretty far, but eventually it started to haunt me.  The more scenes there were, the harder they all were to maintain, even if all the common information was kept in Unity prefabs.  Oh god, the prefabs…  they are great sometimes, but they also can puke all over themselves if I moved files around or a metafile got invalidated somehow.  Also, any time I wanted to choose something randomly, it felt like I was writing new code to deal with it each time.

I also used the serializer for a number of structures, but there was always a desire to have more flexibility when reading data.

Anyway, I knew I needed to up my datafile game.  My friend Jim’s amazing RL Dungeonmans has something like 500+ datafiles holding anything from name generation to encounters to tile definitions, with weighted randomization tables and tables that reference other tables.  How slick!  He spent many years refining his data methods and he encouraged us to reuse his approach in our own games.

So last weekend I finally bit the bullet and built a datafile system around some of the same concepts and in the end my format is virtually the same as Dmans.  This way I can build a sector with a pretty flexible format:

defThing sector_basic
{
 class adSectorData
 scene Overworld

 biome Desert
 nametable sector_name_chart
 treasuretable sector_treasure_table

 music mus_desperado

 basic_city_table 1d2
 sector_outpost_chart 2d4
 sector_town_chart 2+1d3
}

And these tables have some handy reference capabilities (recursing through each table referenced) and weighting for randomized results:

defTable "sector_name_chart"
{
 #t1 "sector_place_types"
 #t2 "place_nouns"
 #t3 "sector_adjectives"

 "The [t1] of [t2]" 10
 "The [t3] [t1]" 10
 "The [t1] of [t3] [t2]" 10
}

defTable "sector_adjectives"
{
 "New" 10
 "Old" 10
 "Dry" 10
 "Frosty" 10
 "Winding" 10
 "Hewn" 10
 "Locked" 10
 "Winding" 10
 "Ancient" 10
     ...

…and bingo, my world generation becomes 10x more flexible and powerful.  I’m dyin’ to get back to the drive-shoot stuff, but this was so worth it.

namegen