Friday, May 12, 2017

Dirtside

I've had the 2011 Summer of Starmada on my mind lately.  There were a couple of things that made Starmada successful, I think.  One was that it was simple enough to introduce new players without too much difficulty, with many options disabled-by-default.  This allowed us to achieve a critical mass of regular players and establish a metagame.  Finally, the availability of design rules led to strong participation in the game away from the table and allowed players to play fleets representing whatever science-fiction background they came from.  Unfortunately, it was that same design system that tore the metagame apart.

Dirtside 2 shares some, but not all, of these characteristics.  It does have a design system capable of modeling a wide variety of forces, and if the rulebook were better organized it would be easy to separate into a simple core and a number of optional components.  Compared to its brother Stargrunt, its morale system is simpler, it is larger scale, and it has a greater focus on combined arms. Unfortunately, as a ground-combat wargame, it depends heavily on terrain, and it uses a weird miniatures scale (6mm "microarmor").  Also, like Stargrunt, it does not handle alien psychology very well.  Finally, it uses a really weird damage resolution system involving drawing chits from a bowl; simple enough in practice, but an annoying number of moving parts.  If you lose a damage chit, your probability distribution is going to be skewed forever.

I've had my eye on Dirtside for a long time, but it just never seemed viable, due largely to hardware.  I looked at using roll20, but roll20's support for facing is very awkward, the asymmetric DM-player model isn't a great fit for wargames, and it sort of chugs on large maps in my experience.  I considered writing a VASSAL module, but java.  Now I think I might've found the correct tool, though - Tabletop Simulator.  TTS is already widely-available to the group that I game with, and is cheaper than miniatures.  It is easy to import hexmaps into it (I've looked at just taking Google Maps screenshots, imposing a hex grid at 100 meters per hex, and dropping them in), which solves the terrain problem.  It supports the "drawing damage chits" idiom very nicely with either decks or bags.  There are already steam workshop mods for it with models from the Dawn of War games, intended for playing Epic 40k, which would be perfect for representing units (I've been looking at using NATO-standard counters instead, but for some reason NATO has no symbols for "antigrav tank" or "giant mecha".  Gotta get on that, guys).  It seems like a very good solution to the "need miniatures", "losing damage chits", and "terrain is complicated" problems (though it may introduce some new problems, like "playing against opponents face-to-face is fun, and so is standing over a big physical map".  Maybe I need a ceiling-mounted projector aimed down on to a real table for that "war room" effect...)

The "poorly-organized rulebook" problem remains, however.  The rulebook is also not OCR'd, which is pretty annoying.  These two facts combined lead me to the conclusion that maybe I should transcribe / rewrite the rulebook, cutting it up into independent modules like Starmada had:

  • Core / Armor
    • general sequence of play, units, objectives
    • armored vehicle (tracked, wheeled, GEV, grav, mechs) movement
    • big index of combat actions, direct fire, guided missiles, damage resolution
  • Infantry
  • Artillery
  • Aerospace (I'm conflicted about VTOLs; most of the time they play like armor, but then they're also vulnerable to air defense)
  • Engineering (mines, fires and smoke, bridgelaying, ...)
  • Optional Stuff (oversized vehicles, experimental rules for drones and aliens, ???)
  • Vehicle Design and Points
It's already mostly organized like this.  The problem is that (for example) infantry movement is in the movement section with armored vehicles, rather than in the infantry section, and chit validity for artillery fire is in the direct fire chit validity table rather than the artillery chapter.  That's fine for a reference, but bad when you're first learning the game.  It's (only) a 60-page rulebook, so cutting it up and figuring it out is less work than learning all the quirks of an RPG, probably.  Combined with making tokens in TTS and a unit design spreadsheet (though there is already an online vehicle design tool, but it doesn't really support houseruling), it should be a reasonable, but not overwhelming, prep effort.

3 comments:

Koewn said...


Interesting. Gonna have to read through that one; thanks for pointing it out.

If you get started on this, drop me a line. I can generate real-world elevation maps, now with almost-correctly-scaled water features, at a variety of interesting resolutions. If TTS supports some sort of bumpmapping based on shade/value, that'd be golden.

Should be able to do vegetation shortly, at that.

John said...

Whoa, that's quite a capability! How'd you manage that? I looked at using the google maps / earth API for elevation data, but felt like I was going to need an awful lot of data to figure out the "noise" in the elevation in each hex (to determine eg hills, flat, cliff, ...). Also considered training a neural network to classify vegetation. I'm not really familiar with bumpmapping (or graphics and 3d modeling in general); http://berserk-games.com/knowledgebase/custom-models/ is their documentation on the subject.

Koewn said...


Various GIS data sets, like SRTM data from various Space Shuttle missions, mangled through a currently Rube-Goldbergian series of Perl scripts.

Also, for units:
https://spatialillusions.com/unitgenerator.html

Code here:
https://github.com/spatialillusions/milsymbol

In theory the map should be as easy as having an acceptable image with a matching bumpmap, which is just an 'overlay' that allows the engine to calculate the 3D height of part of the map based on the value of the pixel in the bumpmap. My code could generate the bumpmap as part of the process, in theory.