The environment is harsh. Dust storms of national and global scale have made long distance wireless communications unreliable. So, despite the advanced equipment the factions continue to rely on scouting (human and autonomous drones) and runners to convey situation awareness and instructions between units. Even long range targeting and retargeting takes significant time, but once established is accurate. Some factions rely on well planned actions with strict adherence to the plan by the discrete units. Other factions rely on discrete units making local decisions stemming from the unit's overall purpose.
The scenario I am working on is a tanker truck needs to be driven to the coast (ie, off board) by its corporate owners. A rival faction wants to divert the trunk to its own facilities for local distribution (ie, driven off the other side of the board). It is a stalemate to have the trunk not reach either of these destinations before N rounds of play. It is a defeat for both sides if the tanker trunk is destroyed.
My initial plan was to use the Horizon Wars rules as I played an early edition of them from a few years ago. The rules are basic, but do make for a quick game. However, I am not wedded to them so am open to suggestions for other suitable rules.
My first question is how to start gaming a scenario? Is there an approach to determining the units needed? Or is it ad hoc, ie just play a game with a guess at unit composition and respond to the results? Or something else all together?
Update: The working document for this is at "A setting for near-future wargames."
A setting for an Horizon Wars miniatures wargame.
Before reinventing the wheel I did look around for a tool like this. What I found was a market of crazy, obese, gold plated implementations that actually cost money and often often lots of it. I don't object to making money from software, but not from something so simple as this, that is something that requires hardly more than a single web page. And so the development began.
The webapp is in its very early stages of development. I have just touched the surface of the Google Calendar API and its use within a HTML/JS page. At this point I am only concerned with the mechanics and so have made little attempt to make the UI useable. My goal with the UI is to have a tablet by each meeting room running a browser in "kiosk" mode and only showing the meeting room page. The page will show the events for a user who has authorized and selected a calendar.
If you want a side project and are interested in working on this with me to complete it the project is at https://github.com/andrewgilmartin/meeting-room-occupancy. A live version is running at http://andrewgilmartin.com/meetingroom/.
would have their spine column exposed and then their ribs severed from the spine and pulled open (to resemble wings). Finally the lungs were exposed (and in some instances covered in salt) to complete the torture and lead to the death of the prisoner. (source)is too much for me. I won't be playing that game.
This posting is mostly here to remind me how to configure the DNS records for a site where the www subdomain's content is hosted by Blogger and other subdomains are hosted by my colocation server.
DNS A record
DNS CNAME records
Where X and Y are given by Google/Blogger.
When I figure out the MX records I will update this page!
In a previous posting I wrote about using "splinters" to represent the kind of deadfall you find in the woods and bogs. I spent more energy that I care to admit settling on a source for the splinters: block planer shavings, chainsaw chunks, drill bit waste, ... In the end I used the dried up branches one drives over time and again on the driveway. A hand full of this material will spread out to a square foot of forest floor. Just split off a chunk, flatten it a few times with a hammer, and then pull it apart.
Preparing two more tables tops for May's Great Swamp Wargamers game night. The table tops are 4'×3' hardboard glued and nailed on a framework made from 2"×1" pine boards. The edges are blue-taped to keep them clean until the terraforming is done. The terraforming is a simple process of
- Glue down any surface features. In this case, I am using "splinters" to give the appearance of deadfall found in a bog or forest floor.
- Paint the whole surface with an earth brown.
- Paint the surface features as needed. In this case a "wet" brown.
- Using a spray bottle coat the entire surface with watered-down white glue -- about 1 part glue to 3 parts water. Use a spray bottle rather than a brush as it will apply a more even coating. A brush tends to leave ridges.
- Using a sieve apply a pattern of grass. When using Woodland Scenics's fine turf add some coarse turf to the sieve to slow the casting of the fine turf. If you don't do this then you tend to get mounds of turf rather than an even application.
- Using a sieve apply to the remaining (non-grass) areas dirt. I use dirt from my yard that has been baked for an hour at 400° F to kill off the microbes.
- When dry, turn the tabletop upside down and tap to remove excess grass and dirt.
- Finish with several applications of watered-down white glue or spray clear coat to fix the grass and dirt and make it resilient to playing on. I use a pressurized hand sprayer that is normally used for spraying insecticide. It can apply an even coat of the glue. The tabletop is noticeably wet after each spraying, but I do this outside on a warm day so that the glue drys before penetrating the hardboard.
So these days I am thinking ever more about what language to move to. I think the perspective of my employer would be to remain with a language targeting the JVM. I haven't asked, but I know well enough its conservative approach to solutions. The software architect in me would like to pick a language that is more aligned with a fail fast approach to service runtime and its corollary of needing to start fast.
Lots of folks at this week's O'Reilly Software Architecture conference in NYC are favoring Go (commonly called "golang" to make the conversation clearer and searchable). That it compiles to a binary (and even a statically linked binary) for direct execution on the host is a significant boost to start fast. Starting slow would be your architect's fault: Too much in-process preparation and not enough just in time initialization or not enough externalization of functionality into a service. I will look at Go and its libraries. I do worry that is the new black, like Ruby was several years ago.
Sometime ago I found online a discussion about using D6 dice to simulate percentage dice. Unfortunately, I did not keep a link to the discussion. Anyway, I wanted to add my 2 cents and so here it is. You can use 2 D6 to compute a value over the 1 to 100 percentage range. The two dice, A and B, are treated as base 6 1st and 2nd place values. The range is 0 to 35, ie, ( A - 1 ) * 6 + ( B - 1 ), and so the percentage step is roughly 2.7%. This seems like enough granularity for most games using percentage dice. The lookup table is
1 2 3 4 5 6 1 1 4 7 9 12 15 2 18 21 24 26 29 32 3 35 38 41 43 46 49 4 52 55 58 60 63 66 5 69 72 75 77 80 83 6 86 89 92 94 97 100
"No, you can't use that 2012 Windows 7 machine because you don't have enough graphics RAM."
"No, you can't use that 2014 MacBook Pro because we don't support Steam for OS X."
"No, you can't use that same 2014 MacBook Pro with a Windows virtual machine either you looser."
"No, you can't use that iPad Mini 1 because, well, we hate you."
Dear Wizards of the Coast, I want to play your game. I want to buy your cards. I will even buy your card sleeves. And buy them all again every 3 months. But I am not buying another computer to play a fucking card game!
Next to my computer desk is a second computer desk. This had an old Mac Mini that the kids used to play on and do some homework with. Since they got Chromebooks, however, they really have not touched it. Its last use was for Minecraft, but even that obsession has past. So, I decided to repurpose the desk for modeling.
I packed up all the computer equipment, including two ancient x86 towers, added overhead lighting, and moved over the modeling stuff. I am glad I made this choice. The table is 6' x 2.5'ish so there is plenty of width and just enough depth. I have a couple of Ikea flat files for holding my unpainted figure, modeling bits, and infrequently used tools so I have a good amount of storage. I will likely build something akin to Linn/Darbin Orvar's small parts organizer caddy in the coming months.
So, back to painting those 6mm Vikings and Anglo-Saxons. Which, I have to admit, I might never finish. They are just not that much fun to paint. At this point I am thinking that for 6mm figures I will send them out to be painted. At 30¢ to 80¢ per figure a few hundred would be $100 to $200. Well worth the cost.