Principles and processes of game scripting – LO1
The difference between Scripting and Programming – P1
When it comes to creating a game, you need to decide how it will be created, some games can be created through programming entirely whilst some games are created through scripting. What is the difference between the two? First, I will look at Unity, an engine that I have experience with. When I create a game in Unity and I would like that game to have a character that moves I need a script which I can attach onto an object that will act as the player. What I wouldn’t need to do is simulate physics to drop a box on that players head [1]. The physics that is used is already created and is inside of the game engine. There are many other things that can be handled by a game engine without needing me to create code for that to happen, lighting, rendering, graphics or shaders. Each of those are pieces of programming. Game engines are used due to being pre-made versions of what can be created through programming. Programming is a game engine whilst scripting is what I can create through a programming language inside of that game engine [1]. Unity uses C# for its game engine, it is also used by a user to create a script with a function for a game. There is a difference between the programming and scripting in C# in Unity as the scripts created for Unity are Object Orientated [2].
I have used both programming and scripting to make games. I have used C# to create a script for a 3D action adventure game, Heatwave, where I created a mechanic that raises the players temperature when they step into the light, drops the player temperature when they are not in the light and when they are too hot and the temperature reaches its maximum the player takes health damage and dies when they have no health left to loose. I have used programming to create a simple arcade game, Painter. In this game the player aims and shoots a colour-changing cannon in order to match falling paint cans to the same colour as the bucket they are falling into. To create this I needed to write everything from the cannon shooting to the physics to make paint cans fall. In practice, Painter could only do what I wrote, If I wanted to have a shadow or lighting in the game, I would be responsible for programming shaders and lighting entirely, whilst in Unity, to create a Shadow I would need to create an already available light source and edit the settings in the inspector to create the desired effect. It is not my intention to discredit stand-alone programming and game creation outside of an engine but the complexity of and understanding needed to properly program and utilise is greatly simplified by an engine. The benefits of pre-assembled programming, game engines, is that they are not limited to what can already be found inside of the engine as there are multiple off the shelf programs that can add additional utility to a game engine, this software is refereed to as middleware, Wwise, Bink Video and Havok are widely used examples of middleware. Wwise is related to audio, Bink is used for cut scenes commonly and Havok is best known for its physics simulation seen best in the Red Faction: Guerrilla [3]. Everything that these examples of middleware can be seen inside of OTS game engines like Unity and they are commonly used by companies using their own proprietary engines which may not have these functions built in but die to the increased workload of functional programming, creating these systems from scratch, it is more cost and time effective to take the pre-existing middleware to implement into a proprietary engine. Summering the difference between scripting and programming. Scripting is used to create function inside of a game engine whilst programming is used to create function directly from the language.
Coding Conventions – P2
When it comes to producing code there are various aspects of good practice conventions for structuring code, examples of these practices are: naming conventions for variables, comments, indentations, or scalability [4]. When created in a script, a variable needs a name and the best practice to follow here is to give the variable a name that relates to its function. Using a stand-in name for a variable to test a function works but isn’t memorable for coming back in the future, as an example: if a player has a health system and in that script it is seen as “int A 100;” where the A is the variable for player health, anyone using the code won’t be able to tell the function of the interger from a glance naming the variable playerHealth or leaving a comment next to the line makes the code read easier for use. Related to naming conventions, camelCase is a naming convention which is used when naming a variable, using camelCase makes identifying variables simpler. In a player health script camelCase could be used to identify different variables with ease. the structure of camelCase has all the words of a variable as a constant string with the first word not having a capital letter whilst the rest of the words start with a capital letter, playerHealth and playerHealthRegeneration are two examples of how camelCase should be structured. Moving on to the next good practice to follow, comments. Similar to naming variables, remembering what each aspect of a code does is not always easily followed, using a specific key code will allow for a description of a specific piece of code in a larger script. Different languages use different key codes to comment on code, C# and C++ use double brackets // for comments whilst in Python the hashtag # is used. in HTML <!–Text Here –> is used to comment on code [5]. The reasoning behind comments is the same no matter what language is used, comments make code easier to understand. Another example of good practice is indentation, named variables make their function easier to remember, comments are to make the code easier to understand but indentation is used to make the code easier to read. Indentation is the visual structure of the code and is necessary to properly organize code. Indentation refers to the use of warps and breaks, spacing, and the length of each lines.
in this example, the code is indented, each line of code moves onto the next line and is nested into the previous function which can be seen by the black dotted line between each set of curled brackets { }. In this example the use of indentation makes it easier to identify which part of the code is a part of which if statement and that all of it is in the update function, allowing for more code to be added in the right spot in the future. In this example comments can also be seen and are shown by the double brackets // which are followed by green text, comments only apply to the line the brackets are on so the code in-between multiple comments are not affected by the frequency comments are used. The comments in there show that the void Update is something that happens every frame and the code in it will happen each frame when the game is running. The variables in the example are named after their use but are not camelCased so whilst the code follows most of the examples I have given, it is still not perfect yet even with indentations, comments, and named variables, the code is much easier to understand then without those examples of good practice.
Object orientated and functional programming – M1 D1
Object orientated programming is programming model that revolves around data and objects rather then functions and logic [6]. Examples of OOP (Object Orientated Programming) languages are C#, which is used to write scripts in Unity, and C++, which is used to write scripts in Unreal. The nature of OOP lends itself to actively updating and maintained programs, this is useful for games development as the scripts written in OOP can constantly be updated as the game continues development. OOP allows for organisation of code [7], further lending itself to game scripts which can run past hundreds of lines for simple mechanics, scripts that large need to be managed for the sake of ease of use and lowering development time. OOP organises itself by the use of objects which hold information about state and behaviour, that information can be used to get objects to act in a certain manner. A character in a game that the player controls will have a wide variety of information needed for a complex control but an example of a simple OOP script would be applying speed to a basic cube, capsule, or other object when there is an input of the W key, an analogue stick is pushed forward or any other input that the developer wants the player to have. The speed the player moves at is the state this is because the speed is a characteristic of the object whilst the ability to use that speed when there is an input is a behaviour because it is something that the object does. One feature that OOP lends itself to when it comes to developing games is cohesion. Cohesion refers to grouping code together that contribute to complete a task. Having many different functions in a script that refer to the same one script is low cohesion and creates needless complexity, grouping various lines into one function that is used elsewhere gives one point of access between the two rather then several which can make organising code easier and is a good practice to follow. Referring this to a game, a player has health and there are three different enemies that deal different levels of damage. The player has one script and the three enemies have one script (using the same script and changing variables to account for different damage is an example of a state as it describes the damage the enemy can do), the example of cohesion is putting three enemies in one script. The object would have its own animations that share a trigger that the script activates and have different states that can be changed to be independent of the other enemies. There are several other functions that have an impact on the usefulness of OOP in games development such as coupling, encapsulation, abstraction, inheritance, and scalability. Each of these functions are specific reasons for why OOP is a good match for games development.
Whilst many features of OOP leads to it having benefits for game development, there are still downsides, complexity is a major factor in OOP. OOP gains benefits from its features like encapsulation and inheritance but the knowledge required by someone to know what that entails and the knowledge to write scripts taking advantage of OOP. Looking back to the example of cohesion, one enemy would be simple to program, health, damage, attacks, and animation triggers. Knowing how to put all of those states and behaviours as one that is shared and modified for the three enemies is a leap in complexity and the lines of code added to the script to account for three enemies lead to scripts with hundreds of lines to dredge through, bloat and size is another disadvantage that OOP has [8]. Cohesion bumps up the complexity and the scalability leads to bloat. It is likely that a game developer is not well versed in scripting, and if they are there’s a chance that they aren’t knowledgeable about OOP specifically, the complexity of OOP allows for the wide variety of use cases that the games can need but limits the capabilities of developers young into the career. What games have overcome the challenges of OOP and have used it to create games? OOP is widely used in the industry, many games have been made using languages based on objects, C++ and C# dominate the industry for scripting games, both languages known for their OOP capabilities as opposed to C. Doom Eternal, a AAA title, was made in id Tech 7, id Software’s own engine, which uses C++. Risk of Rain 2, an Indie title from a small studio, was made in Unity and used C# for its programming. From third person roguelites to first person chaotic shooters and then to Stardew Valley (written with C#), OOP provides such variety that it is used in a wide range of genres throughout the industry. The variety of games that can be made using OOP shows that the downsides of OOP are not to difficult to overcome, Doom Eternal may have been made using OOP and over 200 developers, Risk of Rain 2 was produced by 4 people using OOP and then Stardew Valley was made by just one person. A single developer being able to make an award winning game shows the benefits that OOP provides to the creation of games.
Functional programming
Functional programming, like OOP, is a paradigm for programming. FP (Functional Programming) is a model for solving problems. OOP uses states and behaviours but FP uses pure functions to write code, a set of instructions written in a programming language to complete a certain goal or solve a problem. In FP, functions are given more importance then in OOP as they cannot interact with outside elements [9]. Functions cannot change their state, the exact opposite of OOP. Functions act singularly and are best for concurrency which allows multiple functions to run simultaneously. Concurrency has very little use in game development. In many games, there are dozens of NPCs (Non-Player character) and each of them require pathfinding to navigate the complex environments of a world and to avoid other NPCs. Pathfinding is one of the common intensive functions in a game but moving this process to a separate core (concurrency works through the multiple processors modern computers have) and then fetch the pathfinding data after a batch is complete, the NPCs will be able to path find for a short amount of time before the next set of information is needed, when a player walks, the pathfinding of NPCs will need to reflect the players position and so more pathfinding data is needed. As this process continues to happen, the performance of the game is likely to dip due to the constant need for fetching and receiving data, halting other needed information such as rendering, NPCs aren’t expected to be high level intelligence but the visual fidelity of the game faltering is going to leave a sour taste in the players experience of the game. If FPs main benefit, concurrency, is not helpful in game development, what benefits does FP bring to the creation of games?
Games have been made using functional programming languages, the use case of one example [10]. ClojureScript, a functional language, was used to create the mechanics of a simple 2D platform game. Concurrency has a use case in this example as the functions are used as independent mechanics, the gravity of the world, the speed of the player (controlled by inputs), jumping, and the visuals of the player and environment. One of the drawbacks of OOP is the complexity, not only is the scripts based around objects and the actions made by the developer revolve around using objects. In this example, FP highlights the simplicity provided, the graphics of the game are created in the script of the game as opposed to with complex geometric objects. The squares/platforms and the circle/player are simulated shapes which are created through programming.
Languages for games – D1
Why is OOP good/bad for games?
Object based programming revolves around states and behaviours
Pro – states are characteristics, descriptors of what the object is [7]
Pro – behaviours are what the object can do and the actions it can preform [7]
Con – Complexity
Why is Functional programming good/bad for games?
Pro – Lack of states and behaviours lowers the experience needed to use
Con – Concurrency has limited use-cases in the wider industry
Which one is the best fit for game development? Why? What are the features that make it better?
When it comes to creating a game, one question that needs to asked is how is it going to be made? The difference between OOP and functional is so great that the choice made will change the game. What choice should be made? Starting with OOP, the pro’s of this language are the states and behaviours that the languages functions off of, these allow for a script to have complex functions to create complex and in depth mechanics. OOP allows you to package together data states and functionality to modify those data states, while keeping the details hidden away. This means that a games functions can be modified in real time such as the health, stamina, or other information about the players stats. Complex functionality is a crucial component that allowed for modern games to become a staple of entertainment.
Bibliography
[1] Scripting language vs programming language: What’s the difference? (2022) Scripting Language Vs Programming Language: What’s The Difference? InterviewBit. Available at: https://www.interviewbit.com/blog/scripting-language-vs-programming-language/#:~:text=A%20programming%20language%20is%20a,Most%20programming%20languages%20are%20compiled. (Accessed: February 2, 2023).
[2] Momin, I. (2021) Object-oriented programming (OOP) - unity C#, Medium. Medium. Available at: https://imran-momin.medium.com/object-oriented-programming-oop-unity-c-aa0179999e85#:~:text=If%20class%20and%20struct%20are,program%20should%20work%20and%20communicate. (Accessed: February 2, 2023).
[3] sharker1234 (2022) Red faction: Guerrilla – Physics & Destruction, YouTube. YouTube. Available at: https://www.youtube.com/watch?v=PvkSpj75ufE (Accessed: February 2, 2023).
[4] https://www.thinkful.com/blog/coding-best-practices/ (19.04.2023)
[5] https://geekflare.com/how-to-add-comments/ (19.04.2023)
[7] https://varad-kajarekar19.medium.com/object-oriented-programming-in-game-development-1293e6ebed45 (27/04/2023)
[8] https://unstop.com/blog/advantages-and-disadvantages-of-an-oop-paradigm (27/04/2023)
[9] https://www.spec-india.com/blog/functional-programming-languages (27/04/2023)
[10] https://www.youtube.com/watch?v=7XUWpze_A_s&t=2s (27/04/2023)
Planning Game Script development – LO2
Scripts needed for the game – P3
The game is a VR based horror game where the player is tasked by the nature magazine they work for to take pictures in a specific environment and then develop those photos before sending them to the magazine for publishing. The aspects of horror do not become apparent till the end of the game where upon developing the last photo, it is replaced by a supernatural being. When the player goes to leave the entity from the photo is behind the door. The brief outlines that the game is to be made in VR but does not limit the genre or theme of the idea, VR functions are outlined in the list of scripts, locomotion and interaction with objects are the aspects that reflect on the brief whilst the Camera, ghost in photo, and darkroom/photo development are all scripts which relate to the game which is not limited by the outline of the brief. The complexity of the camera script will take a considerable amount of time to develop as not only am I working with a bespoke mechanic that I have not created before, it is created for VR, a medium that I have not worked with. A portion of development time will go towards developing the camera as it is the main function of the game.
Project Management – P4 M2
There are several ways to plan production, three methods are commonly used in games production: the waterfall method, agile method, and the scrum method. Each of these methods function in different ways as each changes the development cycle. There are other methodologies such as Gantt project planning but these three methods are commonly used and provide variety in how to approach production management. The waterfall method is split into segments, each corresponding to a feature of production, progress moves forward once the last segment is completed. Agile development is structured in sprints which are development cycles which last any set amount of time, commonly 2-4 weeks. Before the start of each sprint, development is planned, what is going to be completed at the end of this cycle? How long will this take?/can that task be completed in one sprint? After planning, design and development of that feature is worked on before testing and then that feature is fully deployed and a complete part of the game. At the end of each sprint, the cycle is reviewed and the take-aways from that review will influence the content and structure of the next sprint. Scrum is the third method and works through sprint, like agile. How the rest of the method is structured is where development differs, what makes scrum its own method is the use of a backlog and daily scrum. Daily scrums, sometimes referred to as stand-ups, are small meetings with the team where the develop of today is discussed or the struggles of yesterdays development giving constant information to the rest of the team and keeping everyone up to date on the specifics of the sprint as opposed to a review at the end. At the end of a sprint, the total development of the cycle is reviewed and tasks that are not yet complete are moved into the sprint backlog. When the planning for the next sprint is beginning, the contents of the sprint backlog are assessed and put into continued development for the current sprint.
For the development of this project, I will be using the waterfall method, at the start of a week I will be working on a set task till completion or till the deadline of that milestone. Each milestone marks a feature of the full game. An important feature in the planning is a cut-off for the development of mechanics, all mechanics for the game need to be completed by 03/05/2023. Having a set date where mechanics need to be stages development into its own format, by that date the game will be mechanically complete and so most of early development is focused on creating the functions of the game so that after the cut off date work for the game focuses on the creation of content for those mechanics to be used.
Why use waterfall over the other two methods, agile and scrum?
Development of the game and scripts – LO3
Creating the camera script and mechanics – P5 P6 D2
In this code I had made an error which was apparent when I tried to take an in-game photo for the first time, the error I had made was in this section of code. When returning to the live display, I had not referred to the correct variables, LastImageShowTimeRemaining is the incorrect variable, it is supposed to be LastTakenImage, which is a toggleable game object. Referring to the wrong variable here perhaps could have been avoided if I where to have used a clearer naming convention, such as camelCase, which I could have noticed before attempting to test the camera. The mistake was an easy fix and did not causse any re-accruing problems but did highlight the use of camelCase, although I have already stuck to one Naming convention in the script so far and I will likely stick with the same naming convention in future development of this script as changing naming conventions part way through development is likely to cause more issues then the ones it would solve, in development of other scripts it will be useful to remember this incident.
The script works by having a camera in unity stream to a render texture which is then linked to a live display Raw Image which allows for the camera object to stream a live display of what the player can see. When the player takes a photo it switches to another Raw Image, last taken image. The last taken image is split into two, the variable LastTakenImage which is a serialized field so that it can be linked to a Raw Image inside of Unity and then a Texture2D LastImage which is not serialized as it is only used inside of the script. Even though the LastImage is not used in Unity it is still worthwhile to name the variable after its function. LastImage has to be a texture as the render texture (the camera) cannot be set to be the texture of a raw image (LastImageTaken) as it needs to be able to swap with the live display and show the picture the player took for a set amount of time before swapping back to the live display, the code for switching the live display and the players photos functions off of taking a variable and removing Time.deltaTime away, which takes down the LastImageShowTimeRemaining by 1 every second, having the LastImageShowTimeRemaining set to 10 will leave the players photo visible for 10 seconds. Once the time reaming reaches 0, the script returns the camera to the live display.
At this point the camera was working in theory but due to an issue with the installed XR Interaction toolkit it was not possible to test inside of VR but I was able to take a picture using the script using a VR simulation which then shows on a cube which I used as a test for the camera screen. After getting the base camera working I moved on to creating some UI for the camera. In-game the photos need to be developed and limiting the amount of photos the player can take is a reasonable precaution as allowing for a constant stream of infinite game objects may lead to issues that I cannot foresee and implementing this code now gives me an upper limit when it comes to coding the development of photos.
When the game starts, it sets the number of pictures the player can take to the variable which I can change in the inspector and sets the display counter for the number of shots. When the player goes to take a photo, the first thing the script checks for is the number of pictures the player has available if the player has used all of their film, the TakePicture() function “returns;” which stops the script before it can take a photo. The last part of that code ticks the NumShotsRemaining down by one and then updates the display for the player and shows how many photos they have left. After setting up the limit on player photos I made it so the photos the player took are saved as a jpeg.
The first line fetches the current real world time and date to use in naming the file, the second is setting up the file name, the name of the photo is set to show the current month, day, hour, minute, and second followed by a number which corresponds to the player photo and number of shots. If a player where to take a photo now it would show “Shot_0420_101638_1.jpeg”.
At this point I started working on developing the players photos. When the player takes a photo with the camera, it is saved temporarily in Unity as an actual photo file. My first idea was to assign the photo the player took to a material and then when the player creates their photos, the material would be applied to an object and show the players photo.
The code originally used the second line (Graphics.Copy…) in order to transfer the texture from the camera and render texture to a Raw Image. When I started work on saving the players photos I found that the resulting file was a blank image. The reason behind this is that Graphics.CopyTexture works through the graphics card and in order for the image to be saved it needs to go through the CPU and so the rest of that code is used to format the players photo through a GPU request which allows it to be saved.
Feedback from testing – M3 D2
When developing the script for the camera mechanic, I had it so when the player takes a photo, the display on the camera freezes to show the photo for a short time. I did this so that the player knows when they take a photo. When creating the photo-limit this part of the script broke, fixing this was not high on my list of priorities as I had both a counter which ticks down when they take a photo and I set up a tigger to player a camera shutter sound effect when they take a photo. In the version of the game that has been tested, I sized up the display as other feedback had highlighted that it is not easy to see the camera screen. Re-sizing the display shrunk the text box which shows the photo counter and the sound effect that I had set up did not play when taking a photo, this lead to the taking photos being unresponsive which lead to confusion on the testers behalf. In response to this feedback I have made informed decisions based on this feedback to the games scripts. The visual aspects of the camera are handled by a separate script to the camera that gives visual feedback to the player, the other camera is what takes the pictures that the player later develops. The separation of cameras is so that the player visual camera has a culling mask on the horror layer where aspects of horror are based.
The changes to the visual camera where based around removing additional code that broke the ability for the script to show the last image the player took. Showing the last picture the player took is half of the response to feedback, I have made alterations to the script that show a visual aspect of feedback, the next changes that need to be made is a sound effect of the camera shutter. This will only add a few lines to the camera script but will increase the responsiveness of the game, as according to the testing feedback.
These two lines play a camera shutter sound effect when the TakePicture function, further iterating on the feedback about responsiveness. Sound is a vital part of a game, in the work done here it gives an auditory notification of the players actions which further enforces the immersive nature of VR. Responding and considering player feedback before development is over allows the players of the game to have an impact on its development.
Evaluate game scripts and project development against feedback – LO4
Evaluating user feedback from different forms of testing – P7 M4
To test the final version of the game I have put the game through exploratory testing and play testing. Both of these forms of testing are used for different reasons, exploratory testing is about letting testers play the game and offer feedback on improvements that can be made and what is already good with the game. This type of testing lends itself to qualitative data, as the information gained from testing is opinion based, what one tester thinks is good about the game might be the same thing another tester thinks needs improvement. Quantitative data is numbers based and for getting information about the games players can be used to represent the pre-determined audience of the game that was founded pre-development. The two different types of data will lend itself to a broader evaluation of the game. The intended audience for the game was predominantly men aged between 20 – 30, how does the testing feedback represent this? The players who had the most enjoyment with the game where men aged between 20 – 30, directly correlating with my intended audience. The players who had the most difficulty with the game where women aged over 30. The scale of the play testing was small and so the fact that the player group that had most trouble with the game is not corelative to what data there could have been if the play testing scale was larger. The players would usually spend 3 to 5 minutes playing through the game before completing the experience, on par with the scale of the project and what I had predicted. Exploratory testing has provided a range of qualitative data which is where the majority of the workable feedback is derived from. This is a mix of positives and negatives, an example being that most players thought the controls for the game worked well and where interactive but for some players they ended up guideless on what they where supposed to be doing. What do players think about the game? What is an appropriate evaluation based on the qualitative data I have received? The main feature of the game is the ability to take and develop photos the player takes in game, the most common piece of feedback is around the camera mechanic, some mentioned bugs such as when the camera is held at an angle, the screen clips into the body but most was about how the idea behind the mechanic and game is intriguing and though the execution could have been a more polished experience the premise of the game is interesting and having a working camera inside of VR is impressive. The main focus after the camera is the aspects of horror in the game, the main feature of the horror takes place at the end of the game, when the player takes their las photo there is a knock at the door and at the end of the hallway there is the same creature that the player can see in the photos they have taken but this time the player can actually see the creature instead of through the pictures they have developed. When working on the game, I had no issues with this part of the game but I knew what was going to happen and what the player needs to do so I did that but the playtesting that I have done shows that the player is not as quick as I am and so they do not reach the door or reach the correct door before the creature hits the end of the hallway “killing” the player and sending them to a hallway where there is a message and a large copy of all the pictures they have taken. A notable piece of feedback was to split this into stages. When the player develops their last photo, their is a knock at the door and the creature starts moving I was suggested to have it so when the player goes to the door and opens it, the creature starts to move, assuring that the player sees the creature moving towards them and allowing them to experience the end of the game rather then wonder why they disappeared. The third focus of the game was the environments of the game, during testing of the game before I was finished, the space for the player to develop the photos was visually bland and uninspired, in the current finished version of the game, the player has a small desk where there is a printer and copier which the player interacts with to spawn and develop the photos that they took. In the feedback from the exploratory testing, player found that sometimes when the printed the photo, it went flying out of the printer. A side-section of the environment was the audio. Good audio goes un-noticed but a lack of audio or low-quality audio breaks the immersion of the player to a point where the quality of other parts of the game begin to falter. As VR is an immersive technology, the audio is more important then in the other projects I have worked on and the quality of the work I have done is represented in the feedback from playtesting where the nature sound-scape of the forest was complemented as immersive and emphasised that the world the player is in is a part of nature. Outside of the forest, the player has a home in a city where they go to develop the photos they took in the forest, the environmental detail in the house is used to show the player that they have recently moved into their home, the lack of normal appliances, stacked boxes in the corner and dishes piled on the counter. There where several negative pieces of feedback that did not fall into a similar category as the positive feedback I have received. Some of the feedback here is related to bugs that the player encountered in the game. It is possible for the player to walk out of the intended area in the forest and fall out of the map, also in the forest the lighting is too dark in the shadowed areas and details are hard to make out. For some players, they where to high up which made interacting with the world difficult as actions that are normally waist height where close to the knees and the leaning down and back up to interact with the world made the players motion sick. Another issues involves the player moving backwards, the cause for this is holding objects too close to their chest, the object needs colliders in order to be picked up but those colliders collide with the collider of the player XR Origin, which is needed to move around the world. Both things need colliders to be used in VR which is unfortunate as in my time developing the game I could not find a solution for the issue. Another issue is that on the info UI that can be seen around the world there are some mistakes such as asking the player to look left when they need to look right or mistakes in punctuation. Overall the game is a well-rounded experience, it may have a collage of issues but no issues that stop the player from enjoying the experience as a whole. The world the player explores alongside the audio and mechanics creates an immersive experience and the shock and confusion of the players when they reach the twist does not replicate a horrific experience to the point that I was originally intending. The development of this game has taught me much more then I anticipated and will have an impact on the future of my development. Being able to develop on a platform that I have not worked with before and deliver a bespoke experience to the player opens up new pathways for what games I could make or work on next. Out of the games I have developed, this game is the most technically impressive and I would consider it my best work yet and I have delivered on what I intended to develop.
Comparing game scripts to my intentions and plans – P8
Before starting development, in accordance with the brief, I created a list of scripts that I would need in order to create the game. How does the end product match with the specification of scripts that I set before development? Starting at the top of the list with the camera mechanic, the basis of the game, beyond the aspects of horror, was to take pictures in VR using a simulated camera. The script for that working camera was the bulk of scripting work needed for the game. There are specific parts of the script that are in separate sections but work together in order to create a working camera mechanic. The point in the script that makes the camera take pictures is the “public void TakePicture()”. This is a function that can be called upon in engine by various things and when it is triggered, the script inside of the brackets goes through a series of lines that work to show the picture to the player and also allow for that picture to be printed onto an in-game object that the player can interact with.
The next script that I outlined was a script that allowed for the horror aspects of the game to show up in the photos that the player takes and prints but not on the camera that the player takes the photo with. In the game this script was simplified into being called the Fake Camera. This name is inherent to how I went about creating it sa it functions off of similar code as the actual camera script.
Developing the photos the did not end up needing its own script and is partly handled with player input and the script that controls the actual camera. When the player takes a photo, the script creates an image and then adds that image to a list of images. After this, a raw image is set to have the texture of an item from the list of captured images, in game this shows as the player taking a photo and that photo showing as an in-game object.
The are several sound effects in the game and most are not handled through a script as Unity does not need to have sounds triggered through scripts to play them, they can be played automatically. Code is only needed to play sound effects at specific moments such as the triggering of the camera shutter sound effect when the player takes a photo. The code for playing a sound effect is simple, you need to assign a sound effect in the inspector and then in the take picture function, use the second line to play the sound effect. Specific settings in engine stop this sound from looping, if this wasn’t the case PlayOneShot(); can be used in order to play a sound effect once, no matter other settings.
The remaining scripts that I anticipated using are different forms of locomotion and interaction with objects. Both of those are scripts that I have not needed to create as they are handled by the XR Interaction Toolkit. What about scripts that I did not anticipate the need for? There is only one script that I have made that I did not anticipate and it is a script that resets the player when they fall off of the map. This is was an occurring issue during testing and so I reflected on that feedback and created a simple script that resets the players position to a set point when they collide with a large object below the map.
Another script that I did not anticipate was one to move the player to another environment where the story will play out and where the player can develop their photos. This script moves the player from the forest to their home, it also changes the skybox to reflect a passing of time, turns on fog in the renderer and turns off the directional light, which acts like a sun. Turning on fog and the sun off is to make the city environment look close to what it would if it where night.
Although it is not a script I made, I do use the functions available from the XR Interaction toolkits buttons. I have a range of uses for these buttons. There are two sets of ten buttons, one set of buttons are used to “print” a photo base, this also spawns the next button and plays a short sound of a printer. The next button is from the other set of buttons, these buttons use a photo base and activate the raw image aspect of the photos, making the players photos visible in game, these buttons also play a sound effect and spawn the next button which “prints” another photo. Overall, a large portion of the scripts developed where anticipated but certain functions like those seen in the Car Teleport script where not scripts I had originally outlined in my development plan
Jacob's game journal 