Prototypes

Week 9: Environment and Lighting In Unity by Valzorra

Aesthetics and Lighting

The main mechanics in the Unity Prototype were completed at this stage as James and I had come up with a functional Movement Script, Camera Script, Teleportation Script, and Electrocution Script. All of these mechanics worked as expected and there were no obvious bugs or inaccuracies with them. That’s why I thought it would be rather nice to modify the prototype environment in Unity and to make it more a bit more presentable and thematic. Additionally, this was a nice way of adding additional floor space onto into the prototype, allowing for further mobility to any testers. I started the process with the idea to recreate a very basic and abstracted City Street, as that is one environment we may see Zeta in throughout the game. I started this process by including additional 3D Planes and positioning them next to the green ones in the preexisting version of the prototype. Once I was happy with the space I had, I took basic cubes generated from within Unity and edited their dimensions to make them look like buildings. I kept adding on blocks and buildings, changing their shapes and sizes until I was happy with the overall look and feeling of the environment.

Positioning the Buildings and Floors in Unity.

Once I was satisfied with the positioning of the different objects I thought I would edit the lighting and make it appear as though it was a thematic night scene, only illuminated by street lights and signs. At this stage, many of these aesthetic decisions are not particularly significant, because the most important part of this prototype is to showcase the functionality of the mechanics. Anything else is there to make it a bit more aesthetically pleasing for anyone testing the prototype. With this in mind, I decided to make the lighting seem native to the environment, as though it was coming from flickering lights onto the buildings. That is why I have included a series of Point Lights with different Range and Intensity settings scattered throughout the street. Additionally, these lights have slightly different colors, ranging from pinks to purples and blues. This results in a very beautiful mix of color that gives the environment a distinct nighttime feeling and is reminiscent of neon signs and highlights. Once I was happy with how the lighting tuned out, I directed my attention to the Buildings, and made a few materials to color them in and make them fit into the rest of the scene. What’s more is that I thought it would look even better if I were to add an appropriate Sky Box, so I picked up a free one from the Unity Asset Store.

Overlap of the Point Lights’s Range, which produces interesting pleasing color mixes.

Solving Axes Rotation and Scaling Problems

Once I was happy with the aesthetics of this prototype, I thought it would be nice to replace the current tablet-shaped model with the 3D Model I was working on during Week 8: Intro to Modelling with Blender. However, that could have gone a lot smoother than it did. When I added the model to the project, its axes from Blender did not match the conventions used in Unity, which resulted in the model appearing to lay down. This problem tested my spacial orientation and my capabilities of accurately estimating rotation and after a series of failed attempts, Google Searches, and a series of questions for James, I managed to find the fix. In order for a model from Blender to stand up straight and behave as expected, the model needs to be turned on its X-Axis at 90 degrees. Once this fix was implemented in Blender, the model worked as expected in Unity. In addition to the issue with the axes, there was a minor scaling issue in Unity, which made the Range Indicator grow exponentially in size. The problem was that the Unity scale measurements did not correspond to those in Blender. As the Range Indicator is parented to the Player Model, and the Player Model was rather scaled up after the import in Unity, the Range Indicator also grew proportionately. This fix was rather easy and all it required me to do was to downscale the model in Blender by the appropriate amount. Once that was done, the model was imported into Unity once again and the Range Indicator appeared as expected. Overall, importing 3D Models from Blender into Unity had its intricacies, however, all problems were solved with the mere configurations in the 3D Modelling Software. Additionally, this was a valuable learning experience, because now I know what edits I would need to make when I am importing future models into the project.

Some of my failed attempts at trying to solve the rotation issue in Unity.

The Finished Prototype

After these aesthetic changes and after fixing the issues with Axis Rotation and Scaling, a new NavMesh was baked, and the prototype was tested. I was happy to discover that there were no further issues with it and that all of the aesthetic and environmental changes ran smoothly. I was a bit concerned that the player and the enemies would blend into the environment and would be difficult to spot, however, upon running the prototype, they seemed easily distinguishable from everything else. I created a series of different materials to add onto all of the separate models into this prototype, some of which emitted luminosity to stand out even further, such as the Enemies and the Player Model. A detailed video of the prototype in its complete state with all of the environmental details and functioning mechanics has been provided below. The full source code, scripts, materials, and assets can be reviewed in the Unity Project.

Week 9: Paper Prototype by Valzorra

