Author Archives: Fishbreath

OpenTafl v0.3.1.0b: spectator mode

Posted by

OpenTafl hit another major development milestone over the weekend: spectator mode! I believe that makes OpenTafl the first real-time-viewable location for online tafl play in the world.

I mentioned in one of my last tafls post that OpenTafl’s architecture has made many of these features extremely easy. Before I let you go today, I wanted to bust out the old object relation chart builder thingy and talk about what I mean.

This is the rough structure of OpenTafl, as relates to the actual play of games. The Game object (along with its children, not shown here) encapsulates the rules. It has methods to play the game: you can ask the Game object who is up to move, and give it a move (in the form start space, end space) to advance the state of the game. It also handles the game clock and a few other bookkeeping tasks.

The CommandEngine object wraps the Game object, and with objects of type Player, handles all the upper-level bookkeeping: sending events to the UI, tracking which player corresponds with the physical human player, and so on. Higher-level components host a CommandEngine object, and correspond to one or more of the Player objects.

When the CommandEngine wishes to notify a higher-level component that something has happened, it uses the Player object. The higher-level components interact with the CommandEngine primarily through the Player object, sending moves and receiving their results through that interface.

Let’s look at an example: a human player, playing a network game against an AI player running on a different computer.

Start with the human player. He’s sitting at the keyboard, looking at the in-game UI. He makes a move. The GameScreen on the screen has a CommandEngine. One of the Player objects is a LocalHumanPlayer, which the GameScreen uses to deliver the human’s moves to the CommandEngine. The CommandEngine delivers the move to the Game and gets the result. The move is good! Hooray! The CommandEngine takes the result and delivers it to the other Player’s opponentMoved method.

That Player is a NetworkClientPlayer. It has a reference to the ClientServerConnection which corresponds to the server, and its opponentMoved method is wired to ClientServerConnection’s sendMove method. The move goes out into the ether.

At the server, a ServerClient receives the packet. The ServerClient has a NetworkServerPlayer as its Player.The ServerClient sees that it’s a move packet, so it parses the move and calls the NetworkServerPlayer’s onMoveDecided method, which sends the move to the CommandEngine associated with the game on the server to which the client belongs. That CommandEngine sends the move to the Game, then gets the NetworkServerPlayer belonging to the other client and calls its opponentMove method. That NetworkServerPlayer sends the move to its ServerClient, which creates a move packet and sends it.

Now, remember that this client is an AI. Does that change anything? Not really! The move packet arrives at the client’s ServerClientConnection, where it is parsed and sent to the connection’s NetworkClientPlayer’s onMoveDecided method. From there it goes into the CommandEngine. The AI plays through a LocalAiPlayer, so the move result goes from the CommandEngine through the LocalAiPlayer’s opponentMove method. Finally, the CommandEngine tells the LocalAiPlayer that it is expected to move, and the AI begins its work.

You’ve no doubt spotted how easy this makes extra functionality. The CommandEngine doesn’t care how the player ultimately makes its moves; it only cares that the player eventually responds to waitForMove by calling onMoveDecided. As such, going from simple human-on-human play all the way to networked play with spectators has required zero major architectural changes. As I said last time, robust.

You may have noticed that I wrote about AI playing over the network. This is not yet implemented, but it is the remaining headline feature for v0.3.x. I hope to build a proper, headless AI-only client, which can be started and run in the background. Ideally, it will have these features: first, it can log in and create games, with or without a password. Second, it can be passed an opponent name on the command line to join and play automatically. Third, after playing, if it created a game originally, it should leave and create a new game. Fourth, it should optionally save records of all of its games on the machine running it, so curious AI authors can investigate how it played. The above behaviors should be controlled by command line switches.

Writing it out, I don’t foresee any of those features causing too much trouble. It should be available soon, and when it is, you can expect to see a few OpenTafl AI players on the intersect server at any given time.

OpenTafl v0.3.0.0b released!

Posted by

Well, actually, it was released on Thursday, but parvusimperator needed some space filled on Saturday, so here we are.

OpenTafl v0.3.0.0b is a major milestone release, as you can tell by the version number increment. It brings support for network play and, as far as I know, is the only real-time tafl game with support for a proper game clock built-in. From now on, there will be a server running at intersect.manywords.press, which is the default setting in OpenTafl. Selection of server is user-configurable, and anyone can run a server by using the –server command line option, and optionally –threads <#> to indicate how many worker threads the server should run.

In other news, OpenTafl now lives primarily at Bitbucket: you can find the link (and the link to the updated version) on the OpenTafl website. Bitbucket has a built-in bug tracker, so if you encounter any issues, file them over there1. The source will continue to be mirrored at the old Many Words hgweb instance, but those updates will lag by a day2.

