Pre-Production, Modeling & UV Mapping


Pre-production involves finding references or source material for the specific thing that you are modeling. If it is a realistic, real-life object, then images of the object, or even schematics, are appropriate. Otherwise, if it is original (e.g a character, monster, etc), it would be more useful find reference images that are similar and then use them to create concept art.


^Schematic/Blueprint of a ship. Retrieved from Anatoliy Nepochatov.


^Sometimes, an image search is all you need

The purpose of this stage is to provide a foothold/starting point from which to begin 3D modeling. In some situations, the concept art may be directly imported into the 3D modeling software. This allows the modeler to directly follow the contours of the concept art.

3D Modelling

This stage is all about creating a usable asset. There are many programs that can help achieve this, such as 3dsMax, Maya, zBrush, Mudbox and more. They are all a little different but the core principles behind them are all the same.


^Overview of modeling basics.

All of the programs rely on multiple vertices that form polygons or quads. By adding and arranging these vertices, it creates a mesh which is our object. It is a modelers job to manipulate the vertices and faces in order to achieve the desired outcome.


^A completed model of a radio.

The number of polygons that are in a model determine its ‘quality’. It is entirely dependant on the restrictions of the target device that the model is being made for, but there are typically two different qualities. They are low-poly and high-poly. This simply refers to the number of polygons that a model is made of.

Finally, the structure and distribution of polygons. This is referred to as a models topology. On non-static models, e.g characters with animation, it is important that joints that move have a higher poly count so that movement looks smoother.

UV Mapping

UV Mapping is the process of ‘peeling’ the ‘skin’ off of the model and flattening it into a 2D image.


The left section of the above image is the UV. It shows every face of the model but on a flat plane. This collection of faces is referred to as a UV Shell. By texturing the image beneath the UV Shell, the image is projected onto the faces of the 3D model.


As you can see on the image above, the colours and patterns that are on the 3D model can be seen on the corresponding UV Map. The UV Map on the right is made of a variety of shells all unwrap from the 3D model.



Nepochatov, Anatoliy. (3 May, 2017). Wargaming’s 3D Modeling Workflow. Retrieved from  

Pettit, Nick. Asset Workflow for Game Art: 3D Modeling. Retrieved from
Terävä, Tapio. (2017). Workflows for Creating 3D Game Characters. Retrieved from


Acclim: A Post-Mortem

The following document is a post-mortem for my game Acclim. You can find the game here.

Acclim was a group project created by Narisa Macleod and myself. The game is about a character named Harriet Danvers and her struggle with acclimatising to a new culture. Harriet has moved away from home and now lives by herself in a different culture. She is determined to prove that she can live away from home, despite the challenges that it brings.

The main element of Acclim is the letter system. Everyday, the player receives letter from from locals and family. However, only the letters from the family are in English. The rest are written in the local language. As the player progress through the days, the letters get translated from the local language to English. By day 28 (the last day in the game), all words have been translated and the player is able to fully read every single letter that has been sent to them throughout the game.

As of this writing, the game is currently unfinished. All playable content is in, I am just awaiting the arrival of some 3D models so that the aesthetics of Harriets’ apartment match the story.

The one thing I am most proud of in this project is the English to Gibberish system I made. The script takes an elements of English text and splits it up based on where the spaces are. Each word that has been separated is added to a different list called ‘Unique Words”. Once all the separate words are done, it removes any duplicates.

Next, there are two more lists. One called ‘Gib Terms’ and another called ‘Auto Gib Terms’. The Gib Terms list is blank and is there if you wish to manually translate the words. The Auto Gib Terms is a list just like Unique Terms, except all the terms are scrambled. Then there is a list of bools called ‘Translated’.

When the system wants to get an element of English text, it will search the list of bools to see whether the word is translated or not. If the word isn’t translated it will put the gibberish term in the text box. If the word is translated it will put the original English term in the text box.

The system can do this for anything from one word to pages of text.

Now then, what am I least proud of?

I can’t pick documentation, since I have already written about how bad that was here.

So if I can’t pick that, I would have to pick lack of collaboration.

Acclim started as a 3-man team but, not long after the project started, our programmed left. This means that I was left with all the programming duties. Because of my large workload, I was hesitant to approach other disciplines and continued to do my work. When I eventually presented to the other disciplines, most already had a lot of work on their plates and were unable to help. Fortunately I found two animators, but I was unable to find any audio students. Because of this, there is currently no audio in Acclim.


Improving Documentation

