Week 7-8 : The final touches

This is polish week and almost all of what we have logged as artifacts is now within the game itself. What this boils down to is that at the moment no new systems are added, but  tweaked, updated or made to shine just a bit more (sometimes literally).

What then could there be to discuss? Quite a bit, as those tweaks tend to be what takes a game from being acceptable to being either great or awful.

For instance this week we chose to address the sluggish nature of some of our player movement in a more direct way than before: Changing the actual game-speed to run at 20 percent faster than before.  More specifically, the tick-rate or update-rate of the game http://www.nbnco.com.au/blog/entertainment/what-is-tick-rate-and-what-does-it-do.html

As our game is a network game, this is quite a different change than just altering the amount of updates on the server side. The client needed to send updates at a somewhat higher rate than before as well, so as to account for lost packets when deciding on how a player makes their next moves.

After the actual programming was completed,  testing began to see if players felt the game was more or less responsive. In general the change was seen as a positive one, but a slight issue cropped up with animations, as they too were locked into tick-rate (a possibility only because of the small amount of packets being sent between updates). This should never be done for any game with real-time changes during gameplay or with more than a handful of players.

The issue was that the animations would play a bit too fast and felt “jittery” to players who barely had a chance to see the effects. Luckily our old friend State Machines came along to help, or in other words, the Unity Animator. Changing up the animations speed itself meant the attack could be tweaked to move at a few percents slower pace without impacting the effect on other models as they collided with one-another, especially during attacks. While this essentially “hid” the fact that attack effects are not tied directly into animations, it still looked close enough at the angle seen by our cameras.

 

Advertisements
Week 7-8 : The final touches

Week 6 : Beta and the re-design of UI systems

The pre-beta playtest has come and gone, lending a number of reviews with information we were mostly already aware of. However, this was still a critical event as this confirms the need for re-designing the game in some key areas, including the very system we use to move our players and let them take actions. This blog post will thus detail the design work done before the feature freeze to come, rather than the producer side of handling the beta process itself. 

At the inception of our movement system, players were required to commit to taking certain actions at the cost of action points.  Once they had completed a set of moves, they were asked to confirm the same, then end their turn. This meant that in essence players who had no issues with deciding on their actions were still left with unfinished turns, as they either missed the extra confirmation button or would forget they needed to commit. The reason this system existed in the first place was as a placeholder for future development, but at the core of the issue was the fact that players could take very different actions, both moving and attacking out of order, if they so desired.

While this gave players more freedom in terms of strategy, that freedom was still limited by the fact that we were not giving them all that many points to do anything beyond a short set of moves or a quick burst of attacks. A solution to this could have been to afford players more points, but that would affect not only game balance but lengthen the planning stage, as more actions would require more time to think about what to do. This would have been fine in a game that was not multiplayer-based,  or focused on achieving a certain lower playtime, but not for what our game was aiming for.

So instead, I and the lead developer adopted a system akin to the one employed in the new X-Com. Here, players would be able to move 4 squares in any direction, or decide to move 8 without a chance to employ an attack. No longer can players attack more than once, but must instead use positioning to gain an advantage for future rounds to take down enemies with greater health. This also meant that players no longer got “stuck” near throngs of enemies without recourse, but could instead run away from their plight (possibly behind the other players, lending another source of paranoia). 

At the same time, we removed the need to ”confirm” a turn, saving each choice as it was made so that if a player got stuck pondering what move to take next and their timer ran out they would not lose their intended “progress”. This cut down time played by 5 minutes and produced less frustration among playtesters.

Client UI current

Week 6 : Beta and the re-design of UI systems

Week 5 First Animation (ever)

This week saw me taking my first steps into animation programming, resolving how to code to move a character according to input and the speed it was traveling.