Since I have a few extra days3 to write this, I may as well go into a little more detail on OpenTafl’s server architecture, for the curious.

For maximum scalability, the OpenTafl server does as much work as possible on a set of worker threads, which pull tasks from a priority-based task queue. The task queue has three separate internal queues: a high-priority, standard-priority, and low-priority queue. Tasks are preferentially executed from higher-priority queues, interleaving low-priority queues as necessary to prevent total starvation of the lower-priority queues4. When a client connects to the server, a client thread is created. This client thread has the sole task of taking incoming data and pushing it to a handle-communication task on the standard-priority queue. The handle-communication task in turn pushes tasks to the high or low priority queues.

On the server, clients can belong to no game, belong to a game, but remain in the lobby, or belong to a game and be in the game UI. The server sends lobby updates (connected users, available games) to clients in the first two states at regular intervals. Clients in-game don’t get lobby updates, to save on bandwidth and time spent sending lobby updates.

Finally, some player information is stored on the server: currently, usernames, hashed and salted passwords, and time of last login. The mechanism by which this data is stored is transparent to OpenTafl—hidden by an interface. Right now, the ‘database’ is a pipe-separated file. In the future, if I decide to go further in on the idea of server-side recordkeeping, it’ll be a fairly simple change to kick the file-database to the curb and swap in something like Hibernate+HSQLDB.

That’s where we stand now. Obviously, it’s subject to change, but generally speaking, I’m happy with it. Keep your eyes open for spectator mode and headless AI play.

1. Over there, over there…
2. Or possibly longer, until I get the cronjob working right.
3. It’s a musical tafl post, evidently. You’d better believe that my wife and I always sing ‘Extra daaaaaay!’ whenever we have reason to say ‘extra day’ now.
4. Or so it is planned. My current implementation behaves like this under light loads, but inverts its behavior at the worst possible time: as the queues begin to get busy.

OpenTafl v0.3.x: The Networkening Begins

Posted by

The time has finally come. OpenTafl v0.3.x is officially under way. You can find the ongoing changes to the source code at the Mercurial repository. I’m going to spend this post talking a little bit about the structure and organization of the OpenTafl server.

First: I decided that a thicker server was the way to go. Peer-to-peer networking is almost always more trouble than it’s worth for things like this, and OpenTafl shouldn’t be all that resource-hungry. So, the OpenTafl server will maintain the authoritative version of each game, and the authoritative version of that game’s clock. OpenTafl uses TCP instead of UDP; OpenTafl doesn’t run a lot of network traffic or need particularly low latency, and the guarantees provided by TCP are super-handy.

Second: I wanted a server which could easily be scaled up and down. Rather than work with Java’s default threading model for networking, which uses a reader thread per client to both read and do the work, I decided to write a priority task queue. Everything the OpenTafl server does, from parsing incoming communication from clients to updating the game clocks to distributing chat messages, is encapsulated in an individual task object. The task objects are pushed to one of three queues, corresponding to high, standard, or low priority. Higher-priority tasks are executed preferentially, unless there’s a large backlog of lower-priority tasks. This lets the number of worker threads be subject to user configuration. Finally, to distribute load, the OpenTafl server spreads out repeated tasks over a number of buckets in the period of repetition: clients get an updated game list every 30 seconds, by default, but only one in thirty clients gets the game list per second.

Third: Clients are expected to do some heavy lifting. The client gets a server clock update every five seconds, and has to maintain its own clock for display purposes in between. Although the server runs the authoritative version of the game, each client also keeps a full copy of the game. This lightens the burden on the server, which does a lot, and pushes it to the clients, who don’t do much, relatively speaking.

Those are the big features. I’ve run some successful tests over the past day or two, successfully playing out games over the network. I have more features to do before I can make an initial public release, but I expect to have one for you in the next few weeks.

Oracle v. Google: Apocalyptic Subhead

Posted by

Bringing you only the finest in topical writing, it’s your Soapbox contributors.

So, Oracle v. Google. First, some backstory. In 2009, Sun Microsystems, the creator of Java, was acquired by Oracle, Inc., Larry Ellison’s database outfit. At around the same time, Android was in the middle of taking off. (The HTC Dream/T-Mobile G1 was released in October, 2008.)

Android, of course, is the most widely-used mobile operating system in the world, and something your humble author works with on a daily basis. Developed by Google, Android has two parts: a low-level operating system, powered by Linux, and a framework running on top of it, written in Java. … but not exactly. Google re-implemented some of Java’s APIs, for reasons of developer familiarity. I’ll pause for a moment here and give you some metaphors for APIs, in case you aren’t also a developer.

