Tag Archives: gaming

OpenTafl v0.4.6.2b released

OpenTafl has seen some major development work for the first time in a while, culminating in the recent release of v0.4.6.2b.

This version adds some major features which have been on my to-do list for some time. First, the in-game and replay board views now support keyboard input, a major usability enhancement. No longer will mistaken command entries torpedo your games!

That feature, however, was merely a happy piece of good fortune, falling out of the true headline feature for the v0.4.6.x releases: a variant editor. That’s right. OpenTafl is now the best tool available for designing tafl rules, bar none. Not only can you individually tweak every rule described in the OpenTafl notation specification, you can also edit the board layout to look any way you like.

If you’re interested in playing a few games with the new UI or experimenting with rules variants all your own, you can, as always, get the latest version from the OpenTafl website. I haven’t promoted v0.4.6.x to the stable release yet, but I expect to do so soon.

With these features done, I turn my attention next to a few network-centric things for v0.5.x. OpenTafl’s network play server has not, to date, seen much use; now that PlayTaflOnline.com is getting close to its new architecture, I hope to write a PlayTaflOnline front end for OpenTafl, so you can use OpenTafl to play games at PlayTaflOnline, with all the rich support for replays, commentary, and analysis from OpenTafl. OpenTafl’s network server mode and self-contained network play will continue to be a supported mechanism for remote games, but won’t see new features. v0.5.x will also contain an automatic updater, to simplify the end-user updating process.

Looking further into the future, I’m running out of OpenTafl features I want to do. With luck, 2017 will see a v1.0 release.

Fishbreath Plays: MHRD Review

If you like puzzle games, it’s a good time to be alive. You’ve got your programming puzzle games, like Shenzhen I/O, SpaceChem, and really, the entire Zachtronics catalog; you’ve got your process optimization puzzle games, like Big Pharma and Production Line; you’ve got puzzle games of every shape, size, color, and description.

You even have, it turns out, logic puzzlers. That’s where MHRD comes in. You’re a hardware engineer for the waggishly-named Microhard, a company building the Next Big Thing in CPU design in the 1980s. You start with a single logic element: a NAND gate (for the uninitiated, that means not-and). You end up with a simple but entirely functional 16-bit CPU1, designing all the logic circuits you need along the way. Start with NAND, build the rest of the logic gates, figure out your multiplexers, demultiplexers, adders, and memory elements, put it all together into your higher-level CPU components.

It’s packaged in a fun, oldtimey DOS-style terminal editor, and unlike a lot of retro UIs, it doesn’t wear out its welcome. All your circuit design happens in a hardware description language, in an in-game editor. The editor has some foibles: it doesn’t scroll, and it only does line wrapping when adding text. On the other hand, it has a decent auto-completion engine. The hardware description language makes sense: you refer to pins and buses by name, connecting them to other pins and buses with an arrow operator. For instance, opCode->alu.opCode would connect the circuit’s opCode input to the ALU’s opCode input. Generally, the syntax is straightforward and easy to remember. Sound effects are basic; you get a background fan whir befitting an old PC, and an IBM keyboard sound effect which wears out its welcome after a while.

That’s all there is to it, which brings me to my next point. Is it good as a game? That’s a harder question to answer. It is sited in a difficult middle ground. It can’t be too freeform—given an instruction set and a CPU specification, very few people who don’t already know how could build all the necessary subcomponents. At the same time, it shouldn’t be too static, or else it feels a little too much like rote construction to the truth table for the component at issue. MHRD errs a bit too far in the latter direction. There is no real sandbox. All you’re doing is building the gates and circuits the game tells you to, in exactly that order. There’s no discovery to be had, and not a lot of freedom to design solutions in different ways. Unlike, say, Shenzhen I/O, the problems are small enough that it’s never all that unclear how to solve them.

That isn’t to say that there’s no fun to be had. If you aren’t a hardware engineer, or a software engineer with a deep interest in hardware2, you will find it fascinating how few steps it takes to get from a NAND gate to a functioning processor3. There are leaderboards, too, based on NAND counts for each element. Given that logic design is a fairly well-understood field, the NAND counts are uniformly the smallest possible number of gates required for each task, which gives you a nice target to aim for. The developer is active on his Steam forum, and seems to have more planned for the game. Given that it’s an atmospheric logic puzzle that I, an experienced software engineer, found enjoyable and educational, I think it’s worth a buy. (You may want to wait for a a sale.)

At the same time, there’s a better way. (If you’ve been reading the footnotes, you should have seen this coming.) There’s a free course out there, a Computer Science 101 sort of thing, called Nand2Tetris. As the name suggests, it’s similar to MHRD in that you’re building a CPU from a NAND gate alone. Nand2Tetris differs in two ways. First, it isn’t a game. As such, there isn’t a plot (MHRD’s is skeletal, but present), or any pretension that it’s about anything besides learning. Second, it goes a lot further. MHRD stops at the aforementioned functional CPU. The last puzzle combines the instruction decoder, the ALU, and some registers, and that’s it. It verifies your solution by running a few instructions through the CPU, and you’re done.

