This article originally appeared in issue 298 of 'Slingshot', the journal of the Society of Ancients.
For the past few years I have been developing, in my spare time as a hobby project, a computer game/simulation of naval warfare in the Age of Sail (which I have defined as from 1660 to 1815 (AD)). The emphasis is on the ships and battles of the Royal Navy and the game covers the period from the formation of the modern British navy up to the end of the Napoleonic wars and stopping before the advent of steam. The working title for the game is 'Heart of Oak' (though I have recently come across two other projects working to the same end and both using the same title, so I might have to change this!).
This is a hobby project in that it does not come anywhere near the levels of graphical sophistication that would be expected in a modern commercially released computer game - I have neither the time nor budget nor (crucially) skill to provide the sort of 'eye candy' demanded for real commercial games, so instead I have tried to concentrate on making the game reasonably historically accurate (hence the 'simulation' part of the description above). At the same time my intention has always been to produce a game that can be picked up and played without first having to spend years studying the minutiae of sailing and navigation, and as such the game is heavily simplified (or abstracted) in a number of areas, particularly ship handling and the sailing model. This allows the player to concentrate on tactics - both ship to ship tactics and squadron and fleet tactics, since the game handles fleet actions up to around 50 ships a side. For command and control, the player has direct control over his own ship, and sends signals to other ships and squadrons under his command (if any), using a set of signals broadly based on those in use at the time, without trying to accurately recreate any particular signalling system in detail (since they changed constantly throughout this period). This project has been in progress for a remarkably large number of years but is finally approaching something like completion.
All very interesting perhaps, but you might reasonably be wondering what this has to do with Slingshot. Well, I have been thinking for some time of adding oared ships to the game (necessary because galleys were still in use right up into the 19th C, particularly in the Baltic and Mediterranean), and once I have added the code and models for oared ships the obvious next step is to extend the game's scope right back from 1660 AD to, say, 3000 BC! So that is what I am working towards now - to use the underlying engine of 'Heart of Oak' to produce a similar game set in the Age of Oars, a game to which I have tentatively, if unimaginatively, given the working title 'Trireme'. I thought it might be of interest to Slingshot readers to hear about this project and some of the problems and considerations that come up as it proceeds, and to this end I have written this article as an introduction, and as time goes on, if the editor is willing and there is any interest, I may provide some irregular brief updates on progress.
Such a project usually starts with a survey of the opposition, to see what has already been done, what strengths and weaknesses previous efforts have, and if there are any good ideas I can make use of (or steal). In this case this did not take long, since there does not seem to be much in the way of existing computer games/simulations of naval warfare in the age of oars. All I could find is a game called 'Galley Battles' from Shrapnel Games (advertised in around 2005 but apparently cancelled unfinished), and the naval battle element of 'Rome Total War 2' from Creative Assembly. I have played neither of these (having been put off the 'Total War' series by the bugginess and silly, ahistorical gameplay of the first 'Rome' title) but they appear to represent the two opposite ends of the historical computer gaming spectrum. 'Galley Battles' appears to have been a top down 2D game, in effect an on-screen version of a traditional hex-and-counters board wargame. It sounds as if it would have had plenty of detail and historical flavour, but the high level of abstraction of such games seem to me to negate all the advantages of having the game on the computer. I have also tried a similar game from the same publishers set in the Age of Sail, 'Salvo' - which was fine so far as it went but again was really an on-screen boardgame. For 'Rome Total War 2' I have seen movies of in-game action that would be enough to make any hobbyist game developer give up in despair (especially one with only rudimentary graphics skills) - not in a thousand years of trying could I come within a million miles of the graphical quality achieved by the developers of the 'Total War' series. But graphics aren't everything, and my experience with previous 'Total War' titles suggests that while they have undoubtedly nailed the stunning visuals, it is likely that there are few historical lessons to be learned from such a game.
This brings me on to my aims in developing such a game myself. Obviously the primary aim is to have fun - and the fun is as much in the development, the act of creation, as it is in the playing - for every hour I have spent playing 'Heart of Oak' I must have spent ten on research, building 3D models, and coding, a ratio not wholly unfamiliar to miniatures wargamers, I suspect, given the time it takes to build and paint an army. But beyond that, I do also hope to learn something from these games, at least some feel for 'what it was like', and insights into the problems and limitations commanders of fleets of the time would have faced.
At the same time, I am developing a game, not a computer model - this has a number of effects on the way such a project is developed. For one thing, I am happy to abstract and approximate such matters as ship performance - there is now good data available on likely trireme performance from the sea trials of the reconstruction Olympias, and I will certainly feed this data into my game, but I will not attempt to create a perfect mathematical model of trireme performance, just a fair approximation, and for such questions as the performance of other ship types, I am happy to take a best guess. It also means that the approach is 'first person' (the player plays from the point of view of a trireme captain on the deck of his ship), and (for purely practical reasons) single player, with the computer AI taking on the control of the opposing fleet (and of the other ships in the player's own fleet). A computer model for research purposes would need to emphasise a top down view (so it is obvious what is going on), and have ships all under direct human control, so that it is possible to experiment directly with various events or tactics (I am thinking here of the various tactics explored by Andrew Taylor in Slingshot 277). My hope is that these sorts of events and tactics will arise during the play of my game, and I do have an optional overhead or top down view, but I am not primarily building a research tool, with all the rigour that would involve. My aim rather is a 'you are there' sort of entertainment, but one with a strong basis in historical fact, so far as it is known.
I am generally doubtful of the value of wargames for historical research, even in their most sophisticated guise as computer simulations, since so many assumptions have to be made at the outset about how ships performed and fought, for example, and these fed into the computer model; what comes out of the model is therefore more likely to be shaped by how the model was built and the assumptions underlying it as it is by any historical truths the model might have uncovered. Building the simulation is driven by the historical data, rather than the other way around. That said, in the case of a vehicle simulation such as this, there are facts about the dynamics of the real time interactions which might be better revealed by playing (or otherwise enacting) a simulation than by abstract theorising or study of the ancient evidence. Andrew Taylor's article referred to above illustrates this, revealing facts about close approaches and turning circles that would not be obvious without actually acting them out (even if only in spreadsheet form). From playing through trial versions of 'Trireme' I believe I have gained a clearer understanding of the interaction of fleets of oared ships than I could have gained any other way, in particular in such areas as penetration of a line abreast (diekplous) and circling and ramming (periplous). Caution is essential of course, in case the lessons learned are based on faulty modelling, but even so I think there is some scope for increasing historical understanding at least a little through a game like this.
Here I am bound quite strictly by what I know, and what I have already done for 'Heart of Oak' - I work on a PC, and I write in Java, using as the graphics engine an open source (i.e. free) product delighting in the name of 'Java Monkey Engine'. A graphics engine is a piece of software that takes care of all the low level nitty gritty details of displaying and moving 3D models around on the screen, allowing the programmer to concentrate on higher level game logic (not that a graphics engine does all the work for you, sadly, but it certainly takes care of all the hard maths). There is much debate amongst people who care about such things as to whether Java is fast enough for 'serious' game programming - maybe it is, maybe it isn't, but it's a language I know and is relatively easy to use, and with so many years of my time invested in the game engine I'm not about to change now. Being written in Java the game is theoretically easily portable to other platforms (Linux, Mac, iOS, Android), but it's never quite as simple as that, and as this is a hobby project for my own entertainment, I haven't been keen to invest the time and effort it would take to make the game work on other platforms - in fact I can only guarantee so far that it will run on my own PC. But as these games reach completion, I may devote more effort to such things.
Graphics are the basis but also the bane of most commercial computer games. In order to sell well, a commercial game must provide 'eye candy' - if it does not, the howls of derision from the denizens of the various online gaming forums will sink it without trace, and as a result game development budgets are now in the multi-millions of pounds. Yet all too often graphics are thought to be enough, and gameplay (sometimes) and historical accuracy (almost always) suffer as a result. There is a market for niche games emphasising historical rigour and gameplay over graphics, but it is tiny in comparison with the mainstream, and even those who should know better, such as forum posters on wargamer.com, will often condemn a game for having dated graphics.
Miniatures wargamers are not wholly free of the affliction of course - an unpainted wargame army, or one dipped en masse in red or blue paint, would perform just the same as one lovingly painted, but aesthetics, while not everything, are also not completely irrelevant, and the 'look of the thing' does play a part both in the enjoyment of the hobby, and the creation of a good historical feel. In the world of computer games though it has gone a bit crazy, as if nobody could field a wargames army unless it had been professionally and expensively painted by a famous artist. There is little of the do-it-yourself ethos in computer games that exists in miniatures gaming, perhaps because the graphical demands are so far out of the reach of ordinary mortals (of course the programming skills aren't widely held either, but there is little incentive to learn if it seems impossible to produce anything of sufficiently high standard anyway).
So for my games, I am content to bumble along ineptly in the graphics department, happy in the thought that these games are probably never going to be released commercially anyway. Yet the decision (which was taken very early on in the development of 'Heart of Oak') to go with a 3D game environment, means that graphics are inevitably pushed to the forefront. The simplest type of game to develop is a 2D, top down, boardgame-on-a-screen game, where almost all the effort can go into gameplay and AI. Once the decision is taken to present a (reasonably) realistic 3D environment, graphics start to consume vastly more development time.
For a game set in the ancient world, there are a number of purely graphical challenges. For a start, there are the ships themselves. An 18th Century ship is a fairly simple model, being on the whole solid sided and fully decked, with only the rigging providing real challenges (and I greatly simplified the rigging of my ship models). A trireme, or equivalent, has a number of tricky features - it is largely open in design (beams rather than solid sides), it is packed full of rowers, and it has a couple of hundred oars sticking out of the side - oars which really need to be animated (partly to look nice, but also because the speed and direction the oars are moving give important visual cues as to the movement of the ship). An internet search will reveal plenty of trireme 3D models, but these are mostly intended to look nice on their own, not to feature in a game, and the strain on the hardware of depicting large numbers of these highly detailed models would be considerable, while building, texturing (the computer graphical equivalent of painting) and animating them would be a full time job in itself. So simplifications are needed - the sides and deck probably need to be covered over (even though not all triremes were really cataphracts), rowers hidden (and so not modelled, or depicted as flat textures), and some solution found for the oars.
Computer games generally make use of a concept called LOD ('level of detail') modelling, in which a given object is represented by several models of varying complexity - when the object is close to the viewer (or camera) the most detailed, complex model is used, while as range increases, progressively less detailed models are swapped in. Using such techniques and playing around with the ranges at which the models are switched, it is possible to have fairly detailed models up close to look good, while still retaining reasonable performance by using low resolution models for distant ships. My current plan is therefore to model and animate the oars of the player's own ship and those nearby, out to, say, a couple of hundred metres. Beyond that, as ships are too far to see clearly (on a computer screen), solid blocks of non-animated oars can be substituted, hopefully without ill effects. Similar considerations apply to the crew on deck - the player's ship must have reasonable-looking deck crews and marines, but there's no need to model the marines on a ship half a mile away - they can simply be missed out.
As to the crew themselves, the ancient world benefits from the fact that most deck crew can probably be represented by standard figures (did Ionian, Athenian or Roman deck crew dress very differently? I don't suppose anyone knows, and I am happy not to care). Marines are a bit different, but at least a standard hoplite figure will do for a vast swathe of Greek history - so I'm anticipating fewer problems here, despite a longer time span to cover than 'Heart of Oak'. Numbers are also slightly less of a problem, but this has already been addressed in 'Heart of Oak' - HMS Victory for example should have 40 or so marines on the poop deck, but this number of figures poses (as ever) performance issues, and would make the deck too crowded to walk around - so the old wargamers' trick of using one figure to represent many can be used here, and I populate my Victory with just eight marine figures - in the broad context of the game, it looks OK, I think, so a similar proportion of hoplites on a trireme should also work well enough.
Similar considerations apply to the numbers of ships themselves. Fleets in the age of sail were relatively small - at Trafalgar the fleets were only around 30 ships on each side, and while late 17th Century battles were larger (a hundred or so ships, albeit individually smaller), this is still nothing compared to, say, Salamis, with 300 or so Greek and 600 or more, depending who you believe, Persian ships. Once a standard trireme model has been built, with LOD used to simplify the distant models, representing 1000 ships should not be too great a challenge, and the big commercial games (such as 'Total War'), have no difficulty putting thousands of animated figures on screen at once. But again, this is a hobby project and the graphics engine I am using evidently does not have the power of these serious players. I have found through experience that anything above about 100 ships, total on both sides, starts to bring performance down significantly. This wouldn't matter if I was producing a computer model - I would just calculate results once per second, say, which would be fine as a way of calculating positions and interactions - but having chosen a 3D animated real time game, I am locked in to needing to do updates 20 times a second or more, and with hundreds of ships, that is going to be a problem.
The obvious solution is the wargamers' trick again, and using one model ship to represent five or ten real ships - but this poses its own problems. In a miniatures wargame, the ground and time scales can be fiddled with so that a single ship (or soldier) model can occupy the same space, to scale, as the number it represents, and move at appropriate speeds. To do this in a 3D computer game, though, would mean having enormous ship models and having them move at a snail's pace - in a 3D first person perspective virtual world, these sorts of abstractions become highly visible. Or I could use fewer ships to represent a sort of mini-Salamis - 30 Greeks v. 60 Persians - but the problem with this is that it is the very mass, the vast number of ships covering a huge area of sea, that I am trying to represent, and which would form a large part of the historical lessons, if any, to be learned from such a game.
I am still uncertain how to tackle this problem, and from the solution I adopt will no doubt arise a lot of the further design decisions to be made as the game progresses. I suspect the solution may look something like this - out to say half a mile from the player ships will be graphically depicted, but beyond that they will either not be depicted at all, or shown as simple placeholders, and updated only periodically, thus producing a real time 'bubble' centered around the player. Given the low resolutions of computer monitors compared with real life, ships at these ranges are hard to see other than as blobs anyway, so the lack of updates or detail may not be noticeable.
For any single player computer game, the AI is of paramount importance - and even more so in a game such as mine where the forces of both sides are controlled by the AI, with only the player's own ship under his direct control. AI for games is of course a vast subject in its own right, and one of which I have barely skimmed the surface in my games; I have instead taken a pragmatic approach - if the computer-controlled ships act in a way that seems generally plausible and which poses a reasonable tactical challenge for the player, then my job is done. My AI therefore mostly consists of a set of stock behaviours in given situations, and the computer periodically picks one for each ship and acts accordingly, until a certain amount of time has passed or the situation has changed in some significant way, at which point it picks again. Some people are very much opposed to such an approach, and indeed it can be too predictable, but the great benefit of all the fog of war of a first person perspective game, and of the difficulties of controlling a fleet using signals rather than directly by 'point and click', is that the player is not in a great position either to notice that the computer captains are acting stupidly, or to do anything about it if he does - this is a big advantage, in terms of difficulty for the developer, of a 3D battle experience type of game over a 2D battlefield model type of game. So while my AI does sometimes do aggravatingly daft things (avoiding colliding with friendly ships, or with land, seem to pose particular challenges for many of my AI captains), on the whole the results in 'Heart of Oak' are good enough, I think.
The main challenge for 'Trireme' will be adapting the AI for the very different tactics of the period. In the age of sail, the key things the AI needs to be able to do are to move towards an enemy ship until within gun range, then move perpendicular to it so that broadsides can be brought to bear, and all the while avoid bumping into it (and any friendly ships in the vicinity), unless there is a definite desire to board. For the age of oars, the 'bumping into' part moves from being something to be avoided, to the primary objective. But just colliding with the nearest enemy is not the same as ramming, and ideally the AI will try to set itself up facing an enemy's beam at suitable range, then dash in at ram speed, all the while avoiding other friends and enemies, and while it is early days, I suspect this is something the AI is going to struggle to do well.
It will also be necessary to develop decent squadron and fleet level tactics, so that the diekplous and the periplous can be carried out (if indeed these were squadron-level tactics), and this too will pose a challenge, but also a possible opportunity for the game to offer some useful historical information. Debate rages as to how these different tactics worked, and whether ships engaged in line abreast or line ahead - and where the ancient sources are not sufficiently clear or explicit, historians have to fall back on assumptions or speculations about what was practical, without however any way of testing the various possibilities. As I progress with this game I hope I might be able to test out the possibilities and by seeing them in action gain a clearer idea of how they might have worked.
I have mentioned the signal system used in 'Heart of Oak'. For 'Trireme', things are going to be both simpler and more complicated. Simpler, because so far as I know there is not much historical evidence for how ancient fleets were controlled other than a few references to pre-arranged manoeuvres triggered by signal flags or trumpets. More complicated because the fleets are much larger and the manoeuvres they need to carry out in some ways more subtle and complex - an age of sail fleet can simply sail in line ahead perpendicular to the enemy and achieve good results, while an oared fleet needs to find a way to perform meaningful rams in formation. If the only signals available were the waving of a few coloured flags, the range of things that can be signalled is going to be very small. Another consideration is that sailing ships could hoist their signals on tall masts, while signal flags waved from the deck will be very hard indeed to spot from any sort of distance away (even with trumpets blown to draw attention to them). I have not yet got very far exploring these issues but I suspect I am going to find that once fleets are close to engaging there is very little commanding to be done, and very little controlling possible. We shall see.
At this stage of the work in progress a lot of details - and not just details, but major issues - remain to be worked out. Some things that spring to mind - how if at all will 'oar rakes' work (and in fact, what is the evidence for the use of oar rakes?). How will damage to oars need to be tracked and what are the effects on speed and manoeuvrability of various levels of damage? What about crew tiredness - how long can a crew row at full pressure without becoming exhausted, and how long do they need to rest to recover again? How much faster is a 'fast trireme' than a slow one, and how much more manoeuvrable - what performance differences are reasonable and what effect will they have on tactics? How will the 'land battles at sea' favoured by the Romans work out - both graphically (lots of marines) and tactically (they don't seem to leave much for the player to do)? How big is a quinquereme, or an eight, or a sixteen, how fast could they row, how well could they turn? What about archers, javelins, catapults, the corvus - again, both graphically and tactically?
All in all there is a lot to do, but I hope it will be an interesting process.
Back to main page