After our feedback session on the Friday of Week 8, Adam recommended that I create a paper prototype of the dice rolling mechanics and the actual process by which one selects abilities. I thought this was a fantastic idea, so during Week 9 I spent some time creating and testing the paper version of this mechanic. In order to do that, I needed to design a very simple level that allows for creative exploration, sufficient movement, and for all of the mechanics I had so far to be utilized. That’s why the goal of the Paper Prototype was to get from Point A to Point B, all while navigating an environment with enemies scattered throughout. My hope was that the simplicity of the level and goals would provide the perfect conditions for testing the actual mechanics without making things too complicated for players.

The first decision I made was to use a very basic Hex Grid as the hexagonal shape means that the player would be able to move to either side with only one space. By contrast, it would take two spaces to re-position the character diagonally if the grid were a made of squares. Using a Hex Grid also eliminates the necessity for any special rules relating to adjacent tiles and so on. While crafting the level, I filled in some of the Hex Tiles, to indicate that those blocks were walls, which means that the player and the enemies would not be able to walk over them or to see through them. Another key decision I had to make for the Paper Prototype was how many dice to use and what type. I chose to run the paper version with three six-sided die, because at this stage I had settled on a total of 7 abilities, including the Telekinetic one, which would allow you to alter the results of the roll. I’ve chosen to go for a set of three in order to give players a sufficient number of opportunities to make combinations with their powers and to come up with more creative solutions around the level. Based on user testing, the number and type of dice may change later on.

Dice.JPG

The Rules

At this point I knew what type of map I was going to use, and I knew what dice I would be using. I picked up a few high quality models from the board game Descent to function as placeholders for the player and their enemies. This meant that I now had all of the key components to test this paper prototype out. All that was left was to come up with a few basic ground rules of how this game would be played. The first important bit to figure out was how the turn system would work in this prototype. Taking inspiration from Descent, I decided that during a turn, the player would be able to perform to actions. One action would be a Movement Action, while the other would be an Ability Action. A Movement Action allows the player to move up to 4 spaces in any direction. Ability Actions will be described in further detail shortly. Once the player has completed their two actions, the enemies also get a turn. An enemy turn consists of another set of two actions, one Movement Action, and one Melee Attack Action. Enemies can also move up to 4 spaces in any direction, and in order to perform a Melee Attack Action, enemies would need to be located in a tile adjacent to the player.

It’s important to note that both the player and all enemies have only 1 HP, which means if anyone gets hit once, they are out of the game. This system has been implemented because to me it was crucial to set this prototype up as a strategic experience, rather than something you could fight your way through. Players must use their abilities in combination to maneuver across the environment and the enemies in a strategic manner, and their mistakes would mean death. This also correlates with my idea of Zeta as a character so far, because she is no brawler or fighter, which means that most enemies would have an edge on her physically. However, she is quite clever, which is why she uses her intellect to escape such confrontation. In addition to having 1 HP, enemies also have a stat for how far off they can see. Their line of sight is 4 spaces in any direction from the enemy, while the player does not have a limit to their line of sight.

IMG_2293.JPG

Now that I have discussed the basic Turn System of this prototype, and the basic stats of the player and enemies such as Movement and Health, it’s time to move on to the abilities. It was necessary to come up with a table of basic stats for each ability and to assign them to a number on the dice. Additionally, each one would have a certain range, which is indicated by the number of tiles in any direction it takes for that ability to reach its target. Some abilities would take place instantly, as soon as the player chooses to cast them, while others would have a predetermined duration. Duration is measured by the number of turns a certain ability would last for. The powers I have chosen to explore within this prototype are Teleportation, Shield, Blinding Light, Stopping Time, Chameleon, and Electrocution. I would like to take the opportunity to note that the Chameleon Ability is taking the place of what used to be the Sound Wave Ability. The Sound Waves, which used to reveal enemies behind walls, are not particularly useful in a top-down view camera, where the player would be able to see most things anyway. In contrast, the Chameleon Ability provides more opportunities for a stealthy approach to problem-solving.

  1. Teleportation

    • Dice Number: 1

    • Range: 5

    • Duration: Instant

    • Effect: Teleport the player to a desired location instantly.

  2. Ability: Shield

    • Dice Number: 2

    • Range: N/A

    • Duration: 2 Turns

    • Effect: Forms a protective shield around the player, allowing them to take one extra hit from an enemy.

  3. Blinding Light

    • Dice Number: 3

    • Range: 5

    • Duration: 1 Turn

    • Effect: Causes the player to emit a blinding light from their body, temporarily stunning enemies and rendering them unable to act.

  4. Stopping Time

    • Dice Number: 4

    • Range: N/A

    • Duration: 1 Turn

    • Effect: Stops time for all enemies and NPCs, except for the player. The player is able to move and use other abilities while time is stopped.

  5. Chameleon

    • Dice Number: 5

    • Range: 5

    • Duration: 2 Turns

    • Effect: The player takes on the form of a chosen enemy within the range of the ability. Once the player has put that mask on, enemies would not attack them, as the the player would appear to be one of the enemies.

  6. Electrocution

    • Dice Number: 6

    • Range: 2 + 1

    • Duration: Instant

    • Effect: The player can damage a selected enemy within range with an electric bolt. If there is another enemy within one space of the first target, then the second enemy will also take damage from the electric bolt.