Nand2Tetris, as the name suggests, keeps going. After you finish the CPU, you write a compiler to generate your microcode. After you write your compiler, you write an operating system. After that, you can run Tetris. Furthermore, although you have assignments, you also have a proper sandbox. You get a hardware design language and a hardware simulator, and you can build anything you like. That, I feel, is the promise of a logic design puzzle game, and MHRD doesn’t quite deliver.

In the final reckoning, though, I say MHRD is worth the price of entry. I don’t really have the inclination to write my own compiler, and I have plenty of other software projects besides. If you’re only interested in the logic design portion, you ought to get MHRD too. If, on the other hand, you want to really understand how computers work—how the processor you built becomes the computer you use every day—try Nand2Tetris instead.

  1. It’s very similar in architecture, I understand, to the CPU designed in the Nand2Tetris course. We’ll come back to that. 
  2. Or a very good memory for that hardware class you took back in college. 
  3. Not counting the memory elements, the CPU task takes fewer than 800 NAND gates in the minimal solution. My current best is 3500. 

Fishbreath Flies: DCS AJS 37 Viggen Review

Leatherneck Simulations is at it again: a 1970s aircraft modeled in loving detail. Once more, we get a plane which has virtues beyond accuracy. Leatherneck’s DCS Viggen has heart.

I’ve written about the Viggen’s history already, so if your first thought is, “Why should I care?”, there’s your answer. With that out of the way, we can move onto the plane itself.

Digital Combat Simulator made huge strides on this front with the release of its new rendering engine in 2015; Leatherneck has proven itself well above average at the graphical side of DCS module development. The MiG-21 was a work of art, and the Viggen is perhaps even more so. The external model is well done, and seems perfectly realistic to me1. The real artistry comes inside the cockpit, though. Flip on the battery and the low pressure fuel pump, and the master warning lights (labeled HUVUDSVARNING, because Swedish) come on, bathing the cockpit in a luminous flashing red. Turn them off and get through the rest of the startup checklist, then turn the radar on. The CRT casts its eerie green CRT glow over everything, and seems to glow with the inner light all displays of its type do.

Beyond the superb lighting effects, the cockpit also has the weathered feel you would expect from twenty-year-old airframes. (Remember, the AJ 37 Viggen is a 1970 plane; the AJS 37 Viggen is the 1990s update). It isn’t dingy, but it does look and feel as though it’s been used, and that adds tremendously to the plane’s character.

We come now to perhaps the best part of the Viggen: its sound design. Although the DCS engine may not do very well at exterior sounds for any plane, Leatherneck has still managed to make the flyby sound meaty, especially in afterburner. In-cockpit, the state of things is much better. Turn on the AC power, and the computer’s fans spin up with a sound that reminds me of my childhood machines. The master warning alarm has the same warmth to it as the light does. Later, the insistent chirp of the radar warning receiver gives way to the thunder of the afterburner, growing deeper by stages as the throttle clicks past its detents through the three afterburner power bands.

Sound is an important and underrated component to immersion in sims. The Viggen gets it spot-on. It’s good as any sim I’ve played to date.

Systems and weapons
The Viggen flies a mission profile rather out of favor in today’s world: interdiction. That is, it’s designed to fly at ludicrously high speeds and ludicrously low altitudes, carrying a wingload of bombs, rockets, or rudimentary guided weapons. It gets to its target, pops up at the last minute to aim its weapons, makes one pass, and heads home.

This is reflected in its design: the canarded double delta makes quite a bit of low-speed lift, but it does so inefficiently. The Viggen is happiest in its native habitat: Mach numbers greater than 0.6, altitudes lower than 500 meters above the ground. It does not fit into the low-intensity COIN world of DCS nearly so well as (say) the A-10C, the Ka-50, or even the Su-25. The weapons fit requires you to know where your target is, and even the air pressure at the target’s location. All of this (except for the air pressure) must be programmed into the computer ahead of time, or using the wee six-digit input display while flying.

So, don’t expect to do much loitering, waiting for JTAC, and dropping bombs precisely. Even if it was more straightforward, the Viggen has very little facility for dropping quantities of its weapons smaller than ‘all’. Only guided missiles fire one at a time.

Having introduced this section with an extended ramble, let me get back on point for a paragraph. The systems modeling feels right to me. I’m not an expert on Swedish systems of the 1970s and 1990s, but everything feels plausible enough, modulo some early-access issues Leatherneck is working through in weekly patches. Notable fun items include the overwhelmingly programmable RB-15 anti-ship missile, the BK-90 totally-not-a-low-altitude-cluster-JDAM, and the RB-05A manually-guided missile (easier to use than it sounds). The air-to-ground mapping radar works as expected; that is to say, it’s very cool, albeit with the confusing wrinkle that green means no radar return and black means return.

There are some ongoing issues with rearming, as well as some others involving weapons and multiplayer, but I’m confident Leatherneck will be able to get those squared away.