At its most basic, an API (which stands for application programming interface) is a list of capabilities a certain piece of code exposes to the world. First consider a racing rowboat, with a team of oarsmen and a coxswain in the back. The rowers have a simple API: there is one function (sometimes called a method or a procedure) called ‘stroke’. The coxswain doesn’t necessarily need to know how the oarsmen row, but he does need to know that, when he says ‘stroke’, the oarsmen will all row at once.

Next, consider a car. It presents a slightly more complicated API: ‘go faster’, ‘go slower’, and ‘turn’. In modern cars, the API is implemented by the gas pedal, the brake pedal, and the steering wheel. In the early days of motoring, this wasn’t necessarily so: the Model T, for instance, used a very different control scheme. The important point is that both the Model T and a Tesla Model S implement the same API, no matter how different they may be in the details.

Finally, consider a dictionary. Say you invent a language and create a dictionary for it. Your dictionary is protected by copyright, but your language is not. US copyright law says that you can copyright expression, but not information or data. Your language is information, but the definitions in your dictionary are expressive, creative content. So, although your dictionary is copyrighted, someone can come along and rewrite all your definitions. By doing so, they have created a new work, and you have zero rights to it: they’re using the freely-usable data (the words which compose your language) that you have collated, and making new content where copyright would otherwise be an issue (the definitions).

So, what does an API entry look like in Java?

public String toString()

There are three parts here. ‘Public’ means that anyone who includes this piece of code in their own piece of code can ‘see’, and therefore use, the function. ‘String’ means that the function returns a value of type String. (A String is a piece of text.) toString() is the method name. (There is a fourth part; the parentheses enclose the arguments, the information which someone who wants to call the function must send to the function. In this case, there are no arguments.)

An API is something like a mixture of all of those metaphors1. It’s a way to lay out the functionality of a piece of software, and functional works are generally not subject to copyright. On the other hand, an API is also a description of the functionality of a piece of software, and descriptions (like dictionary definitions) can be copyrighted.

That brings us back to the matter at hand, re-implementations of Java. Two other projects with that aim predated Android: GNU Classpath and Apache Harmony. You’ll note that neither calls itself Java: Oracle, by way of Sun, owns the trademark for the term ‘Java’. Now, Java’s APIs are organized in groups called packages, which have names, for instance, like java.lang (core functionality in the Java language). Crucially, Sun never thought it could copyright those names. It could copyright the implementations: for instance, there’s a method called Math.max(number, number), which returns the larger of two numbers, belonging to the java.lang package. Its full address is java.lang.Math.max. Despite the occurrence of ‘java’ in the package name, Sun never asserted ownership over the structure of the API: it was broadly accepted in the software industry that API definitions were functional, not expressive, and therefore not subject to copyright.

In 2012, though, Oracle looked at Google and thought to itself, “Hmm. I want a piece of that sweet, sweet Android pie. How can I get my hands on that?” The answer? Assert copyright over the Java API. Oracle sued Google in the US District Court for the Northern District of California. The jury ruled that there was infringement, but hung on Google’s fair use defense. Rendering the jury’s verdict moot, Judge William Alsup4 additionally ruled that APIs aren’t copyrightable at all, under a certain clause in the Copyright Act5 which states that procedures, processes, systems, and methods of operation, among other things, are not subject to copyright. Oracle appealed to the Court of Appeals for the Federal Circuit, which overturned Alsup’s ruling that APIs are not copyrightable, and remanded the case back to Alsup’s court to hear arguments over fair use, which is where we are today.

Before I go on, I want to remind readers that, from a practical standpoint, I’m on Google’s side. I don’t think that APIs ought to be copyrightable, for reasons I’ll get into later. That said, having read Judge Alsup’s decision in the original case, and the CAFC’s decision overruling that decision, I think that the CAFC probably ruled correctly, exclusively as a matter of law, in Oracle’s favor. Oracle argued—convincingly—that, although a method like toString(), the example above, may not be copyrightable in itself, the arrangement of methods into classes and those classes into packages constitutes a taxonomy, which an earlier case found to be subject to copyright. In the same way that writing, “It was the best of times, it was the worst of times,” would not infringe on Charles Dickens’ copyright, but inserting the whole text of A Tale of Two Cities into this post would, copying a single method from an API is different than copying an entire API.

