For a long time I had an idea of what I wanted for the Battle Hymn interface. It had to have a period feel, to be evocative of the era but most of all it had to work with the maps and units, which had been designed first. I’m a firm believer that a game should be designed as a whole entity. Not as separate disperate elements that are later thrown together. So, as we had with the maps, I took examples of period print and built on a subset of the defining elements.  The Battle Hymn interface took its inspiration from posters and leaflets of the day, reworked to suit a modern audience and touch device.

The main stylistic factors we can take from the above are the use of multiple fonts, styles and sizes. little bits of decoration and embellishment to separate sections and headlines. In many cases they seem to want to fill as much white space as possible. Overall quite difficult on the modern eye but I wanted to capture a flavour.

So instead of the multitude of fonts, I’ve picked out just two of the more popular period ones, Baskerville and Egyptian. (The red glyphs are missing but we were’t considering localizing to Icelandic or Czech). These give a good mixture of weights and capture the essential flavour without overwhelming us with multiple fonts.  Baskerville, a slim elegant serifed font suitable for body text and some sub headings..nice flow to the italic.  And regular and condensed versions of Egyptian .. A solid slab serifed font suitable for headings and buttons.

I thought I may need a sans-serif at some point but I wanted to achieve as much as possible with just these. As a nod to the desire to fill space and use a lot of text sizes (and also to aid localization) I set the text to automatically resize based on content and size of the button, panel or whatever it was anchored to. This had the advantage of automatically giving us different text sizes based on content. While I liked the idea and the look, it proved a little tricky to get the balance and flow right and as the project closed there was still a lot tweaking left to be done.

While I’d been developing this look, the designers had been busy with Balsamic, putting together the required layouts for each screen. Once these were set in stone I could then go through and work out what assets were needed and how the users eye was meant to flow through them. I began mocking them up, trying different looks and combinations of elements, fonts, colours, decoration. I started off just concentrating on two pages .. the in game map view, and the game menu (the second image above) as the most seen/used, and the most complicated, respectively. My usual approach is to concentrate on the most important interactive elements, define a coherent and consistent look for them and then build from there.

The designers original intention was to have just one scalable interface for iPhone, iPad and PC. Not always a good idea, especially for one so complicted as these became. I was very dubious as we’d learned from CiC that mouse and keyboard based interfaces do not translate to touch screen and vice versa,  both from a UX and visual point of view. Likewise, cramming a complicated iPad screen onto two sizes of iPhone required a lot of changes. But eventually we created one that would work well on iPad and reasonably on PC. A compromise. iPhone would need its own treatment but plans for that release were postponed.

So, as we did with the map, I took a period style and technique and tried to make it more usable by todays standards. Hopefully without cliche .. This is a sample of the art spec document that laid out how each page was to be constructed and its constituent elements, type sizes etc.. The developers would put them together fairly roughly .. the essential elements present and working .. and I’d go in, tidy up the layout, fix prefabs, add decoration etc.. This is a set of documents that I wrote during pre-production and as part of a proposal. A living rule book that grew throughout the process as techniques, artwork, pipeline developed.

While I’ve inevitably tweaked things, all these mock ups were based directly on the Balsamic layouts provided by the designer and eventually most were implemented using NGUI in Unity. One stipulation was that the panel artwork had to be scalable and made from a limited set of assets so as to reduce the time taken to produce them. As it turned out, many of the panels simply didn’t need to scale and many of those that benefitted functionally didn’t look so good. As it was, the actual setup and construction of all the screens from many small 9-slice elements was extremely time consuming and what little time was saved by making relatively few (if complicated to create) assets was nullified by that process.

Here’s a small selection of the initial Photoshop mockups. These were essentially the first pass and the intention was to test and revise. Iteration being the plan. We had rough builds in game, test, iterate, test, iterate  … Sadly Shenandoah closed before we got passed the first iteration. So its easy to pick out the flaws now but we were aware of them then too and planned to address them.

Obviously the player should always know what elements are interactive so the buttons where the first thing to be designed. Mostly if its a black box or animated flag you can press it. Didn’t quite work for selectable lists but then thats often the case.

I’d also started to work out a simple heirarchy of panelling colours. Slightly different shades to emphasise the importance of different areas and so attract your attention. Likewise different button and text sizes to lead the player through the most frequent route (not shown in these mockups) It was implemented on some screens but not others. The colour scheme and symbolism is quite typical for games representing this period but I planned to make a lot of use of period photos, giving them a consistant etching and hand coloured effect. After our research trip out to Gettysburg and because the game abstractly represents the soldiers as simple blocks I felt it important to represent the ordinary soldier in some way.

There is no solid black. The darkest shade used was a dark grey yellow, textured to look like ink printed from worn plates. Using a paper shade for the background and button text also help reduce the tonal contrast and eased readability.

INTRO SCREEN

Since Shenandoah folded and Slitherine bought the rights to the game, I’ve occaissionally been able to dip back in and help out the new developers. This is a PC intro screen, essentially created from pre-existing UI elements. The game logo, designed to suggest the wide range of ages, the change from a young country to a more mature, the loss of innocense and that it was a civil war – a war between neighbours and friends – was designed when the game still had the working tilte of War Between the States. So internally it became known as WBtS .. Wabbits.

MAIN MAP VIEW

The commit button would pop out as you press the action button which would have a faction specific flag, animated when it needs to call you to action eg. when theres nothing else you can do this turn. Currently this is a two tap procedure the same as CiC. Again, from lessons learned from CiC about how much information the player wants immediatly available on screen, I added VP bar and turn number to the original design. The player always wants to know where and when they are and if they’re winning. These were placeholder.
Note that the entire map is surrounded by a black lined border for added theme and separation ( ingame panels always appeared above this frame with the map and units below) and has a vignette at the top to provide separation for the buttons.

GAME MENU

This was the defining menu. The use of buttons, text  and decoration came from this as it had the most interdependent anchoring within anchoring of any panel. Notice the on map buttons and interface has vanished and the map has darkened so as to focus the players attention on what they’re doing now and to emphasis that its not currently possible to interact with the map units. There was some discussion about this. The conventional wisdom is that you shouldn’t take the player out of the game. However, use of any of these menus stopped the game completely so since the player was already being pulled out we thought it might be important emphasise it. We never got to test this in the wild so don’t know whether it worked.

CALENDAR

All the panels are made of 9-slice so are scalable. On a PC screen the calender simply opens further to the left, showing more dates. Below is the calendar panel. Note that the main horizontal dividers and the frame of the slider are integrated.

If you look at the time and date information, this is an extreme example of how the content defines the size of the text. Alternate days would be picked out by a slight darkening of the background but on the whole, differences in paper colour were used to bring menus to the front or push them back. For example the main game menu to the right is slightly warmer than the main calendar panel.

FORMATION INFO

While this had limited practical use during gameplay, it had an important role in the historical side of the app. The general portraits were from photographs, hand coloured and etched in photoshop so they remained consistent in a style and scale of etching throughout the app, similar to that below ..

TURN INDICATOR.

Battle Hymn the board game worked with the Chit Pull mechanism to determine which division could activate next. So everytime a new division was added to the board, a new counter was added to the cup. This is our metaphorical cup .. divisional symbols would spin past and then stop on either the one to be activated or one that designated a faction starting combat. Each division could comprise multiple units so you’d be moving upto maybe 6 units at any one time. And while you could position your units into a favourable position for combat, you couldn’t always guarantee when the order to attack would reach them .. ie. when you would get the combat counter.

And here’s a selection of the work in progress assets used to create the above.