On to the most subjective point! Is it fun?

Yes. Yes it is.

The design of the HUD, with few numbers and lots of indicator lines, makes you feel like you’re flying a Swedish X-Wing, and the rest of the cockpit supports that impression. As the treetops zip by at four hundred knots, and the waypoint distance line on the HUD shrinks to indicate you’re closing in on your target, you can just picture yourself hurtling down the Death Star trench.

Maybe that’s an exaggeration, but the Viggen’s mission profile makes for a certain sense of rising anticipation as you speed toward your target. Do you know that stereotypical scene from adventure movies, the one where the sun inches toward a bejeweled staff placed just so, or the one where some narrator is speaking while an orrery clicks toward planetary alignment? Everything is building toward a single moment, and then, bam—the payoff. The sun sparkles off the jewel and lights up the model of the city below, the orrery’s planets align. That’s the feel of a Viggen mission done correctly. Your range-to-target dial—and it is a dial; the Viggen may be computerized, but it isn’t that computerized—ticks down toward zero. You pull up, catching a glimpse of your target as you do. You roll onto it, lining up the sighting mark in the HUD, and then, bam. You pull the trigger and your weapons strike home. There’s the payoff.

It’s tremendously exciting.

I recommend the Viggen wholeheartedly, based on its production values and on the sheer thrill I get out of flying it. I offer the following two caveats, though. First, it’s an early access product; more importantly, it’s an early access DCS product. There are still plenty of gremlins. Second, if you’re a multiplayer-primary player, be warned that there are several bugs and several usability issues to contend with. Even with those caveats, though, it’s an excellent aircraft, and I very much doubt you’ll be disappointed with your purchase.

  1. I don’t count rivets, though. 

2016 Tafl Efforts: Results and Roundup

First off: the inaugural OpenTafl Computer Tafl Open has come to a close. It was a bit of an anticlimax, I must admit, but fun times nevertheless.

To recap, only one entry (J.A.R.L) made it in on time. On January 2nd, I had the AIs run their matches, and it was all over inside of 20 minutes, with a bit of technical difficulty time to boot. You can find the game records here.

To move one layer deeper into the recap, both AIs won one game each out of the match. J.A.R.L won in 22 moves, OpenTafl won in 18, giving the victory to OpenTafl. Disappointingly for me, OpenTafl played quite poorly in its stint as the attackers, allowing J.A.R.L to quickly set up a strong structure funneling its king to the bottom right of the board. Disappointingly for Jono, J.A.R.L seemed to go off the rails when it played the attacking side, leaving open ranks and files and leaving a certain victory for OpenTafl. Deeper analysis is coming, although, not being a great player myself, I can’t offer too much insight. (Especially given that neither AI played especially well.)

I do expect that, when Jono finishes fixing J.A.R.L, it’ll be stronger than OpenTafl is today. He intends on making its source code available in the coming year, as a starting point for further AI development. (If feasible, I hope to steal his distance-to-the-corner evaluation.)

There will be a 2017 OpenTafl Computer Tafl Open, with the same rules and schedule. I’ll be creating a page for it soon.

Next: progress on OpenTafl itself. It’s difficult to overstate how much has happened in the past year. Last January, OpenTafl was a very simple command-line program with none of the persistent-screen features it has today; it had no support for external AIs, no multiplayer, no notation or saved games, and a comparatively rudimentary built-in AI.

The first major change of the year was switching to Lanterna, and that enabled many of the following ones. Lanterna, the terminal graphics framework OpenTafl uses to render to the screen, allows for tons of fancy features the original, not-really-solution did not. Menus, for one. For another, a UI which makes sense for the complicated application OpenTafl was destined to become. Although it’s the easiest thing to overlook in this list of features, it’s the most foundational. Very few of the remaining items could have happened without it.

Next up: external AI support. In the early days, I only planned for OpenTafl to be a fun little toy. At the end of that plan, it might have been something I could use to play my weekly (… well, kind of) tafl game without having to deal with a web interface. (For what it’s worth, Tuireann’s playtaflonline.com renders that goal obsolete, unless you really like OpenTafl.)

Later on, as I got into work on OpenTafl’s built-in AI, I realized what an amazing object of mathematical interest it is, and that it has not, to date, seen anything like the kind of study it richly deserves. As such, I decided I wanted OpenTafl to be a host for that sort of study. Much of what we know about chess, go, and other historical abstract strategy games comes from the enormous corpus of games played. That corpus does not yet exist for tafl games, the amazing efforts of people like Aage Nielsen and Tuireann notwithstanding. The quickest way to develop a good corpus is to play lots of games between good AIs. Good AIs are hard to come by if every AI author also needs to build a UI and a host.

So, OpenTafl fills the void: by implementing OpenTafl’s straightforward engine protocol, AI authors suddenly gain access to a broad spectrum of opponents. To start with, they can play their AI against all other AIs implementing the protocol, any interested human with a copy of OpenTafl, and possibly even the tafl mavens at playtaflonline.com. Not only that, but the AI selfplay mode allows AI authors to verify progress, a critical part of the development process.