Unfortunately for the world of software, Oracle’s argument—that the organization of the API is expressive, and therefore subject to copyright—seems correct to me. There are infinite ways to organize an API, and deciding on one of those is an expressive process which takes creativity. Certainly, there are well-structured APIs and poorly-structured APIs, and there are no hard and fast, mechanical rules for how to design the former as opposed to the latter. An API is not like a general-purpose English dictionary, where there is only one reasonable arrangement for the words and definitions, the alphabetic and that arrangement is therefore purely functional. It’s more like a Chinese dictionary, where there is no purely alphabetical arrangement for the words. To arrange words in a Chinese dictionary, the dictionary author has to design a taxonomy or an arrangement, and that, again, is a creative process6.

Up until now, I’ve spoken of the law as it stands. How the law stands is, in this case, different from how the law ought to be. Although the organization of an API is taxonomic, and therefore subject to copyright, APIs need a special exemption. I’ll provide a few examples of products which, under the case law established by the CAFC, would be infringing.

First, and most ironic, we have… Oracle’s flagship database product. Almost every database in wide use today uses a programming language called SQL to manage and query the database. Oracle DB is no exception. Oracle did not, however, invent SQL: that honor falls to IBM, which created the language in the early 1970s. Oracle re-implemented it, evidently without obtaining a license, in the late 1970s, and SQL was not released as an ISO standard until 1986. Since Oracle was founded, and went through its initial growth, by infringing IBM’s copyright on the SQL API, IBM has plausible grounds to literally sue Oracle out of existence7.

Second, we have Linux, as well as all the GNU utilities. In the 1980s, Unix was an AT&T product, and antitrust judgements had forced AT&T to license Unix freely. When AT&T spun off Bell Labs, those judgements no longer applied, and Bell Labs began to sell Unix as a commercial product. The GNU project, and eventually Linus Torvalds, wrote clean-room implementations of the Unix kernel, which became Linux, which now powers the larger part of the Internet. Nokia, the owner of Bell Labs, can now hold the whole Internet hostage. (Fortunately, I doubt they will. Nokia tends to be pretty chill.)

Third, and most compelling, we have literally every non-Apple computer in existence today8. In the 1980s, IBM released the IBM Personal Computer, from which we get ‘PC’. Almost immediately after that, dozens of competitors released IBM PC-Compatible computers, which re-implemented the low-level API by which programs written for the IBM PC interacted with the operating system and the computer hardware. The presence of a de-facto standard allowed competitors to enter the marketplace, and as the PC market grew, Microsoft released MS-DOS and Intel figured out its own expansion card standard. When IBM tried to go proprietary, the consumer PC market—now almost entirely independent from IBM—moved to the Windows/Intel standard that has persisted to this day. Without IBM’s initial innovation, and the freedom of other manufacturers to re-implement IBM’s standard, we wouldn’t have the vibrant personal computer market we have today.

So, the law is wrong. We can’t fix that in this case. What can we do? Google is trying to claim a fair use defense, and may yet prevail, but I don’t want to speculate on the odds. Provided that APIs are copyrightable (and, right now, as a matter of law, they are), Google’s use was probably not protected by fair use. My read of the trial suggests that, in general, Google argued well and Oracle argued poorly. With any luck, the jury will agree.

What if they don’t? The result is bad for the software industry, but not as apocalyptic as some might claim. There is no copyright concern as far as using an API goes: that isn’t the issue at hand here. The issue is reimplementation, which is a driver of innovation and market expansion. We will likely see fewer products which are designed to take the place of other products, because such projects are now risky on copyright grounds, and depend on the good will (or free licensing) of the copyright holder.

We’ll also probably see a return to ‘not invented here’ as an objection to using open products—unless they were designed from the ground up to be different from other, existing products covered by copyright, the risk, for corporate entities, is too great.

Finally, it’s also bad for Java. Closing a platform tends to kill it; see the IBM example above. Even if that doesn’t happen, Oracle’s behavior here will undoubtedly have a chilling effect. Although I just said that this suit doesn’t have a major impact on day-to-day usage of Java, what it does do is demonstrate that Oracle is willing to push the boundaries of IP law in pursuit of a quick buck. If that’s the way they want to behave, they’ll have to deal with the consequences: people are going to run away from Java.

Fortunately, Google appears to have won, according to the news today. More on what that might mean after I read enough to synthesize an opinion.

