Seize Warsaw: Onside Review – Nick Luft

Seize Warsaw was inspired by reading about a failed offensive of the 4th Panzer Division which attempted – on its own – to attack and take Warsaw.

This event occurred during the collapse of part of the Polish Army, 6 and 7 September. The Panzer Division thought it could push into the gap formed by two Polish Armies retreating in different directions and drive into a weakly held Warsaw from the route of march and seize it. They failed.

Traffic jam of a Panzer 1 and Panzer 2’s being slowly passed by a command armoured car (SdKfz 234?). Note the angle the car is at as it drives on the road side. Also note the dead horse and overturned cart pushed off road.

They failed mostly because although the Polish were in disorder, the local authorities and garrison commander in Warsaw had formed a barricaded defence and reinforced it with field guns and anti-tank guns. The Panzers thought they could drive in to the city and push through the barricades. They found to their cost that at short range a 75mm field gun could blow apart any of the early models of Panzers and that they only way to take these positions was with all arms cooperation, infantry and support weapons.

There was a lot of confusion on that first evening they attacked, 7th September 1939. At this stage of the war the lowest formation to have a radio was the battalion HQ, and the Wehrmacht had still not quite worked out its doctrine for using armoured formations, nor had they invented kampfgruppes. The few infantry units with the Panzers had not practiced communicating directly with the tanks at the low level needed for street by street urban warfare.

I thought the scenario provided an excellent test for an online game that was mostly about communications. The actual tactics were straight forward, armour on its own failed against barricaded infantry and field guns; armour plus infantry and support weapons had a better chance.

The game was going to be about getting the players to talk, cooperate and get lost in a maze of streets.

Simplified Orbat for 4th Panzer Division, 1939.

My Design/s

Initially I thought I would have about 3 to 5 players. One or two would be in the Brigade HQ and the rest would be battalion commanders.

Design 1 – To Each Map Square its own Text Channel

I was going to use Discord to control the flow of text and audio between players. All players could talk in the Brigade HQ “net” (audio channel) but once the Battalion commanders moved into combat they would have to leave the audio channel and then move through a series of text channels as directed by control and discover the street layout and fight any Polish forces. And then the Battalion commanders could report back.

I was thinking of making a text channel for each square on the map. When I designed the map I realised I would have to have 8 x 13 = 104 text channels. I would have to populate each one with a map square – not too difficult, as I only had five square types (just rotate) and also whatever Polish forces were discovered there. I also needed to have links stating what other squares the player could exit from. Yes, a bit like a D&D dungeon. Still it was a lot of work.

What finally decided me to give this up was that I realised that the player experience would be very isolated, they were in teams of 1. I also could not work out a good way for Control to literally control the game. Once off into the dungeon maze of streets how would the players know when the turn was up and had to report back to Brigade etc.

Design 2 – HQ Map Table and Sub-Unit Map Tables

I abandoned the above and decided to just have a HQ Table with sub-unit tables.

The model was effectively an online version of the old liaison umpire and main map model so well used in operational (tankie) megagames.

I used the Discord “roles” so the players could only see what their unit and the Brigade HQ.

In the image to the left the CO of I/35 Panzer Battalion can see the 5th Panzer Brigade HQ, audio and text channels, their own unit audio and text channels and a set of “field meetings” audio channels.

As the number of players wanting to take part increased from 3 to 10, I invented the Chief of Staff (CoS) role for each team / unit. The CoS had permission to see into all text channels of all other units, as well as the same Audio channel as their CO. This was to simulate the massive use of motorcycle messengers used during the campaign. The CoS was able to read messages from, but not talk to the other sub-unit players.

Control can see all channels. Control is able to call the turns and ask the players to move to their “tables”, and then visit each in turn, and take their orders. Control then processes moves and any combat and revisits and give feedback, telling each team to go back to HQ – if they were able to.

Experienced Discord users might wonder at my use of Categories (the headers prefixed by a “>”). I know others who have their own Discord servers only use these Categories for each game they are running on their server. I am opting to customise each Server I create for each game I am running on it. One server; one game. I think the Category headings simplify and make the layout clearer. The only downside of this, is that I need to “invite” all the players to each new Server I create.

Briefings

All briefings, rules and map were via Google Documents and the Map via ConceptBoard.

• Player Brief
• Combat Resolution Table [Control only]
• Control Brief [Control only]
• Main map and Movement Rules [Control only]

My initial concept was to let the player’s adjudicate their own combat results, but at Jim’s suggestion I quickly dropped this and the Control took this on too.

Running the Game

The Map

Prior to the game I sent out the briefings and allocated the roles to the players. I had a lot more players than I initially thought I was going to – I had 9 players, 1 lurker and 2 controls (including me).