Those are the six available abilities and which number of the dice they correspond to. The interesting and innovative mechanic that we are testing here, is the actual manipulation of the dice roll. Players would be able to change the roll and strategically plan which abilities to use. As they roll the three dice they would be able to make a total of three changes to them. From left to right, the first die could be changed twice, rotated both along its X-Axis or along its Y-Axis, essentially leaving the player to choose any ability on the die. The second die from left to right could be amended only along one axis, either the X-Axis or the Y-Axis. The third and final die cannot be changed and the player would have stay with that ability and figure out how to implement it in their solution. Players can cast these abilities in any order they choose, and they are not required to cast all three. I believe that sums up most of the statistics and core mechanics of this paper prototype. So far, it seemed rather promising and it even made me think that this would not be a bad idea for a board game as well. However, as I am intending to include a fun little narrative within this experience as well, so far I will not be turning to the world of Tabletop Gaming. Now, without further ado, let’s have a look at how the testing went.

Testing the Prototype: Step-by-Step

Testing the Prototype: Changing the Roll

The example above showcases a step-by-step description of how the game would be played and how one could maneuver through the environment using the abilities rolled from the dice. However, in that specific, play-through the player did not feel it necessary to change any of their abilities because they were happy with how the dice rolled. Below I have embedded a video recording of a player who chose to change their first ability in the manner described above in the rules. The change their dice twice, once along the X-Axis and once along the Y-Axis. They chose to keep their second and third abilities unchanged. Unfortunately, the player was not successful in completing this level as one of the enemies was able to complete their turn and get in melee distance of the player. However, this play-through showcases the mechanics beautifully and according to the rules.

Thoughts and Reflection

Overall, I was very pleased with how the testing sessions for these mechanics went as it genuinely seemed kind of fun. The prototype did exactly what I was hoping it would do and it gave players the opportunity to choose how they would maneuver through the level. Each time the level was tested, players used different sets of abilities to solve the puzzle, many of which worked. This means that the mechanic successfully provides a variety of different solutions to the same problem, making each play-through unique. The condition of all characters having only 1 HP made the prototype all about strategy and forced players to think carefully about what powers they used and when. What’s more is that it seemed like all of the mechanics transitioned to the board game format beautifully, thus providing a fairly accurate idea of how this would work in a video game.

The first test conducted allowed players to roll the set of dice without any limitations, so long as they exhausted all three abilities per roll. In that test, the level was solved without much trouble and with the use of only four spells. After that test, James recommended to try and set a limit on the number of times one could roll the set of dice. We tried playing it again, under the condition that there could be only one roll. This made the game a bit more difficult, however, it was still manageable provided players planned their movements carefully. At this stage, James made another great recommendation, which was to allow players to roll the set of dice as many times as they needed, however, with each roll after a predetermined number, the enemy’s line of sight would increase. This could work quite well because it means that if players are stealthy and as strategic as possible, then they would have an easier time solving the puzzles. On the other hand, if they use their abilities recklessly, they will be a lot easier to spot, putting them in increasingly difficult positions.

Another revelation from these tests concerned the individual abilities themselves, Teleportation, Chameleon, Electrocution, Stopping Time, Blinding Light, and Shield. As I watched people play the paper prototype I came to the realization that some of the abilities are functionally identical. For example, there isn’t a great deal of different between what Stopping Time and Chameleon do, they both help the player move undetected. This has prompted me to analyze each individual mechanic again, to rework some of them, and to figure out a better set of abilities, which would be more exciting and varied. I will aim for each ability to fulfill a different function and to be more interesting than just the first thing that comes to mind, which I have realized is what a lot of the current abilities are. This massive redesign of the individual powers will commence next week and I may even need to change the type of dice I end up using.

These are the type of questions and considerations prompted from this very simple paper prototype. Once all of these mechanics are also implemented in the digital version, I would have a much greater understanding of what could work in that format and how to balance it properly. The main bit to take away from these testing sessions is that the mechanic of dice rolling not only seems to work, but it also quite fun and that the individual abilities will undergo a redesign. I look forward to continuing the tests digitally.

Week 8: Prototyping Abilities in Unity by Valzorra