1. My wife, who holds a seminary degree, often talks about heresies2 as regard the Trinity, and how most common metaphors for the Trinity end up espousing one of those heresies. My usual response is, “Yes, but there’s no such thing as a perfect metaphor; a perfect metaphor is just the thing you’re trying to describe.”
2. In the technical sense; that is, beliefs incompatible with lower-case orthodox Christian doctrine.
3. (There is no third footnote. I forgot to update the numbering when I removed it, and can’t be bothered to change it now.)
4. His middle name is ‘Haskell’, which the programmers and computer scientists in the audience will find amusing.
5. See here for more; you’re looking at section b.
6. To my knowledge, which is very limited, because I am not a lawyer, this has never been tested in a US court, but my feeling is that the arrangement of a Chinese dictionary would also be copyrightable. See this article and point 5 in this blog post for more on Chinese dictionaries.
7. Your author would watch that case.
8. I don’t know if Apple computers count here, so I’ll leave them out.

The Crossbox Podcast: Episode 7

Posted by

This month on the Crossbox Podcast, in the grim darkness of the far future, there is only one Warhammer 40K game we’re talking about. In other news, Jay recommends two things with the initials ‘KSG’, and John savages a childhood hero.

Further reading
How to win, FREMMs, and influence people
Lightning Squalls: John likes the F-35A
I promised a King Sejong the Great article, but I must be misremembering. Sorry.


(Download)

We Sail Off To War E-Book Releases June 11th

Posted by

War has broken out in the Confederacy of Allied Worlds, and it falls to the brave men and women of the Naval Arm to defend their country against the Exile fleet. Over the gas giant Argo, they are losing. With few resources and little time to spare, they must find—and bring to battle—an Exile armored cruiser which has terrorized the spacelanes for too long.

We Sail Off To War, a military science fiction novella by your second-most-prolific Soapbox contributor (me!) is available for preorder now, and will be released on June 11th. Visit Many Words Main for more information.

Luchtburg Responds: an IFV for the rest of us

Posted by

Parvusimperator is fond of a certain sort of infantry fighting vehicle: it should be big, heavy, share parts commonality with his tank, and transport a whole platoon of infantry. It may come as a surprise to you that this is not the only sort of IFV1.

The Hoplon, parvusimperator’s design, fits certain scenarios very well: your Golan Heights, your Fallujah, perhaps your Fulda Gap. Those sorts of scenarios are important, but in exchange for its superb performance there, the Hoplon gives up some other capabilities that other IFVs offer, and other IFVs can be nearly as good as the Hoplon in the Hoplon’s preferred field of play.

I’ve always been a BMP-3 fanboy, so we’ll talk about the Hoplon and Namer relative to the BMP-3. We’ll kick things off with the biggest difference…

Mobility
Otherwise known as the dreaded M word. The BMP-3 is the obvious winner here. Its advantages stem from its weight: fully kitted out, it tips the scales at less than 20 tonnes.

This means that it need not bother with complicated, failure-prone fording mechanisms. It can simply swim its way across a river. That’s right: it’s fully amphibious, which is an important quality for an infantry-carrying vehicle. Mechanizing infantry usually improves their speed of tactical movement while reducing their ability to cross or occupy rough terrain. An amphibious IFV actually adds some terrain-crossing ability: infantry can’t really cross or occupy a river on their own. More generally, a lighter IFV leads to enhanced tactical mobility overall: lower ground pressure means lighter vehicles can move across a wider variety of terrain, in which another vehicle might bog down2.

Enough about tactical mobility, though. There’s another kind of mobility where the heavy IFV concept falls down: the capital-M sort, Strategic Mobility. How many Namers or Hoplons can you fit into your C-130? Zero. How many BMP-3s? One! How many Namers or Hoplons can you fit into your C-5? One! How many BMP-3s can you fit into your comparable An-124? … six.

Now, airlift is not the be-all, end-all of strategic mobility, but, being the hardest part, it’s a good place to start. Certainly, airlift is the way you want to move your stuff when it absolutely, positively has to be there tomorrow. Being able to fit your IFVs into your smaller air transports, freeing up your big transports to move tanks, is a significant win for putting a mechanized force somewhere fast. You can get by with rail and road transport if you’re a purely continental power, but I would suggest that the world is too complicated a place for anyone to call themselves a truly, exclusively continental power.

A lighter vehicle is also somewhat easier to transport by rail: it doesn’t call for specialized rolling stock, whereas your standard flatbed rail car would be hard-pressed to stand up to a Namer-sized vehicle. Road transit is also easier, because of reduced road wear, and again, a lesser need for overspecialized vehicles.

Ship-based transport is a wash, but you can put just about anything on a boat. Hoplon or Namer don’t get any points for being easily transportable that way.