Multiplayer was an obvious extension, although it hasn’t seen a great deal of use. (There are, admittedly, better systems out there.) It proved to be relatively straightforward, and although there are some features I’d like to work out eventually (such as tournaments, a more permanent database, and a system for client-side latency tracking to allow for client-side correction of the received server clock stats), I’m happy with it as it stands.

OpenTafl is also the first tafl tool to define a full specification for tafl notation, and the first to fully implement its specification. The Java files which parse OpenTafl notation to OpenTafl objects, and which turn OpenTafl objects into OpenTafl notation, are in the public domain, free for anyone to modify for their own AI projects, another major benefit.

In defining OpenTafl notation, I wanted to do two things: first, to craft a notation which is easily human-readable, in the tradition of chess notation; and second, to remain interoperable with previous tafl notation efforts, such as Damian Walker’s. The latter goal was trivial; OpenTafl notation is a superset of other tafl notations. The former goal was a little more difficult, and the rules notation is notably rather hard to sight-read unless you’re very familiar with it, but on balance, I think the notations people care about most—moves and games—are quite clear.

Having defined a notation and written code to parse and generate it, I was a hop, skip, and jump away from saved games. Shortly after, I moved on to replays and commentaries. Once again a first: OpenTafl is the first tool which can be used to view and edit annotations on game replays. Puzzles were another obvious addition. In 2017, I hope to release puzzles on a more or less regular basis.

Last and the opposite of least, the AI. Until the tournament revealed that J.A.R.L is on par with or better than OpenTafl, OpenTafl was the strongest tafl-playing program in existence. I’ve written lengthy posts on the AI in the past, and hope to come up with another one soon, talking about changes in v0.4.5.0b, which greatly improved OpenTafl’s play on large boards.

Finally, plans. 2017 will likely be a maintenance year for OpenTafl, since other personal projects demand my time. I may tackle some of the multiplayer features, and I’ll probably dabble in AI improvements, but 2017 will not resemble 2016 in pace of work. I hope to run a 2017 tafl tournament, especially since the engine protocol is now stable, along with OpenTafl itself. I may also explore creating a PPA for OpenTafl.

Anyway, there you have it: 2016 in review. Look for the AI post in the coming weeks.

Fishbreath Plays Total War: Warhammer

I fear we are too late.

Under the High King’s banner, we drove the grobi scum out of the halls of our ancestors. We chased them through the badlands and put them to the az, and now they will never trouble us again. Our diplomats traveled the whole of the world, drawing together the karaks and reforging the alliances of old. We stood side by side with men for the first time in a thousand years.

But while we looked south, Chaos fell on the world from the north. Kislev fell. Nordland teeters on the brink. Men fought men in the Empire’s heartland, and now tendrils of darkness reach the very gates of Altdorf.

The High King looks north now. Umgi and dawi alike are united under his command. So we march to the lands of men, az in hand, to face those who would bring about the end of all things—servants and champions of the dark gods.

The Empire is a shadow of its old self. The Wood Elves still make war on all who stand for order. Their stubbornness may yet doom us all. We are the world’s last hope.

– Elmador Oathforged

Warhammer is an excellent setting for storytelling.

You should need no further convincing, but in the event you do, let me elaborate. From its rather humble beginnings as a miniatures wargame, Warhammer Fantasy Battles1 developed a world full of timeless themes for war stories: dramatic final stands against insurmountable odds, the evil horde sweeping through the world to eradicate all that is good and right, brave men standing athwart the tide.

Total War games are story generators. Perhaps they aren’t as effective in that role as Crusader Kings 2, but they nevertheless make interesting alternate histories. Note I say ‘interesting’, as in, ‘huh, that’s interesting’, and not ‘compelling’, as in, ‘I cannot wait to see where this goes next’. Previous Total War games were interesting, but not compelling. Factions aren’t all that different, generals are more or less interchangeable, your enemies are the ones next to you, and your territory is whatever you can take.

Not so much in Total War: Warhammer. Factions are very different—some depend on siege weapons, some depend on strong infantry, some depend on movement and trickiness, and all feel almost like different games. Generals have a deep skill tree, and that helps to turn them from collections of bits into characters. (I didn’t even have to start the game to look up General Oathforged’s name.) Your enemies may be across the world. Chaos, remember, comes out of the north, and the dwarfs start in the south. You can’t take territory willy-nilly, either. Most factions have some territorial restrictions. Dwarfs, for instance, can only occupy territory which was originally dwarfen: the settlements in the central plains are right out, but old dwarfen settlements occupied by the greenskins are fair game.