Acclim, the game made for the fourth project of Studio 2, struggled at the end of its development. There were too many times when Narisa nor I knew what to work on next. We finished working on one section of the game and spent far too long figuring out what our next step should be. The reason for this? Poor documentation.

We did write documentation, but we never updated it. The GDD (Game Design Document) still lists all our original ideas for the game and none of the pivots that we made. Hell, it still even details the mechanics we were going to have for the players’ phone. Since this document was so old, it was of no use to us by the end of development.

For a project with the scope of Acclim, we really required a detailed and up-to-date GDD, TDD (Technical Design Document) and Asset List. While we had a good Asset List and successfully handed that over to Animation, we had no TDD and an old GDD.

The lack of these documents lead to Narisa asking me what to do next, after she had finished her task. This, in turn, slowed down my workflow as I checked to she what she had done and what she could work on next. If the documentation was up-to-date, Narisa would have been able to look at the documents and decide what to do for herself, as well as how she could do it.

Our GDD needed to list all of the elements of the game from a design standpoint. This means it would need to show: what scripts are linked to other scripts, what needs to be in the scene, what elements are in the UI, how our letter system was going to work, what objects needed to be in the scene on each day, and more.

Our TDD need to detail each script that we were going to use. This means it would need to show: how the player is going to move, how the player is going to look around, how we are going to implement controller support, how the player is going to interact with objects, how the player is going to progress from one day to the next, how the player is going to trigger animations and, most importantly, how we are going to turn English text into gibberish and make the gibberish and English text appear in the same text box.

As a result of having neither of these documents, I had the take their role. It was my job to remember all the pivots that we had made and to remember what had been completed. This put an unnecessary toll on me and restricted Narisa to only working with script when I was around, since I was the only person who knew how it worked.

Use of Analytics in Unity

For the fourth project of Studio 2, we were introduced to Unity Analytics. Unity Analytics is a data platform that tracks certain aspects of a player and their gameplay. It doesn’t track anything automatically.

Unity Analytics does have some limitations though. It can only take 100 custom events per hour, per user. A custom event can track up to ten different parameters so long as the character count is below 500. Those ten parameters can only be one of these three different types of data: Booleans, Strings and Numbers (ints, floats, etc).

Acclim definitely could have benefited from using analytics. At first, I thought that I wouldn’t need analytics and could just rely on recorded video for playtesting because everything that I needed to know could be seen there. However, I didn’t account for how tedious it is to sift through video files.

If I had of implemented analytics, I would have set up a timer that runs in the background and given each interactable object type a label. This means that, when a player interact with an object, the time (float) at which they interacted with it and what the object is called (string) would be sent to Unity Analytics.

This means my custom event would look like this:


With this data, I would be able to see if players are interacting with all of the objects that I wanted them to and I would be able to tell how long players are taking to interact with objects. This would allow me to tell if an object is too small or too well hidden, or it might even show that players aren’t interacting with anything but the letters. That would mean that there needs to be more incentive to interacting with the objects that are around the apartment.

If I had of used analytics, I would have realised that people don’t check the wardrobe or the fridge, after the first day, sooner.


Improvements Through Playtesting

Playtesting is always a valuable tool for making a game better. People who have never seen your game before will give you insight that you wouldn’t find anywhere else.

Point in case, my playtesting for the fourth project of Studio 2. A problem that was pointed out by a player was the how small the window is for interacting with an object. It hadn’t occurred to me how, with a small window and a gamepad, it is really difficult to line it up correctly. For example, the only way to interact with the light switch in the apartment was to move the dot on the screen over the red circle on the image below.


After the player suggested that I make the area bigger, it occurred to me that there is no reason why the area is that small. It was just something that I hadn’t thought about and had just become accustomed to while developing the game. From then on, I just couldn’t stop noticing how some people were struggling with interacting with objects.

Because of that feedback, I have adjusted the size of the interactable area to be as large as the object. This fix should make it easier to interact with the smaller object in the apartment.

Implementation of Tutorials

Teaching people how to play my games is something that I have never really focused on before, much to my detriment. It always occurred to me as an afterthought instead of during development. As a result, all the games I have made have a info dump approach to tutorials.

Acclim is no different. The player is typically notified of the controls before playing through the description on the I say ‘typically’ because it is entirely possible for players to miss this before playing, which is one of the downsides to my approach.

I have tried to minimise the amount of controls that the player is required to remember in order to play. To do this, I took a ‘one button does everything’ approach when making the game. I have set all interactions to run off of a single button press. This means that players only need to remember three controls in order to play: Left Stick to Move, Right Stick to Look and Right Bumper to Interact.