Armament
We should start by talking about what an IFV needs to do. Infantry are versatile, able to do almost anything on the battlefield; their vehicles ought to be too. This is why most IFVs have an autocannon armament. The autocannon can engage fellow light vehicles, enemy infantry, aircraft, and to some degree, dug-in positions. You’ll note, however, that tanks are not on the list. Although infantry armed with proper missiles represent a serious threat to tanks, IFVs, generally, do not: they don’t hide as well as infantry, and unlike infantry, they can’t spread out for protection against deadly point fire. IFVs equipped to defeat tanks are therefore so equipped for purely defensive purposes: anti-tank missilery is not a headline capability on an IFV. Ideally, your IFV won’t be in evidence when the tanks come a-knocking; that’s why you have infantry antitank teams.

On to the BMP-3, then. It does indeed have an autocannon: the 30×165 2A72, a variant of the 2A42 you might know from past Ka-50 posts. The 30×165 cartridge, while a little lighter than the NATO-standard 30×173, is nevertheless quite punchy, by IFV standards; the BMP-3 carries 500 rounds split between high-explosive and armor-piercing types. Little needs to be said about the autocannon. It’s an autocannon. Every ex-Soviet state and Russian arms buyer in the world uses this one. It works as advertised.

Next, though, the BMP-3 goes a little bit off-script. Mounted coaxially with the autocannon is a 100mm rifled medium-velocity gun. “But why?” you ask. “That’s way too small to shoot at a tank, and the autocannon is good enough, right?” Not altogether! You may recall the infantry tank from the Second World War: a bad idea, but one based on a germ of truth. Infantry don’t have a good way to deal with a really stout dug-in position. Launchers can help, but tend to be short-ranged and inaccurate. Mortars are nice, but they’re an area weapon. What the infantryman really needs is a good-sized, say, 100mm HE-chucker, able to keep up with him as far as terrain crossing, and able to bear rapidly on any intractable enemy defensive position. So, stick one on the IFV. The BMP-3’s 100mm gun is an infantry support gun, which is important tactically, but also logistically: it doesn’t have much in the way of anti-tank use, so what ammunition it carries is all for, y’know, supporting the infantry.

Which isn’t to say it has zero anti-armor use. It carries eight gun-launched missiles; although they won’t do much against a modern tank, they provide an extra-long-range punch against lighter enemy vehicles.

Three 7.62mm machine guns—one coaxial in the turret, and two bow guns, each with 2000 rounds of ammunition—round out the weapons fit.

What it comes down to is that the BMP’s armament is hyper-focused on its role as an infantry fighting vehicle. It doesn’t faff about with anti-tank weapons it should never have reason to use, if deployed correctly. It simply gets on with the business of employing every piece of hardware it possesses to defeat the sorts of enemies the infantry it carries is most likely to be facing.

Protection
We come now to a category where the BMP falls down a little compared to its HIFV competition, but really, of course it does. They’re literally tanks, with the tanky bits taken out and seats put in. It isn’t like I was somehow going to miss this one. I just don’t care, and here’s why you shouldn’t, either: doctrine. I gave three scenarios where the Hoplon-Namer school of IFV design excels: the Golan Heights, the Fulda Gap, and Fallujah. Let’s look at each one.

The Golan Heights, as parvusimperator mentioned, is probably one of the most featureless regions on the planet which is nevertheless worth fighting over. It’s flat, and there’s nowhere to hide. If the enemy can see you, the enemy can peg you with a missile. Now, if you’re advancing in proper combined-arms fashion, with your tanks and IFVs working in concert, what happens? They shoot at your IFV and it shrugs off the hit, or they shoot at your IFV and it dies, but either way, they aren’t shooting your tanks. The tanks are your true breakthrough weapon: IFVs are just there to deliver your infantry to hold the ground you’ve just captured with your tanks, and to provide some extra punch when they get there. Losing a few doesn’t matter; tanks are the bigger, juicier target, and a combined-arms advance against an ATGM-equipped position should rightly see most of the missiles headed for the tanks anyway.

The Fulda Gap presents different challenges. You (presuming you’re a Western power) are on defense. You’ll be facing tanks and IFVs pouring through the West German forests, but you have the edge: you get to dig in, which nullifies a lot of the survivability edge. Missiles mounted on the IFV are less of an advantage in this scenario, because your men can simply dismount and use their own ATGMs.

In Fallujah, the Hoplon’s edge is slightly more pronounced: it can eat an RPG shot from the front, and that helps when you’re turning a corner or going down a long street. That said, you’ve taken your armored fighting vehicle into an urban area. That is not a low-risk proposition. You’ll want a TUSK-style kit however heavy your IFV is: if Big Army and the United States Marines found that the Abrams needed specific upgrade kit to be safe and effective in cities, your IFV is going to need the same3. The single most important upgrade out of your TUSK kit is slat armor, which is lightweight compared to real armor, and will do a number on that most common urban threat, the RPG.