Ultimately, though, the thing Total War: Warhammer has over previous Total War games is its setting. It probably isn’t quite correct to say that everyone knows Warhammer, but a lot of people know Warhammer. There are more people familiar with Warhammer, I would say, than the 18th-century history of the Netherlands2. Even if the numbers were equal, the Warhammer setting is a fictional setting. By their very nature, fictional settings generate stories more easily than historical ones. This isn’t to say that there aren’t interesting stories out of the Netherlands’ exploits in the 1800s—just that they aren’t as memorable or as frequent as the stories out of the dawi’s fight against the grobi, or the Empire’s strife with its neighbors, or the coming together of all the civilized peoples to stand against Chaos.

So, when compared to other Total War games, Total War: Warhammer has much deeper emotional impact because of its setting. Game systems reinforce this: I’m not just fighting a war of conquest, I’m fighting wars of conquest to rebuild the Karaz Ankor and reclaim what was lost to dwarfkind thousands of years ago. Or, I’m not just beating up on my neighbors to take their stuff, I’m beating up on my neighbors because they are to the south, they won’t stop fighting me until they’re defeated, Chaos is to the North, and the Empire is the first and best line of defense against the Ruinous Powers. Or, I’m not just swarming up out of the badlands because I’m looking for a scrap—well, okay. Maybe the greenskins aren’t the best example, but even if they do fight just for the sake of fighting, they have a reason for it. It’s what they do: beat up on anyone small enough to take a beating, then find the next biggest thing, rinse, and repeat.

That, in my opinion, is what previous Total War games were missing, and what Total War: Warhammer has in spades: context.

To hit on a few final, technical notes, battles play quickly, moreso than even the relatively quick games in recent Total War history, but the factions are varied, tactics are interesting, and the AI has a great sense for cavalry flanking maneuvers. The Creative Assembly finally got to cut loose and have some fun, and it shows here. Presentation is generally superb all around; the writers nailed the Warhammer feel, and the art design follows along. There are some spectacular battle maps, too.

Really, it’s the perfect union of theme and mechanics. I’m glad it took this long to happen, because they got it very right. Ordinarily, when I’m looking forward to a game, I build up a picture in my head of what it’ll be like. That picture is usually not altogether accurate, so when the game finally comes out, there’s a time of adjustment. The game may not be bad, but it isn’t what I’m expecting, and so in a sense, I’m disappointed. I never had that feeling with Total War: Warhammer: it is everything I had hoped it would be. If you like games that generate stories, the Total War formula, or Warhammer, you owe it to yourself to give it a whirl.

  1. May it ride eternal, shiny and chrome!
  2. Fun fact: your author’s next favorite Total War game is Empire, because he likes to be contradictory.

Fishbreath Plays: Train Simulator vs. American Truck Simulator

If you caught the most recent episode of The Crossbox Podcast, you may recall that I cited these two games as examples of a genre I don’t quite understand. (I’ve come to call it the Podcast Screensaver genre1.) At the same time, said I kind of understood the appeal of Train Simulator. Namely, driving a train is at least a little unusual. Driving a truck on a highway is a little too similar to my daily commute.

Predictably—inevitably—further experience has made me change my tune.

What makes a good entry in the Podcast Screensaver genre? It needs to take a little attention, but not so much that you can’t follow the thread of the podcast. It should present occasional challenges—if it doesn’t, it ceases to be a game in the Podcast Screensaver genre, and you might as well just watch a screensaver. Ideally, it should be immersive. Most importantly, it should be pleasing to look at.

Let’s go down the list.

Takes a little attention
American Truck Simulator fits the definition more or less perfectly. If you drive a car, you know this. Driving isn’t difficulty, but it does take a constant minimum expenditure of brainpower.

Train Simulator, on the other hand, is a little harder to defend. Driving a train, though it is more exotic than driving a truck, takes basically no attention at all. You have to watch out for signals every mile or two, and if one of them is red, you have to fiddle with some brakes. Things get more complicated if you’re running a steam engine, but not dramatically more complicated.

The distribution of required attention is different, too. A driving game requires a relatively constant amount, whereas a train simulator takes extra thought when you’re coming up to a signal: you have to squint through the window to see the thing, decide whether or not to brake, and then carry out the action of braking to stop where you want to stop. This is not conducive to paying attention to a second thing. (At least, not for me.) The human mind (or my human mind) is much better at handling two constant cognitive loads (such as driving and listening) than it is at handling one constant load and one highly variable load (such as listening and train driving).

Points, then, to the truck simulator.

Presents occasional challenges
It may perhaps be a result of Train Simulator’s demographic2, or perhaps it is a result of the inherent ease of driving trains3, but Train Simulator is easy. Nor is it only easy because trains are easy. Even the scenarios labeled ‘difficult’ (for example, using a tiny British tank engine to haul a rack of passenger cars up a hill, or using an enormous American gas turbine locomotive to haul a bunch of hopper cars up a different hill, and taking a steam locomotive low on water4 to its next stop) are straightforward. I’ve seen some people on forums complain about the difficulty of these precise scenarios, while I—a train neophyte if ever there was one—had no trouble whatsoever.