Having crafted a basic system for the camera and movement of this prototype, I thought it was now time to introduce some of the fun abilities that would help players maneuver through the environment. At this stage, I had a very rough idea of what I wanted those abilities to be based on some initial idea generation in Project Proposal 4, As It Lies. I felt the strongest about Teleportation as it would give players mobility and flexibility and about Electrocution as it is a damage-dealing ability that would help players confront any threats. I would like to note that these have not yet been set in stone and could be amended or removed as the design and development process progresses. Additionally, I would also like to reiterate that the work described below has been a collaborative effort between James and myself and that this prototype would not be possible without his help and guidance.

Range Indication and Teleportation

The very first ability I wanted to try my hand at was the Teleportation Ability. The exact methodology of how this power would work has been described in detail in Project Proposal 4 in one of my storyboards within that post. However, to briefly summarize, once the player has selected that ability, they will be presented with an indicator of their range in the form of a circle around them. The player would then be able to click anywhere within the Range Circle to select a target location, and after they have made their selection, they would be instantly teleported there. There were a few problems to solve within this description, the first of which was to figure out how to best implement the Range Circle Indicator, which would be used for a series of other abilities as well. I knew what I was going for, which was ideally a large circle around the player, which would give them a clear indication of where their abilities stretch up to. Additionally, the Range Indicator needed to appear only as players are about to perform an Ability and had to disappear and reset as soon as the ability has been executed. That way, players would not have circles all over their screens without necessity. A terrific example of the type of indicator I wanted is constantly used throughout League of Legends as shown below.

League of Legends Range Indicator

For my own prototype, the Range Indicator was handled through the use of a very basic cylinder, scaled to X: 1, Y:0.0001, and Z: 1, making it as close to a two-dimensional circle as possible. That Cylinder was then placed straight on top of the Player, keeping them in the center. The Cylinder was then parented to the Player, which meant that as the Player moved, so would the Ranged Indicator. Additionally, in order to see the scene clearly, a Semi-Transparent Material was added to the Range Indicator with the transparency set to 50 out of 255. At this stage, I had a very simple environment and a Player character with a large semi-transparent circle on top of their head, meaning I was ready to actually make the Range Indicator work. The system for it functions in a similar but slightly more intricate manner to the way Player Movement is handled as described in Week 8: Prototyping the Camera and Movement in Unity.

This is how the Range Indicator appears in the prototype for Teleportation.

This is how the Range Indicator appears in the prototype for Teleportation.

The first step in the process was to indicate what the maximum range of Teleportation would actually be, which was determined by a simple float. For the purposes of this prototype, the value has been arbitrarily set to 15. The next step was to ensure that the Range Indicator would only be displayed when the Teleportation was actually used. As the Range Indicator would only really be needed if an ability has been activated, its Mesh Renderer was disabled in Unity for all other general purposes, making it invisible to the user. The only occasion on which the Mesh Renderer is enabled through code, is when the player presses down any keys associated with the activation of powers. For the purposes of this prototype, I have set it up so that pressing T activates Teleportation. The dice rolling mechanic will be implemented at a later point. Once the Mesh Renderer is enabled, the other important aspect of displaying the Range Indicator is ensuring that the Circle resizes itself according to the range of each ability as indicated by the associated variables. To do that, a line of code has been implemented, which states that if the Current Power is Teleportation, then the Range Indicator will be scaled in accordance with the maxTeleportRange variable. This is basically how the Range Indicator is handled within this prototype not only for Teleportation, but for all of the abilities that would need it. Therefore, the entire system for displaying the Range Indicator has been compacted in a switch statement as showcased below.