Beyond that, an autocannon and coaxial machine gun alone are insufficient armament for city fighting. Much better to have a 100mm HE-thrower, so you can bring down the front of a building in response to an RPG shot, and some independent machine guns, so you can hose down multiple targets at once.

Ergonomics
We come to the BMP’s weakest point: its ergonomics. Tank-based IFVs and APCs have cavernous internal spaces and proper rear exits. For some reason, the BMP-3 puts the engine where that rear exit ought to go, robbing the troops inside of both convenience and survivability4. Getting out of a BMP involves at least a little bit of climbing.

In this picture, you can see the troop compartment: once you go over the engine (the raised section beneath the opened top doors), you drop into the troop compartment, which is behind the turret. (The turret’s fighting positions are enclosed by the two white pillars.) Three seats are placed with their backs to the engine compartment, and two are placed on either side of the turret base. Two more jumpseats can be folded down between the three seats in front of the engine, but five is a good capacity estimate for troops carrying any real amount of gear.

To get in or out, you have to do one of two things: open the top doors and jump up onto the engine, or leave the top doors closed, and crawl out the back. Neither one is as fast as a traditional rear door, and the safest way—crawling—is much slower. If you’re willing to further handicap your exit speed, you can probably stash some gear on one of the crawlways, which might be handy if you’re carrying an ATGM team, say.

Really, though, the BMP’s design follows its ergonomics. It’s almost purely an infantry support vehicle, which can incidentally carry five infantrymen. I don’t know what the prevailing Russian doctrine is, but the BMP is not a good battle taxi. Its job, as far as carrying infantry goes, is to get them close to the battlefield, not reliably serve to move them around thereupon. Once the infantry has disembarked, preferably somewhere out of direct enemy fire, they can advance with the BMP in support. It can serve in the battle taxi role—it’s quick, has decent terrain-crossing ability, and can fit an admittedly small number of infantry—but that is not its natural home.

Luchtbourgish Advantages
The BMP requires some doctrinal modifications relative to your HIFV or HAPC: namely, in situations where it is likely to encounter tanks, it must be used in close concert with tanks, and in combat generally, the infantry should be disembarked earlier and fight their way to their stopping point, with the BMP providing fire support. Urban survivability requires specific urban survivability upgrades5.

These modifications may not be for you. I don’t think they’re for parvusimperator or Borgundy. Survivability in a limited area of operations is too important for his purposes. Luchtburg, however, is a different story.

The mobility of lighter IFVs, and the BMP particularly, meets a Luchtbourgish need. The country is mountainous, swampy, and filled with rivers. An IFV which can swim has a huge mobility edge over one which doesn’t: it can easily penetrate the Luchtbourgish interior where a heavier vehicle or a tank might get bogged down.

The armament fit is perfect, too: busting up a cartel camp in the jungle is tricky with infantry or lighter vehicles, because the drug lords have moderately heavy weapons; an IFV which can take hits from machine guns and grenades while dealing out heavy punishment in return is ideal for Luchtburg’s aggressive enforcement of anti-cartel laws.

Finally, air mobility is of critical importance. Luchtburg is an expeditionary power with global interests. The BMP-3 is easy to ship rapidly, which lets Luchtbourgish forces enter the fight faster, which helps protect Luchtbourgish interests worldwide.

  1. You’ll recall that parvusimperator also recently wrote on the Namer, Israel’s ‘IFV’, but that’s more properly a heavy APC, its own class. It’s designed to transport infantry in safety exclusively, not to provide added firepower on the battlefield.
  2. Heavy APCs and heavy IFVs (Namer and Hoplon) have tank-like ground pressures of 12-15 psi, ordinarily. Standard IFVs (the range from the BMP-3 up to, say, the unupgraded Puma) tend to be in the 6-8 psi range, which is approximately the range of a standing human.
  3. Unless you’ve bought Namer, but Namer is basically frontal-strength armor all around.
  4. Don’t get me wrong, putting the engine in front of the troops is bad for the engine if you take a hit, but it’s better to lose an IFV alone than it is to lose an IFV and everyone inside it.
  5. Surprisingly, I don’t think the Russians have any. I can only find one or two pictures of real BMPs equipped with slat armor. (ERA and active anti-missile systems are obviously out for a vehicle intended to operate closely with infantry.) The rest are kitbashes. Parvusimperator says the Russians were mostly concerned with plunging fire from tall Chechnyan buildings and mines, so they didn’t bother. Frontal and side-on shots are still plenty likely in lots of the world, though, so I stand by this recommendation. Or just slap ERA on and establish a minimum safe distance, though even the Russians aren’t quite that cynical. (The Americans have done this on Bradleys with good results in Iraq. -Ed.)