Unity’s animation solution is a new type of challenge, but not entirely. It is mainly built up from State Machines https://www.techopedia.com/definition/16447/state-machine , something which a programmer might be more familiar with than an artist.  What these boil down to are devices or programs that produce a certain type of output depending on input, in this case calls from the Unity engine such as triggers, set values and Boolean variables. These start pre-made animations that artists have created beforehand which can be played at variable speed and merged into other animations via Blend trees  https://docs.unity3d.com/Manual/class-BlendTree.html . These state machines are named Animation Controllers in Unity, an example of which can be seen below.

AnimationController

Arrows are drawn between each animation, indicating what animations can transition into which. These are given the aforementioned triggers or requirements,  unless you want avatars to move into another animation at the end of a play-through of another without delay or prompting.

Here we come to my first assignment and the work I needed to complete: Making our character walk towards a target tile and animate that walk. Setting up the state machine itself was as easy as creating an animation controller via Unity’s automated process, then creating two sets of animation possibilities: The Idle and Walking animation. At this point it did not need to check if a player was moving at higher speeds or not, so all that the controller had to check was if the player was moving at all.

This however became a slight problem based on the fact that the player was often told to move based on lerping , or in other words moving not directly to a point but in increments based on how many ticks a process had accrued. A walking animation would therefore look jerky and “jumpy” if only polled from that data, with the character pivoting on its axis to move to new areas, should it be given a command to move in anything but a straight line.

Deltapos

The solution was to not use the lerped movement, but the magnitude of it, that is determining if a character was truly moving instead of simply being adjusted to a point. The rest was a simple if/else check to set the attached animator to run or not, since high-speed movement as mentioned was not requested at that point. The result was better, but not perfect. We would eventually need to put in a delay on tickrate, to ensure the animations played to completion as they should. (GIF of this incoming at a later date)

 

Week 5 First Animation (ever)

Week 4: Actual UI implementation, Alpha Presentation

The Alpha has come and gone , its presentation over. Feedback mainly centered around difficulty in determining which player is where and doing what, indicating our placeholder art needs to be replaced ASAP. But that would not make a very good blogpost, so here instead the project UI and where it derives its statistics are obtained. Remember that all art here is placeholder at the moment, meant only to represent what each player should see, not what they WILL see.

The UI itself would not make for a very interesting post either: The main health bars of a player on the game client would be placed in a Unity Canvas, with a masked bar moving from left to right across the screen to indicate a change in health. The bar’s position is determined based on screen size and its length on the amount of HP, to reflect characters with greater health as appropriate.  What is interesting is how the entities in a multiplayer game are created, their data obtained and sent to the controller of the bars themselves.

Entity Blog Code

As seen in the code above,  each entity is defined with certain characteristics that need to be instantly accessible: If it is dead or alive, controlled by a player, what its maximum action points and health are and if it is affected by any statistic effects. Beyond the struct of EntityData, which provides temporary values, these co-incidentally are all the values we need to depict on the screen at the start of the game, sans Initiative for movement which is chosen after the player is created. Both players and enemies have their data pre-defined in json files, loaded on creation of each scene as they are not meant to change between sessions.

And here is an early revision of the game UI , sans current player values.

ClientUI.png

Not much to look at, as mentioned. The Entity Data itself is located on the server, not the client however. Therefore that data needs to be updated via the network,  which contains a list of entities , both players and not, as well as data on what playerID active characters have. All health and actions are altered on the server, not the client, so these numbers are forwarded through server updates when applicable.

Before that can happen, the UI itself is instantiated, then updated as needed. If the playerID given at connection and creation of the player entity is the same as the one being updated the client recognizes this and either sets the bars of the player to their correct numbers, or creates the UI if it does not as of yet.

 

PlayerUI Updates.png

This data is not the only instance being accessed of course, given that this is a multiplayer game, but this represents our solution for obtaining player data for a single entity.

Next week’s post should see information on how the Unity Animator tree works and early iterations of how our group got it running.

 

Week 4: Actual UI implementation, Alpha Presentation

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 1 and 2 of Big Game Project: Production and Design

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.

Blog Post UI-LESS

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

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

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 1 and 2 of Big Game Project: Production and Design