I like SF. I like wargames. I like naval adventure fiction.
These tastes put me square in the middle of the target audience for
David Weber’s Honor Harrington novels. And yes, I do
enjoy them; Weber may be a hack, but he’s a very competent hack who
delivers good entertainment value for my money. So I was pleasantly
surprised to learn, this weekend at the annual Philadelphia Science
Fiction Convention (Philcon), that there is now an Honor Harrington
wargame — Saganami Island Tactical Simulator (SITS).
Weber started out as a game designer writing novel-length
game tie-ins before launching the Honor Harrington books in the early
1990s. In retrospect, it’s a little surprising that an Honorverse
wargame didn’t get produced ten years ago. There has long been a
flourishing genre of wargames that simulate 3D space combat;
Star Fleet Battles, set in the Star Trek universe, is
perhaps the best known of these. A tie-in to the Honorverse should
have been a natural.
On the other hand…most tactical space wargames are junk. As much
as I enjoy SF and wargaming, I can’t stomach a game that (as so many
do) just blithely handwaves away the actual physics of space combat.
Another deeply annoying flaw of most space wargames is that, though
space is a 3D maneuvering environment, they tend to have at best
rather poor support for modeling 3D movement and tactics. You end up
with games that are essentially 2D naval maneuvering with a thin and
patchy SFnal veneer.
If all I’m going to get is 2D maneuver with funny-shaped ships, I’d
really rather play a Napoleonic-era naval wargame like Wooden
Ships and Iron Men or Close Action — one
that sweats the details, that tries to get cannon ranges and
wind-driven movement right. And in fact I have a lot of experience
with such games. In general, I find they reduce space wargames to the
status of unsatisfying shams by contrast.
So I am pleasantly astonished to report that SITS (or rather, the
earlier Attack Vector Tactical game it’s based on) is a
true breakthrough in 3D game design. By use of an ingenious bit of
shaped plastic called a tilt block
, SITS ship miniatures can be
placed with an 0, 30, 45, or 60-degree increment of roll or pitch with
respect to the game table. The movement and firing rules use charts
that hide a lot of 3D-geometry and spherical trigonometry under an
easy-to-use interface.
Thus, you can really do 3D maneuvering in this system — and I
did, in fact, in a demo game that pitted two Havenite
Sultan-class battlecruisers against a Manticorn
Star Knight-class heavy cruiser. The system reproduces
the feel of Honorverse battles from the books extremely well, even to
the point where it models the attrition of missile salvos by several
layers of defenses from countermissiles down to sidewall. We even had
one of those explosion-wreaks-havoc-on-the-Manticoran-bridge scenes
Weber likes so much happen quite naturally.
Unlike most Peep division commanders in the books, I knew how to
use my tonnage advantage effectively — in this case, “Never mind
maneuvers, just go at ’em”. And the Manties didn’t have Honor
Harrington on the bridge pulling miracles out of her butt. So this
time, the good guys lost.
It’s a sign of good design that I was able to apply the tactics
that are supposed to work in the Honorverse books and get the
notionally correct result. I was also impressed by the fact that the
designer, Ken Burnside, modeled physics so carefully in his ruleset
that there are explanatory sections describing the heat-dissipation
equations he used.
Yes, there is a certain amount of handwavium and unobtainium in the
game system — the Weber books are space operas, after all. But Ken
(who I met and got to talk with) keeps the McGuffins to the bare minimum
necessary to capture the feel of the Honorverse. For me, this painstaking
effort at verismilitude makes the whole system far more enjoyable.
The only criticism of this game I have is that it is too
complicated to be accessible to most casual or social gamers. While
Ken Burnside’s components do a tremendously clever job of simplifying
your tactical information management, the game domain is irreducibly
complex and it shows. Personally, I relish that as a challenge, but
undeniably this game is not going to be a hit with the
beer-and-pretzels crowd. Only serious gamers need apply.
For those serious gamers, the rewards will be large. SITS aims
both to break new ground in realistic tactical space wargaming and to
capture the drama and feel of the Honor Harrington novels. It
succeeds at both these objectives, combining them with a panache I
would have thought impossible until I saw it. Kudos to Ken Burnside
and Ad Astra games for a truly superb design, which I hope and believe
will permanently raise the bar in space wargaming.
(Note: when I told Ken Burnside I was likely to plug SITS on my
blog, he asked me if I did so to add the caveat that Attack
Vector Tactical is temporarily unavailable due to production
constraints. I gather they’re having to work hard just to keep up
with the demand for SITS.)
Ingenious bit of plastic? Wow, and I thought it was a videogame up until that point. Brilliant.
Tabletop nerds are like that; the game worlds are real to them in a way that matches or exceeds the environments in videro games. A few years ago I was listening to some otakus discuss the vicious attacks they were dealing one another in a battle game of some sort; I thought it to be some fighting game or RPG on the Playstation but it was in fact a collectible card game with an anime theme.
Myself, I could never get into it that greatly.
And here I thought Trivial Persuit had the ingenious pieces of plastic.
I, too, had thought that SITS was a computer game from hearing about it on Usenet.
How do they handle compressing the often many hours of one Honorverse space battle into a timeframe that results in a playable game?
Jay, SITS is designed for single-ship duels and small-squadron actions. These don’t tend to be as protracted as fleet engagements.
I personally don’t like this game.. I have gone through several demos by the author.. before and after he got the Honor Harrington licences..
The extra realizm just slows down game play.. as much as he had tried, the mechanics still get in way.. and you end up thinking to much about the system.. and not the problem of space combat.
SITS and AV:T are not for everyone. (I’m the guy who was telling ESR about it, and called out “Ken, your target audience just arrived!”) That having been said, I’ve been watching Ken from the beginning of this project, and he is committed to doing a playable, physics-oriented game. In that regard, he has suceeded admirably.
Minor corrections to the above:
Tilt blocks and box minis allow you to show angles at 0, 30, 60 and 90 degrees of inclination, not 45 as described. Stacking tiles show altitude levels.
Also, while I’m not the first person to do 3-D space combat (BattleFleet Mars, Moondragon are two others), I’m probably the first to try it in a very long time. (BattleFleet Mars is dated to the late 70s, Moondragon went off the market in less than a year.) Paragraph 2 of the original entry reads:
==
There has long been a flourishing genre of wargames that simulate 3D space combat; Star Fleet Battles, set in the Star Trek universe, is perhaps the best known of these. A tie-in to the Honorverse should have been a natural.
==
I suspect Eric meant “2D” space combat.
>I suspect Eric meant “2D†space combat.
It’s been a long time since I played or saw Star Fleet Battles being played. I thought I recalled that it had a crude altitude mechanic. But perhaps I’m confusing it with a different game.
Ghu. I played Battle Fleet Mars when it came out in the ’70s. I’d forgotten all about that.
Oh, and BTW…I was thinking about the tilt blocks, and I think it might be possible, with some alteration of the shape, to make them stackable so you could actually use them as altitude spacers. Had this occurred to you?
Having played BattleFleet Mars, I’m not sure “forgotten” is the best adjective for not recalling it. It illustrates, beaufifully, why the “easy and straightforward” approach doesn’t work for 3-D. Anything that has you correlating your movement on two different maps rotated at 90 degrees is 30 degrees…but playable it is not.
SFB has no 3-D component – the standard joke is that adding 3-D would be in the “Heat Death Of The Universe” edition. Starmada has very primitive altitude rules that add so little that nobody uses them.
The stacking tiles use base-4 numbering behind the color coding based on a proof from a comp sci professor at UW Madison about expressing the widest range of values with the smallest number of tokens in the smallest number of types of tokens…and are as short as they are because making them taller made them too expensive for me to put enough of them in the box. Plus, they get awkward to game with when the altitudes go too high.
We are planning on using the 3-D system (sans the record keeping and proportional movement) to bring 3-D to the “run lots of ships” end of the market with a product tentatively titled Squadron Strike!
A question to Ken and ESR, What about the RPG Traveller, the New Era (Last of a long line of the original traveller game system) and its compainion piece Fire Fusion and Steel. If you could get the license to that material would it be suitable for creation of a 3D tactical space combat simulation?
Oh and to esr, I am also a big fan of Wooden ships and iron men.
Bob Childers:
I’ve talked to Marc Miller about licensing terms for the Traveller universe. It’s something I can afford, but there are other licenses that will make me more money, faster, and with VASTLY less heartburn. (I’ve read the Traveller mailing lists…). Adapting AV:T to any SF setting boils down to crunching numbers for game scales, and writing new weapon tables. Doing so requires some careful consideration of setting appropriateness.
However, I suspect the question you’re really asking is “I liked being able to make my own ships in Fire, Fusion and Steel – could I use Attack Vector to do the same thing?”
The answer is “Yes, but not really.”
One of the “every 2 weeks” questions is “When will you release the ship design rules for AV:T?”
My answer is “I won’t, because the process is manifestly unsupportable for my company.”
Were I to publish the ship design setup, I would be inundated with requests to make rulings, clarify intentions, fix imbalances, and otherwise get swarmed by demands to support this – rather than writing new products that keep me in ramen and peanut butter.
The ship design spreadsheet for AV:T is arcane – over 8 MB unzipped. This spreadsheet has been proven to crash OpenOffice 100% of the time after spending 4 hours on high end systems trying to open it.
Furthermore, it has, built into it, a lot of setting-specific assumptions about limits on material science, moment arm calculations, radiation tolerances, etc. (When you get down into the weeds, Traveller’s tech assumptions and materials science assumptions are really based on “Yeah, that looks about right…”) or just random guesses, or picking a number to make the game work.
That’s the easy part of it.
Making a working SSD (Ship Systems Display) requires lots of time with a vector graphics tool.
However, Squadron Strike (mentioned in my prior post) is designed SPECIFICALLY for a “design your own spaceship” modus of operation, in 3-D. It is not limited to realistic physics, as AV:T is, and is somewhat more abstract/low information density.
Ken, Thanks for the response.
Although I do like the build your own ship aspect of FF&S, I was more interested in your evaluation into useing the material as a framework for a combat system. Where its strengths and weaknesses were, etc. You didn’t go into the detail that I was hoping to get, but you did answer my question. And yes I do know that they did do some speculation and provided rules for tech that just wouldn’t work in the real world (thrustless drives is the first that comes to mind). It just happend to be a system that I was familiar with and wondered how usuable it would be outside of Traveller. Inside traveller I was just happy to finally see them give a comprehensive system from ground combat all the way to space combat. To me at least it was a big improvement over the original ruleset.
I can also appreciate why you wouldn’t want to be flooded with tons of requests to expound on a set of ship design rules. After all people can get very pasionate about a system that they like. Also having played in different systems over the last 20 years or so, I know how much gamers like to argue rules.
So yes your decision makes a lot of sense. I hope you do well with your games and hopefully I will get a chance to pick up a copy and take it for a spin.
OK, to answer your explicit one:
AV:T focuses on space combat – we’re trying to use the same tech assumptions for ground combat.
FF&S, in some ways, tries to do too much, but there’s more than enough there to do a Traveller variant for AV:T if you have both rules sets.
Where they differ is that I ask for a fair bit more detail on what a ship is made out of, how much of it is fuel, where weapons are actually placed, what arcs they cover, how far away the drive has to be to keep the rear of the ship from getting irradiated to heck and gone, and similar details, most of which FF&S just sort of hides under the deck plates. (For example, one optimization parameter is trading off thickness of the base plate of the engine (made of lead-doped concrete), and mast length, trying to minimize engine mass while also minimizing moment arm for pivots; this also factors in the overall length and diameter of the main hull of the ship.)
Ken, you say that large spacer blocks make it too awkward when altitudes get large. But the way my brain works, the closer the ship placements are to being in an isotropic 3D space, the better I’m going to do with tactics. So for me there’s at least some reason to pay that awkwardness cost.
Oh, and would you please resend your terms for shipping those PDFs? I seem to have mislaid them.
Dang. I wish I could be in on the playtest for Squadron Strike.
(I playtest things for Steve Jackson occasionally.)
Eric – if you want taller spacers, there’s an easy way to get them.
Pick up several copies of the Milton Bradley game “UpWords”. I used an UpWords tile as my template for the stacking tiles, and they nest perfectly.
I have found that there is an adaptation period for people to get used to stacking tiles (or, for that matter, making sure your SCC is lined up on the hex grid.), which is unavoidable, at least until we get holographic display units or something. :)
If you have time to get into playtesting Squadron Strike, send me an email.
Hmmm.
Thanks for the information. I’ll have to pick these games. A few years ago, before I got very ill with ESRD, I was working on a computer simulation of space combat in the Honorverse. Maybe I should revist that code, upgrade it and start working on it again. I’m pretty sure I’ve got it vaulted in my cd-rom code library though I’ll probably have to start over from scratch with these new rules.
Hmmm.
Then it shouldn’t be in a spreadsheet then. Or if the spreadsheet format is preferred then the data should be stored in an SQL database and the calculation functions packaged into an external object. and called when necessary. Frankly most of my experience has been programming Excel spreadsheets and not OpenOffice. I’ll download it tomorrow and check it out and see what functionality is built into it. But that’s how I’d set things up. With very few exceptions complex spreadsheets work much better when integrated with an SQL database and a computational layer.
As an example I wrote, a couple years ago, a Microsoft Excel spreadsheet that would query several SQL database and an ERP/MRP system along with the inventory and shipping databases. The purpose was to create a single POV spreadsheet that would offer the company’s CEO both a P/L sheet, Balance statement, Inventory status, production schedule, shipping schedule and expected inbound shipments. In essence it was a complete overview of the entire company’s status in financial, customer expectations and production. If I had tried to do all this in a single spreadsheet it would never have worked since I was dealing with processing, analysing and mucking around with a 15gb worth of data.
Please note that this isn’t a criticism, we all work with what we’ve got and I’ve very much have seen far worse with far bigger companies*, but in most situations spreadsheets like this tend to grow into a system rather having been designed as a system from the beginning. Generally issues like this are a clear warning to expect a redesign shortly.
* This was working for Ameritech in Chicago. Imagine my surprise when I found out that the Cellular Phone Division, where I worked, stored it’s customer information in Excel spreadsheets!!! One spreadsheet for every single customer. All of it completely unsearchable and extremely clumsy. I had wondered why there were 38 dedicated Excel spreadsheet servers…..
Ed – in a real sense, the AV:T spreadsheet grew out of “What tools I had at hand and knew how to use”.
Right now, the spreadsheet part of it’s done. (I think we want to be clever at showing one bit of information in the XML to make it easier on the parser).
It’s parsing the XML into PDFs that’s the bottleneck.
As to working on the Honorverse computer game, I regret to inform you that those are packaged rights with a price tag attached to them. My company does not own the rights, but we do know the people who do have those rights.
They have already sent cease and desist orders to two groups doing some work in that area.
Should I ever have the development budget to do it…
Hmmm.
Yeah that’s pretty much how it all works out in the corporate world. :) I looked at OpenOffice, downloaded it last night, and a prelim survey shows that it does seem capable of the same sort of architecture. I.e using a spreadsheet as the GUI while incorporating form elements, such as textboxes, buttons and dropdownlists, into dialogs, windows and right onto the spreadsheet itself. The Calc Basic doesn’t seem to much of a stretch though the syntax, as always, is slightly different enough to be an irritant. OpenOffice also allows the creation of data links to external SQL databases and to, surprisingly, external XML and even HTML data sources.
So it would be possible to employ the standard Office architecture of Calc -> GUI elements -> external functions -> SQL data.
If you ever want it cleaned up and/or implemented in such a fashion let me know. The best way would be to take and create a working prototype that incorporates all the needed functionality without having the exact data you’re using. This way you can protect your data while providing only the general range of values. I.e. is this specific dataset unsigned or signed. Is it alpha or numeric. Is it covered by a short integer or long integer. Or is it a float or double. Etc etc. Then build in a data entry interface to allow for entry of the actual data. This is usually how I did it when dealing with extremely sensitive data.
I see. Well I work with PDFs a lot. If I thnk of a solution I’ll certainly let you know.
Pity. I think at one point I had permission, very informal, to give it a try but that was quite some time ago before I got very ill. *shrug* in any event such permission isn’t a big deal for me as I hadn’t intended to either publish it independently or try and sell. I had actually intended to use the exercise to upgrade my knowledge of Flash. Right now I’m working on internet based applications, using Flash MX 2004 Prof/ Flash v8, incorporating XML, AMF and webservices. Though I’m still interested in writing a Flash 3D game so I might either take the time to create my own 3D engine or just buy one premade and then just goof around with creating a Flash based 3D tactical simulator.
The interesting aspect of doing something like this would be to actually simulate a fleet engagement in a multiplayer setting where each player can operate a squadron and where fleet and element admirals have to give out orders and have them obeyed. It would allow for very large battles whilst also simulating some of the confustion, fog of war and plain craziness of player interactions. Well at least that was my original design. I had also planned on a real time/automatic turn based sort of game system.
I.e the battles would be fought in a turn based manner, but that each turn would have a set max time limit whereupon the turn would cycle whether or not a player had completed all actions. This would take the game more into strategy rather than a twitch-type game and would provide for a great deal of complexity as players would have sufficient, but not all that sufficient, time to give orders and set tactics.
*shrug* I still might do it for my own entertainment even if I couldn’t ever publish it.
Have a nice day!
Hmmm.
Actually I’m rather curious as to how you do this now. Personally I use a open-source product called “Report Manager”, which I like very much.
Using this product I can either design reports, using the designer, or I can write a script to create reports on the fly, convert them into compiled report file and then execute the report and produce a PDF file. It’s a fairly simple process, particularly if you’ve got all the necessary data and you don’t need to query a database.
We use a perl script and xmlparse to filter the XML data through a postscript template to create the ship data sheet.
It works (partially), it’s being debugged, and the people doing the debugging are having life issues cropping up. I intend to spend some of the time between Christmas and New Years working closely with both of the people doing the code monkeying to see what we can get completed. It’s very very close to the point that, while not full featured, it can be exceedingly useful to me.
However, I are not a code monkey. Last time I studied a programming language, GOTO statements were considered really cool…
Hmmmm.
Sounds complicated. Frankly I generally prefer the really easy method, which affords me more time to goof off on these blogs. In the case of Report Manager I use this tool as both a report designer/writer and as a tool to create reports on the fly. Report Manager keeps it’s reports in a *.REP file that can be converted to and from straight structured text. And it’s a pretty straightforward structure at that as it includes data sources, connection strings, parameters and display/print elements. So what I do, in this sort of circumstance, is output my desired end product in the structured text and then use an included program “txttorep.exe” which then compiles the report and then I run “printreptopdf.exe”. No muss, no fuss and it’s pretty easy.
What makes it even simpler is that I can design the overall report using the designer and then poke in the specific data or elements that I want or I can store individual substructures in a SQL database and then assemble the reports on the fly. Plus the added advantage is that I can choose to not include fonts so my resulting PDFs generally weigh in at around 30k.
Example of a Report Manager substructure:
object TRpLabel1: TRpLabel
Width = 1155
Height = 225
PosX = 915
PosY = 0
Type1Font = poHelvetica
FontStyle = 1
PrintCondition = ”
DoBeforePrint = ”
DoAfterPrint = ”
WFontName = ‘Arial’
LFontName = ‘Helvetica’
WideText = ‘Ownership’
end
Basically Report Manager is written in Borland Delphi and the author uses these *.REP files to dynamically build the report as the *.REP file is loaded.
Personally I like XML a lot, particularly combined with XML-RPC or SOAP, but XML can often be a royal pain in the ass. Especially if there isn’t a specific requirement for interoperability with legacy systems or vendor/customer systems. Doing XML for XML’s sake is often an exercise is frustration, so I avoid it whenever possible and go for the simple route.
But then again, I’m lazy like that. :)
Don’t feel bad. When I first started programming computers arrived in the mail in a set of plastic bags. :):)
Hope it all works out for you. If I can offer any help, though I haven’t touched Perl in a (literally) a dog’s age, let me know.
The parsed postscript file is highly graphical in nature; lots of b-spline curves and vector art, lots of layered objects one atop the other, all conveying data by position, shape or color (or often two of the three..)
An AV:T or SITS SSD has a LOT of data on it; it looks cluttered if you don’t know how to read it. Once you know how to read it, the remarkable thing is how readable it is…
When I first pissed away an opportunity to learn programming, computers arrived in semitrailers and we never got to see them, and programs arrived in boxes bigger than today’s computers. And that was just the programs; I’m not sure if documentation had been invented yet.
Heh. This will quickly devolve into “Well, when I learned to program, all we had were ones and zeroes!”
“Piker. We didn’t even have 1s. WE had to write assembler in just zeroes! On screens that only had one color: Black. On black! And we were grateful!” :)
Think you had it bad? We had to rewire plugboards with our teeth. While the machine was running.
Ken, Cathy gave me a copy of SITS this morning. Not, it must be said, entirely to my surprise.
Hmmm.
Luxury!
When I first started programming we didn’t even have keys! Instead we had 8 di-pole switches and a button and had to program it one byte at a time!
Hehehe! :)
Eric: If you find typos, please send them to acehunter@gmail.com; he’s the official errata coordinator.
Or post them on my BBS in the relevant topic.
I now have components to assemble AV:Ts and SITS in Amarillo, and will be doing so in the evenings after worl.
Esr, could you put this in your Games section?