void ShowRangeOfPower() {
        switch(currentPower) {
            case "TELEPORT":
                //Enabling the Mesh Renderer
                rangeIndicator.GetComponent<MeshRenderer>().enabled = true;
                //Scaling the Range Indicator accoring to predetermined variables
                rangeIndicator.transform.localScale =
                new Vector3(maxTeleportRange, 0.01f, maxTeleportRange);
                break;
            case "ELECTROCUTE":
                rangeIndicator.GetComponent<MeshRenderer>().enabled = true;
                rangeIndicator.transform.localScale =
                new Vector3(maxElectrocuteRange, 0.01f, maxElectrocuteRange);
                break;
            //If no powers are selected, the Meah Renderer is Disabled
            default:
                rangeIndicator.GetComponent<MeshRenderer>().enabled = false;
                rangeIndicator.transform.localScale =
                new Vector3(1f, 0.01f, 1f);
                break;
        }

After the algorithm for the Range Indication had been sorted, it was time to code the Teleportation itself, which was a relatively straightforward process. The function works by casting a Ray from the Main Camera directly onto a location in the environment selected by the player. Just as with Walking, the Player can select a target location by pressing the Left Mouse Button. The function then checks whether the the target location is within the predetermined Teleportation Range and whether it is on a Walkable surface as indicated by our NavMesh. All floors within this testing environment have been marked as Walkable and if the player were to click anywhere else to move, such as on a building or outside of the environment, then the Player Character will be taken to the closest point to their selection. If the target location answers to both of those conditions, then the Player Game Object will be Warped to that point. The last bit of that function simply states that once the Teleportation is completed, then currentPower variable goes back to Null, thus resetting the whole process. The Teleportation function used in the prototype is displayed below.

 void Teleport() {
        RaycastHit h; 
        if(Physics.Raycast(Camera.main.ScreenPointToRay
                          (Input.mousePosition),out h, 100f)) {
            //If the Player Selects a location in Range and on a Walkable area
            if(Mathf.Abs((h.point - transform.position).magnitude)
              <= maxTeleportRange && h.collider.gameObject.layer == 9) {
                nAgent.Warp(h.point);
            }
        }
        currentPower = "NULL";
    }

That’s the basic premise of how both the Range Indicator and the Teleportation Ability work. The player can move freely within the environment and once the press T, a large circle will appear around them. If the player clicks on a surface within the environment that is also within the Range indication with the Left Mouse Button, then the player will be instantly teleported to that location. Currently there is no cool-down of any kind on the Teleportation, which does make it kind of fun to play around with. Below I have attached a few screenshots to display how the Teleportation Mechanic works in the prototype, and a video will be available in future blog posts.

Initial Phase of Teleportation: The Range Indicator appears in front of the player, allowing them to select a location.

Initial Phase of Teleportation: The Range Indicator appears in front of the player, allowing them to select a location.

Final Phase of Teleportation: Once a selection has been made, the player is transported there instantly.

Final Phase of Teleportation: Once a selection has been made, the player is transported there instantly.

Electrocution

Now that the Teleportation mechanic had been created and fully functional, James and I thought we would move on to Electrocution as it is the only damage-dealing ability in the game, making it rather significant. The Electrocution mechanic works by allowing the player to select an enemy within a certain range. Once an enemy has been selected they will take a certain amount of damage. If that initial enemy has any number of other enemies surrounding it within a certain range, then those secondary enemies will also take damage. In a sense, it is a strategic chaining mechanic meant to represent electricity going through enemies. The first step in this process was to create a list that would contain all of the Enemies, which would be affected by the Electrocution. Then, the algorithm finds the first enemy that would be affected by checking whether the player has selected a target marked as Enemy and whether that target is in range. If the selected enemy answers to both of those conditions, then it is added to the newly created list of Enemies Affected. The player selects the first target by clicking on it with the Left Mouse Button, and a Ray from the camera locates the selection much like with Teleportation.

After the first enemy has been located and added to the List, then the script searches for other enemies in range that would also be affected by the Electrocution. To begin with, a check is performed to see whether the List of Enemies Hit is empty or not. If the List is not empty, then an Overlap Sphere Collider is placed over the existing enemy within that List. The sphere’s radius is equal to a predetermined maximum range for the Electrocution. The next check performed is to see whether or not there are any other enemies within the Overlap Sphere Collider. If there are, then those enemies are also added to the List of Enemies Hit. Through this method, we can get all of the enemies that would be affected by the Electrocution. After this list has been filled, Damage must be applied to the Affected Targets. For the purposes of this prototype, a very simple check is executes, which simply states that if an enemy is within the Enemies Hit List, then that enemy will be destroyed. That’s the overall logic behind how the Electrocution Script works and the code for it can be reviewed below. Images of the visual process within Unity have also been included.

 void Electrocute() {
        GetComponent<PlayerMove> ().enabled = false;
        nAgent.SetDestination (transform.position);
        RaycastHit h;
        List<GameObject> enemiesHit = new List<GameObject>();
        //Get Initial Victim
        if (Physics.Raycast(Camera.main.ScreenPointToRay
                           (Input.mousePosition), out h, 100f)) {
            if (Mathf.Abs((h.point - transform.position).magnitude) 
            <= maxElectrocuteRange && h.collider.gameObject.layer == 10) {
                enemiesHit.Add(h.collider.gameObject);
            }
        }
        //Find next victims
        if(enemiesHit.Count > 0) {
            Collider[] nextVictims = 
            Physics.OverlapSphere(enemiesHit[0].transform.position,
                                 maxElectrocuteRange/2f);
            foreach (Collider c in nextVictims) {
                if(c.gameObject.layer == 10) {
                    enemiesHit.Add(c.gameObject);
                }
            }
        }
        //Visual Effect
        for(int i = enemiesHit.Count - 1; i >= 0; i--) {
            if (enemiesHit [i].GetComponent<LineRenderer> ().Equals (null)) {
                enemiesHit[i].AddComponent<LineRenderer>();
            }
            enemiesHit [i].GetComponent<LineRenderer> ().positionCount = 2;
            enemiesHit [i].GetComponent<LineRenderer> ().material = 
            Resources.Load<Material> ("Materials/lightning");
            enemiesHit [i].GetComponent<LineRenderer> ().startWidth = 0.2f;
            enemiesHit [i].GetComponent<LineRenderer> ().endWidth = 0.2f;
            enemiesHit [i].GetComponent<LineRenderer> ().startColor = Color.cyan;
            enemiesHit [i].GetComponent<LineRenderer> ().endColor = Color.cyan;
            if (i == 0) {
                enemiesHit [i].GetComponent<LineRenderer> ().SetPosition 
                (0, enemiesHit [0].transform.position);
                enemiesHit [i].GetComponent<LineRenderer> ().SetPosition 
                (1, transform.position);
            } else {
                enemiesHit [i].GetComponent<LineRenderer> ().SetPosition 
                (0, enemiesHit [i].transform.position);
                enemiesHit [i].GetComponent<LineRenderer> ().SetPosition 
                (1, enemiesHit [0].transform.position);
            }
        }
        //Apply damage
        foreach (GameObject enemy in enemiesHit) {
            enemy.GetComponent<Renderer>().material.color = Color.blue;
            Destroy(enemy, 1f);
        }
        currentPower = "NULL";
        GetComponent<PlayerMove> ().enabled = true;
    }
Initial state of Electrocution: The Player has activated the ability and can now choose a target.

Initial state of Electrocution: The Player has activated the ability and can now choose a target.

Middle state of Electrocution: The Player has selected the only target in range and the damage has been distributed to the enemies surrounding the initial target.

Middle state of Electrocution: The Player has selected the only target in range and the damage has been distributed to the enemies surrounding the initial target.

Final state of Electrocution: The damage has now been dealt and all enemies are destroyed.

Final state of Electrocution: The damage has now been dealt and all enemies are destroyed.

Reflection and Feedback

Overall, I really enjoyed working on these mechanics with James, because of how fun they seemed to me even at the prototyping stage. Because there were no cool-downs to these abilities at this stage, they could be used in combination with each other. For example, I found it quite entertaining to use Teleportation to get in range of the enemies and to then use Electrocution to defeat them, all in a manner of seconds. I think that with the addition of new abilities and their refinement, even more fun combinations will be possible. In terms of challenges, I thought that the Electrocution mechanic was rather tricky, especially because it was quite difficult to actually visualize the effect. James and I tied to apply some sort of texture as opposed to a single colored Line Renderer, however, we did not have much success. This indicates that I would have to do some more research on how one achieves effects of Lightning that can be controlled. And although this is just a simple prototype, I would like to refine the Range Indicator and make it a bit more intuitive. The main problem with it for now is that it has to stay on top of the Player’s head, because any other position results in it colliding with the environment, which can look quite broken. However, these problems may end up finding their solutions in Semester 2, because there is still quite a bit of design work to do for this Semester. Nonetheless, I am really excited about what we have so far, and I look forward to developing it further.

IMG_2269.JPG

After a long week of prototyping we had our Formative Feedback Session with Adam on the Friday of Week 8. At that point, I was relatively up to date on what I had been doing so far, so thankfully he was able to see most of my work. We primarily talked about Project Proposal 4 or As It Lies and I briefly went over the main mechanics, the abilities, the dice rolling, and some elements of the world. Overall, Adam’s feedback was positive and he had some really good recommendations on where to take the project forward. For example, he recommended that I translate the game into a paper prototype, specifically for the dice-rolling mechanic and to ensure that it would actually be fun. Additionally, after seeing a 3D Model I was working on, he suggested that I create somewhat of a style guide to help narrow down the specific style of models and game overall. Adam also suggested that I should carefully consider what abilities to include in the game, as they shouldn’t seem random or boring. That’s why none of them have been set in stone yet, and I will be reworking some of the powers later on, possibly through testing with the paper prototype. Quite reasonably, Adam also expressed concerns about the size of the project as I am working alone. That’s why we agreed that I would create a timetable for the second semester in order to ensure that the game will be fully completed by the time it needs to be presented. I intend to start working on Adam’s recommendations as soon as next week, so hopefully I will have even more clarity and information by next Friday.

Week 8: Prototyping the Camera and Movement in Unity by Valzorra

In addition to some experimentation and practice with 3D Modelling in Blender, Week 8 was also dedicated to developing a basic prototype in Unity around Project Proposal 4. I should also mention that for now the working title for Project Proposal 4 is As It Lies, so I will be referring to the game with that title in all future documentation until it is changed. The first set of important decisions that needed to be made in regard to the digital prototype was how to the camera and movement within this game would work. To answer both of these questions, I needed to ask myself what is the actual goal of this game, what am I hoping to achieve, and what is the essential experience I want players to go through. For now, I knew I wanted this to be a problem-solving experience where players would have to navigate through an environment by using a series of special abilities. As previously described, the abilities would be determined by the roll of a set of dice and players would be able to control and change the roll to some extent. With that in mind, this game is very much a strategic experience, and I would not like it to be possible for users to punch their way through the level.

Camera Angle

Having narrowed down the overall experience I would like to create, I began analyzing different camera perspectives to try and figure out which one would be the most appropriate one. The first version I analysed was the standard over-the-shoulder or third person camera angle. These type of cameras are usually used when the character and how they act is rather significant to the overall experience, shifting the focus away from the environment. We explored a lovely version of this camera angle in one of our Tech Workshop Session, so I had a pretty good idea of what it would look like in the game. However, I decided against it, because a large part of the screen with a third person camera view is focused on the player’s character rather than on anything else. This would be very problematic because precision and accuracy would be rather important in this strategic problem-solving game. Additionally, the solutions to levels would be incorporated within the level design, which means that the environment would be a major focus of the game. Therefore, I knew straight away that third person was not the way to go for this project.

Example of a Third-Person Camera Angle in Skyrim. Nearly 1/3 of the screen is occupied by the character, which is not ideal for As It Lies, which needs to give you an accurate view of the surroundings.

Example of a Third-Person Camera Angle in Skyrim. Nearly 1/3 of the screen is occupied by the character, which is not ideal for As It Lies, which needs to give you an accurate view of the surroundings.

Since I had established that the layout of the level would be the focus of this game, I started thinking about the potential of a first-person camera angle. First-Person Camera Angles display the game through the eyes of the protagonist, dedicating the entirety of the screen to the environment and the events going on in it. In theory, this sounds perfect for As It Lies, as it will enable players to look at their surroundings carefully, to analyse them, and to figure out how to maneuver their way through. However, even though this is closer to what I would ideally want for the game, it does not focus as much on the strategic and planning elements as much as it could. What is the most crucial about this game is the level layout and the careful positioning of separate abilities. As nice as a first-person camera would be, it does not allow for that careful strategic planning of using your powers. What’s more is that upon further investigation, I discovered that if As It Lies were in first-person, it would echo a series of other games in the genre more than I would like, namely Dishonored. What I want to avoid more than anything else is re-skinning a preexisting game, as that would make the exciting dice-rolling mechanic fade. Therefore, I had to take a look at other options.

As fond as I am of the First-Person Camera Angle, it is not appropriate for As It Lies, because it neglects the strategic elements I want to convey and it makes the game too similar to what’s on the market.

As fond as I am of the First-Person Camera Angle, it is not appropriate for As It Lies, because it neglects the strategic elements I want to convey and it makes the game too similar to what’s on the market.

After taking a look at those two options and realizing they would not work, I began analyzing a Top-Down or Isometric Camera Angle. Top-Down and Isometric Camera Angles places the player above the main action and scenes, often giving them a bird’s eye view of what’s going on. This wide oversight of an area is the most precise and accurate way to make strategic decisions about the environment. This gives the player complete and total control over what is going on in the scene allowing them to make the best possible judgement on how to solve the situation they have been placed in. The only problem with a Top-Down/Isometric Perspective is that is detaches the player from the events, thus making it more difficult to establish an emotional connection. However, the main goal of As It Lies is to provide an exciting experience with environmental puzzles all wrapped up in the context of an exciting world and story. Therefore, as long as players are having fun, emotional attachment to the game is not a priority.

I would like to take this opportunity that the Camera Angle of As It Lies is closest to Top-Down/Isometric, but would likely be a mix between that and the General Third Person View. This combination would still provide enough flexibly for strategy, but would help the player connect with the protagonist and events that are going on more-so than a pure top-down view. Additionally, this would give me more flexibility as I could chose where to lock the camera based on the level and I would not be confined to solid view that’s always straightly vertical to the ground. The closest example I can think of would be the League of Legends Camera System, which is locked into the same position, oftentimes onto the player and follows them as they move. The League of Legends camera system allows for careful strategic decisions and enables players to work together and see everything that’s going on in the scene. For more on Camera Angles, have a look at this fantastic blog post I found on Gamasutra.

A camera angle similar to the one in League of Legends would be ideal for As It Lies.

A camera angle similar to the one in League of Legends would be ideal for As It Lies.

Creating the Prototype and Movement

After I had made my decision about what Camera Angle would work best for As It Lies, the way the player would move in the environment became very straight-forward. Traditionally, Top-Down and Semi-Top-Down Camera Angles are accompanied by a mouse-click system for movement. Therefore, at this stage I knew that I wanted the game to have a Top-Down Camera View, similar to League of Legends in terms of angle, and that the player would move through the environment by using their mouse to click on a target location. Now that I had come to those conclusions, it was time to actually make a prototype in Unity that would showcase how it all works. I would like to note that as I am not a very experienced programmer, I had quite a bit of help from James in the creation of this prototype both during our Tech Workshop Sessions and beyond. Therefore, anything you see from here on out in Unity has been a collaborative effort between the two of us.

To my surprise, crafting a locked Top-Down Camera that would follow the player is actually quite easy to do. The first step of this process was to position the camera adequately, so that it fully shows everything that’s going on in our testing environment. For the purposes of this prototype the Camera was locked in a relatively arbitrary position, above the testing environment and player, in such a way that it would display them efficiently. After that, a basic Camera Move script was created and the first thing that script does is to locate the Game Object in the Scene tagged as “Player“, which in this case is a basic cylinder. After the Player has been located, the script takes into account any changes in the player’s position according to the coordinate system. After those changes have been calculated and assessed, they are applied to the Camera in the same manner, causing the two objects to move simultaneously. That way, the camera is constantly looking at the player from a predetermined angle and is moving along to the actions of the player. Below I have attached a few screenshots of the scene in Unity and the code for the Camera Movement as an image and in text format.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class CameraMove : MonoBehaviour {
    private GameObject player;
    private Vector3 offset;
    void Start () {
        player = GameObject.Find("Player");
        offset = player.transform.position - transform.position;
    }
    void LateUpdate () {
        MoveCamera();
    }
    void MoveCamera() {
        transform.position = player.transform.position - offset;
        transform.LookAt(player.transform);
    }
}

An example of how the Camera View Point is directly looking at the player. If they were to move, the Camera would directly follow the player, always keeping them in the center of the image.

Programming the Player Movement Script was slightly more challenging as it involved moving the character by mouse click rather than more conventional means such as a controller or keyboard buttons. First of all, I needed to do some work with Unity to determine the areas that could be walked over in this environment. This meant that I would have to bake a Navigation Mesh to indicate that the three green planes on the screen are Walkable Objects. Once that was created, I also needed to indicate which Game Object was the Player. Therefore, I tagged my basic Cylinder as “Player“ and proceeded to attach a Box Collider and a NavMesh Agent to that Cylinder. These Components in combination with the baked NavMesh are what would make the Cylinder move over this very basic environment. Both the Box Collider and the NavMesh Agent have not had any of their default settings altered. Now, with all of those Unity bits and pieces sorted, I could get down to the actual code. The Player Move Script works by saying that if the player presses the Right Mouse Button onto a Walkable part of the environment, then a Ray will be cast from the Camera to the location the Mouse Cursor is directly over. That way, once the player clicks on a part of the environment, then they will be automatically moved toward the location where the mouse was clicked at a predetermined speed. I have attached the code for the Player Move script below.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.AI;
public class PlayerMove : MonoBehaviour {
    private NavMeshAgent nAgent;
    private float currentSpeed;
    void Start() {
        nAgent = GetComponent<NavMeshAgent>();
        currentSpeed = nAgent.speed;
    }
    void Update() {
        GetPlayerInput();
    }
    void GetPlayerInput() {
        if(Input.GetMouseButtonDown(1)) {
            MoveToClick();
        }
    }
    void MoveToClick() {
        nAgent.speed = 0f;
        RaycastHit h;
        if (Physics.Raycast (Camera.main.ScreenPointToRay
                            (Input.mousePosition), out h, 100f)) {
            nAgent.SetDestination(h.point);
            nAgent.speed = currentSpeed;
        }
    }
}

Thoughts and Reflection

These were the first of many scripts to come. James and I designed and crafted the Camera Movement System and the Player Movement System, which will be the building blocks of the entire project. Overall, the process for these two scripts was rather smooth and James and I did not have too much trouble making decisions in regard to them. I did wonder for the longest time whether a first person or a top-down camera perspective would be ideal for this game. However, after seeing the prototype with the top-down point of view, I know we made the right decision, as this perspective accentuates the strategic elements of As It Lies. So far, I think this has been a terrific start to the prototyping process and I look forward to writing more code and designing the algorithms for the abilities, dice rolling and so on.