Week 1 and 2 of Big Game Project: Production and Design

These two weeks saw the start of a project that is to span 8 weeks of development, where I will be taking the role of Producer along with part-time Designer and Programmer. The game being made is an isometric 3D-game, tactical and turn-based. Secret agendas are a main mechanic, where-in players will be given secret objectives to complete that include betraying other players and killing them before reaching the end game. In short, the Mechanics involve Moving and Attacking enemies and allies, the dynamics of which would introduce planning where and when to attack to support or divert the group, leading to Paranoia as to if they can rely on player information as our aesthetic.

First of all came the development of our Project Plan ( https://drive.google.com/open?id=1F39-gTY6bFOfjBnSBnTLX6IpsU3q6ZPePITMo1iKRyI ), Trello Scrum Document (https://trello.com/b/KHPsWZYo ) and Design Document ( https://drive.google.com/open?id=0B_-RqKRH1s5yakJWNk4zWkNtT0E ), where I was responsible for the main writing of all three.

Our programmers meanwhile developed our first prototypes for game movement, server and client connections and our main input mode, so as to allow us to test the game as early as possible. To prepare for this I organized several testing sessions for mechanics that were to be included in the alpha version of the game, including initiative order for characters on the field, separating enemy and player turns as well as player endurance and difficulty.

Iterative testing was utilized to produce each specific set of content, in this case mechanics and how they are introduced. A paper prototype (Image for this is missing unfortunately) was utilized before the main game prototype was completed, consisting of a single room with base characters with similar abilities to the ones imagined for the final game.  Iterations were tested by group members during the first week and people outside the group in the second to see if the implementations would be easy to understand.

 

 

(Image linked from Gamasutra, Making Better Games Through Iteration)

First to be tested was Initiative Order, as earlier testing had already produced attack and movement designs. The initial test was for set initiative values between 1-5 for each player and enemy, with an average of 2.5 out of 5 for each enemy to give them a predictable pattern of movement. The effect however was games that ended in the favor of the player most turns played as they would nearly always go first. The second solution was to raise the enemy initiative by a point, to put the players on the defensive in the first few turns. However this resulted in an increase in difficulty that was insurmountable when playing against a concerted effort by the player representing the AI of the game. It was too difficult for players to communicate properly what their intentions were and how to gather together to defeat enemies with this disadvantage.

Due to this, a mechanic was introduced that let players “bid” initiative cards, from between 1-5 as before, splitting the player and enemy turns to make the initiative value influence the dynamic between players more rather than be against just the enemy. This meant that with proper planning and co-operation players had the ability to beat most foes as long as their communication was honest, which meant objectives that pushed for betrayal needed to be looked out for.

While this seemed to solve our problems, it created new ones in the form of people choosing the same initiative and resolving who goes first in that case. Since it has not been tested on a screen as of yet, it may also introduce a concept that is difficult to grasp or takes up too much time or space when played instead of the automatic solution of set values from before.

This testing proceeded with single changes between iterations for player health, the larger campaign the game is intended for with several rooms as well as Character Class abilities yet to be implemented. Each alteration was written down after evaluation to give an explanation for each change that each group member could partake in.

Next week should partially move away from testing and move towards Programming and Producer solutions.

Tag : 5SD037, BGP

Week 3 of Big Game Project: Early UI and what to show the player.

Beyond more production and design work, migration of systems from the prototype to an early pre-alpha build began.  Since systems were no longer being tested by internal testers, the game required an UI on both the server and client screens displaying statistics like player health, Initiative number and which attacks are selected. The transfer lead to the use of actual equipment to appear on the GGC floor where the UI appeared differently and would require different solutions.

Above is one of the earliest Server images with actual placeholder art the group I was part of produced. It lacks almost all UI elements except for what we were testing at that very moment, namely connectivity. Players only needed to know if they were connected or not to show if the server would keep a stable connection and to test the new hardware our clients had similar designs.

As the game was populated by player and enemy entities and they were allowed to commit to actions, decisions had to be made about what information to show and when.  Not only because users require consistency and ease of use (https://www.interaction-design.org/literature/article/user-interface-design-guidelines-10-rules-of-thumb) but because our game was focused on betrayal and paranoia and hence as designers of the game, we did not wish to give away too much about player choices towards other players. Our first decision regarding this came in regards to initiative.

In the first draft, each user could see other users choices as they happened, listing their initiative order as it was altered. However, players responded with irritation at not being able to hide their actions through such free information: If they could instead remove that ability from other players in some way, they were free to tell users they were doing one thing at one initiative step, but do another in the real player space once they committed to an action.  This change was implemented and partially inspired by the Diplomacy game, a more text and speech-focused game played as much outside the game itself as within it.

However, initiative order was still a useful tool to explain to players just what players did what and so the order was kept, except only updated post-turns. That is, after a turn was completed, the initiative order was displayed on the server screen to give a summary that players could scan to give them an indication of what sort of initiative they had left to choose and to determine if a user’s proposed actions were true to their words. At this stage, most UI elements on the Client side were related to movement, attacks and statistics the player could affect directly, whereas “passive” elements were kept to the server, such as timers, former turn information and enemy placement.

TAGS: BGP, 5SD037