Kat’s new furniture: when a stock is not stock

Posted by

Last time, I said I would open this post with my precise optics choice. Here’s why I tried to put it off: my optic is an Aim Sports 4×32 ACOGalike. (ACOGalike is not the brand name; that’s just my description.) A quick note on Chinese-built optics: if it doesn’t have Primary Arms on it, you can’t trust it. If you roll a 12 or greater on a d20, it’s probably worth using; if you roll a 20 and 12 or greater on a second roll, then you might have a hidden gem. I hit about an 18 on mine: it doesn’t show the same issues as some other Chinese optics in my possession, but it’s inferior to parvusimperator’s proper ACOG in terms of optical clarity and low-light performance. So it goes. I can buy ten cheapo Chinese optics for the price of his one ACOG; at least one of mine is going to be usable.

Anyway, same optical characteristics as a Real ACOG, which means limited eye relief. Originally, Kat had a polymer stock in the same vein as the stock AK stock, except lengthened a bit for parvusimperator’s monkey arms1. You can see the issue if you look at a picture of an AK stock: it slopes somewhat downward, and my cheek weld, for a relatively high-mounted scope with short eye, ends up being a beard weld, since you find yourself in front of the actual comb. This is not ideal.

The solution? A stock with a higher comb. There are varied and sundry options here. After looking at several options, I chose the Magpul Zhukov-S. “A Magpul?” you ask. “Fishbreath, aren’t you a massive cheapskate?” Yes, yes I am, but at the same time, I recognize quality when I see it. Let’s count the ways the Zhukov-S is a good choice.

Number one: the comb is straight back from the receiver. This fixes my chin weld issue: the comb is high enough that I can properly place my cheek against it, while being low enough that it doesn’t interfere with over-the-ear hearing protection.

Number two: it’s a side-folder. This is not of critical importance, but there’s something about folding stocks on AKs that just feels right.

Number three: the build quality is superb. The folding mechanism feels durable and has positive locking in the folded position; in the extended position, there is zero rattle. It may as well be a fixed stock.

Number four: the attachment mechanism. Magpul has solved probably the largest open problem in AK customization. This one requires some further explanation.

An AK stock is secured to the receiver by two screws: one through the tang poking out the back of the receiver, and one through an internal tang in the receiver a little bit further forward. These are not for precision alignment: they’re there for retention only. The stocks are precision-fit2 to wedge into the receiver, which prevents them from wiggling. This requires a good bit of force, and a good bit of fitting on initial installation.

Magpul decided this was a terrible idea. They came up with two innovations to make the whole process almost painless. The first is their so-called ‘wedge block’. Looking at the stock from the side, the forward bit which slides into the receiver is cut diagonally, longer at the top and shorter at the bottom. The wedge block is cut the opposite way; putting the wedge block against the forward bit of the stock makes a square. A bolt holds them together, and when you tighten the bolt, the wedge block slides downward. This pushes the stock upward, and eventually, the wedge block and the stock have wedged themselves against the receiver, securing themselves against it without having to be made the same size as the receiver.

The second innovation is a keyed nut: oval-shaped instead of circular, it fits into a cut beneath the tang screw hole in the stock. Magpul provides a machine screw to fit the nut, so when you tighten the machine screw, it ends up centered over the nut, which is positioned at a defined point in the stock, yielding correct side-to-side orientation. So, unlike most AK stocks, the Zhukov-S goes on painlessly. All you have to do is tighten a few screws to hold things in place; no mallet required, and the end result is just as solid.

Is it perfect? No, not quite. I’d love some storage, especially since my optic’s illumination is powered by watch batteries, not radioactivity or natural light, and as far as I can tell, my options are limited to duct taping things to the outside of the stock. Nor does it have the classic looks I usually go for: it’s a tacticool accessory through and through. Although it has sling swivel points, it doesn’t come with any of the push-button sling swivels they accept, and for the money, I feel like a swivel would have been a nice extra. Finally, it is a little bit on the expensive side; at about $100, it’s the most I’ve ever spent on a firearms accessory which is not an optic.

Don’t let those critiques take away from the product, though: it’s certainly worth the money.

1. This isn’t entirely fair. The stock is NATO length. I just don’t like ’em that long.
2. In AK Land, this means they’re cut a little large, and you bang ’em into place.