American Truck Simulator is also not all that difficult, provided you’ve driven a vehicle with a trailer before. That said, there are some places where it is honestly hard, mostly relating to maneuvering trailers in tight spaces, whether they be right-angle corners or narrow loading docks.

Again, points to the truck simulator.

Is immersive
Immersion is, of course, subjective, and I can see how it might go either way. For the particular games I’ve played (American Truck Simulator and Train Simulator with 2016 and 2017 routes), it comes to a coin toss.

I’ve done a little bit of driving in the American Southwest, and ATS gets that right on a reliable basis. Sunrise and sunset are also super-pretty, and the sound design is excellent. That said, Train Simulator’s Sherman Hill route also has things to recommend it, and in fact, the scenario I played there obscures one of Train Simulator’s biggest flaws.

Is pretty
This, unfortunately, is where Train Simulator falls down a bit. In terms of graphics and audio design, it lags far behind American Truck Simulator5. For a game in the Podcast Screensaver genre, visual and aural beauty are non-negotiable. The whole idea is that, while your brain is mostly focused on listening to something, you have a pleasant background scene to enjoy. If the background scene is ugly, then it all falls apart.

As I mentioned, there are moments where Train Simulator looks and sounds good. I was hauling a load of empty hopper cars up Sherman Hill at sunset. A rainstorm was overhead, but it didn’t reach the horizon, and as the sun went down, it lit the scene in a perfect gloomy orange. The sounds for the turbine locomotive I was driving were also excellent, lovely whirring, a bell which rang as clear as itself, and an air horn in the finest tradition of train air horns. Moment to moment, though, I give this one to the truck simulator.

As scored above, the final tally goes to American Truck Simulator, 3-0, with one tie. I should note that the difference is not quite so vast as I make it seem. For instance, the Unreal Engine 4-based Train Sim World, the next in Dovetail Games’ series, is extremely good-looking, and the sound design is just superb. That would pretty handily tip the balance in the ‘pretty’ and ‘immersive’ categories, and suddenly the score is 2-2.

Or is it? If you’ve looked at American Truck Simulator and Train Simulator on Steam, you’ll have noticed a certain crucial difference: price.

American Truck Simulator has a list price of $20. At press time, it’s on sale for $14. Going by European Truck Simulator 2, we might expect DLC prices in the $10-$20 range. Those DLCs massively expand the road network—ETS2 has DLCs for regions like France and Scandinavia—along with new cargo types, which are at least graphically interesting.

Train Simulator, on the other hand, seems bound and determined to extract as much money from its captive audience as possible. A small route runs $20 or $30, and I mean small. That’s about sixty miles of track, generally without any branches off the main line besides sidings. (Some routes, however, do give you a little more for your money. Sherman Hill has two routes over the hill.) You get one to three locomotives and a few types of rolling stock, and that’s it.

In this genre, repetition is bad. The world ought to be big enough so that by the time you see scenery again, you’ve forgotten what it looks like. If the world is small, it should be cheap to expand. Train Simulator has neither quality. American Truck Simulator has both. Buy the latter.

  1. There are evidently two classes of people unlike me: those who can simply sit and listen to a piece of audio-only content, and those who can multitask effectively enough that they need not focus primarily on a piece of audio-only content. If you’re one of those sorts of people, and you still like transport games, please drop me a line as to why.
  2. Let’s face it. On aggregate, train simulator fans are, well, old.
  3. The only major challenge is learning braking distances. Working out how to keep steam up in a steam locomotive is an additional challenge. Otherwise, it’s a vehicle which travels in one dimension, and navigation is done for you at the switching office.
  4. Well, not so low that you can’t make it if you don’t know how to use the water troughs the scenario tells you to use. Which I didn’t. (Neither knew how nor did use.)
  5. At press time, the next iteration in Dovetail Games’ train sim series, Train Sim World, is in preview-beta. Built on Unreal Engine 4, it appears to be quite a lot prettier, and a lot more sonically pleasing, than Train Simulator 2017, which is built on an eight-year-old engine.

Random Carrier Battles: what’s in the prototype, then?

Yesterday, we spoke briefly of what’s getting left out of Random Carrier Battles’ first playable prototype. Today, we’ll cover the happier side of that story: what’s in!

UI stuff
I have some informational interface tasks to take care of, to allow players to view task force members and elements of air groups. I figure to stick this on the left side of the main UI.

Some aircraft design improvements
I believe I’ll need to make some tweaks to aircraft and escort design, to specify quality of armament: the early use of the TBF Avenger was hampered by the poor quality of the Mark 13 air-launched torpedo, and I can’t capture that in the system as is. Similarly, British battlecruisers, German pocket battleships, and Yamato aren’t well-captured by the system as is. (Battlecruisers, in this framing, would be heavy cruisers with good guns; Scharnhorst would be battleships with poor guns, and Yamato would be a battleship with good guns.) Although surface combat is out of scope for the initial prototype, I want to have enough data to do a passable job at it when I come to it.