While this approach is ‘working’, it isn’t ideal and may even prevent players from attempting to play my game. There are a few different approaches that I could use in the future.

I could use in-game prompts.respects.jpg

An egregious example, I know, but it was the first one that came to mind.

It is definitely very obvious what the player needs to do but it can be obnoxious if the prompt is constantly appearing throughout the game, especially if it is something very simple. It could be useful as a first time instruction though.

Another method I could use is the ‘tutorial room’.MGRRtut.jpg

This method places the player in a room where they given instructions that tell them how you play. Other than the instructions, the player has free rein over the player and are able to experiment with the controls as much as they want. It can be useful because it combines audio, visual and interactive teaching but you run the risk of overloading the player with too much information too early.

While the ‘tutorial room’ might not be appropriate for the scope of my current games, it is a good reminder that there are many different ways to teach the same thing.

For my games, I must at least start making some kind of in-game tutorial. I believe I will start with one-time button prompts that will trigger when the player encounters something for the first time as well as an option in the pause menu that lists all the controls. This will allow players to play the game uninterrupted and if they forget or there are controls that adjust settings, there will be a screen they can go to to check.

Storytelling in Acclim

The story in Acclim, the fourth project for Studio 2, is going to be told through a series of letters that the player receives from people. Each day, the player will receive new letters from the player characters parents, their boss’ secretary, their neighbours and an automated bot. This is the more traditional side of storytelling, the written word.

This, however, presents a problem because the letters are in gibberish and the player will be unable to read them. The reason they will be in gibberish is because we want to try to simulate the feeling of adapting to a new culture, and that includes learning a new language. So the letters from the characters who are native to this culture will write to you in their language. While this will interrupt the flow of the written storytelling, I believe it will also add to the environmental storytelling by making the foreign language more visible and the cultural divide more apparent.

To make sure the player is still engaged when the letters are unreadable, we included letters from the player characters parents that will be written in English. This will allow the player to understand their character and their characters’ motivations when they can’t read the other letters. Once the player has progressed further into the game and the letters have started to become translated, they can read the letters after knowing about the character.

The letter on the left is in gibberish, the letter on the right is from the parents.










As the player progresses, the apartment that they are in becomes more populated with items such as food, clothes and furniture. This is to reinforce the fact that the player is not seeing everything that is happening, that what they are looking at is snapshots of this characters’ life. This is environmental storytelling. It tells a story without words, without sound.

An example of such storytelling can be found in Portal, as well as in many other games.


Throughout the game, the player travels through white rooms and white corridors, with little to no dirt. But later in the game, the player can find a little nook with words and pictures scrawled on the walls.


These words and pictures tell a story all on their own. The nook is dirty and GLaDOS mentions not being able to find you. The scene is set up to show you a side of the game that you wouldn’t of seen otherwise and would seem out of place if mentioned any where else.

I try to use environmental storytelling in Acclim as well. Not as significant as Portal, but Acclim’s environmental storytelling is used to represent that the player character is starting to settle in to their new home. The fridge/freezer is stocked and the wardrobe is full. More objects get placed around the house to show that the player character is making the apartment their own.

The top image is the wardrobe and the fridge/freezer on the first day and the bottom image is on the last day.Room1.png






Inspiration: Presentable Liberty

For the fourth project of Studio 2, we were required to make a game around the theme of Home. Narisa pitched the idea of acclimatising to a new culture, the idea of having to adapt to a new home. She wanted the game to communicate the feeling of being in a foreign place, while maintaining a connection to the familiar. That is when I suggested the idea that the player could receive letters both foreign and familiar. After we discussed and ironed out the details, I began to look for games of a similar nature and I came across Presentable Liberty.

Presentable Liberty is a game where the player is locked in a prison cell, receiving communication from the outside in the form of letters. As the game progresses, the player receives gifts from the people who sent letters and those gifts start to fill the room. The letters that the player receives allows them understand the people who are sending the letters, as well as the world outside of the cell.


Below are letters from different characters.






What I want to draw from this game is how it tells its story. It limits the players’ visual stimulus by confining them in a single room but tells its story through multiple narrators, represented by a different font and a different letter layout. This allows the players to establish the world on their own, based on information provided by multiple sources. I believe this combination is a good way to spark a players’ imagination, provided that the writing is very solid.

Below is an image of a gift that the player is sent.


