Responsibilities

Game Mode Design

To justify Gallipoli’s existence, besides to unique locals, new weapons and factions, we needed to create a new core game mode. Each previous instalment in the series has a unique game mode that sets itself apart. For Gallipoli we set out to maintain the sequential capturing of sectors from Isonzo. Our main goals were to, in no particular order:

Improve on emergence
Maintain density of player
Balance inherent defender benefit
Reduce play time per map

Under some heavy constraints, together with Aaron Baker, we initially set out by creating paper prototypes and doing a competitor analysis. We quickly settled on a well established setup where each sector must have multiple objectives to be taken by the attackers. Applying this to the Offensive game mode from Isonzo we immediately had a core on which we could further iterate that addresses the main goals.

Later on, we established that it does not matter in what order an objective is captured as long as it’s within a single sector. Otherwise we risked dispersing the fairly limited number of players in any match. Leaning on the non-linearity of objectives, we established that objectives can have functions, those functions can be unique per objective and those functions can switch between objectives per new match.

Mockup showcasing building structures in an objective to capture it

Gameplay Design

As is almost routine with any project. We initially had many ambitious goals for the gameplay. However, under solid guidance from Creator and Founder CEO Jos Hoebe, we set out with some specific adjustments to existing gameplay from Isonzo.

Firstly, we wanted to reduce the rigidity; the simplicity of the ticket system. Early on we decided that there were two main issues:

The number of attacker tickets did not accurately reflect how well they are doing
There was virtually no cost to defenders being reckless and aggressive

We were able to solve this issue by introducing a ticket system to each team. Initially the tickets of both teams decreased, or now increased, by (re)capturing objectives and killing players. If defenders ran out of tickets they would lose the sector. This caused one issue where killing defenders became the prime solution for attackers to be able to win the match. With this the second issue was flipped entirely. Defenders became timid, unable to be aggressive even if the situation called for it.

Having established from playtests that this was an issue. We shifted our approach and introduced asymmetry into the system. Shifting our mindset here was of great help. Instead of seeing it as a number of lives we started viewing it more abstractly, an abstract representation of a team’s ability to achieve their goal.

The attacker tickets decreased by attackers being killed but would increase by achieving specified goals. This supported the desired outcome of attackers needing to progress through the sector to be able to win. The defender tickets are more simple. The defender tickets can only drain. Running out of tickets is a win for attackers and regains them tickets but does not result in a loss state for defenders. This creates the desired outcome where defenders have to be sparing with their lives but gives them room to be aggressive when they need to be.

HUD elements with described ticket system in the released version of Gallipoli

One internal criticism of Isonzo is in regards to a number of features where the player simply has to wait to achieve something. This describes the spotting feature, the wirecutting, building or bomb planting feature or the call-in feature.

Our main goals were make these various features more engaging without making them more challenging. To accommodate these wishes we made a number of iterations. My main contribution are towards the build marker mechanic and officer call-in system. With the former, the player is challenged with hitting specific on screen markers to increase the construction or demolition of a buildable. The latter is one I’m personally more proud of.

In Isonzo the player has to place a marker on the map by firing a flare gun at the desired location. Than the player has to traverse to a specific Officer Table. From there the player is able to deploy call-ins. By far the most significant issue is the complete detachment from match going on around the player and not using call-ins in Isonzo is suboptimal. In Gallipoli we detached deploying the call-in from such a station and has been combined with shooting the flare gun. The player can select a desired call-in from a new menu with a minimap that has been adjusted for the purpose. Wherever the player shoots the flare is where the call-in is deployed.

Mockup showcasing the call-in selection menu with adjusted minimap

Weapon & combat Design

In regular cooperation with one of the team’s programmers and Deputy Game Designer Ned Birkin, we spent a significant amount of time working on the weapons and combat. One of our core pillars is that rifles are (almost) always one-shot kill weapons. This came with a clear issue. Survivability of players extremely low. It’s nearly impossible to get shot and respond to that. Either because you would already be dead or the quick follow up shot will achieve that goal.

We took a few measure to improve survivability that mainly involved slowing down the combat. Players are induced to stay in place and take cover by a revamped suppression system. Shooters are encouraged to stay in place at medium distances as all weapons have been given the ability to brace on surfaces, reducing their sway. We reduced the reserve ammo count of all weapons and paired that with a newly introduced Ammo Bearer class with increased importance.

On top of that, most significantly of all, we introduced a revive mechanic. At close range, most weapons will still instantly kill any enemy. However, at long range or medium range with pistols a player may now be downed as a consequence of being shot. These players can be brought back up and this will prevent the loss of a ticket.

Another not nearly such significant a change is to the Heavy Machine Guns. We’ve managed to significantly handicap the weapon’s accuracy while maintaining it’s high power status. With increased impact of suppression and reduced accuracy of the HMG the player has become induced to spray down a certain area with the general goal of keeping the enemy hiding in their holes. Meanwhile, the player still has a real chance of killing opponents. It’s been changed from an automatic sniper rifle to what it was actually used for.

One of the team’s Dev Blogs describes some of the subtler changes very well.

Wiki Management

Largely a minor task but I was tasked with maintaining a wiki page for internal company use. The main purpose of the wiki is to easily be able to keep other team members, especially those from the other branches, informed about the current designs.

Our policy was to adjust the wiki based on design changes that had been implemented into a build and playtested. This way we assured that we didn’t have to wait to document the design until release with the added benefit of only occasionally needing to update the various wiki pages. Besides keeping current team mates informed, it also helped us to onboard new team members.

QA Assistance

Given the size of the team I also became involved in playtesting. My main tasks were not to set up the playtest but to participate and assist our playtester if they had any questions or other issues that needed resolving.

I also engaged playtesters in our Discord’s private playtest channels to encourage them to provide feedback, information and bugs from these playtest. On a rare occasion I would be hosting the playtest and so I also became involved with reviewing, updating and posting the questionnaires. Responses were checked by our producer and QA Lead.