I may also have to make radios a feature of airplane design, so that types with historically good radios can communicate better than types with historically poor radios.

Aircraft handling: repair, fueling, arming, launching, recovery
Aircraft handling is a big focus of Random Carrier Battles: more than previous games in the carriers-at-war genre, I want to get down into the weeds. I want to track aircraft status to a fine-grained level of detail, down to how far along arming and fueling have progressed, or how warmed-up the engine is. On deck, I don’t think I plan to track exactly where planes are spotted, but I may do some tracking of takeoff run available—this would penalize light aircraft carriers with large air wings by preventing them from launching everything in one go, which is, in my view, a feature.

In terms of discrete development tasks, I’ll have to figure out how to turn a designed air group into an air group instance in the game world, build systems to hold air operations status and control transitions between air operations states, and build UI to control it all.

This feature will also lay the groundwork for land-based airfields, as well as seaplane tenders and seaplane-carrying cruisers.

Air combat!
Making this one heading is perhaps a bit ambitious on my part, but there you are. Air combat has a bevy of subordinate features, including representing armaments (to give damage) and ship and aircraft systems (to take damage), a planner for missions, and unit combat behavior AI.

Systems and armaments are the easiest of the bunch; they merely involve defining a set of systems for each class of asset, along with a set of armaments generated from the asset’s statistics and arming status.

The mission planner is a complicated feature, and one which I hope will be industry-leading: a central clearinghouse where admirals can view all missions currently planned or in progress, create new missions, cancel unlaunched missions, and eventually, handle every air operation in the task force. For now, it may fall to players to prepare the aircraft assigned to missions on their own initiative, depending on how the aircraft handling features shake out.

Finally, combat behavior AI: this is by far the biggest feature under this heading, and the hardest to handle. It includes automatic marshaling of air groups (players won’t have direct control over aircraft in flight), CAP behavior, scout plane behavior, strike planes’ flights to their targets, and attack behavior for dive bombers and torpedo bombers. Ships will also have to maneuver under direct attack (that is, to avoid incoming torpedoes, and to throw off dive bombers’ aim).

Initial spotting and scouting
Spotting and scouting in their fullness will require a lot of work, so I’m going to build a simpler system to start with. Simply put, you can see everything on your side, and anything within horizon range of your ships and planes.

Submarines will come later.

That’s that! I hope you find these plans as exciting as I do. I hope to get the demo to a state where I can take some usable screenshots and videos and submit to Steam Greenlight, at which point I’ll be hitting you up for upvotes.

Random Carrier Battles: the road to a playable prototype

Good afternoon, and happy Thanksgiving! While sitting here watching the turkey and the giblet broth, I had some time to work out a little roadmap for taking Random Carrier Battles from its current state, barely above proof of concept that the Godot engine is suitable for this purpose, to a playable prototype (if one that doesn’t capture my full vision).

So, to get the ugly out of the way first, let’s talk about what I’m leaving (for now) on the cutting room floor.

Wind and weather
Though they are crucial parts of aviation, they’re incredibly complicated, and I want to do them right the first time, rather than hacking something together now. With modern processors and multi-threading, I can push weather simulation into the background and only update every few in-game minutes, which leaves me lots of time to try interesting simulation techniques. ‘Interesting’, as I said, is a synonym for ‘hard’, and so I won’t be exploring these yet.

Land-based air
It may turn out that the mechanics of land-based air—launching and recovery—is a freebie based on doing carrier-based air. If it isn’t, though, I’ll tackle it later, along with design for land-based types like multi-engine bombers and flying boats.

Full visibility and spotting system
My plan for Random Carrier Battles is to attempt to capture just how blind carrier admirals were a lot of the time. Enemy positions will only be known by spotting reports, and allied air positions will only be known with full precision when they can be seen from friendly task forces. All of that will require a detailed system for spotting and visibility, and a system for displaying and archiving spotting reports. It’s less straightforward than it sounds, since the AI (when that arrives) will need access to that information for its fleet. Speaking of…

Artificial intelligence
I may provide some sort of rudimentary AI, but I may also leave it more or less entirely to scripting, or give the computer perfect knowledge. Don’t expect anything amazing, at any rate.

So, what does that leave to do? Nothing less than the core of the game. Come back tomorrow or Saturday for details!

Random Carrier Battles: kinematics and scale

I spent some time the other day playing the old-school DOS version of the current state of the art in carrier air warfare simulations, SSG’s 1992 classic appropriately entitled titled Carriers at War. As far as DOS-era wargames go, it’s pretty good—it doesn’t bother you with too many details, and it (largely) lets you focus on the grander strategy. I really blew the Battle of Midway as the Americans, though.

So, let’s talk about a way in which I hope to improve on the old classic: movement. Carriers at War plays out on a 20-mile hex grid; Random Carrier Battles currently tracks positions down to 10 meters; rather than a five-minute time step, I use a six-second timestep (organized into ten steps per one-minute turn) for movement and combat. This lets me do all sorts of fun things which 1992’s processing power did not allow, which I’ll get to shortly. It also causes me a great deal of trouble, which I’ll gripe about first.