Also, the gifts that accompany some letters are a good way to establish a connection between the story and the players’ space. It gives the players a reason to care for the contents of the letters, outside of the story. Additionally, not all gifts are decorations. One of the gifts is an ‘entertainment system’ that the player can play mini-games on. It also serves as a way to pass time while waiting for new letters.


The player receives letters everyday. Some arrive at the start of the day and some arrive after you wait a while. The forced waiting makes the surroundings more enticing to interact with since they are all that the player has. This way, the player is coaxed into using everything they have been given and not ignoring anything.




Working For An External Client

The third project for Studio 2 was a team project and it was the first time I had ever made a game specifically for someone. A game with an external client who had the final say on elements in the game.

I was very fortunate with the external client i had to work with. In the early phases of development, she had a general idea and was very receptive to suggestions and feedback. This made it very easy to proceed into implementation but it also meant that certain elements required multiple iterations to be shown to the client.

For example, she asked for a 3rd-person camera but ‘3rd-person camera’ has a lot of possibilities. So we decided to create a scene that could switch between multiple cameras that are at different angles. This way, the client was able to actually see how the angle would look in-game. This was a huge benefit because it allowed us to know the rendering limitations of the camera early.

Something similar occurred when discussing the transition she wanted. The idea of the game at this point was that the player would be driving down a road and then it would transition to the player flying through space. However, how the player was going to go from the road to space still hadn’t been decided. In order to make the decision easier, we made an example of each transition that we had thought of.

While this was a good idea at the start, it quickly turned into a lot of work. Making the scene look decent enough was easy, but programming all the different transitions so that they would run appropriately on play was, perhaps, a little too much. I feel like the programming took too much of my time and a similar effect could be achieved with just a tour of the scene, which would need no programming.

The final hurdle of working with this client was audio. Since this game is being made to go with the clients’ audio, it is an element that was needed as soon as possible. At the start of the project, we were supplied with the audio but later realised that certain aspects of the game would be easier to achieve if the audio was run through FMOD.

This meant that we needed to approach the client about whether she would learn FMOD, which she wanted to. However, I approached her too late in development. It took longer than I estimated for her to set up the audio in FMOD, but ultimately that is my fault for not approaching her earlier.

For future projects, I must remember to establish what will be required for the project earlier and I must allot more time for learning new tools. I must continue to work on my ability to make fast prototypes. This project was evidence enough that an in-game demonstration is invaluable when needing to clarifying anything or to help decision-making. Prototypes are also going to be important in larger collaborative projects because it will help make sure that all collaborators are on the same page.

Reflections: A Post-Mortem

The following is a post-mortem for my game, Reflections. You can find the game here.

Reflections is a game based off of an artwork that I saw on my trip to GOMA (Gallery of Modern Art) called Lightning For Neda, by Monir Shahroudy Farmanfarmaian (further info on another post here).

In Reflections, the player can bounce colourful lines off of the mirrors that they are surrounded by. The longer the player charges the line, the further the line travels. There is no specific goal or objective in the game, just expression. The player can shoot lines of various lengths and various colours in order to make abstract art.

The most challenging, and most rewarding, part of this project was making sure the lines bounced correctly. The way that the game works out where to reflect the line is by Raycasts and RaycastHits. A Raycast travels in the direction that the player is looking, until it hits an object tagged ‘Mirror’. When it hits, the ‘normal’ (a Raycast that travels perpendicular to the object) is recorded. The code then figures out the angle difference between the incoming Raycast and the normal, then shoots an outgoing Raycast on the opposite side of the normal at the opposite angle.

I’m quite happy with how the mirrors turned out. Using a Render Texture on a Plane and a Camera behind the plane has given the effect of a mirror. An important thing to note is that each plane needed its own Camera and its own Render Texture assigned to it.

There are actually a few things that I would like to improve, if I had more time. Most importantly, I would have liked to change the lighting. As it stands, the mirrors only reflect well when they are set to emit a blaring white. I would of liked to have a setting, that the player could change, that could make the background lighter/darker. For now, the player must shoot lines in a white space.

The next thing I would fix in the game is a small bug in the controls that I wasn’t able to fix. When the player charges a line, there is a small chance that, when the player releases the button, no line shoots. It isn’t gamebreaking, but it is a little frustrating when charging a line.

Finally, the Colour Randomiser that I put in place, which randomises the colour of the entire line when the player shoots a line, has a tendency to select white over all the other colours. While removing white from the list of colours is the easiest solution, I would prefer to implement some sort of weighting on the Randomizer. That way I can keep white, which would be a very powerful colour if I was able to change the lighting.