I had deliberately handed the players a poor starting map. Remember my initial inspiration in Design 1 – to have a dungeon like approach to the game, with the players exploring on their own square.

My assumption was that the chance to take Warsaw by the 4th Panzer Division had taken the Higher Command by surprise. If any pre campaign planning had gone into attacking or besieging Warsaw, I am sure those maps and plans would be at a much higher formation than a new untested Panzer unit.

Andy H noticed the poor map and via the Facebook link to the game suggested that he might ask men in his unit if they had any knowledge of Warsaw. I thus updated the map in the briefing to show more info.

What I had forgotten was that the map still had grid references that were no longer valid. Later in the game this caused the bridge meltdown, when Jerry was not able to find the bridge at E5. My apologies for this error.

Setting up Discord

As usual setting up players online is an additional obstacle to starting the game. Luckily I had Jim on the case and he quickly sorted out players with correct permissions. I think only one player was new to Discord and I spent sometime taking all players through my Panzer Division Discord Server – the previous link should grant temporary membership and also be a permanent link.

Narrative of the Game

I don’t want to spend too much time and bicker and argue over who killed who If you want there are some offside reviews on the game play – Andy G.

4th Panzer Division, unit badge, 1939.

Lessons Learned and Would I do it again?

Of course I would do it again.

In fact I hope I have now learnt how to customise a Discord Server, with player roles and audio and text channels to facilitate a multiplayer operational map game. I would hope I could use this model again.

Lesson 1 – Multiplayer versus team channels

My first lesson is that I prefer to have players in small groups chatting online than keeping everyone in one big Jitsi or Zoom video link.

I have used one Jitsi video channel for my previous game After the Battle of Towton, 1461 and I have played in similar setups. I notice that I spent a lot of time listening and waiting when in a video channel of 6 or more players. I noticed in this game that all the teams – of two players – were happily chatting to each other in their sub-unit audio channels. I also noticed that when I told them they could go back to report to Brigade HQ many teams said, OK, but we’ll have a team chat first before reporting back.

My feeling as a Control was that the players were more involved because of this.

Lesson 2 – Online requires more briefing

I thought I fluffed the briefing a little.

My lesson is that it is even more important to have everyone upto speed with the briefing when playing online. And that you have given the players time to get used to the setup and have a chance to ask questions.

It’s not just a briefing about the scenario, or what roles the players have, its also how to operate the software interface, how the game will be run etc.

Lesson 3 – Think of the players not the simulation

This is always a bit of a problem for me. My initial inspiration was to have a game about the difficulties of communication in a time and place where there were more than the usual set of difficulties. However, any game the players meet for the first time always has that hurdle – why simulate it.

Lesson 4 – Maps: Provide for the players or Get the players to make?

I am not too sure about my conclusion here.

On the day I provided a map and counters in a Google slide that James K copied and customised as the game went along. One player later said: “James’ map was utterly essential“. Though bear in mind, the map coordinates were not correct on this map.

I intended for the players to make their own map and to be sharing details as they went along. In fact it was one of the reasons why I created the CoS role and this is after all what the operational megagames used to get the players to do.

Some players thought I should not add to the level of difficulty here and let them see the “real map. I could have easily opened up the interactive whiteboard map to viewers as well as to both Controls, who had editor rights.

Lesson 5 – Give somewhere for Control to chat

This was something I had forgotten to do, so quickly I added a Control audio channel where Jim and I could chat. I also learnt that you can just pick up and move other players and control to channels as needs be. Quite powerful, but it does feel a little impolite.

Lesson 6 – Control need practice time

I wish Jim and I had practiced a few turns prior to the game and iron out any procedural difficulties.

Online games bring their own unique and new set of difficulties that only practice – or being in the game – can resolve.

Lesson 7 – Control is too busy to read

I noticed that once engaged with the game I read nothing in the text channels.

I did all of my control work via Voice. I am not sure if this says anything about me, but my guess is that as Control you really need to be in several places over a short period of time and going to read a player’s set of orders is not necessary.

I noticed that the players did leave and send some messages, but my guess was, from the volume, that this was done when they could not find the other player to talk to. I would love to hear from the players about this.

Lesson 8 – One game per Discord Server

I was pleased during the game that no player ever seemed to get lost in the interface.

I put this down to using one server for one game and having a Category for each unit or table! Another advantage is all the player’s nicknames as customised for that server. If you have multiple games on one server I have noticed my “nickname” is “Spacefoam Bob” from a Universe game in a game about War of the Roses.

I know Jim has customised his Discord server to have each game in its own Category and then within each Category the server automatically sorts the text channels from the audio channels and then allows the admin to sort them into any order they prefer, though I notice the default order is time created. The only advantage I see of this is that you don’t have to keep inviting players to your new Server and I suppose you might be able to reuse “roles”.