The short version is, the kinematics are hard.

The slightly longer version is, there’s a lot of math involved in working out just how game entities ought to move. Warships aren’t much of a problem, because it turns out that warship maneuvering is pretty straightforward1. Aircraft, however, get a little tough. Not only do I have to consider everything I do with warships, I have to account for performance differences at altitude, as well as rates of climb and descent beyond which aircraft must either decelerate or accelerate. I don’t have the design fully worked out for that yet, I’m afraid, so I can’t say much more yet. Rest assured it’s complicated.

So, what does that enhanced positional and temporal resolution buy me above Carriers at War?

Better simulation of strike range
This is the biggest win, in my opinion. With such a high temporal and positional resolution, I can simulate fuel consumption to a much greater level of accuracy. As such, I don’t need to limit myself to Carriers at War’s fixed strike ranges2. The TBD, for instance, gets a with-torpedo range of 90 miles. I’ve seen other figures give a combat radius of 150 miles, and still others give a range (not radius) of 435 miles with a torpedo. By tracking fuel, I can, to some degree, ignore the trickier combat radius figures2, and simply grab a plausible cruise range figure. If I mix in some reasonable modifiers for speed, altitude, weight, climbing and descending, and maneuvering, suddenly I have a system which doesn’t need to work with combat radius at all. Players can launch strikes well beyond range if they want to; they just need to know that they’ll have to either deal with losing planes to fuel exhaustion, or follow the strike with their carriers.

Realistic combat behavior
The level of detail in kinematics, and the short time step, lets me make emergent some behaviors which might otherwise be the result of dice rolls. For instance, are Devastators running in on your carriers? Turn away from them, and the slothful American torpedo bombers will have to chase you, running their fuel down and exposing them to the depredations of your CAP and your escorts’ AA. Dive bombers rolling in on you? Throw the helm hard over to throw off their aim.

Many of these behaviors can be made to happen automatically: ships under dive bomb attack will make evasive turns on their own, for one. I haven’t yet decided which behaviors will end up being automatic, and which will be tactics set up by the player, but my aim is to do the low-hanging fruit for the player.

A notable exception to the above model is air combat: my current expectation is that the six-second combat step will prove too large for air combat (and relatedly, that emergent air combat behaviors will prove very complicated to code), and that the best way to handle it will be to put planes into a furball object inside which combat is handled in an abstract manner.

Exploration of unexplored formation options
Allowing the player relatively detailed control over formations, and keeping track of positions in similar detail, allows players to try some unusual tactical ideas. For example, the Japanese were not in possession of shipboard radars until fairly late in the game. What if, in some hypothetical battle, they detached some escorts from the main task force to make a search line a few miles toward the threat? Perhaps they could better direct their CAP to meet incoming threats.

That’s only one example. Undoubtedly there are others which haven’t occurred to me yet.

Those are at least a selection of the benefits of an approach with a greater focus on direct simulation, as opposed to a more traditional hex and counter approach. We’ll see how they turn out.

  1. At least to the fidelity I plan to simulate. There are lots of fascinating behaviors when you introduce multiple screws into the mix, but given that Random Carrier Battles is still, at its essence, a game of task forces, I don’t intend to allow players to give orders that detailed.
  2. The reason they’re so fiddly is that nobody ever talks about their assumptions: what load, exactly, constitutes a combat load? Is range deducted for reserve fuel and the time spent forming up? Are allowances made for maneuvering over the target? These are three of many questions left unacknowledged by most authors of military references.

Announcing Random Carrier Battles

Coming soon, or at least at some point down the line, from the Softworks division of Many Words Press, Random Carrier Battles:

random carrier battles main menu

Random Carrier Battles is a computer wargame simulating aircraft carrier warfare at the operational level between the mid-1930s and the end of the Second World War. It features a user-friendly design system for carriers, escorts, and aircraft, along with a large library of predefined types for your convenience. Planned features include a scenario editor and a random scenario generator, along with some premade scenarios covering major battles in the Second World War.

If you listened to Episode 12 of The Crossbox Podcast, you’ll remember my goal for the design system: create something just complex enough to adequately capture the different schools of carrier design in the era in question.

random carrier battles design

In scenarios, the player fills the role of the admiral in command, controlling the composition and disposition of the task force or task forces under his control, as well as the tempo and target of air operations. Hands-on admirals will be able to control aircraft handling down to the individual plane aboard their carriers; big-picture admirals will be able to delegate those to the computer.

Both kinds of admiral will have plenty to sink their teeth into strategically: Random Carrier Battles will accurately model the uncertainties inherent in carrier warfare, including incorrect spotting reports and communications failures, incomplete information about enemies, and lack of direct control over aircraft.


Obviously, this project is still in its infancy. I’ll be blogging about the development process here (at least until it’s far enough along for its own website), and sharing more screenshots and videos as things progress. Stay tuned for more information in the months to come!