Planning, Production & Practical Skills
25/03/2019 Week 7 – Continued
List of Tasks planned for this week:
- Create player controller
- Create inventory manager back end
- Start on the front end work with the inventory manger
Now time to start the final production, the first thing I started with was the player controller. This player controller was the core script which would move the player around the scene, this also includes the camera movement. The reason I have picked this to start with is that most of the other mechanic will rely on the player being able to walk to them and use them such as, picking up items and loading the terrain around them.
This was an easy task as I have done it many times before, at the start of projects, I first started by creating mine with a capsule and added a capsule collider, rigidbody and a camera inside around head height as a child. Then for the code, the method was first adding up all the possible forces into a vector 3, for example, if the player pressed the forward key it would add the movement speed to the z-axis which is forward. In these forces did include gravity on the y-axis. Then I would apply this vector3 to the rigidbody with MovePosition(Vector3 Position);. Then once the movement had been applied that frame I would Mathf.Lerp(float start, float end, float interpolation); the z-axis and x-axis back to 0 so if the player let go of the key the next frame it would slowly stop moving depending on a breaking force set by a variable.
Once I had the player’s controller feeling natural to use I then started to work on the code behind the inventory. I wanted to get the back end of the inventory code sorted out first with the basics of storing items before I started working on the user interface so that I would know for the user interface what data I would be working with.
I was expecting this task to be the hardest and with the small amount of time I had left for this week I didn’t think I would have completed in that week however when breaking it down into different bitesize sections it was a lot easier to understand. One of the methods I used to understand how the inventory would work was by writing the logic down on a whiteboard I have at home, this meant I would visualise what needed to happen and in what order. I managed to get this task completed a lot quicker than I expected so I started to work on the user interface for the inventory which also meant I could start doing more of the complex movement which I had planned to do next week.
For the UI in the game I knew from the developed ideas what type of design I would like to go for however I knew the default square sprite which Unity provides was low quality around the edges, so I went into Photoshop and just created a two by two pixel big image of just black and exported as a png to Unity. That two by two pixel big image has now become the main backing for all my UI stuff. So then when I had that image created I used to create the UI for the player’s inventory, I also imported TextMeshPro so that I can have much cleaner text with more control to customise it. Overall this process of making the UI was simple as it was just dragging some panels around in the editor, the only problem I faced was later on when adding the ability to move items around in your inventory. The problem was that the scroll rect component had a on drag feature which you can’t disable, so with a quick search on the internet I found that I can just create my own scroll rect simply by inheriting from that component and then overriding the drag features.
Surprisingly I had managed to complete all of the tasks that I and some extra just on the Friday of week 7 so I decided to keep on going by completing some of next weeks tasks. I first started by creating the main menu. I exported the same background image I had used for my develope idea and test pieces so that the background wouldn’t just be white, then I used the small black image I had used for the back panels of the inventory for the back panels behind the text. Then I went onto working how the different menus would switch between each other when the player selected the buttons at the top. The method I went for was creating a custom script on each of the buttons which would send a callback to the main menu manager, which would then go through a dictionary and enable the one which the key matches. Overall this was a simple task and it was nice to get it out of the way early than later, completing this task set me up nicely to start working on the customisable controls.
For the customisable controls, I knew I would need a method to save these to the user’s computer, so I first started working on a static file manager class. The reason I made this first was so that I could first plan how I want it to save then with that information how I will convert it to keycodes, also making this class static meant that I could access it anywhere without having to reference it at the top of my script as a variable like normal monobehaviour scripts. For saving the scripts I went for a similar approach by storing them as commands then running these commands, for example one of the lines in the players config would be “bind w forward” which is split into by, the action which is bind so we know we are setting a key, the key which is w and the in-game action which is forward. Then for the main script which would change the UI and talk to the file manager script I made a custom class called Binding which would store the information for each bind such as the display name which would show to the user, the command name which is used in the config and the keycode of what it is bound to.
Overall this was a big task but the method I used to tackle this part of code made it simple and a breeze without any problem, I guess just experience helped me get through this task without any problems.
The last thing I worked on was making a simple loading scene for when the player was loading into their world. This wouldn’t have much use at the moment as my test world was really small but hopefully, later on, it would have a better use to display to the user how much is left to generate of their world. I had never done loading scenes async however Unity’s documentation explained it really well and I managed to get a basic blank scene which would output the percentage of loading the next scene in the console.
Planning for next week:
I decided to stop early for this week on Saturday so that I could have a break from the on the Sunday and Monday as I had been doing long hours on the develop ideas and test pieces. Thankfully I managed to surprise my self by completing more task that I thought I would be able to get complete with the few days I had left in the week. This now means I have a lot fewer tasks to complete for next week however I think I will just move some of the tasks one-week earlier. The tasks that I will be bringing down to week 8 from week 9 will be, improving the models, creating their LOD groups and setting up the sprites, ids and prefabs.
01/04/2019 Week 8
List of Tasks planned for this week:
Finish the user interface for the inventory in game Create the main menu layout Get the code for switching between options and play Get the controls from the player controller to display on the main menu Be able to change the control from the main menu for the player controller Create a loading screen which loads the game scene without freezing the game
- Create a pause menu with an options screen
- Add the ability to change the controls in the options screen in game
- Add the terrain generation into the project
- Start on generating roads
At the start of this week, week 8, I worked on creating a pause menu for the game scene. I wanted the design of this pause menu to stick to the same theme of which the main menu and inventory had in common, so I used the same back panel image and did the same style of a top bar as which I had done on the main menu. Then when the player selects the options a new section will be enabled in the middle with the options. This pause menu was nothing complex and didn’t take me long at all to get finished.
Next, I went on to creating the models and putting them into Unity from Blender. At this current time, I didn’t have much motivation to any of the art for this project, so I was jumping around doing random models for the project with no real order or list to follow. Some of the assets I did manage to work on before I fully lost motivation to do any art was clouds, trees, sticks, sheet metal and a log. All these assets I made had their prefabs done with colliders and rigidbodies if they needed them and I tried to keep the file structure in an organised way so that I could easily find these items again when I needed them. Creating the art is definitely a hard process for me in games development as I don’t enjoy it as much as I do coding mechanics however whenever I want to do interesting mechanics I know that I am going to need the art to go with it.
Seeing how this art was not going so well, I didn’t want to waste this week. So instead of going through all the art assets and importing them into Unity, I decided to switch week 8 and the Easter break around. So for the rest of the week, I started working on the terrain generation which I had done on a test piece before. The reason I did this is because even though I already had got ahead of my self from the first week, week 7, I didn’t want to just lose that.
When I imported what I had created in the test piece there was one problem right away; for the final production I had changed it to the high definition render pipeline, whereas my test piece was using the old render pipeline so the mesh was generating the same as it was before but there was no colour getting applied to it. This was a hard fix to get working because of how new the HD render pipeline is there aren’t many resources on how I could fix this problem. This problem took a few days to fix but the final fix was found with help of a tutor, once we have applied the new HDRP shader material, we set its colours to either fully red for water, fully blue for grass and fully green for stone. Then using the new shader graphs, change the colours to chosen colours in the material using vertex colour to get the colour we set in code. This process does limit me to three different colours for the terrain but it is better than only have one white colour.
However, there was another problem, each vertex was getting its colour for that triangle based on the height which would cause this gradient effect where the two terrains heights joined.
After sitting down for a while and writing out the logic for colouring the terrain with the tutor, we worked out that we should only set the colour for every three vertices, which was the number which made a whole triangle, this worked but the showed another problem. This problem I managed to fix after some testing, instead of changing the colour for every triangle, I did it for every quad.
The last problem with the terrain generator was the chunks not matching in height. This was a known problem I had from my test piece and still hadn’t fixed. The fix I ended up doing was just following through the same tutorial I used but instead of cutting out the parts I didn’t need and making the code simpler, I just did it all the same as he did it. This did resolve the issue but did take a lot of time to sit there a follow it step by step, the reason I did that was so that I could get the problem fixed and out of the way as it was wasting too much of my time where I could be spending it on working on other parts of the project.
Overall this terrain generation was very hard to accomplish but I am glad I had done it, this was my first time trying something like this before so there was a lot to learn about creating meshes at runtime using Perlin noise and octaves. I will have to touch back on this generation as currently there are lots of puddles, and then when I do the road generation I may need to change the terrain where the roads will be placed. But hopefully, this is the hardest part done and out of the way.
The last thing on the list was starting on the road generation for the towns and cites the player could explore. For this, I started in a sperate scene and just wanted the points of the road set out in lists so that later on I can get the road mesh spawning on those points.
My first method of generating the road was in an angle it would pick a random place at a random distance both set by variables for that type of road and spawn the point. That made the roads we are used to here in the UK where they turn left and right all the time. The first image is 100 different roads getting generated based on the angle and max distance variables for each point, the second image is now using a class I have different road types with their own variables(Blue is an motorway, Green is an A road, White is an side road). And, the last image is getting the roads to join from the previous teir road at a random point, for example, a side road and only be connected to an A-road. Creating this was fairly easy, I started writing down the logic before I would start coding it, this made it a lot easier to understand what things I need to do in what order, which in turn meant I wasted less time on this.
That night I realised some problems with that method of generating the roads. It would be extremely hard to know where to place the buildings with curves in the roads and with random distances and angles that they can bend. So the next day I rewrote it all but went for this grid style. Every road would move one unit, then it would have a random chance if it could turn left or right (if ticked in the road type settings). This meant I always knew that at a minimum there would be one by one gap for buildings and everything would be straight lines. I feel that doing it this way will make it easier for me in the future when I come to placing the buildings next to the road for the player to explore. Also, this method was a lot easier to understand and change around if I needed to, it had more predictable results which gave me a good feeling that it would create weird effects in the game.
Planning for next week:
This week I managed to catch up with everything after switching some of the tasks around. I got a good decent start on the road generation and next week I can continue improving that and get it mapping the hight to the terrain. I don’t think I will need to change anything more with the current planning which I have done unless something unexpected pops up like a bug I can’t fix.
List of Tasks planned for this week:
- Improve on the generation to add roads
- Improve on the generation to add buildings next to those roads
- Add the cloud effect at the edges of the map so the player can’t explore as far
- Add a fog effect to the players max view distance so that at the end it doesn’t just cut off
- Touch up on the models for items in the game and export them into unity
- Create LODs for each model
- Set up all the sprites, ids and prefabs for these new assets
Changing the road generation again….
Cities connecting to each other with motorways
View distance in setting menu and config
Problem with changing the terrain mesh for where the cities are
During the Easter Break, I was hoping to finish the road generation and then start working on the assets however I experienced a lot of problems with the road generating. I started the Easter by changing the road generation so that it was in a much more predictable pattern, this could make it seem more repetitive for the player, however, there are still some areas which change each time depending on the seed. The cities are now in a grid style pattern where the bottom section is split for housing, then the top section is the factorys where those people worked. Each road linking the houses and factory are picked at random, but there is common lines which you might see which is ever 1 unit. This method of generating the cities is a lot easier to code and have a much more predictable result and, with this, I can easily place buildings inside the empty grid slots in the future. Once I had cities generating at random then I wanted them to be connected via a Motorway, so for debugging I just made it be a straight line from the top of one city to the bottom of the nearest city above them.
During the time that I was changing the road generator, my Steamworks application got accepted, for a little break from procedural stuff I just added that into my project. I didn’t spend long, just messed around and got it so that the users steam name would show with their picture. It was a nice simple thing to code compared to procedural generating everything.
After that break, I set out to trying to merge my road generation with the main game scene and getting the mesh to flatten where the cities would be so that roads and buildings wouldn’t clip through the ground. The first way I went doing this task was by having a prefab which I could spawn where the city was positioned then the terrain would generate around it, once the terrain had generated it would send a raycast down from the sky to find out what chunks need to be changed for the city. As I knew this was going to take time for the computer to work out everything I decided to first get working the loading scene. The current method I had from the Unity documentation for loading the scene didn’t work in my case as that would just be loading assets that were already placed in there, non of my procedural things. So I made my own method of loading, there would be two numbers, one the total number of tasks that need to be completed and another how many currently have been done. Then after set points when I say a task is complete it would increase the current amount when this current amount reached the amount calculated to be done it will unload the loading scene and enable the player game object. This also has a little loading bar a the bottom right of the screen so that players can see how much left is to be done.
Overall this loading method in a simple bit of calculating, and it didn’t take me long at all to work out but will be an essential feature when players are loading into their worlds not thinking their game has crashed.
Once I had the loader scene set up and ready for other actions to be added into the loading queue I went to work changing the terrain were the cities where located. My first method as said above was just by loading the terrain with a game object then sending a raycast down on to the mesh to work out what vertices I needed to change and what chunks they were going to be. The problems I faced with this is that it was very resource heavy, it had to generate a noise map for a mesh which wasn’t even going to be used, then sending raycast is another heavy task. Another problem is that I could not manage to make more than one chunk get changed for the city, and telling how far into the array of vertices got hit and how far I should continue to get all directions(Image 2). After a week of trying to fix these problems running into more errors, when discussing my errors with another student they suggested the idea of spawning the cities in the centre of the chunks so then I know that it will only affect one chunk and also with changing the point of which I change the mesh, so instead of after the mesh has been generated from the noise I just do it while getting the noise, this means there is an inefficient code. Over that last weekend of the Easter break, I added in the to the noise generation the city list from the road generated, then while creating the noise, it could check if there was going to be a city then just set it all to 1 which made it max height (this just is a testing thing, later on, I will set it to an average height) (Image 1).
Overall this Easter has been one of the hardest, as I haven’t done procedural generation as much in a project like this before so it’s causing me to have to so many problems slowing it all down. There are many tasks that I didn’t manage to complete putting me far behind. I wanted to work on each asset and get them ready to be placed in the game with their LODs, colliders set up and sprites for the UI done. Add a fog effect at the end of their view distance so that buildings and terrain in this distance wouldn’t just apart, they would slowly fade in.
Planning for next week:
I still don’t think there is much I can currently do to catch up and get all the task that I wanted to get completed at the start for this deadline in two weeks. So instead I will have to change somethings about my work by removing some of the features I don’t think I will be able to do in a time such as saving and loading and base building. These features will make the whole experience of the game not as interesting and something that you would want to spend time playing but for the exhibition, I think it will do, then, later on, I can add them into the project if I want to continue it.
22/04/2019 Week 9
List of Tasks planned for this week:
- Assets spawning in the world and the player being able to interact with them including roads, buildings, items and food.
Items spawning in the buildings which are generated Item controller so that players can pick up and use items in their hotbar Saving and Loading of map with near by items
The plan of what I wanted to do during this week what I wrote at the start of this project has gone out the window, this week I started working on city assets such as roads and buildings. I first started with creating the roads, the road is a very simple and basic design of just a plane extruded along so that when there is a lot of them it’s not so heavy in performance and the art style of the game doesn’t have much detail.
However, when I added this first asset into the city generation, I found out that my cities are really small compared to the players’ size. I didn’t want to have to go through all of the city generations and try and make it bigger, so instead, when I start reading the information such as road layouts, I just multiply them by a set number making the gaps all bigger and fit the player, which was a quick simple fix instead of wasting days on it.
Now I had something that could spawn for the small roads, I realised in the code I forgot to add gaps in between each small side road. So for this, I had to go into the city generator and change it so there are two gaps in between each road, one where the next road is and the other where buildings will be placed.
The first image is of how it was without the gaps between each road. Small roads are white lines and you can see in the lower, housing section, there is no black gaps for buildings. In the second image, you can see my roads being displayed with the line renders, and this is when I have now included the gaps, and the third image is of the slots using the prefab plane with custom colours.
Also for this, I made a new way of debugging what information was generated from the city generator. There are two main parts to the city, one 2D array of different slots and what is filling that slot and, a list of all the roads and what type of road they are in what direction. I use line renders to show the information in the list of roads, and then for the slots, I spawn primitive planes and change the colour depending on what the slot is. This all is easily enabled and disabled with booleans.
Now that the cities are at a much larger scale, I needed to change how much of the terrain below got flatten for the city. The new method I had worked out and left it on temporary was using Vector3.Distance to see how far away the chunk was from the city, however, this did cause the effect of a circle but I just left it and started working on more of the road assets. I wanted to get away from the terrain generation and get the visual done as I knew the terrain was slowing me down and is the main reason why I am behind on the plan that I made at the start of the project. So this quick method was good enough for now.
Once I had got the first roads completed and generating correctly with their colliders and in the right rotations, I started to realise something when showing it to other peers. It took way to long to try and get to the other side as a player running. My current city was 100×100 tiles big, so instead, I lowered it down to 20×20 tiles. This made it a lot easier for players to run to the other side of town to the factories to get different loot, also meant better performance for the moment as I have done no optimisation to the assets.
Making it smaller also solved another issue for me, the area where the terrain is flattened. Now as it was much smaller it spread over a two by two tile area than which meant with the distance, I got the right distance so it just flattened the areas which covered by the city. I still do need to fix the smoothing between that flat land and what height that flat surface is at, but it’s still progress.
I also had completed more of the assets for all the road junctions, empty tile slots, and the start of the first type of building. Here are images of all of the road junctions that I use in the city.
So far, overall, this asset creation is a time-consuming task even though I am not unwrapping or doing very complex models. I took me around three days to complete those assets, I would say it’s mainly because I enjoy focusing on the programming, not the art, so I don’t get much motivation to work on the art in my projects which slows me down when I have to do the art.
I knew at the start of the week that I won’t be able to do the features such as saving and loading which I had originally planned for and as I am behind with the terrain generation, I have to push back the item spawning to later with the item controller so that the player can pick up the items. I still also have more assets that I need to create, then once I have those assets spawning correctly, then I can work on the item controller. Hopefully, I can get these core features done by the deadline the week after.
Planning for next week:
To try and make the workload less I am going to simplify some more things, then if I get all of the core things completed in time, then I can add more detail later on. For the building assets, I will just have the one variant which is used and one type of factory which spawns. Then this will hopefully give me time work on the playing features like health, hunger, damage etc, not just a world generator.
29/04/2019 Week 10
List of Tasks planned for this week:
Placing building blocks Placing extra items for bases Saving the bases
- Factory Building
- Traffic Lights Models
- Traffic Lights Imported
- Item Spawning
- Player stats UI
- Player stats code
- Death and Respawning
Monday, I didn’t get much done, I had a short 30-minute break from English and managed to create a cloud generator. This cloud generator would spawn clouds above the players head and move them depending on what the wind direction was set as, as a vector 2 in the script. This meant later on if I wanted to all I had to do is change that wind direction during gameplay and the clouds would start moving a different direction. A simple short feature I added just to make the game feel less empty and more alive.
Tuesday I worked more on some assets, I created a traffic light, street light and a stop sign. I also got these assets imported into Unity and added into the world generation so they would be in the correct places. Now it’s starting to feel less empty bit by bit. A problem I faced with these lights on the side of the road is that I wanted to add spotlights on them so they would actually light up the street, however, the lights didn’t work well as there was so many of them in the scene, Unity didn’t like trying to process that many lights so instead I just removed the light sources from them.
Wednesday I finally got around to adding the fog effect which comes with the pollution, this fog was a lot easier than I expected and didn’t have a performance hit. As I am using Unity’s new HD render pipeline there was a built-in volumetric fog set the atmosphere perfectly.
Now that I have that fog limiting the player’s view distance, I can spawn the new cities a lot closer to the player without them noticing. I first tried using the player’s position and then if it had moved more than the threshold it would spawn a city in front of the player, however, this didn’t work out as I couldn’t constantly work out which direction to spawn the city in so instead I created an empty game object, attached it to the player but forward in the X-Axis then just spawned the new cities on that. Also with the reduced view, this meant there was no need for the distance option in the graphics settings and I could set the terrain generation to much smaller which improved the loading time at the start.
Thursday I added some missing colliders which I forgot to do to the traffic lights and other roadside items. Then I did more asset work but this time working on the different rooms inside the flats. The assets I created was a tv, wardrobe, beds, chairs, tables and a sofa. While I was creating these and adding them into Unity with colliders the loader broke meaning it would get remove the loading scene and enable the player anymore, however, I wanted to wait till I had finished importing all of these new assets into the world generation before I start figuring out why.
On Friday I started to notice that my FPS was getting low, around 40. This was because of all of my assets were in the scene and being rendered even though the fog made them not visible. Then I remembered about Level of Detail, so I got to work creating a lower poly version of each asset so then I can add it to a LOD group. I also found out that it also culls the object if it gets too far, meaning it won’t render any of it which is great. Creating these LODs’ took a long time but improved the performance to a much better playable rate, but does sometimes make it a bit hard in the editor to find things.
At the end of Friday, I tried to make it so that the terrain would be flat and the buildings would spawn at the height of the flattened terrain. At the end of the day I had thought I got it working, but soon realised the day after that I hadn’t and knew that it was going to be another long painful problem to fix.
The next day, Saturday, I changed the style of the hunger and thirst to also include the player’s health, and use a slider bar to show the values instead of a percentage. This was a quick simple thing and didn’t take long at all, but was the needed start of the core mechanics of a survival game. I had one bug where these stats would still go down when the player had paused the game, this was fixed by having a while loop in the count down loop to just pause it when the game was paused.
On Sunday I had a real think about with only two days left, I couldn’t see some of these features being completed and usable in the playable prototype for the exhibition. So on Sunday, I removed all of the terrain generation scripts, this means there would only be one city, also all of the Steam developer SDK. I did this because of the transition to open world from the city wasn’t good at all, I had also spent so much time working on the city the terrain was very empty. Once I had removed all of the code for the terrain generation I then upped the size of the city back to 100×100 making there more for the player to explore. Then made map borders so that the player couldn’t explore outside of that one city. The reason I did this all was just to make the game seem more complete and not little bits worked on here and there, this also reduced the number of problems I had and the amount of work I had to complete for the exhibition.
The way I am showing that its the end of the map is by increasing the fog density when they enter that area and adding some post-processing effects. When the player starts to leave the bounds of the map, I slowly add a vignette of red to show that they are losing health, a colour grading to make the whole scene seem to get darker and an increase of graining effect as well. This all overall adds a nice effect as was really simple to do with the new render pipeline.
Now as the city was a lot bigger, spawning all of the rooms at the start of the game with their models inside the rooms wasn’t going too well. If I added a delay to wait for a new frame the FPS would drop still quite low which wasn’t nice to play at. My first solution to this was object pooling. I knew I needed around 18,000 which at that time of night seemed easy for Unity to handle. So I made an editor script which added a button and it would spawn 19,000 of my random rooms, disable them and put them under a parent so I didn’t have to see that list. Then in the game, it would just pull them from there at the start meaning I didn’t have to spawn them in which was causing the lag.
Surprisingly, Unity didn’t like me adding 19,000 game objects into a scene. They spawned in all fine, it played but the whole editor and game was at 1 FPS, until there was a point where it was not responding for a long period of time, so I used task manager to close it. I knew the scene was saved with all of the 19,000 objects pooled, but that caused another problem. The first error, which I am still unsure what it really was caused by, but some of the packages went missing, so continuing into the project I found out the scene became 4GB in size, so Unity couldn’t open the scene.
My first thought was, I knew the .unity scene could be opened in notepad or any text reader, so I could just open it and delete the text. But it was too big for Notpad++, Notepad and Visual Studio Code. So thankfully I have been using Github since the start of the project, so all I had to do is download the scene file from Github and replace it with the one I broke. This managed to fix it easily and all I had to do is delete a few game objects which I had removed from the last backup to Github. Overall looking back at it awake, it was a stupid idea done when I was really tired. It caused me to end up just all night fixing that problem where I could have been progressing on with the game.
The only other things I managed to get completed that night, was fixing an issue where if the motorway was so close to the side, the side of the city which was small had a high amount of side roads. To fix this I changed the amount of side roads to be a random number depending on the seed, and also made a max distance that the motorway can go to each side.
And also getting the area set for factories to spawn. The way the cities are generated is all by data in a sperate thread, so in that data, I needed to declare where factories would be and what tile they spawned on. The red area is where factories are, yellow is where they spawn.
Looking back at what I had set for my self the week before, I didn’t manage to model the factory buildings, get dying and respawning coded, model any food or water assets and having them spawn.
Planning for next week:
Next week I will have to rush something to try and get them completed in time for the deadline, then hopefully afterwards I could add in any missing parts which I could get done in time.
06/05/2019 Week 11
List of Tasks planned for this week:
- Death and respawning
- Player stats UI
- Players stats code
The start of this week I worked on getting the player to spawn somewhere when they die, to achieve this I just added an empty game object with a tag of ‘respawn’ on all of the buildings. Then when the player dies it will just search the game scene for all game objects with those tags and picks a random one to move the player to. A simple easy task which makes the game have an end and start.
Tuesday the first day of college I created a script which would hide the minimap and take a screenshot at a higher resolution, this first was originally for creating my boards but then I used that feature to create the background panel on my main menu and loading screen.
When trying to get the scene set up for the screenshot, my flats colliders all broke. The reason for this was because I added some more material ID’s to different faces which changed the file, and changed the whole higher in unity which caused the colliders to be removed. So I spend a while setting all of the colliders back into the flat.
I then next wanted to create a friendlier way to know when you have died, so in my pause menu, I created a death screen which would get enabled when the player died giving them an option to respawn or quit back to the main menu. The reason I wanted to do this is to make the game seem more complete and easier for people to understand if they weren’t looking at the health before they got teleported.
Now that the cities are much bigger, I needed a way not to spawn everything at once otherwise the game would just freeze at the start. So for this I created a big sphere on the player, changed the layer it was on so that it would only collider with other things on that layer, then whenever the sphere collider with a room it would spawn that room in from a prefab. This meant the game would run at a much better frame rate as there weren’t tons of objects being spawned at the start. This was a lot easier fix that I was expecting once I understood that you can do layer only colliders.
Wednesday I worked on creating a simple tutorial for people who are not to familiar with playing games with keyboard and mouse. This tutorial system I wanted to make as modular as possible so it would be quick and easy to add more sections when I add more mechanics. So to achieve this I made it so all of the texts for each tutorial section was stored on a list, and then it would just go through this list, some of the sections required the user to press the buttons. For example the second page it says for the user to press WASD to walk around, to check if the user presses these I have a switch statement checking which tutorial we are on and then checking if each key was pressed then using rich text to change the colour. This was an easy bit of code however it did take most of the day as it was long and included some writing I had to do. But it was good because now people will understand what they are meant to be doing in this game.
On Thursday I set out to improve on the player’s controller, as currently, it didn’t feel very nice and also had a problem with edges and slopes. This time I decided to use Unity’s character controller component but that did mean that I couldn’t use the rigidbody for physics, thankfully the code I needed to get it moving was the same input as I had already done for the rigidbody. This made it a quick thing to get going but then I had to work on the player gravity which took a bit more thinking. I knew there was set states that I had to set the players gravity so I went to the whiteboard and wrote down what needs to happen and when.
Creating this artificial gravity was harder than I thought, but it just required me to spend some time to set down and concentrate alone. So when I got home I looked at the image I took of the whiteboard and started fixing the players gravity. Now the player can walk up steps and they don’t seem to slide down the stairs, however, jump still seems a bit inconsistent.
The last day Sunday, I started working on some items spawning. As I already had a few items in the game already, so I started working on a visual way the player will know that these items can be picked up. I first thought of a yellow outline with a shader graph, however, I struggled to get this working and later found out that the way the outline worked was by using the vertices and as it was a low poly model the outline didn’t work too well. So I spent the whole day trying to figure out different methods just to find out in the end that it wasn’t possible with my art style.
I managed to get the tasks that I had set that the start of the week done however, there was some things which had carried over from previous weeks such as the item controller and spawning items I didn’t manage to get completed this week.
Planning for next week:
Next week I plan to get the items spawning and the item controller working with items going into the player’s inventory and the ability to drop them back into the world. Hopefully, this will get me much closer to a playable game for the exhibition.
13/05/2019 Week 12
List of Tasks planned for this week:
- Items Spawning
- Item Controller
- Dropping Items
Week 12 I didn’t get to work till Thursday, I had a short break from the project while getting ready for an interview I had on Wednesday.
On Thursday I first started fixing an issue with the tutorial, whereby the if the player pressed any of the keys before the tutorial had finished typing out the text, it would start inserting them into the next slot.
To overcome this, I did a quick and dirty fix by blocking the player’s movement until the text had finished being displayed. I did it this way because it would mean the player wouldn’t be getting distracted with what is placed around the city and can focus on the text.
Another problem I had to fix, which was discovered when someone was play-testing the game. Was when you die, respawning just spawns you in the same place you left off. To overcome this setting a variable I use to delay the spawning during the loading scene back to its default value of false triggered all the right things to move the player back to a random spawn on the map, then with clearing the inventory and setting their health, thirst and hunger back, it was all good. This was an easy fix to find as it was already code and saved me time instead added in functionality, I just reused what I had.
Once I had these two bugs out of the way I started working on the text which would tell the player what they are picking up. I created this because I didn’t want the player to have a guess what it was that item was, especially with my art it would be hard to tell. This was just a simple world text with an image as the background panel attached to the item, then every frame it looks towards the player. I also had to include a collider to check if the player is near then enable it, otherwise, all objects would just have texts floating and I only wanted it when they were near.
The next day I managed to get some time to work on it was on Saturday. Saturday I got the ability to pick up items and them being placed in your inventory. All of the code was already done on the inventory side of things as all I had to call was one method with the given ID and amount and it would find the correct place to add the item and update the UI. So I just had to send a raycast from the player’s camera and if it hit an item on the items layer then it would start trying to add that item to the player’s inventory.
This only took about one hour but I didn’t have much time to work on the project that day.
Sunday, I had to work on the ability to click on items in the inventory, see information about them and also be able to eat them if they are consumable. This feature was harder to implement because I was trying to add on already a large number of features which the inventory already had and trying to get my head around it took a bit of time. The method I had for this was when the player pressed mouse 0 on a slot, it then waits for a short delay, if the mouse is still down this means they want to drag it somewhere else they want to see the information on it. For the consume button, I checked the ID of the item they have selected then checked if a boolean was true, then I would enable the button and add the listener.
There were many different situations that I had to overcome with this because all of the different states the inventory could be in and what the user could do the change those states. All these different situations are what made adding this feature a lot longer than other new features in the game.
During developing this new feature I discovered a bug which was the reason why when pressing the inventory key it didn’t always open up or close. The bug was that it was opening and then closing right away, to overcome this it was an easy switch from moving that section of code from a FixedUpdate to an Update method.
Overall, this feature did take some time to implement but it was worthwhile as now the player has a reason to explore this city and interact with the world.
This week I did manage to complete all the task with the extra task of making it so that players can also consume items. Which is a good change and shows my planning has changed and improved so that I set more achievable tasks.
Planning for next week:
Next week I plan to add some more items into the spawner so that it’s not just sticks spawning everywhere. Then once I have done that, as it’s the last week I want to focus on fixing bugs and only adding small features just to make the game seem a bit more polished. Nothing massive.
20/05/2019 Week 13
List of Tasks planned for this week:
- Create more items
- Import these items into Unity and add them into the spawner system.
- Set up them in the Item Database
- Fix bugs and polish parts off
The start of this week I worked on getting some more items into the game, at the moment there was only sticks spawning. So I created three different items which where very basic but would give the functionality to keep the player alive and give them a reason to use their inventory. These items were a drinks carton, cereal box and tinned food. These items didn’t take long to create and import into Unity, once they were in Unity, I added the text prefab to them so it will display what this item is.
When I was adding the items into the spawner and adding the texts onto all of the items so that it would display what the item is. I encountered a problem with my sheet metal item and some of the other big items in the game. For the sheet metal, the text was fine on the prefab, but when it came to spawning it, the text became scaled in one direction making it unreadable and very off-putting. Because the sheet metal now had no use in the game, I decided to just remove it from spawning instead of wasting valuable time in fixing it. The other problem was with some of the bigger items, the text was inside of the item it’s self, for this, I just raised up the height of all of the text positions in code meaning it was above all items.
These were quick and simple fixes, I did it this was because I didn’t want to spend so much time on it as it was my final week on this project before the hand in.
On Tuesday I first started on the Minimap, as I realised it wasn’t very useful at the moment. The way did the minimap was just my copying and pasting the code which generated the debug lines from the roads list, and made it spawn the lines up in the sky above the player. Then with another camera rendering only those lines on a layer, I used that to show the minimap in the top left of the screen so the player can see what roads are near them. This was easy to add, just had to change a bit with the layers as at first the lines weren’t showing up and the arrow wasn’t visible. This now makes it easier for players to tell where a junction in a road is, and what could possibly be on the other sides of these buildings.
Next, I changed some of the values of how much hunger and thirst the different foods and drinks would give you. I also added images into each one with descriptions so that in the inventory it wouldn’t just me sample text.
Afterwards, I worked on some information about what other people had been doing during that session at the exhibition. For this, I wanted to record the longest play time and the most amount of items picked up. The reason for adding this was first to fill up space where I had originally planned for achievements to go, and also get some interesting feedback on how long people played. This was a simple feature to add and also included adding an AFK timer to the player so that if someone just leaves the game running, it will take it back to the main menu.
Last week I also had a bug with the inventory opening and closing in the FixedUpdate method, so this week I decided to also move the player movement into the Update as well it see if that would improve it, which it did. However, the gravity didn’t work too well, so I split up the movement between Update and FixedUpdate so all of the stuff which affected the gravity I made was in FixedUpdate, then everything else was in Update. Now the player movement feels a lot more responsive and its a lot easier to control when navigating around the world.
The last thing I worked on to make the game ready for the exhibition was the health regen and display the name of the city you are in. For the health regen, I just checked if they had above 90% on both hunger and thirst, then it would slowly add onto the player’s health which was really simple to do. Then displaying the name, I used the same effect which I had done for the tutorial text but just this one got the name town and displayed it at the top of the screen once they finished or skipped the tutorial. Both these features were added to make the game feel more polished and complete with little attention to detail, hopefully overall improving the player’s experience in this prototype.
This last week has been good, I completed all the tasks I set my self and did some little extra finishing touches to the project before I build it and put it on my PC for the exhibition.