Loading

2018 FMP by Anthony Sturdy

Research (Week 1 - Week 2)

Market Research (Week 1 : 8/1/18)

I will use this research for my FMP pitch and proposal. I need to research what game genres are currently popular and which are trending. To do this I'll look at statistics and try to find out why people seem to be enjoying the game, also if a game has a niche fanbase I'd like to find out what makes the game niche and why the fanbase is so loyal to the game.

Firstly, I'd like to look at general statistics to find out what the 'average' gamer is. Looking at 2017 statistics (Lofgren, 2017), we can find out that the average gamer is 35 year old male. Of course this can vary a lot, but appealing to this audience would likely be the biggest audience. It's also interesting to see that 56% of frequent gamers use PC, and 53% use a dedicated gaming console. This means that most people use both for gaming, although it could mean they use PC for light gaming such as online browser games, and their console for more regular gaming. It doesn't necessarily mean they use both for regular gaming.

Moving onto genre specific statistics (Statista, 2017), we see that the 'Shooter' genre is most popular with 27.5% share of units sold, then closely behind is the 'Action' genre with 22.5% share of units sold. These 2 genres are quite far in front of all other genres with the 3rd most popular genre being 'role-playing' with 12.9% share of units sold. This explains why there are always first person shooters, action games and combinations of both being released often, they're the best-selling and most popular genre.

Looking at the indie games that have been released over the past few years, there's been a trend of a retro style/pixel art games. Just looking at the games on Steam tagged as 'Pixel Graphics' (SteamSpy, 2018) you can see how many games have managed to be successful whilst having a retro/pixel theme. It's not just Pixel Art games that are popular at the moment though, there's a trend of retro 3D style games becoming popular also. I think this trend is driven by nostalgia, and the fact that 'retro' graphics are easier to produce for indies than 'realistic' graphics.

Games which are considered niche are also becoming more popular. It's not as often as other indie games reaching success, but when a niche game is successful, it seems as though the fanbase is more loyal to that game, and you hear a lot about it online and how great it is from them. An example of this would be 'Papers, Please'. The game is essentially a 'boring' job simulator. "It's hard to describe the game and make it sound fun." (Lee, 2014). Despite these type of comments, the game managed to succeed, it started with a small but loyal fanbase who spread word of the game and convinced people to buy it, and now it has almost 2 million sales (SteamSpy, 2018) on Steam alone due to how different it is to any other game and how weirdly-enjoyable it is.

Looking at the most popular games of 2017, there's a clear trend of player freedom and open world games. They've been become more popular over the past years but this year it seems more than ever. First, looking at the best selling games on Steam for 2017 (Steam, 2018), we can see that 7 out of the 12 games in the 'Platinum' section are open world or have open world areas. Next, looking at Game of the Year nominations at The Game Awards (The Game Awards, 2018), 4 out of the 5 games nominated were open world, and the winner, The Legend of Zelda: Breath of the Wild, has a huge emphasis on player freedom in the open world and restricting the player as little as possible.

Different games perform better on certain platforms, this is due to their audience and demographic. For example looking at the Nintendo Switch demographics (Wynne, 2017) and comparing them to the Xbox One demographics (Corden, 2017), we can see that releasing a game with the target audience of Women, would be better on Xbox One, as 42% of Xbox players are Women, whereas only 10% of Nintendo Switch users are Women.

Market Research References

Engine Research

As I'm going to be focusing on programming in my final major project, I want to look at different engines to see the features each one provides, so I can weigh up the pro's and con's of using that engine. There are a lot of engines so I'm not going to look at all of them, but I'll look at the most popular 3D engines and a few 2D engines.

Unity is a 2D and 3D game engine, which is free to use until you earn up to $100k, which you then need to purchase a pro license, which won't affect my college work at all. I'm quite familiar with using C# with Unity so I think this would be a good option for my FMP, but I also would like to look at other engines as it'd be good to get experience with multiple engines. Unity is a popular game engine as it's widely available, free and user friendly. It can export to 27 platforms, from the Nintendo Switch to Samsung Smart TV's. It also has a good history of games that have been made with Unity, with best-selling games such as Rust and Cuphead. It's constantly being developed and new features/optimisations are being released constantly, which makes it a great engine for hobbyists or professionals.

Unreal Engine 4 is also a very popular choice. Similar to Unity, it's very accessible for everyone, to an extent even more than Unity is, as Unreal Engine provides a visual scripting option, which means you don't have to actually type any code, but rather drag modules to make mechanics work. It's also more appealing to some as if you do want to write code in UE4, it's in C++ rather than C#. Personally I think Unreal's 2D tools aren't as great as Unity's, but it's very easy to make a good looking 3D game in Unreal as apposed to Unity where you might need to change some lighting settings and add some post processing to get it to a similar quality.

Godot is a relatively new engine which has been getting a lot attention lately due to it's 'transparency'. The other 2 engines are both proprietary software, whereas Godot is open source and you don't need to pay any royalties to the company. The way the company makes money is through Patreon, which allows them to have a pay-what-you-want model where the more you pay, the more you have a say in what happens next with the development of the engine (for example, $26 per month allows you to vote on what's developed next). The developers also show their 'roadmap', allow others to contribute to fixing engine bugs and are growing their engine quickly with consistent updates. When making the games, Godot uses a Python-like scripting language, and C++ for optimizing or extending the engine.

CRYENGINE is also an engine becoming more popular recently. It has been around for a long time, but the engine recently became completely open-source and free, with optional premium packages similar to Unity. It has a reputable history with some gorgeous games such as Crysis 2 and Far Cry 3. Although there aren't as many indie studios using CRYENGINE as there are with other engines, the engine only became 'free' in March 2016, so I would expect more developers to start using this, as there are also no royalties when using the engine.

Lumberyard is a game engine developed by Amazon, it's a very new engine as it only released in February 2016, and has been getting consistent updates since. An interesting feature with Lumberyard is the native Twitch and AWS integration built in with the engine, as both Twitch and Lumberyard are owned by Amazon, they seem to be pushing the Twitch integration as much as possible. The engine's source code is also available for you to download and modify, but you're not allowed to redistribute the code unless you follow their terms. Along with that, there are no subscription or royalty fees, you only need to pay for the AWS services you use. Lumberyard uses Lua for scripting gameplay, and C++ for extending the engine.

Source is a popular engine developed by Valve. It first debuted in 2004 with Counter-Strike: Source. The engine has been used by Valve, many third-party companies and in countless community mods. Some notable games made using Source are of course, Valve's games all the way from Half-life to Dota 2, as well as third-party games such as Garry's Mod, The Stanley Parable, Titanfall 2 and many more. All code is written in C/C++.

LÖVE 2D is different to the rest of the game engines shown above as it doesn't have an editor. It's a framework which you can use to make 2D games in Lua. It's also free and open source, and compatible for Windows, Mac, Linux, iOS and Android. Although there aren't any big games developed using this engine, I have seen it used a lot for prototyping ideas and for small, quick projects such as game jams.

GameMaker Studio is a 2D game engine which was first released in 1999, although it's had many big updates since meaning it's not dated at all (It wasn't even called GameMaker in 1999). The engine is used by a variety of developers, from beginners to professional studios. It seems to be a great game engine for 2D games as it seems to have everything built into the engine, including an image editor and animation system. The engine appeals to beginner developers as it provides a visual scripting option, but you can also use something called Game Maker Language if you're more comfortable coding the games. It overall seems like a brilliant engine for 2D games, and has been used in some amazing titles such as Hyper Light Drifter, Undertale, Hotline Miami, Spelunky and many more. Although if you want to release a game using the engine, it won't be free. You can pay only $39 for a 12 month license for Windows publishing, $99 for a permanent license for Windows, Mac and Ubuntu publishing, and it goes all the way to $799 per 12 month for one console or $1500 per 12 month for absolutely every platform they offer.

In Conclusion, I'm going to use Unity for my project. This is primarily because I'm most familiar with it and because it's one of the most developed engines out of the bunch I've looked into. Another good option would be Unreal as I've used it before and it's very developed, but I'm not great with C++, not keen on using the blueprint system and haven't used it enough to confidently make a full game with it. Godot was another option, as it has C# support, but I still feel as though Unity would be better for this project as Unity has more features and Godot is a fairly new engine.

Focused Research (Week 2 : 15/1/18)

Based on my previous research, for my final major project I'm planning on making a Roguelite FPS. The game will have a main hub, then when you're in the hub you'll be able to choose a level to raid (e.g. a Barracks or a Warehouse, one gives more xp, the other more loot). The level is randomly generated and so is the loot, but you only get to keep the loot for your later runs if you make it to the end of the level, if you die mid-level, the loot is lost and you go back to the hub. This adds a risk/reward factor when going into deeper and harder floors of the level, they will get harder but there will be better loot, but you're risking losing what you had at the previous floors. So what do you do? The whole game is also going to have a retro FPS aesthetic as I want to focus more on the programming rather than making realistic models with texture, normal, heightmaps, etc.

The reason it's classed as Roguelite and not Roguelike is because it doesn't follow the exact definition of a Roguelike but uses many similar elements. For example Roguelikes need to have random level generation (Check), Exploration (Check) but then it also needs to be turn based, grid based, Hack 'n' Slash, etc. (Lifewire, 2016). which my game is not, so it's not classed as a Roguelike.

Looking at other FPS games, we can see it's clearly one of the most popular genres. Looking at Steam's top selling games of 2017, in the Platinum section, 7 out of 12 games are FPS games or have FPS elements (Steampowered, 2018). Since it's origin in 1992, FPS games have been some of the most successful games each year. If we look at franchises such as Call of Duty, we can see the franchise has sold over 307,350,000 copies over it's 23 games (including mobile) which equates to $15,900,000,000 (Statistic Brain, 2017). Looking back at my previous research too, we see that the Shooter is the most popular genre. Of course this isn't only first-person shooters, but big portion of shooter games will be first-person shooters.

The Roguelike genre first started with the game Rogue which was 1980 game for Unix systems (Kuittinen, 2001). As 'clones' of this game started being developed, people started categorising them as Roguelikes, and over the near 40 years since the original game was released, people have put their own spins on the genre while still sticking to the same core principles the original had. The term Roguelike has always been very vague, for almost 30 years it was never defined what actually made a game a Roguelike, until 2008 when the Berlin Interpretation of a Roguelike was defined at the International Roguelike Development Conference (Lifewire, 2016). There aren't any AAA Roguelikes, but for indies it's a very popular genre as the levels generate themselves, creating a lot of content and endless reputability without having to create every level by hand, which costs a lot less to develop. This doesn't mean the games are bad, it just means that the developer can spend more time doing other things on the project without having to focus most of their time on level design, in fact, some of the most successful indie games are Roguelikes. If we look at The Binding of Isaac, it has 95% positive reviews on Steam, the original has over 2 million sales, the updated Rebirth version has almost 2 million sales (SteamSpy, 2018) and that's only on Steam, it doesn't include the PS4, Vita, Xbox One, Wii U, 3DS and Switch ports. Another successful game with Roguelike elements is Spelunky. The game isn't considered a Roguelike but rather a Roguelite (or Roguelike-like). This is because it follows many characteristics of a Roguelike but not completely. The game has over 740,000 sales on Steam alone (SteamSpy, 2018), 90% positive reviews on Steam and a sequel in the works.

A current trend in video games (specifically indie games) is a retro theme, whether it's 2D games using a pixel art and limited colour palette (e.g. Undertale) or 3D games which use very low-poly models, basic animations and low resolution textures to give the classic 3D effect (e.g. Vaccine). These games are becoming more popular for a few reasons. Firstly, the nostalgia - People love to play games that makes them feel like they're playing the same games as when they were younger, but it's all new content. Another reason is it's easier and faster for small dev teams to create these assets. Creating a low-poly model with basic diffuse textures is much easier than creating a realistic model, with diffuse, normal, height, occlusion, smoothness and many more maps. This doesn't mean the developers are lazy, but it allows them to get more content in a shorter time, which is important when you only have a small amount of time or budget.

Some of the main inspirations for my game are the old Doom and Quake games, they have the same retro aesthetic I would like to achieve, and also the same fast paced, run and gun gameplay which I'm aiming for. Another inspiration is Enter the Gungeon, it's a fairly new indie game with procedurally generated levels, the objective of the game is to get as far down as you can whilst completing other objectives along the way. While that sounds similar to my idea, the game doesn't have loot that you keep, when you die all of your weapons are lost until you find them again on another run, I want the player to be able to keep weapons in my game so you can equip them in a later run.

The reason I like how Doom and Wolfenstein play is because you never know what's going to be around the corner or through a doorway, the game doesn't let you see further than the current part of the level you're playing so it's always a surprise. You also don't get much time to think once you've progressed through the level, the second you enter a room there are enemies shooting at you and you have to react quickly and decide which enemy you should go for first. I think this is what makes the game so fun, at least for me. The game is full of ambushes, surprises and secrets to find, so even though the game is linear, it still feels like you're exploring a space station.

The game engine I'm going to be using is Unity, as I'm more comfortable using it than using similar engines such as Unreal. I would like to try and get more experience with a few game engines but I think for the FMP, Unity is what I should use so I can just get on with the work and not have to worry about learning to use the engine too. Unity is becoming a more popular game engine for commercial games recently, as a few years ago most people just saw it as a prototyping tool, now there are many very successful games using Unity. The engine's most recent success game is Cuphead by StudioMDHR, the game has over 1,300,000 copies sold on Steam alone (SteamSpy, 2018). Countless other successful games were made with Unity such as Rust, Hearthstone, Firewatch, Ori and the Blind Forest and many more.

As I said before, Roguelikes are popular within indies because they can generate a huge amount of content without having to spend time meticulously hand-crafting each level. Not every game generates the levels the same way though, if we look at two 2D games, Spelunky and Enter the Gungeon, they both have procedurally generated levels but the levels are completely different. By looking at the 2 pictures below, you can clearly see the levels are different. Enter the Gungeon's levels are rooms randomly placed around then connected via paths, whereas Spelunky's levels look like just one giant level, but is actually a 4x4 grid, which becomes more obvious when you know it's split into 16 sections. Personally for my game, I think Spelunky's method of level generation would be best as I think it makes the level feel more whole rather than randomly selected rooms, but I do still like Enter the Gungeon's method of level generation as it gives the designers a lot of control over each scenario as each room is self-contained, nothing can come in or out once you've entered the room, until you've killed everything in there.

Another part of the game which'll be procedurally generated is the guns. I love how the guns in Borderlands are always random, you never know what stats a gun will have, they have different rarities, it makes the game exciting and every play through the game can be different depending on how lucky you are with getting weapons. I decided this would work well with my game and the procedural generation theme so I decided to take inspiration and implement something similar in my game. Of course Borderlands is a sci-fi game and mine is a WW2 themed game so I can't have laser guns or unrealistic guns, but instead I'm going to have a set amount of real guns but then different attachments randomly attached to it which'll buff/nerf certain stats of the weapon, making each one different. In Enter the Gungeon you get a log of every gun you've earned and I like that collectible aspect of the game, so I in my game I'm going to have an inventory system with all of the players guns so they can choose what they want on the next run, it'll also showcase their best guns in a hub area.

As my game is going to have a 'retro' theme, I need to look at other games doing this too. I want the game to look old, but I will also be using modern lighting in Unity and some other effects which weren't possible back in the 90's such as reflections. I haven't seen many other games doing this but I think it'll work well, because the game will look old but still look great with some modern elements to it, similar to the Octopath Traveler demo on the Switch, it uses pixel graphics but modern lighting and the effect looks great. Some other games I'm looking at which use the retro style are Vaccine and Devil Daggers. Vaccine is a third-person survival horror, and though the reviews of the game aren't great, I think it imitates the retro style very well. Another is Devil Daggers, the game is quite simple but extremely challenging, the game has this retro feel, with a lower resolution screen, simple models and limited colour palette, everything comes together really well and I think the game is better how it is, than if it used a modern graphics style.

My game is going to be set at the start of WW2, with the Invasion of Poland. The game isn't going to be completely true (as the guards will be attacked by genetically modified nazi's) but I want to keep some truth, and Germany did invade Poland at the start of WW2. The Germans referred to this as Fall Weiß (Pronounced Fall Weiss), but there's already a game called Fall Weiss on Steam, so I decided to call my project Case White, which is Fall Weiss translated to English.

The game is going to be set indoors, so I want to look at some Polish and German interiors and how other games' interiors look. The reason I'm looking at German buildings even though the game is set in Poland is because the Germans have meant to have taken over so they've built their own buildings, but will have also kept some Polish buildings. I really like what Wolfenstein does with the buildings, everything looks like a sort of modern castle, with big concrete structures and a cold feeling. Everything is huge, and the environments go from big metal structures to small, narrow corridors which look more like a typical castle interior, although these buildings aren't generally true-to-life, looking at actual German interiors, I've found that they're often very detailed and grand. You can see the comparisons in the pictures below. I'm not aware of any games set in Poland, but if we look at some real Polish castle interiors we can see there are some similarities with German castles, except it's often a bit more simple with only areas of high detail instead of the detail being absolutely everywhere.

There are many games I can reference which are set in WW2, many of the games set in that era are shooters too which is great because it means there's a lot I can reference for my game. The games I'm mainly going to be referencing for the WW2 elements are the Wolfenstein games, specifically Wolfenstein3D and The New Order. I like The New Order because they have an element of fiction to the story like my game does, and it still does a great job of creating a believable world even though it's not true to life. The reason I'm referencing Wolfenstein3D is because it's one of the first FPS games, and it doesn't have any fancy extras. It's still fun with the bare minimum an FPS needs, and also manages to sell an environment and immerse you with very limited detail.

Focused Research References

Week 3 (22/1/18)

I've moved my original timeline from my proposal forward slightly, as I've finished my research a week earlier than expected, which means I can move onto planning my project and beginning the prototype for my project which'll also help in my pitch as I can show anything I make on the presentation instead of everything just being explained.

Firstly, I put the project into a project management tool. I decided to use HacknPlan as it's geared towards game development, which means there's categories for each part of the development which was helpful for organising everything. I've got a basic list of 12 features which need implementing, some will take longer than others and of course there will be smaller problems I'll encounter which I haven't thought of, but all of the main mechanics are listed, and when you click each mechanic it goes into more detail about what I need to do specifically.

Level Generator

Before starting the level generator, I want to have a solid understanding of how it works so I know exactly what I need to do. I've read Derek Yu's book, which explains how it works but I also found a more in-depth explanation by someone called Daruis Kazemi about how Spelunky generates it's levels which walks you through completely how they're generated and what the game does to make the levels feel even more 'random'.

I've drawn a simple version of the level generator, there's going to be more features when I put it into Unity (such as seed generation, making it so the level can be bigger, etc.) but this is my basic understanding of how it will work. From this I know how I'm going to implement it using C# in Unity.

Before I start on the code, in Unity I made the 4 basic blocks which'll make up the level. These will have a lot more variation in the final game (which is what makes the levels feel random) but just for prototyping, this will work perfectly, as we can clearly see the layout of the path which will be made. So I made these objects into Prefabs which I'll instantiate later in the level generator.

I want the level to be generated from a seed (which is a string that's input to the generator, the level is then generated around that string meaning if you input the same string it should always generate the same level each time), so I have to make a seed generator and then convert that seed into something which the level generator can read. They way I'll do this is have the game pick a length of random characters (can be anything) which'll then be converted to Binary which should be about half and half 0's and 1's but in a seemingly random order. This means I'll be able to use the seed, as it's numbers and not just text.

These are the two functions which generate the seed as a string, then convert that string to binary and return it as an array of integers, I then use these functions in the Start() function to create the seed. I also added an option for manual seed input if I don't want it to create a random seed, which just skips straight to the converting to binary part.

Next I need to start on the actual level generator. The way I'm going to do this is have the 2D array of integers, and a Vector2 representing the current position along the path being generated so I can loop until the current position is at the bottom of the map (meaning the path can end there). The generator will pick a direction based on that converted seed I made before and the correct integer will be assigned for the correct type of block in the path depending on where it just moved to.

After starting on the level generator, I noticed a problem with the seed to binary converter. It only outputs 0 and 1, but I need 3 options so the path can go left, right and down. The way I got around this is by adding a small for loop in the StringToBinary() function which changes every third element of the array to -1 before returning it, this means that instead of being half and half 0 and 1, it's now in thirds -1, 0 and 1. I think this could be improved in some way as it's exactly every third element that's -1 instead of being slightly random like the 0's and 1's will be, but it doesn't really matter at all as there's not really any way of predicting how the level will turn out based on any string that's input.

From the code I've written so far I can see it's kind-of working. I can create the levels, but they're very vertical and boring, or if they do have more horizontal movement to them they have an error where it creates a wall so they player can't pass through the level. I want to try and tackle both of these so I'm going to have to force more horizontal movement and try to fix any problems in the map.

To fix the problem with the horizontal movement, I made it so the level is forced to move a horizontal a certain amount of times every time it moves down one. This is the code and the results.

It is clear that the level is using more of the horizontal space instead of just shooting straight down, which is great. The levels look a lot more how I imagined they would, but it's still getting the path blocking error. To fix this I'm going to have for loops run through the whole map and fix the map after the path has been made, but before the blocks are instantiated into the world.

When fixing the first problem I also decided to try and fix another problem which wasn't game-breaking, but just not right. When there's a solid 0 block, I wanted the block above it to always be a block 3 which means it's open at the top, left and right but the bottom is nice and flat like a wall should be. This will stop levels from looking weird later on as there won't be openings for areas that are just blocked off. I also managed to fix the problem with the paths being blocked off, this was happening because there were '1' blocks with a '2' above it, which meant the path was trying to move down but is getting cut off by the '1's. To fix this I changed any '1's with a '2' above it to a '3', meaning there is an opening at the top of the block which lets the path carry through. Here are some of the results from the final prototype of the level generator. I need to make all of the variations of these blocks for the levels to feel fleshed out but this is the basic system working.

In this video I have it so the current level is destroyed, then a new seed and level is generated every time I press 'R' which lets me preview levels very quickly and check if there are any other errors which might occur. Next I'll need to add some first person controls which'll allow me to walk around the levels, it shouldn't be hard as there's a lot of resources online for me to reference, and Unity provides an example First Person Controller which I'll might use if it'd be better to use theirs.

To begin to test the player controller, I need to make it so the level generator spawns the player once the level has been instantiated. At the moment we haven't got a player to spawn, but I can still write the code for it so I just have to assign the prefab to a variable.

This is the line of code for spawning the player, I've added a boolean called isTesting, which if true, means the player won't spawn. This is so I can choose to only generate the level if I don't want the player to appear each time.

Player Shooting and Weapons System

To save time I decided not to make the player controller and mouse look script myself, there are plenty of resources online and a built in Unity FPS Controller which work perfectly, as I'm not going to be having very advanced movement. All this does is allow me to walk around and look around using the mouse but it means I can save time and focus on the shooting mechanics earlier, which I think is going to be a bit more of a challenge as I want to be able to swap the weapon to whichever weapon I like and have the shooting system use all of the properties of that gun I'm currently holding (e.g. Damage, Weight, etc.)

I've started the shooting system, this script is going to contain functionality for Shooting, Reloading and Switching weapons. So far I have a Gun class, which I have an array of instanced for the 2 weapons that the player can equip at one time, I then check for the players input and call the relative IENumerator to activate that function. The reason I'm using an IENumerator is so I can add delays easily, which works well because everything will have some sort of delay. I still need to setup shooting, but reloading works and weapon switching works. I've also got a function called PlayerBusy() which returns a bool, this is used to check if the player is currently doing anything (e.g. Reloading, Shooting), and if the player is busy, you can't do anything else.

Today I added some more functionality to the shooting script, as it didn't take bullets out of the mag when I shot before, and it didn't have support for fully automatic weapons, only semi automatic. Both are now available and I'm going to start adding some simple placeholder weapons so I can test shooting and getting a good feel to everything before moving on, for example I want the weapons to have a certain amount of sway depending on their weight, but I'm not sure how exaggerated the effect should be.

To start with getting the right 'feel' to the weapon system, I started with the weapon sway. This gives the weapons the effect of weight when the player looks around, meaning weapons that are heavier will have more sway than lighter weapons. Here is the code and an example of the sway when actually in-game. From the video you can see that the 2nd gun moves more, meaning it's heavier.

I decided to add some simple animations to the weapons to help everything feel more polished, I'm not sure if these will be the final animations but they work for now as placeholders. You can see the animations in the video below, there's an idle, reload, shoot, sprint and switch weapon animation.

Next I want to work on being able to pickup guns (as loot from chests) and store them in your inventory as just a string, then be able to equip that gun mid-run and have it convert to a Gun object. The inventory shouldn't be difficult as it'll just need to be a List or Array of strings, and this inventory won't be saved (because all of these guns will be lost on death) so I don't need to worry about that yet.

To start, I created a function which takes a string and converts that to a Gun object, which can be used to equip the gun in the currently equipped weapons List. This is done by adding all of the attachments attributes together which is then returned as a Gun class. I also added functions for equipping an unequipping weapons, to Equip a weapon you need to input a gun (Using SeedToGun() function) and to Unequip a gun you need to enter the index of the gun to unequip (either 0 or 1). Now all I need is something which randomly generates the gun strings and input all of the different attachment attributes. Once I've made the art assets I'll be able to integrate them too.

As I need to input all of the attachments and weapons I decided to research them now so I can get a few in the system for testing, there won't be any visual changes yet as nothing has been modeled, but the stats of the weapons will change depending on what attachments are equipped and what type of gun it is. Here are the 2 sheets I've got with designs of the guns and the attachment attributes, the guns are inspired by what Poland used in WW2, the drawings are only quick sketches, but I also have the name of the actual gun which was used for reference next to the sketches, so I can go back to them if I need to.

Now that I've got some weapons and attachment stats input to the weapon system, I can start randomly generating weapons. To do this I'll need to generate a string with random attachments, I also want to be able to set a sort of 'rarity' to the weapon generator which'll make better weapons (with more attachments) as the player passes more floors and the game gets harder.

To get this working I had to change a few things as the gun equipping function didn't have any support for when there isn't an attachment in a slot, so there would be errors. To get around this a I had to re-write part of the SeedToGun() function so it checks if there's an attachment before adding it to the final weapon stats. I also wrote the GunGenerator script which adds a random gun seed to the players inventory when the player collides with the object. Here's both the re-written SeedToGun() function and GunGenerator script.

To finish this week I decided to add Raycasts to the shooting to actually give it functionality. Before, the moment ammo was taken away from the mag, there was an animation and you had to reload ammo, but nothing is actually 'shot' when you fire the gun. I've changed that now by implementing the Raycasts which are shot from the camera every time you shoot, along with the bullet spread, bullet range and shotgun bullets.

There's not really any difference in the normal bullets and shotgun bullets other than a shotgun just shoots 6 shots at one time rather than 1 like a normal gun would. Shotguns will generally have a wider bullet spread as well as a shorter range and damage. Here is the code for the shooting. I've also made a video to demonstrate the difference between normal guns and shotguns.

Next week I'll hopefully start on the AI. It's going to be a challenge as the levels are procedurally generated and I'm not sure if Unity supports baking a navmesh at runtime so I might have to look at some alternative pathfinding techniques. I'm also going to be starting on the pitch for my game which might mean I won't be able to work on the game as much as I'd like, but hopefully it won't affect it too much.

Week 4 (29/1/18)

Pathfinding

To start this week I tried implementing some simple pathfinding which would be the foundation for the AI. My first attempt using Unity's NavMesh system didn't work well. I managed to generate the NavMesh on the procedural level, but the NavMesh Agents wouldn't lock to it and kept giving me errors that it couldn't create an agent because the NavMesh wasn't close enough. This was because I couldn't bake the NavMesh onto the level (because they levels are procedurally generated). I might try and come back to the NavMesh system if nothing else works but for now I'd like to try a few other techniques. A popular pathfinding technique is the A* algorithm. I need to do some research into how it works and how I'd implement it into my game, but I think it could work well for what I need and would be more rewarding if I manage to make it myself, rather than using something which is built into Unity.

My second attempt at creating pathfinding for my AI is by using the A* algorithm. The A* algorithm uses a grid of Nodes which the AI can navigated, there are walkable and unwalkable Nodes (unwalkable being areas with walls/obstacles). Each Node has 3 values; the gCost (which is the distance between the node and the starting point), the hCost (which is the distance beween the node and the target destination) and the fCost which is both added together. The game then loops through the each node picking the lowest fCost each time the values are calculated, until it finally loops and reaches it's target node. Unity Developer Sebastian Lague does a great job of explaining it by breaking it down and demonstrating it, and also shows how to implement A* in Unity. I'm going to be following these tutorials, as I've never tried anything like this before so I think it'd work better if I follow the tutorials.

Firstly I need a grid of nodes which were either walkable or unwalkable. You can see this grid of nodes visualised using Unity's Gizmo system, the red cubes are unwalkable and the green cubes are walkable space. Here is also the code so far that creates a grid, checks which nodes in that grid are walkable then assigns the correct values to the grid nodes (whether the node is a walkable space and what point in the game world it is. There is also a function to return a node when given a world point, this will be used so the enemies know what node the Player is standing on.

Next is actually implementing the A* algorithm using this grid of Nodes. The pathfinding script takes a Start Position (which'll be the enemy position) then a Target Position (which'll be the Player). Then uses the A* algorithm to find the shortest path within the walkable nodes. Here is a path being generated between 2 objects throughout a level (represented by the black line).

The pathfinding is now almost finished, so soon I'll be able to continue with the rest of the AI. The enemies can now create a path to the player, and walk along that path to get to the player. The most important part about creating this pathfinding was that that it works dynamically when creating the level. I had a few problems with this while working on the system as there were times when the game was trying to create the grid of Nodes before the map had been instantiated which meant the enemies could just walk through walls as there were no unwalkable areas yet. To get around this I had to change the Script Execution Order a bit to ensure the map is instantiated, then the grid is built, then the enemies can request a path, if done in a different order it either wouldn't work or would give me an error because the enemy was trying to request a path to the player before the grid had been created. Here is a video of the enemies following a path to the player. The enemies don't do anything at the moment but next I'll start working on the AI which attacks the player and lets the player shoot the enemies.

Next I need to implement the pathfinding in 3D space as at the moment is only works on a 2D plane and I want enemies to be able to walk up any stairs or objects within each block of the level. In my head I have in idea of how I'll make this work but I'm not sure how easily it'll actually be to apply to the system, or if it'll be efficient enough to actually be viable as it means I'm going to have to have a lot of Nodes for the grid. The editor already lags a lot when showing the gizmos for the grid so having that multiplied by 20 might not work well.

After attempting to implement 3D movement (rather than just on a 2D plane) into the pathfinding system, I've decided to give this technique a break and look into other methods of pathfinding. There's a few reasons for this, first being it was either very restrictive, or very slow. If I made the grid more detailed, it took a very long time to create the grid and was extremely inefficient, this was the same for creating paths for the enemies to follow, it started taking a long time for each path to be calculated. Otherwise it was very glitchy and difficult to get it stable. After trying for a few hours to get it working completely stable, with countless different attempts, it always seems to go wrong somewhere, whether it doesn't generate the grid properly based on a slightly wrong angle on part of the environment meaning the enemy can't find me, or whether it's an enemy walking through parts of the map, the system just wasn't working for what I wanted. If it's the only pathfinding option I have, I'll go back to it, try and optimise it and make it stable, but I think at the moment it'd be better use of my time to try something different, as I've been working on this for the first half of the week with not much to show for it. It has been a good learning experience though. Despite the fact that it's not working well and is very inefficient at the moment, it's been great to learn the basics of A* pathfinding and pathfinding in general. If I were to make a 2D game I think this would be perfect, and I feel more confident looking at other pathfinding techniques now that I've learnt the basics of this one.

My next attempt on pathfinding is using an alternative to popular alternative to Unity's NavMesh system by Aron Granberg. From researching different pathfinding methods for procedurally generated worlds, it seemed that a lot of people kept recommending this asset. I decided to have a look into it and so far it's working perfectly, within 5 minutes, I managed to have the asset create a pathfinding grid over my procedural levels and have enemies find paths within that area to my player, and it also works in 3D space too, not just over a 2D plane. It's also very efficient and provides a lot of settings and gizmos which let me customise it for my environment. Although I think this is the solution I'm going to use for my pathfinding problem, it does have one drawback, which is that it doesn't allow me to have 2 stories in my levels (demonstrated in picture below), meaning if there's an elevated walkable platform, the enemies won't be able to walk underneath them.

AI

Before starting on coding the AI I want to plan my enemies. So I've drawn a quick sketch of the 4 enemies I'm hoping to get into the game and a small description of how they each behave. This will make it easier for when I actually get into the code because I can just reference this design document when writing their mechanics.

I've now got the foundation for the first type of AI, which is the melee AI. Without any animations or character models it's not really clear what's happening, but the functionality is all there. If you watch the video below I show the enemy hitting me, and if you look at the inspector you can see my health going down. I also show that the enemies can be killed now. This AI will be quite similar to both the Tank and Charger AI, with a few changes to health, damage and with the charger they will increase in speed (and charge at you) when they get close to you.

I've now finished the functionality of the other types of AI. They're fairly similar except have different speeds and differences, one of them gets close to you then starts charging. Although they don't change much they do all affect how the player reacts to them and prioritises them. For the melee enemies the player will just have to keep a distance, the ranged will probably want to be taken out first so they're not just doing damage constantly from a distance. The tanks will constantly need to be avoided while dealing with any other enemies as they do great damage and lastly the player will want to keep the chargers at a distance until the room is cleared because they can't outrun them. They also don't look any different at the moment, but once I've added the character models and animations to them, they'll come to life much more.

Skills

In my game I'd like to have quite a big emphasis on skills. So the player can level up certain things which will improve that aspect of the game, for example, the player can level up a health skill which means they have more health. I'd like there to be a few skills for this so people have something overall to work towards (other than getting better weapons) and I'd like there to be online leaderboards using Dreamlo. I think this gives the players even more of a reason to work towards the level as it's fun to be competitive with other players and try to reach the top of the leaderboards. I've tried this before so I remember vaguely how to implement it, but I want to try and make it more complex by letting the user create a profile before they enter the game which'll remember their username, rather than them having to input it every time.

I want the leveling to have an exponential EXP curve, meaning it gets harder and harder to level up each time. The formula I use to calculate the amount of EXP needed until the next level is (BaseEXP * (CurrentLevel^2.2)). The pictures below shows each amount of EXP needed per level until level 100 and the code for the Skill class.

Although I'm not finished with the skills yet, as it hasn't got any online capabilities, I am finished with the main part of it so I'm going to start work on some small parts of UI (Crosshair, Ammo Count, etc.) so it's a bit clearer what's going on, as at the moment you only know what's happening in the game (i.e. when you're getting damaged, how much ammo you have) by looking at the editor, not the actual game. I'm probably going to be jumping from mechanic to mechanic over the next few weeks because a lot of what I've made so far has been waiting for other mechanics or parts of the game for it to be completed, like I need to do the hub before I want to add online leaderboards so I can just put it right into the hub and have that done instead of having to make the leaderboards UI, then go and have to re-do the UI when I create the Hub. It should start taking a lot of shape soon though, as at the moment it's just a few mechanics together in a project, they should start working with each other and creating a proper game soon. I'm quite a bit further ahead than I thought I'd be, which is great because I think I underestimated how long the modelling environments and weapons will take before I started so it's good to know I have a bit more time to fall back on if they're taking a long time.

HUD

I want to add UI to the game before continuing with other aspects of the game so it's clearer what's happening. These aren't going to be any menu's or inventory systems but rather just the in-game HUD which let the player know what's going on. The first HUD element I added is a simple crosshair. It didn't take any programming so it's probably the easiest of all of the HUD elements I'll add.

Next I decided to make the hitmarker as it's in the same sort of place as the crosshair and I knew it wouldn't take too much programming to get it working. Originally I had the hitmarker appear for a few frames then just disappear immediately, but it felt clunky and looked bad, so I decided to add a slight fade out which works much better. The crosshair now appears for 0.5 seconds and immediately begins to fade. It's hard to show in a picture so here's a video of it working.

When making the hitmarker I noticed the game doesn't really show the player that there's bullet spread, meaning sometimes I just feels glitchy and inconsistent when you're shooting right at an enemy but there's no hitmarker. To get around this I want to add a sort of tracer coming out of the gun when you shoot. This isn't really part of the HUD, but it shouldn't take long so I'll just add it now.

Here is the finished tracer, in my opinion it shows the bullet spread a lot better. I need to make it disappear after a certain amount of time or if it hits an enemy but that will only take 5 minutes. The way it's done is a GameObject with a Trail Renderer applied to it, it's then instantiated and has a huge force added to it, I also added a slightly bouncy Physics Material to give the extra ricochet effect.

Next is a reload timer, I wanted this so the player can clearly see when they start reloading and when it's finished incase the animation isn't clear enough. This isn't really necessary but I think it works well, a game called Blacklight: Retribution did this and I really liked it. It's just extra feedback, which isn't intrusive but nice to have. Here is a video of it.

For the health indicator I decided to move away from making it a health bar, but rather just a number showing the players health similar to what Wolfenstein: The New Order does. I might come back to this later and change how the '+' icon looks like, but for now it's fine as a placeholder. The player can now see when they're taking damage which is great. I'd also like to add some more feedback when the player gets damaged so they don't have to watch the health indicator constantly. Here is a video showing the health indicator.

In conclusion to this week, I think it started slow but towards the end managed to make a decent amount of progress on the game. In the next few weeks I really hope it starts coming together nicely and I'll probably start adding art assets soon as most of the main mechanics are almost complete. There a few a small tweaks I'd like (Such as the enemies to only be able to detect you once you're actually in their sight, rather than just using distance from the player) but most things are complete and just waiting for art assets and levels to be designed. Next week I'll be continuing with the UI a bit then onto level designs and the Hub area in my game, I'll probably do both at the same time on-and-off so I'm not spending hours on just one thing, as both will be quite a lot of work.

Week 5 (2/5/18)

HUD

To start this work I made the ammo counter. I decided it'd be a good idea to show a small icon of the gun you're holding too so I made some white silhouettes of each gun in Photoshop, so now when you switch weapon you can see the gun's mag size, how much ammo is currently in the mag and an icon of the gun. Similar to the reload timer, this isn't really necessary but is just some nice feedback for the player which isn't intrusive at all. Here's all 4 of the icons in-game (the mag sizes aren't how they'll be in the actual game, like a shotgun won't have 30 bullets in a mag. They'll also look much better at full resolution).

Hub Area

This week I'm going to begin modelling, UV unwrapping and texturing with the Hub area in my game, which is where the player will go when they're not in an actual level. It'll be in place of a proper main menu as a more interactive way of making the menu (the game will still have a main menu but it'll be limited to only a few options). I want the Hub to be in the theme of an underground bunker, where the player keeps all of their weapons, can check leaderboards and decide where they're going to fight next. I'm also going to be doing this at the same time as my level designs (for the actual playable levels) so these will probably take most if not the whole week.

Before I start on the Hub I wanted to make a few quick designs just outlining the layout of the Hub. I came up with 4 designs, I might switch parts from each design but at the moment I'm thinking of following design 4. I like it because it has the most different floorplan, and I think if it was just a real life bunker which had been put there in-case of emergency, they wouldn't be bothered about trying to make it a perfect square, but rather just however they can fit it. It also lets different interactive elements in the room be away from each other which helps separate the room up into parts.

I started with Hub with the floor. I wanted to get the right sizes and dimensions with it and I'd rather complete one part of the model before moving onto the next, rather than modelling it all, unwrapping it all and texturing it all. Here is the process for creating the floor texture.

The texture doesn't really have a 'retro' or pixelated look to it, and that'll be the case for most textures in the game. The retro look will mostly appear in post processing when I add the pixelated filter and any other post processing to try and get the effect. Also all of the models will be low-poly which will help sell the retro effect.

To finish for tonight, I added the walls, a roof and a door. The door is currently floating because I want there to be stairs down into the bunker, but if you look past that I think it's coming along well. When I'm finished I want to add some post-processing and lighting to help set the mood better but that'll come later. Here are some screenshots of the progress so far.

This morning I added the staircase under the door, and also moved the door over a bit. I think the actual room is finished now, I just need to populate it with tables, crates, boxes, etc. Here is a picture of the room with the staircase.

Next I made a small desk/cupboard. I'll use this a few times so I don't need to make multiple of pretty much the same thing. Here's a picture of it in Unity.

After the cupboard I moved onto modelling and texturing the chalkboard which will display the global highscores. I like the chalkboard because I'll be able to add small drawings around the edges. I've tried to use it to show more of the story, where the player is meant to have drawn a plan, a tally of how long they've been there and some notes of the character wondering what the enemies are. I think if I made this into a full game that could be really interesting if it changed throughout the game, subtly giving the player more into the story and what the character is thinking as they progress.

Here is the finished room. I might add a few details here and there, and there will definitely be more to the room once I've added all of the functionality, but this is the base of the room, fully modeled and textured. I've also added some lighting and post-processing to the room (Bloom, Ambient Occlusion & Vignette) to help set the mood I want it to have. I think it'll look a lot more retro when I add the final post-processing stages which I'm planning, so for now it looks fairly crisp and modern. Here's a video of me walking around the room showing everything in more detail.

Leaderboards

The first bit of functionality I'd like to add to the Hub is the online leaderboards. This is quite easy to implement using a service called Dreamlo, which allows you to add to the leaderboard using just a URL access, meaning I can use Unity's WWW functionality to add to the database, it's also free which is great. I'm going to have to create multiple, one for each skill and one overall so it might take some time to get it fully implemented but there shouldn't be much programming involved once I've got the main functionality. Here is where I've got so far, which allows me to upload and download highscores, at the moment I'm uploading 2 tests then downloading them straight after.

I've now got the game outputting to UI. I've made world space UI Canvas over my chalkboard, and can now display the early stages of the leaderboards. There's a lot more work which needs to go into this, for example I want it to show the top 9, then the player's personal position in the 10th slot (with their position next to it instead of 10). I also need to add support for multiple highscores, not just 1. Then the inputs to let the player look through the highscores, and lastly have it work properly with the skills, meaning the player can actually level up while playing the game, come back to the highscores and have them updated. This will be a bit later in the development though, when I start working on linking the hub to the game, letting the player go from one to the other.

A stretch goal I have in mind if I have time, is to let the player enter their name and the game will download all of their stats from the highscores, working as a sort of login system (without a password) meaning they can work with the same stats no matter what PC they're using, if I were to make this a full game it'd probably be linked to their platforms account, but for this I think it'd be a nice addition. I can only do it if I have time later though, as I think the 3D modelling of the procedural environment blocks will take longer than expected. It's not a problem at the moment as I'm a few weeks ahead of my plan, but depending on how how many small extras I can add into the game depends on how long the modelling takes. Here is a screenshot of the highscores being displayed on the chalkboard (Needs a lot of work aesthetically).

I've now go the system working to support multiple leaderboards. This took longer than I thought it would as there were a few confusing errors because I was trying to access a list which hadn't been initialised yet. Once I got around them problems though it worked great, I've got 2 example leaderboards setup at the moment with some test scores input into them. I now need to work on the aesthetics of the leaderboards and make it work with the skill system I made before. Here is a video of what I have so far:

After a bit of time tweaking the fonts, colours and positioning of parts of the leaderboards, I think this is what I'm going to settle with. There might be a few smaller changes later on if I find a nicer font or decide a different layout would work better, but for now I like this.

I also need to know if this'll be readable once the retro post processing has been applied to it, so I'm going to try and get a basic version of that working just so I can test with it. The style will probably be slightly different when the game is finished, but it's mainly just about the lowered resolution.

I'm going to be using an asset called 'Darkbringer Retro Shader' for the retro effect. It does a great job of creating the perfect retro feel to the game for how I want it. You can make something look like an old gameboy game, or just add a bit of pixelation, there's a lot of customisation. I'm going to be pixelating, limiting the colours and adding a bit of dithering to the game to get the Quake 1 MS-DOS aesthetic. If you look at the picture below, it shows the sort of style I would like, except mine will probably be slightly exaggerated.

I've also made a video demonstrating all of the effects which the asset offers, I'm going to make my own colour palette eventually but for testing the palettes which the asset come with will be fine. Also from this video we can see that the leaderboards are readable, which was the main point of testing the post processing.

In order to continue with the leaderboards and connect it with the skills system properly, I needed to create all of the Skills. So I planned each skill, how it effects the player and how the XP is earned. Here are all 6 of the skills, so I will have 7 leaderboards in total (including the overall leaderboard). Now I've just got to create each leaderboard, get the variables into the leaderboard system then I can start on the controls to switch between each leaderboard.

Now I've got all these skills setup as well as the leaderboards, so I can move onto the controls. I think I'm going to have an arrow either side of the Leaderboards subtitle so it's like the player is scrolling left and right through the leaderboards. Here is a picture of the skills input into the skills system and a test of another skill on the chalkboard.

The leaderboards are now finished. You can now scroll through all of the leaderboards and it shows the player name, level then XP. I need to have it submit the players scores but that's just a few lines of code. I had only one problem with making the controls and that was actually getting the buttons interactable. I wasn't aware you couldn't use normal raycasts to control World Space UI, so I spent a while trying to find out how to access the UI buttons from a first person controller. Here's a video if it all working, I've added a small cursor/crosshair when you hover over the button because it was slightly hard to tell if you were actually looking directly at the button sometimes.

While that was uploading I also added the code to upload the scores. Here is the code for that in the Highscores script:

and here's another video showing the system working. The system feels much more finished now which is exciting, as before it was just the ability to upload to a leaderboard but now it actually uploads the players skills to the leaderboard rather than just random test values.

I've almost finished with the skills system now. I've just implemented the saving/loading from a file so the player keeps the stats when they restart the game. This was quite a lot easier than I expected, and surprisingly didn't encounter any problems along the way. I did do something similar in my FMP last year though which made everything a lot easier this time. Here is the code for saving and loading. You can see there are 3 possibilites the player can be in; First time ever playing, returning players, and players that are just coming out of a run. Knowing these 3 situations lets me decide whether to save the skills or load the skills.

To finish the skills system, all that's needed is the XP being given at the right places so the player can actually earn the XP, and for the levels to actually affect the gameplay. I'll probably finish this at the start of next week.

Pitch

This week I also had to make my pitch so it's ready to present next Friday. I made it in Google Slides and tried to show all of the main information about the game and it's mechanics without it getting too long. This was actually quite helpful because while making it, I had to really think about what my game will be in just a few sentences and how I'd describe it in an elevator pitch.

You can look at the pitch here.

Level Designs

Throughout the week I've been drawing some level designs for the '1' block (corridor). I tried to keep them to scale but they're not 1:1, there'll probably be some change when I come to actually model the levels but the basic layouts will be the same. These don't include filler blocks with just a statue or a straight corridor either. These are just the blocks with the action.

Week 6 (12/2/18)

Skills

At the start of this week I finished most of the main functionality of the skill system, the player can now earn XP in-game which also affects certain aspects of the game, level up, the levels get submitted to the online leaderboards, it saves and loads the stats from a file and the player can view their stats through the leaderboard. There's still one skill which I need to complete (as you can't earn XP with it yet) because it's when you complete a floor, and there isn't functionality to complete/move onto the next floor so I'll add that later.

Inventory System

In my game I want the player to have an inventory of all of the guns they've obtained throughout the game, which they can pick and choose from for their next run. This seems like a simple task, not much different from the skills when it comes to saving or loading but it might take a while as there will be quite a few elements to it. The system first needs the weapon and attachment models, saving/loading, the ability to pick the guns for your next run, showcasing your best weapons in the hub, adding new weapons to the inventory and previews of each gun when you select them. I feel like this will take most of the week and might go into next week depending on how many hurdles there are.

To start with the new Gun Inventory system, I had to move a lot of code from the PlayerShooting script to the GunInventory script, as before I stored all of the guns in the shooting script which clogged it up a lot with a lot of mechanics which shouldn't have been there. Now the script is purely about the player shooting mechanics, and the rest is in the GunInventory script. Next I'll start work on the Gun and Attachment models so I can properly get the gun system implemented and fully working rather than using placeholders. The attachements are going to be the same over all of the guns so there are only going to be 16 models to make. Of course if this were a full game there would be much more customisation, but even with 16 objects it still equates to thousands of combinations so I think this is great for now, it's also very easily expandable.

Here's the first weapon (Degtyaryov) fully modeled and textured. Both the modelling and texturing is very simple, the reason I did this is so I could save time, but also fit with the retro aesthetic. As I want to spend as much time as I can on the programming rather than the art, this works well for me. Here are 2 pictures of the gun, 1 equipped, the other from a 3rd person view.

From the equipped pictures it's clear I'll need to model a hand too, I dont think that'll be too difficult as it doesn't need to be super realistic and animated. They'll just be static and attached to the object, I think that'll fix the fact that the gun looks like it's floating.

Here's the PPS model finished, this one took a bit longer as it kept looking too plain but I didn't want to add too many details because of the low poly style I want, in the end I think it came out well, it's not too plain that it's boring but it's not too detailed either.

The next gun to model was the TT-33 handgun, this was quite easy to model as it was just a few parts that were inset for the details as well as a safety switch. I like how it looks in game, here are a few pictures.

Lastly, I modelled the Shotgun (Ithaca-37). This was one of the easiest to model, as it's quite a simple design and I've done 3 others so I've learnt from them, it's also one of my favourite designs. Here are the pictures.

Before modelling the attachments I'd like to work on getting the inventory system working properly. For this I'm going to need to do some UI for selecting the guns, and use some placeholders for the attachments temporarily.

To continue with the inventory system, I wanted to make a function which created an object from a seed, similar to how the stats are generated from a seed, but this is entirely visual. Here is an example where the seed it a shotgun with an attachment in every slot, you can see it spawns the (placeholder) attachments right where they're meant to be. These will be chosen from the randomly generated seeds in the final game but this is just showing that it works.

Now using that code, I can spawn the players best guns in the hub on display. At the start of the game the player will get 4 stock guns with no attachments which will be displayed, but as they get new guns with better stats and more attachments, they'll be replaced with the new ones. Here is a picture of the guns, and the code.

Next I'll be making the guns appear in-game (in the procedural levels) and modelling the attachments. I like the progress with the weapons, I think it makes the game feel a lot more like a 'real game' as there are actual guns now rather than just blocks as a placeholder for guns.

Here is the progress of the inventory system. Currently it just spawns blank buttons for every item in your inventory, eventually this will be where you select what buttons you want for the next run. Now I need to change the text on the button to something relevant to what the button will do and give it functionality. The style of the inventory is also just placeholder, I'll eventually have something to fit with the theme better.

Before adding the functionality to the buttons I decided to make it so you can open the inventory screen from in-game. So now you can, it has a small prompt saying you can 'Press F to Interact' when you get near it, then when you press F the UI pops up and it switches to a static camera. Here is a video of it:

Next I needed to give the buttons functionality. I want to assign an integer which represents the weapon seed's index in the inventory to an array which'll be referenced when you load a level to spawn each gun. To do this I had to know which button was pressed, which inventory index it represented and whether it was being turned on or off. I also couldn't have more than 2 equipped so I had to 'deny' any attempts to equip when 2 weapons are already equipped. I also needed to be able to unequip a weapon too. Luckily, Unity is very helpful and returns a bool whether a toggle is being turned on or off, the button object which is being pressed and also allows me to compare 2 GameObjects to see if they're the same. This meant I could check through all of the buttons I've spawned, compare them to the button which is currently being pressed and return the buttons index based on how many it's checked so far until the right one is found. That index is then assigned to the equipped weapons. If the player can't equip any more guns, the button is set back to off. Here is a video, I show the code in the video and the system. Next I'll be spawning the guns when the player moves out of the hub into the actual game and adding previews of the guns the player has selected.

The game now spawns guns when you spawn into the procedural level, which is quite exciting for me because I can now use the guns I've made actually in the game and shoot them, rather than just putting them on walls or shooting with blocks. In the video below, I show the guns working and also show a gun with some attachments on it to demonstrate that it works with attachments as well as the stock gun. From the video it also becomes more evident that the guns definitely need hands holding them. It's worst with the pistol as you can literally see the whole pistol floating. I'm going to do that next and add it to the game. I don't think it'll be difficult to model as it's just going to be low poly and static. I can also just mirror one hand to use for the other hand.

Here is the final modelled arm. As you can see it's very basic and low poly. I've positioned the fingers in a gripping shape so it can be used for the handle and supporting hand. The way it was made was using a Spline for the shape, which was then extruded, cut into smaller sections, expanded (using soft selection for more natural shapes) and finally chamfered around the edges to round the corners. It now just needs to be unwrapped then added to the prefabs.

The arms are now attached to the guns in-game, which I think looks a lot better than the floating guns, but of course this leads to another problem.. the animations are now broken and look a bit weird. It's only really the switch weapon and run animation that needs changing. The switch weapon needs to rotate less so you can't see the end of the arms, and the run animation needs to be less dramatic. Here is a video of the arms on all 4 gun models:

Level Designs

This week I've been working on more level designs whenever I don't have access to Unity or 3DS Max. These are all of the final level designs which are now ready to be 3D modelled. I might start the modelling next week depending on how long it takes to model the rest of the weapon attachments.

Pitch Presentation

This week I presented the pitch which I've been working on for the past few weeks to the class, David and also Jake, a developer at VOiD Applications. The pitch was meant to be written as if we were talking to investors about making the game into a commercial product, trying to sell the idea to them. From the feedback I got from David and Jake, there was a good amount of content in the slides, with a good balance of visuals and text information but I could've done better by being clearer on what the game actually was and how the Hub area worked which I agree with, as I was describing it already knowing how the game works and I probably should've gone into more detail about how the hub and main level are linked. Here is a video of the presentation.

Week 7 (19/02/18)

Codemasters

This week I started my work experience at Codemasters as Audio QA. The work experience is 2 weeks long and I'll write a paragraph each day about what I did that day. This does mean I won't get as much done on my FMP this week, but I'm still hopefully going to work on the project in the evenings and weekends, I just won't be making as much progress as previous weeks.

Monday - Today was my first day at Codemasters as Audio QA. The day started with me getting familiar with their upcoming racing game (Edit 21/5/18: It was F1 2018, I wasn't able to say at the time of writing as it hadn't been officially announced), the controls and how the game works. After about 40 minutes we went into a group meeting, where everyone shared any problems they're having and brought the rest of the team up-to-speed with what they're doing. It was great to see people discussing solutions to any problems which arose and an interesting insight to how a AAA games company functions. Later Brad went through some QA work which needed doing, which involved me going through a spreadsheet, listening for sounds to see if there were anything wrong with them, if there were I'd write a report about how to reproduce the bug and how often it happens. Brad also knew my main interest was programming, so introduced me to the two Audio programmers, and asked that if they had any bugs, they could explain how they fixed the bug to me. Lars, an audio programmer, later came over, explained a bug he had, why it was happening and how he fixed it. Although the code was a lot more complex than anything I've done, and some parts of the code I didn't understand fully, I did understand the concept of why the bug was happening and how it was fixed, Lars explained anything I was unsure about and it was really interesting to see how a professional programmer solves problems and how much I need to learn until I'm at the level I need to be, it's clear that I have a lot to learn but hopefully the next 4 years at University will prepare me enough to be able to get a job in the industry.

Tuesday - Today was my second day at Codemasters. To start the day, Brad went through my CV with me, explaining what I should do with it in future when I get more experience and qualifications, and just his general thoughts on it. The work I did was quite similar to yesterday's except I just got straight into it rather than it needing explaining. After a few hours of QA, we went into a meeting with everyone that works on audio and the producer, where they discussed any problems they were having and any new ideas they had. It was good to see everyone debating on whether or not an mechanic would be necessary, whether they had time to do it and how they'd do it. It helped me realise how closely everyone works in the team, so for example if the sound people wanted to add something, they might need people from all over the studio helping with different elements of that mechanic, and the producer needed to take into consideration if they have the time or budget for adding that and if it's worth it. They also had a BAFTA award inside a cabinet in the room we had the meeting, which was really awesome to see one in real life.

Wednesday - This morning I did some more Audio QA when I first got in the office, and I'm almost complete with the spreadsheet Brad gave me on Monday. I also met James, who also works on Audio at Codemasters with Brad and David. Later in the day, I got called to sit into a meeting where the three of them discussed any problems they were having and what they were working on. Then again later in the day, I got called into Brad's office where they had a Skype meeting with the game's composer, which they talked about what they needed next and how they wanted it to sound. The rest of the day was doing QA, finding any sounds that didn't play or didn't play properly and reporting it if there were any bugs. I also got to hold the BAFTA award I mentioned yesterday - it's much heavier than it looks.

Thursday - This morning I managed to finish the QA sheet which Brad gave me at the start of the week, or at least everything I can complete for the moment, Brad is going to walk me through the parts I haven't been able to cover tomorrow, but for the most part, it's finished. Later in the morning, I was called to a meeting with Brad, David and James where they talked about what they're doing at the moment, the problems they were having and how they're planning on fixing them. Soon after Brad and James went into a call with the game's composer, I got to sit in on the call like I did yesterday, it was great to see the progress being made from what Brad and James asked for yesterday to now actually hearing the first stages of that sound. After the call was finished with the composer, James let me sit in on him working on a few bugs I found with the audio, which was good because I got to find what was wrong, the actually see what was wrong behind the scenes and why it was happening. James also introduced me to a programmer on the game, I think next week I'll be sitting with a few of the programmers to see what type of work they do, which will be great because I'll be able to see what it's like to be a programmer working in a AAA environment. I think it'll be really insightful and helpful to be able to ask a professional any questions I have and see how they work. Lastly, I sat in a cinematics meeting with everyone who is working on the cinematics, people were passing ideas and feedback around about the cinematic which was great insight to see how many different departments go into just one cutscene and all of their individual opinions or concerns. David also helped me set up a Linkedin profile at the end of the day by giving me feedback on what I should put on the profile.

Friday - This morning started with a meeting with Brad, David and James about any problems and they were having and what they were doing. After that I sat with James while he fixed a few bugs in the game. There was one bug which I reported the other day we had to fix which was quite a big one, it was great to have some input on how it was going to be implemented and felt like we made some great progress. Later in the day David gave me a few programming challenges from the programmers. They're given to people apply for a job as part of the recruiting process. Doing these were really helpful as it let me know how much I need to learn and what level I need to be at before thinking of applying to jobs. I also learnt a bit about C++ as that was what the challenges were written in, so I had to research a few things so I knew how it was done in C++ rather what I'm used to with C#. I've had a brilliant week and have learnt a lot, I'm looking forward to getting back to it next week.

Animations

Today I decided to fix the weapon animations so you can't see the ends of the arms. All of them got updated, some more obviously than others. The run animation has been drastically toned down, before the player looked like they were swinging the gun around crazily, now it's a lot more of a light run. The arms no longer clip with the switch weapon animations. The recoil on the guns has been reduced and finally the reload is slightly snappier, with faster movements towards the end. Here is a video of the new animations:

ProCore

This isn't actually any progress on my game, but rather some news I found out about which is going to help with the level modelling process a lot.

For about the past year I've been wanting to get an asset (or some assets) which are part of the ProCore bundle. Primarily, ProBuilder. The asset allows the user to create levels within Unity, with no importing of models or having to go back and forth from projects. Many games have used it such as SUPERHOT and Manifold Garden. ProBuilder isn't great for creating high detail realistic models, but as I'm going for a retro theme and the levels will be, for the most part, made of basic shapes without a lot of detail, this asset would be perfect. The only problem was it costed $95. There are also other assets which are part of the ProCore bundle, which are highly recommended such as ProGrids.

Luckily for me, a few days ago, Unity hired the 2 people who made the ProCore assets, which also means they own the rights to the ProCore assets, which they've made free for now and will be integrated into Unity natively later down the line. This is perfect timing for me, as I'm going to be starting to make the levels soon, and these tools will make it much easier than it would've been. I will still have to make 3D models in 3DS Max for some objects, but the basic level layouts will be made using ProBuilder. The ProCore team also have a ProBuilder VR version which allows you to make levels from within VR, I'm not sure if I'll use this as the game is not going to be a VR game, but it might be a helpful tool regardless.

Attachments

I've finished the rest of the models for the guns, which was the attachments. They still need texturing and applying to the weapon system, but now they're finally modeled which is means the weapon system is finished for the most part. Here is a timelapse of me modeling the attachments. (About an hour and 20 mins condensed to 6.5 mins)

Now the attachments are all modeled, I could get them textured and input into the system. I also made a zoom effect on the scopes/sights to give them that extra effect. I used render textures and a camera inside the attachment to achieve it, the render texture is then just applied to a rounded plane (as seen in the video above) to work. Here is a video with all 4 guns and a variety of attachments on them, including both scopes.

Level Blocks

The next task is to make the actual blocks which the procedural level generator uses. I'll be making these mainly with ProBuilder and 3DS Max for more detailed models and details. This means I'll have to learn how to use ProBuilder and ProGrids but I imagine it's intuitive. I would also like to try and use the VR version of ProBuilder and see if it's helpful or not. I'll probably be uploading a few timelapse videos making the levels, especially if I end up using the VR version as I think it'll be really interesting to watch. Hopefully I'll get a lot of the blocks filled next week (and possibly the week after depending on how long everything takes). I only assigned one week for creating levels on my proposal, but it shouldn't be a problem taking a bit longer as I'm quite a bit further ahead than I imagined I'd be. This'll probably be the case for a few of the art weeks I planned.

Before starting to create the levels I want to know definitely what style they're going to be and get some reference images. I have a basic idea in my head (Similar to Wolfenstein) but I want to pin it down to one specific style to reference, which means the level blocks will be consistent and feel more like a cohesive level rather than random blocks picked here and there. I'm going to look on pinterest for specific styles and architects to grab as many reference pictures as possible. I'd also like to sketch some ideas so I can translate them into objects in the game straight away without having to mess around too much, these won't be level designs (as I've already done them last week) but rather just sketches for details in the rooms such as lights, doors, etc. They'll probably be posted as and when I'm doing the levels, I'm not going to sit down and try and think of designs for everything, but if I do have an idea for a cool feature I'll sketch it first.

I've decided I'm going to be making the levels with a Brutalist architectural style. Brutalist architecture basically just means it's 'raw', the term even originates from the French word for "raw", as Le Corbusier (a pioneer of the style) described his choice of material béton brut, meaning raw concrete in French. I decided to go with this because I'm a fan of this style of architecture, and also I think it'll work in a WW2 theme as it gives quite a cold feeling most of the time, and Wolfenstein used similar styles which worked very well. Here is a link to the pinterest board I made for reference and also a few of my favourite pictures from that board.

Week 8 (26/02/18)

Codemasters

Monday - Today I started my second week of the Codemasters work experience. The day started with me finishing 2 QA checks which I couldn't before, as I didn't have the debug command. Soon after that, Lars, an audio programmer, invited me over to look at his work where he explained what he was doing, how everything worked and explained why he used certain techniques over other techniques. This was really cool to see as it gave me an insight to all the concerns professional programmers looks out for, such as not processing a 2mb text file because it takes too long, so looking into other techniques of loading the file which'd be faster for the systems. I had no idea so much went on behind the scenes and how technical it got, it showed me how much I need to learn, which I enjoyed. For the rest of the day I was watching videos, then reporting when certain sounds could be heard clearly which the audio engineers can then use for reference.

Tuesday - This morning started with me doing some more video reference work like I did yesterday, where I have to listen for good reference sounds that the audio engineers will be able to reference, later David showed me a cutscene he was working on. He needed to add the audio to make the environment feel believable, and he only had the voice acting sounds. It was good to see this because you don't realise what goes into a cutscene, even a slight bit of background ambience or a very subtle effect on the voice can help sell the environment so much more. It's one of the things you don't notice if it's done well, which is why most people don't realise how much actually goes into the sound in every part of the game.

Wednesday - I started this morning carrying on with the video reference work. Then later David introduced me to (another) David, a gameplay programmer at Codemasters, who was going to have a chat with me about what it's like being a programmer at a AAA studio, we spoke a bit about what I was planning on doing with University, and spoke about what we were both working on at the moment. Later I asked if he could look through some of the code I've done for the college work (Mainly the Level Generator) and he gave a few tips on how I could improve the readability of the code for anyone else coming to look at the code later on, which I'm going to change later tonight. I didn't really think about making it easily readable for others as I'm probably one of the only people who will see it, but I think it'd be good practice to start making it more readable because if I work in a team later in life it'll be good practice. It was motivating for him to compliment the work I've done though, there wasn't anything that stood out as terrible to him so I'm glad I'm going in the right direction. I also got introduced to Steve who is another gameplay programmer, who helped me setup some software on the PC toward the end of the day, it was good to meet another programmer and ask a few questions to him as well. Overall today I feel like I learned a lot it was great to be able to ask any questions I like to a professional programmer and have them look over my work.

Thursday - Today was a fairly quiet day. I started with continuing my video reference work which went through until just after lunch, then after lunch Peter, an audio programmer, approached me and asked if I'd like to look at what he's currently doing. He showed me how the game calculates sound reflections, such as when you drive near a wall and hear it bouncing off the wall next to you. I enjoyed seeing how it was done and what 'trickery' the game uses to give the illusion of sound reflections. Soon after Peter finished explaining the reflections, the office had a power cut and everyone was told to go home as they didn't know how long it'd take to fix.

Friday - Today was my last day at Codemasters, as it was my last day it was quite chilled out. I started the day with David going over my Linkedin profile, what I could improve and then went and changed the profile with the improvements. It's good to have this basis as now I can just leave it and update whenever I have new experiences to add. After that I did some more video reference work which I planned to do yesterday, but couldn't because of the power cut. Soon after, the studio had to shut early, due to the weather forecast and people not being able to get their train. I've had a brilliant 2 weeks, speaking to so many different departments and talking with different developers, getting feedback on my work as well as learning about other peoples work. The experience has been so helpful and a brilliant insight into the industry, rather than just reading about it, I got to see what it's like for myself, which is invaluable for someone in my position looking to work in the games industry later in life.

Level Blocks

This week I started work on the level blocks using ProBuilder. I'll also be using 3DS Max for some of the details but for the main level layouts, I think ProBuilder will work better as it's quicker to just adjust, test, repeat. Here's the first level's basic layout. It still needs texturing, details added (which will be picked procedurally so even if you get the same block, twice, it'll probably be different) and testing, but here is the basic whitebox version. I should be able to start making these quicker as I become more accustomed to ProBuilder too, at the moment I'm still figuring things out.

As you can see, it looks quite empty, but once I add details (e.g. Crates, Desks, Enemies, etc) and texture it I think it'll look nice. Hopefully some the the references from the Pinterest board are clear in this too, I tried to keep that style with as much parts as I could without adding too much detail and risk ruining the 'retro' feel.

Here is the room completely textured. I think it could still use a bit of work but most of that will come with the details as at the moment it still feels very empty. The two back rooms could probably use some paintings or art in there too to break up the completely flat concrete walls. Thje

After finishing this block, I went and made one level for each of the other block types, meaning I can create an entire level without placeholder art. When testing this I realised how much easier it is to get lost in the levels, so I made the overall size smaller, from 9x9 to 6x6. Also the levels look very repetitive at the moment, but of course that's because there is only 1 block variation per type. Here are screenshots of the other two level types (the lighting will be much different in the final product).

Here's a top-down view of the level, I've also put a green line along the possible paths the player can follow as it's not as visible anymore.

I've also made a video refreshing the level generator multiple times so you can see how varied the levels are.

Enemy Blood

This week I implemented some blood effects when you shoot an enemy to give more player feedback and to make the game feel more 'brutal'. I've wanted to do this for a while but as Unity doesn't have a decal system, I wasn't sure if it would be possible. Luckily, I found a decal asset on the Asset Store for only £5, so it's probably not as good as some of the more expensive option, but I've managed to get it to work for this purpose. I want to add more blood splatter textures so I can have a more varied effect in the future, but this works fine at the moment and once the blood stacks on one another it's difficult to notice repetition. I also have this nice fade out effect by increasing the material's Alpha Cutoff before destroying it which you can see at the end of the video.

Code Formatting

Earlier in the week I got to spend a day with a Gameplay programmer, who looked over my work and told me anything I could improve. He said it was quite difficult to understand at first due to how it's written. As I thought I was the only person who was going to read the code, I just used Integers to represent the Level Generator tile types and current direction, he suggested using Enums to represent an integer, meaning it works exactly the same because TILE_TYPE.DISCONNECTED is still equal to 0, but when reading the code it's much easier to understand what the tile type is as apposed to it just being a 0, it meant you had to either keep referencing the comment I made at the top the class or try and remember what each integer represented, which is unnecessary. This is the updated code, on the left is the enum and the right is where the enum is used.

Week 9 (05/03/18)

Level Blocks

At the start of this week, I finished the base levels (without any details) for each block type, and implemented the functionality for the level generator to pick a 'random' variation (based off the seed it generates). Now I'll have to work a lot in 3DS Max (as all of the work so far has been using ProBuilder) to create all of the small details in the room such as crates, tables, chairs, lights, etc. Here is a video of the levels, they look quite plain right now, but once all of the enemies and detail variations have been added to each block, it'll bring everything to life.

Here is each variation from each block, I still need to add another layer of variations to each of these, but these are the basic levels and layouts.

As you can see, the levels look very plain/bland at the moment. Once I start adding more details and decals it'll start looking a lot better, as well there are a few variations which need some models to make sense, there's one I haven't included here because at the moment it's just a blank room. I need to create the enemies though as they will be part of the variations, and it'll be nice to get the enemies finished soon anyway.

The next thing I added to the environments is some lighting, as it's something which can really change the entire mood of the room, so doing it first makes sense as I can design everything else knowing what it'll look like with the final lighting. Before modeling the lights I decided to look up different types of lights from around the WW2 era on Pinterest. I have more pictures on my Pinterest board but here's a few of the main inspirations I'll be working from. Of course I can't have too much detail though, because it'll counter the retro theme, which is my main problem as I need to try and recreate some kind of old chandelier whilst keeping it 'chunky' or polygonal.

This is my first attempt at a small light, this will be in the smaller rooms and I'll be modeling a chandelier for the big rooms. This was very easy to model, as it's basically just a cone, sphere (which is warped to a bulb shape) and a cylinder for the wire.

Next was the chandelier, this was slightly harder as it's a bit more detailed, but I couldn't make it too detailed as it would counter the retro theme. I think I managed to get a good balance and when it has the retro post-processing, it looks better.

I think for now I'm just going to use these two lights, then if I feel like some smaller lights are necassary after, I can add them to the levels later. I really like how the levels look with the lighting, even though the rooms are still very empty it brings them a lot closer to the idea I had in my head and am looking forward to making more progress on the levels next week.

Enemy Models

I created the AI for the enemies a while ago, but they've had a red capsule as a placeholder since then. I want to create different models for each enemy type based on the concepts I drew in Week 4, then have them animated using Mixamo's rigging and animating service. The service is brilliant for me, as I don't have much knowledge when it comes to rigging and animating, but I know I'll be able to model a character, Mixamo rigs any model I make for me, then allows me to download any of their animations for use on that character. I want to get the enemy models and animations finished before creating the level details as the enemies will be part of the level details, meaning I won't have to go back again and add the enemies, I can just do it as I add the details.

Here is a timelapse of me modeling and testing the Mixamo rigging tool. I still need to unwrap and texture the enemy but this is the first stage done.

The enemy is now textured and in the game. I used the same tool I used in the timelapse (Mixamo) to get the animations. I also added Ragdoll physics when the enemy dies, I think this is better than them just disappearing or a death animation as it's more natural and adds a slight sense of humour to the game, which generally has quite a serious tone. From the following video, you can also see a few other tweaks I made such as blocking the player when they haven't yet selected 2 guns, the hint UI fonts, the textures are now lower resolution and the post-processing resolution has been lowered to help set the retro vibe.

Trello

I was previously using HacknPlan for project management but have now switched to Trello. This way I can see if I'm ahead of my work or starting to get behind. At the moment I'm about a month ahead of the plan which is good, as I might be able to implement some extra mechanics after finishing what I have planned and I've got more comfort room if something takes longer than I imagined.

Week 10 (12/03/18)

Gun Sound Effects

My stepdad has recently been discussing my FMP project where he works, and a colleague mentioned he owns some deactivated WW2 guns (Moisin Nagant, Kar 98) as well as a deactivated AK47 and a full metal airsoft pistol, which I could use for recording sound effects in the game. This was perfect for me as the game is set in WW2, so I went to his house and recorded a range of sounds such as reloading, dry fire and a bullet shell hitting a surface. Here are pictures of the guns I used and me recording. I now need to clean up the sound files and get them into the project, I'm also going to need to get gunshot sounds online as I of course couldn't get them from these guns.

After cleaning up the sounds I recorded, cutting them and trimming them a bit to be more concise, I managed to get 16 sounds. Some of them can be reused or used as variants, and some of them might not get used depending if I need them or not, but I have them anyway in case I need to use them. Here are the sounds I now have.

Enemy Models

Today I started on the second enemy model, which is the ranged enemy with a gun. Here is the untextured and unanimated model, I used the previous model as a base for parts of it but it's not alike the previous enemy at all, other than the left hand and feet, almost everything else is different in some way.

Now I need to move it to Mixamo, where it is rigged and I download any animations for the enemy, which is then brought to Unity and the animations are synced up with the mechanics.

Here is the final enemy, textured and animated. I like how he turned out, I wanted the character to be tall which it definitely is. Here is a picture of it in-game, I'm standing on a box to get this picture, so he looks quite a bit taller when actually playing.

The next enemy I decided to work on is the Tank enemy. I decided to use the previous models as a base again as there's not much point in completely starting over if the model is just going to be another humanoid shape. This time the enemy needed to be very large in order for it to make sense to be able to take a lot of damage, but would also make him slow. Here is the untextured model, now I need to animate and texture it.

The third enemy is now finished, I textured it using Photoshop and Rigged/Animated it using Mixamo. I think it turned out really well, I think the animations work great with the mood I was trying to portray with the enemy, with the way he's sort of sulking when idle, then when he walks he drags his feet slowly and uses all of his energy with a big attack.

Now I need to make the last enemy, which will be quite different to the rest of them as it's not quite a humanoid shape. It does slightly resemble a human (as it was once meant to be a human) but it's supposed to be a highly mutated version so it looks quite strange (as you can see by the concepts I drew before.

This is the model I made for the enemy, when it's actually in the game, textured and not smoothed, it won't be as obvious that it's 2 objects, I've also UV mapped a big area on the face so I can texture a creepy face on it. I think it's going to be interesting when it's fully rigged and animated.

This is the finished model. I wanted to go for a crazy theme with him, so I gave him big eyes and a smile, also his idle animation is him happily jigging around. I really like how this turned out, when he's charging at you in-game it's creepy and that's exactly what I wanted.

Level Generator

I started working some more on the level generator today, at the moment there was no real way to progress through levels, you can just explore and shoot enemies. I hadn't added functionality at the end of the level to send the player back to the hub (or the next stage of the level) meaning the player couldn't actually save stats or upload stats to the leaderboard without using being in the Unity editor. I also wanted to optimize the generator as there were some areas which I think the performance could be improved.

Firstly, I optimized the generator by a good amount, the levels generate a lot faster now. I noticed this when I was waiting too long to go from the hub to main level, each time I wanted to test something it was a drag, and I know it would be for the person playing the game too, so something needed changing. Before the optimization, the game would spawn a parent object which contained every single variation of that block, then just set one variation to active so only one would be visible, but all of these other variations would still need to spawn, making it very inefficient. (Look at the 4th entry: "Level took 1137 ms to generate". Almost all of that is the instantiating process).

Now I skip Instantiating the whole block and cut straight to Instantiating a variation of that block, meaning the other 3-4 variations don't get spawned at all. As you can see this cuts the time to instantiate the level down drastically, and is now 3-4x faster.

Today I started on the end of level functionality, as before you couldn't actually progress with the game. I needed a menu with a button to "Continue to Next Floor" which just regenerates the level and makes everything harder, and a 'Return to Bunker' button which returns the player to the Hub area. Here's a video of both options working, the UI isn't final either, I'm planning to re-do all the menu's at once.

Planning

I also started on a few Main Menu designs this week. I haven't yet started working on the main menu, but I've been taking inspiration from as many games as possible and starting designing a few menu layouts on paper. I also did some research and posted on Reddit asking what people's favourite main menu's were and why. This was great to get a collective opinion on good main menu's and why they liked it. It seemed a lot of people enjoy the main menu's in the Metal Gear Solid series, as MGS 1, 2 and 3 were all mentioned at some point in the thread. I especially liked MGS3, the music and theme of the menu was great, it has soldiers fighting in the background with a really nice effect over them, and a camo pattern scrolling behind them The music is also perfect. Another menu which caught my eye was Nier: Automata's. It's got a very nice landing screen with a glitch effect on the text, then the menu's are also very simplistic and stylized, I personally really like simplistic menu's and art so it grabbed my attention immediately. Also from my personal opinion, I really like The Last of Us and Uncharted 4's main menu's. They're very simple as far as UI, but then have a very detailed environment in the back with subtle motion and relaxing music. It doesn't have any logos to take away from the environment, nothing unnecessary, and I think that's why they're so good, they strike a great balance between being interesting but also being simple, it's not too much but it's still enough. In my opinion it's what a main menu should be.

When designing my main menu, I want to take inspiration from these Naughty Dog games but I also want my main menu to feel retro. I'm thinking of trying to combine the retro feel but also keep the modern simplicity of the main menu that I like. I think I'll be able to do this using pixel fonts, and the retro post-processing filter I use on the background. I'm going to design a few main menu's first though and see if I manage to design anything better.

UI

The game used to feel quite clunky and slow when transitioning from the Hub area to the main level, this was because it basically froze the game until the level was loaded, it's how just Unity loads scenes. Due to the fact it took about 30 seconds to load the level sometimes, it just felt like the game had crashed. The game now has a loading screen to show the player everything is still working fine. Here is a video of the loading screen.

As I was already doing some UI this week, and I wanted to take a break from the 3D modelling due to working on the enemies for most of the week, I decided to make the main menu too. It's not completely finished, I still need to fill in some credits, as at the moment it only says me, and I'd like to credit everyone who helped with the project, such as the man who let me record the guns, Mixamo for the animations, whoever's music I use for the game. At the moment it just says me though, just while I get it working. I decided to use a layout similar to The Last of Us, as it was probably my favourite menu I found while doing my research. I think I'll be changing the font in the future as there's just something about it I'm not keen on, but for now it serves it's purpose well. Here's a video of the main menu, I wanted it to be seamless with going to the Hub.

Lastly for the UI this week, I added functionality for the player to be able to enter their own username. This came with a lot more stress than I imagined, as there was one bug which was incredibly annoying due to an oversight. A boolean was defaulting to false (as normal) and needed to be set to true when loading the game for the first time before loading stats, but because of something I changed, the boolean wasn't being set at all meaning it was always false. I didn't realise this when I changed it and was confused for about 30 minutes until I realised how small of a mistake it was, after that everything went smoothly. Here is a video of the username system working, this is cool because players can now input their own username to the leaderboard rather than me having to do it through code. It works by detecting if the player has played before (which is done anyway when generating save files), if they haven't, the username window pops up asking for their input.

Week 11 (19/03/18)

Environment Details

To start this week I decided to make some details for the room variations, I started with a painting for the rooms. This is just one of the paintings, and probably the most detailed. Even though this still isn't very detailed when looking closely, when the pixel filter is applied over the game the low detail won't be noticeable. The others will probably be much less detailed.

The original inspiration for the drawing came from an album cover from musician Logic. The album was painted by Sam Spratt, who worked with Logic to create an album cover very similar to The Wedding at Cana by Veronese. I originally found out about The Wedding at Cana through Sam Spratt's work, and I used Sam Spratt's art as reference while drawing this. As you can see, the two are quite similar. Original 'The Wedding at Cana' on the left, Sam Spratt's 'Everybody Album Cover' on the right.

From looking at these I started drawing mine. This is the step by step process I took while drawing it.

Firstly, I drew the outline for the environment.

Next I added basic colour over everything and food on the table, this is still very flat though.

To give the picture more depth, I added shading to everything.

Next I added a few details, as this is going to be in a Nazi base, and it's meant to be some sort of Nazi propaganda art, I added the Swastika in the centre and also some clourds to the sky.

I added some shadows to the edges of everything to help make the objects 'pop' more, and also added some mist in the background to give a better sense of depth.

Lastly I added people to the scene. As you can see everyone looks very simple, as it's going to be very pixelated in-game anyway, but I tried to add something unique to almost everyone, such as different hair colours, styles, stances, people communicating, etc. If you look closely at everyone you see them looking each other talking, people pointing at things, looking at other things. I also added Hitler in the centre looking over everything. The idea for the art was Nazi propaganda, which would show soldiers how generous Hitler is to try and manipulate them, so the soldiers would look up to him, despite the fact he's a bad person. This is also why I added a mix of races and genders to the picture, although Hitler was very racist, it's trying to manipulate the soldiers into thinking he's not.

This is how the picture looks in-game. This isn't final, as it hasn't got a frame yet. I'll likely add the frames when I actually put all of the art into the levels which'll make the artwork stand out much more from the wall, as at the moment it blends in too much.

The next painting I drew was just a Hitler portrait. Again, this is a Nazi base so there will be a lot of pictures of Hitler in there. I used Manga Studio to draw this over Photoshop as Manga Studio has great tools for blending colours and getting a realistic paint style easily. Here's the picture in-game, the finished version will also have a frame.

I also made some 3D models this week, I started with the gun crate as it's probably most important, it's what give's the players new weapons when looting the level. I wanted it to look like an old WW2 weapon crate. I'm thinking of adding a slight sound which gets louder as the player gets closer to the box, similar to what Fortnite does when the player is near a chest. This is what the chest looks like in-game.

Next I modeled the dining room benches for a few of the blocks. One of them are entirely dining room benches (as it's meant to be a dining room) so it was quite important for that room, they'll be in other rooms too.

Another block needed a Tesla Coil to complete, similarly to the Dining Room block, this one has other objects in it already but looked strange without the tesla coils. I eventually want to try and add an electric particle effect around these but that'll be a stretch goal once everything else is finished. Here's the Tesla Coils in their level block.

Credits

I decided to finish the main menu by implementing a proper credits menu. I decided to go for a standard scrolling text effect, and the credit list isn't finished. The credits are easily edited through a .txt file, meaning they're not 'hard coded' into the UI element, this just makes it easier to edit and format. The logo is also just a placeholder. Here is a video of the credits.

Logo

The game hasn't got a logo yet and I hadn't really thought of what I wanted the logo to be. When creating the credits I realised I should have a logo, so decided to draw some sketches of a logo. Here are the few sketches I did, I wanted to incorporate boith Nazi Germany and Poland elements to the flag which I think I've done well.

Next I needed to actually make the logo in Photoshop, so I found a nice font and started editing the image to represent what I wanted. I decided to go with the second design from my concept sketches.

This is what I finally came too, and I like how it looks. I'm going to experiment with making it look slightly more 'retro' or worn as at the moment when in the game, there's a very sharp, crisp logo surrounded by low poly, pixelated environments and fonts, which means it stands out a bit much.

Optimisation

I've been meaning to optimize the levels when in-game for a while but never got to it. Most games use some sort of culling to remove objects not being currently rendered by the camera, which improves performance. Horizon Zero Dawn has a great example of this. As my game is in blocks, it's probably easiest to just remove blocks a certain distance from the player.

To do this, I need to convert the player's World Coordinates to level coordinates (per block), which is done through this function I wrote:

Then I cycle through all of the instantiated blocks, and check if each block is outside the culling range of the player, if it is it gets set to inactive, other wise it gets set to active. This is calculated 6 times per second if the game is running at 60fps (otherwise it's just FPS/10 times per second). Here is the code:

At the moment the culling range is set to 1, meaning it's only the surrounding blocks which are active, but this leads to problems as sometimes the player can see the opening where there is no room, so I'll probably set the culling range to 2 for the actual game. Having the culling range at 1 is good for demonstration though, so here is a video of the environment culling working.

Conclusion

In conclusion, I think this week went well. There's a lot of art/design which needs to be done which I really want to focus on next week. I manage to cover a few topics (Environment Culling, Credits, Logo) that I wanted to finish, which feels like a weight off my shoulders. The artwork is also a good step towards getting all of the level details finished, I want to draw a few more paintings for the walls and possibly a few more 3D models for the levels, but most of the detail is either going to be crates or enemies, both of which are finished so any other models will probably just be done as I'm creating all of the detail variations for each block.

Week 12 (26/3/18)

Environment Details

This week I started by doing some artwork for around the levels. I decided to research some existing Nazi Propaganda before starting so I got an idea of what the propaganda actually looked like which I can reference in my work, rather than just having pictures of Hitler. Here are some designs I'd like to reference.

This is the first poster I've made. It's based off the Stalingrad poster, and shows a the german and polish border with a knife through the polish side. I tried to achieve a comic/sketchy style with this, which is different to how the actual poster looks but I think will look good in-game as parts of the picture will stand out better.

For the next painting, I decided to reference the Grossdeutschland poster (middle one). I tried to achieve the painted effect on this by using a paint style brush on Photoshop, as I think the style looks good. I then made the background hands more faded and added 3 layers of gradients in front of the foreground, middleground and background hands. Drawing the hand was a slight challenge at first to get the shape right but once I had the right shape the details brought it to life quite quickly. I also added text saying 'EROBERN' on the poster, which means 'Conquer' when translated to English, I felt as though this would fit well as it's meant to be propaganda.

Careers Fair

This week the college attended a careers fair at Dunstall Race Course. They had stands for most courses, with students and staff showing what the courses had to offer using demonstrations and examples. For our course's small booth area, we had 3 students working on their FMP's (including me) and and forth computing running a game I made a while ago for people to play.

This was great for me as I got to work on my FMP while showing people what I'm doing on my project, explaining how things work and what the course offers, as well as getting feedback from a previous game. It was uplifting to see people enjoying something I'd made, as usually if anyone else plays it I don't actually get to see their reaction as they've just downloaded it online.

The fair was also a good opportunity for me to get some QA on my game that I'm working on for my FMP. I few people played the game, which meant they found bugs. This is a positive thing as it means I can fix them and there'll be less bugs in the final game. It's difficult to QA test your own game because you end up playing and using the mechanics how they're intended to be used, so you often don't break anything because you know what the boundaries are meant to be. When others play it they don't know how the game is meant to be so they just play it will actually be played.

Level Variations

Each level variation needs to each have their own variations, which means the levels will feel even more different and random. The sub-variations will contain smaller details such as enemies, crates, lights, etc. inside the same level layouts so the player doesn't know what to expect if they recognise an environment. Instead of showing pictures of each sub variation for each of the variations, I'll just create a video once they're all complete showing the final levels, otherwise there'll be about 60 pictures for each step (4 Blocks * 5 Variations * 3 Sub Variations).

For now there will only be enemies lights and gun crates in these sub-variations. I want to add a few models to each variation eventually but I've spent a lot of time 3D modelling over the past few weeks, and think it'd be best to finish other elements of the game which are more important before adding more details.

Gun Generator

The gun generator is now complete (except for audio), I've created an animation to help build suspense when the player is waiting for their weapon. I got my main inspiration from Call of Duty Zombies, as it's always exciting waiting for the final weapon to appear and hoping it stops whenever a good weapon appears. Other games such as CS:GO do this with skins, where you can see all of the 'possible' skins but don't know which one it will stop on. At the moment it's quite hard to tell when the animation's finished, but I think when I add sound it'll be clear as I'll add a different sound when you actually receive the weapon to when it's just scrolling through the weapons.

UI

A lot of the UI and menu's are placeholder at the moment, using Unity's default sprites and out-of-place fonts. They don't really fit the theme of the game at all so I'd like to change them to something which looks better. From looking at a few retro games, it seems most just use a simple black background for menus, so I'm going to keep this simplicity for my game. I'm also going to be changing the fonts to pixelated fonts so they match the rest of the game.

Here is the inventory UI. I've changed the fonts, colours and background sprites to fit the simple retro style, the checkmark for the selected guns has also been replaced with a simple square, this looks better than a checkmark for this type of menu in my opinion.

Next I needed to change the in-game UI, so I decided to start with the HUD. At the moment the HUD has a lot of high-res elements to it which don't really look right (Gun type preview and Reload timer) so I need to pixelate both of these elements to fit the theme of the game better. For my first attempt, I tried just importing the sprites at a lower resolution, but Unity blurs them to try and make it look better, so I'll have to go into Photoshop to create the lower resolution versions. Here's the before and after.

After the HUD I wanted to update the level end menu. It was very bare and I didn't like the layout at all. Now it's all shifted to the left and there's much more information such as your current levels and how many guns you've found on this current run. It also tells the player what floor they're on. Doing this also gave me an idea to expand the the leaderboard for more things other than skills, such as highest floor achieved. This will be a stretch goal though, so I've added it to the Trello project.

Sound

I want to get the majority of the sound effects in-game before the end of the week. I'm not planning to get music in the game yet, but I will start listening to some royalty free music to try and find one which fits the theme of my game.

Before recording the remaining sound effects and implementing them, I decided to play through the game and make a note of every place a sound effect is needed. Here is the list I managed to come up with. I think I can do this by recording sounds around my house or from Freesound.org.

Bug Reporter

As I get further into the project, it'll be nice to be able to send the project to people have have them easily submit bugs without having to tell me or message me. So I added a bug reporter to the game which uploads bug reports to a Trello board. I didn't make the bug reporter, it was an asset from the Unity asset store, but I did change the UI design to fit the game better as before it was bright purple/pink. Here's a video of the bug reporter.

Conclusion

I think I made good progress this week, I manage to finish a few things which I wanted to get finished before going to Florence, and also started a few tasks which can be finished when I get back or worked on while I'm in Florence.

While I'm in Italy I won't be able to work on the game due to my laptop being too slow, but I'll be taking a lot of pictures for reference/inspiration and will do any designs I need in my free time. When I get back I'd like to work on the player death mechanic and finish the audio, I'm going to try and send a build of the game to a few friends and family to test the game while I'm away, so hopefully they'll be able to use the bug reporter and I'll have a few things to fix when I'm home.

Week 13 (2/4/18)

Florence, Italy

This week I flew to Florence, Italy with 12 others as part of the Erasmus+ programme. Although I won't be able to work on my FMP much in these 2 weeks, I would still like to get as much out of it as possible such as reference images/inspiration.

We flew on Sunday 1st April but the first full day in Florence was on the 2nd. Due to the fact that Monday 2nd April was a bank holiday, we didn't have work. Instead we had a tour around the centre of Florence, and went to an art museum called the Uffizi Gallery. It was interesting to see all of the renaissance artwork and sculptures, some were much bigger than I imagined and it was really impressive.

The next day we were told about our placements, given our subsistence and also given additional information about Florence.

During the week I started my work placement. I worked at Fox in a Box during my time in Florence, which is place with escape rooms. There are 2 rooms, a Bunker and a Bank. The objective of both is to use clues to complete puzzles and get to the final objective (Bunker is to diffuse bomb, Bank is to get diamonds from safe). It was really interesting to see how the puzzles are designed, although there aren't any puzzles in my game, it could be helpful for any future projects I work on. It was also great to see other types of games other than video games/board games, it's completely different being in the rooms and playing than playing a game through a screen. In the first week I played the Bunker with a group of friends.

Although I was originally supposed to be at a VR company, which may have been more relevant for what career I'd like to pursue, I still think I can gain a lot from working on Fox in a Box. Such as the need to collaborate, there are parts where other people need to tell you what to do with their hands as they can't see them. The timer which adds urgency to everything and creates tension. Using clues from one stage of the game in a later stage and vice versa. There were many things which made the overall experience better which are helpful if ever work on anything to do with puzzles.

Our main task while at Fox in a Box was to create a trailer for each room, the first trailer we made was for the Bank. The bank trailer was mainly edited by me, whereas the other trailer was mainly edited by the others. The bank made me the most interested which is why I wanted to work on that over the Bunker trailer. Here is the trailer we made for the Bank.

On the Saturday, we went to Pisa for the day. The whole trip was brilliant, actually seeing the leaning tower in person was one of the highlights of the week. It's something people see in pictures all the time so actually being able to see it was great, the tour guide also explained how it started leaning and the history of the tower.

Week 14 (9/4/18)

Florence, Italy

This week I continued my experience at Fox in a Box, we started work on the second trailer. The next trailer was for the Bunker as we'd already done the Bank, and we decided we wanted it to be different to the last one, so we decided to go with a slower more creepy feeling trailer rather than fast and action-packed.

In the end we agreed on a one-take style trailer which pans around the room, seamlessly cutting in and out to people playing the room and just looking around the room. This was mainly inspired by an episode of Mr. Robot (Season 3, Episode 5) where the whole episode looks as through it was shot in one take. Although this is a much smaller scale, it's where we got the idea from to do a one take trailer. You can watch the trailer here.

We also played the second Escape room (the Bank) this week. This one was a lot more atmospheric than the Bunker and I personally preferred it. There was also a bit of a surprise at the end when you think you're opening just a cupboard and it actually leads to another room.

We also visited Siena on the weekend, I tried to take as many reference pictures as I could to help my work while I was there. A lot of the buildings were very interesting, all of the side streets had strange layouts and tight alleyways, which made it feel more like an adventure walking around the city. Here are a few pictures from the trip, a few of them were sent from other people so I didn't take them all.

Looking at these pictures I think there are a few things I can use from them for my game, such as the windows and archways. There are a lot of smaller details when you look closely at things and I want to add more of that to my game eventually as at the moment the rooms feel very bare.

We also visited the Boboli Gardens this week, I didn't think I'd get much from it (as far as inspiration for work) but there were a few pictures I managed to get which I think could be helpful for reference. I didn't take all of these too, a few friends I was with sent me some of them.

Week 15 (16/4/18)

Florence, Italy

The first half of this week were the last days in Italy. We didn't do much specifically except just enjoy Florence by going out for meals, getting souvenirs, etc. Completing the work experience was nice too, Simone gave us a certificate of completion and wished us luck in the future. He also put the 2 trailers on social media which was on of the most rewarding parts of completing the work experience in my opinion, as we knew our work wasn't pointless and was actually being used.

In conclusion, the Italy trip was amazing. I wouldn't change anything about it. I met so many great people which I plan to keep in touch with, seeing the different cities, buildings, cultures, etc. was also great and will definitely be helpful for my FMP too. My favourite part of the trip was either renting bikes and riding around Florence all day, or seeing the Leaning Tower of Pisa. The bikes were great as I got to spend time riding around Florence with my friends, and the Tower of Pisa was crazy to sea due to how iconic

After Italy

The rest of the week after Italy was spent catching up with work such as my reflective journal, getting reference images from people and looking over my Unity project to get myself back up-to-speed. Next week I'd like to begin implementing audio and some environment details such as the paintings I did a few weeks ago. After that (maybe not next week) I'd like to send the game to people and do some QA so I can polish the game and iron out a load of bugs before moving onto the stretch goals which I set myself.

Week 16 (23/4/18)

Audio

This week I began record and implement audio for the game. To start implementing audio, I decided it would be best to make an AudioManager script which handles the audio sources and playing audio rather than doing it per script. This keeps everything organised and avoids errors with missing audio sources or some sounds being quieter than they should be.

Here is the code for the AudioManager script, it's very simple but quite helpful.

The script is also a singleton , meaning I can just access the static instance of the script, then call the functions through that. So I don't have to get a reference of the script each time I'd like to use it in another script.

I also recorded some sounds from the sound list I created before I went to Italy. I personally think that the switch weapon sound turned out the best, as it was just me moving my bag in front of the mic a bit, but in my opinion it actually sounds as if someone is switching weapons. Here is how far I made it through the list

Other sounds such as UI were created by recording a keyboard button press and cutting a bit, the hitmarker sound was just made with my mouth and the reload sounds were taken from the recordings I did before with the deactivated guns. I re-used some sounds (footsteps) from last year's FMP, Secret of Malarith, to save time on the sound recording (I've credited the two others from the S.O.M team under sound on Case White because of this). I think the footsteps are also a huge improvement, as the default Unity footsteps sounds are really repetitive and un-natural, whereas these fit with the environment better and there are a lot more variations.

QA

This week I had a few classmates QA test my game for bugs. It was very helpful as I hadn't done much testing in the past and a lot of bugs were reported. This means I've got a lot to fix, but it's not a bad thing as now the game is going to be better in all of those different aspects. I did have a problem with getting the game to connect to the internet from the college computers, but I think that's because of a firewall, not a problem in the game, as I've tested it on other PC's outside of college since and it's not had any problems with the game's connection to the internet. Here are the bugs/areas for improvement that have been found so far.

Conclusion

Although I didn't get too much done this week due to getting back up-to-speed with everything, I think I've made good progress on audio considering it's probably my weakest area of the development, and the QA is going to be helpful for next week, I wanted to get the bugs out of the way before adding more because I kept seeing small bugs more frequently while testing. The project is never going to be perfect and bug-free but it'll be good to work on a mostly bug-free project so I'll probably spend a lot of next week working on fixing everything reported this week.

Week 17 (30/4/18)

Bug Fixes

Last week I managed to get people to QA test my game, which was very helpful as they found quite a few bugs. To start this week I've been working through these bugs, I decided to add labels to all of the bugs so I know how far through fixing them I am, so red means not fixed, orange means attempted to fix but not tested, and green means fixed and tested.

One of the biggest bugs were that enemies would stop tracking the player and stay idle after a while, meaning the player could just walk through the rest of the level and ignore the enemies. Of course this is a game breaking bug and took a while to find out why it was happening, but it turns out it was the level culling causing the problem. As tiles were activated when the player progresses through the level, new tiles didn't have a pathfinding grid on them, meaning the enemies couldn't move through the environment. I now regularly update the grid while the player is playing, rather than just once at the start of the level. I also realised this was causing another bug where enemies would walk through walls and act strangely when moving onto the 'next floor'. This was also caused by the same thing, the enemies were using the old map's pathfinding grid, and not creating a new one for the new maps. So now I update the grid when the map is regenerated too. Here's what I added to fix the problem.

After testing this, it works, but not well. It causes the game to stutter every time it happens which is about every 3 seconds. This wouldn't be a problem if I had the Pro version of the AStar pathfinding project but I'm using the free version, the pro version has ScanAsync() which spreads the task over multiple frames. To get around the constant stuttering I edited the culling function again, this time it only rebuilds the pathfinding grid when there's been a change in the level. It still stutters often, but only when the player enters a new room. Here are the changes I made to the code.

While testing this, and trying to figure out how to only update parts of the grid (rather than the whole thing at once) I stumbled across a much better option. The reason the grid wasn't being built for the whole map before is because the culling removes it before the grid is built. I had to delay the culling by a few seconds while trying to update only the new parts of the map, and in doing that made the grid build for the whole map, but it also stays there when the culling kicks in. This means I don't have to update it regularly at all and can just build it when the map is originally instantiated, I just have to delay the culling at the start for a few seconds.

After testing even more, the culling is still causing problems with the AI. Although the pathfinding grid is being built now, the enemies are still acting the same sometimes, it seems to be quite inconsistent and most of the time it's not working. For now I'm going to disable the culling, as it's causing more problems than it's worth. I'll try and come back to it at some point but for now it's just going to be turned off.

Now all of the small bugs are fixed, most of them were very simple to fix or were related to the pathfinding bug. I had to limit the amount of blood splatters to fix the lag with them, now they don't disappear on a timer, but when there's more than a certain amount of blood splatters, there can now only be 7 blood splatters in the level before the oldest start getting removed.

Muzzle Flash

I've been meaning to add a muzzle flash effect when the player shoots for a while but just haven't gotten around to it yet, so this week I decided to add it in. It's really simple, when the player shoots, the game just enables a sprite object with the muzzle flash image which also has a light component attached to it, then disables it a frame later. The final effect looks like this.

I also added some muzzle flash effects to the ranged enemy as they could shoot you before but you couldn't tell when they were shooting, it just took health from the player. This was simple as it just does the same as the player's muzzle flash, it still needs sound but I haven't got shooting sounds yet so that'll come later. You can see the muzzle flash for the enemy briefly at the end of the video above.

Conclusion

I'm happy with the progress made this week. Now I can work on a mostly bug-free game when adding new features. I'm going to keep trying to get people QA testing the game to keep it as bug free as possible, and as I add more, more bugs will arise but hopefully I'll be able to keep on top of them much easier now the rest of the bugs are sorted. Next week I'm going to add a death mechanic into the game, as at the moment there isn't much of a challenge and it's difficult to gauge how hard the game actually is. I also want to try and get the gunshot sounds in the game, it's just difficult to find non-copyright gunshots so it could take some time, and of course I can't just record my own like I've been able to with other sound effects.

Week 18 (7/5/18)

Player Death

At the moment the player can't actually die. They can take damage and go down to 0 health, but the only thing which happens is a message output to the console saying the player should be dead. This will be the last thing to add to make the game actually a real game with a challenge, and will also let me test how difficult the game is so I can tweak it where it needs to be. At the moment it's difficult to know when you're taking damage too as the player generally doesn't watch the health bar constantly, but just checks it every so often. I want to add some damage effects to the screen and possibly some constant effects when the player's health drops (for example, a red blood splatter on the edges of the screen) so the player knows what's going on without having to pay too much attention to the UI.

When looking for death animation references and how different games handle dying, I looked at a few reference videos. These few were the most helpful for me when researching it:

Although this video is using a 2D game as an example, it's still got some useful tips and is a really good GDC talk.

This was helpful as it shows a lot of death animations in a first person shooter. I'd like to try and recreate something similar to these but of course I probably won't be able to achieve as much detail as DOOM does.

This is the first stage of the player death, the player can now die, the the HUD is disabled and a death animation is played. I want to add more visual effects to this, such as a pulsing vignette, text telling the player they died and some more damage effects which I mentioned before.

Next I added a Chromatic Aberration effect around the edges of the screen when the player takes damage. I really like how the effect looks, especially with the retro post processing effects, I think it fits the theme well.

The death mechanic is more-or-less finished now, I still want to try and add some blood effects and other details but apart from the smaller bits, it's finished and works. Here is a video of dying in the game, the player still keeps XP gained from the level but guns will be thrown away unless they manage to complete the level and return to the hub.

Pause Menu

This week I'd like to make the pause menu for the game, I want it to fit with the other menu's in the game and be similar to other retro games and I'm also going to try and take some inspiration from other games. Here's the reference images I found online.

This is what the the menu looks like, it's simple and straight forward like most menus in the game. It has basic functionality, as there weren't any need for further menu's such as settings, the game is only small and doesn't need that yet.

All of the menu's functionality is handled in 1 script, which just accesses other scripts it needs to such as the player controller for sensitivity and the audio manager for volume. I didn't have many problems while making it as any problems I probably could've encountered, I'd already had earlier in the project so I knew to prevent them.

Conclusion

In conclusion, I'm happy with the progress I made this week. All of the basic functionality I planned is now finished and I only need to finish the sounds. Next week I'll work towards getting most, if not all of the remaining sounds into the game so I can consider the game finished, then work on more QA and some stretch goals.

Week 19 (14/5/18)

Sounds

To start this week I'd like to get more sound effects implemented into the game. I'm going to start by looking for some gunshot sound effects, as they're one of the most important sounds for the game and I can't record them myself, so I'm going to have to look around for free sounds online.

I did manage to find a few free gunshot sound effects online which sound good enough, most sounds I found either sounded bad or weren't free, but these were the few I manage to get which were good.

Another important part of audio is the soundtrack for the game, there are plenty of copyright free soundtracks online by small artists through websites such as the Newsground audio portal. I'm going to look through and try to find 2, one for in the hub area, the other in the actual game. I also need the music to loop.

I'd like the genre of music to generally be metal/rock for the main game, and something a bit more chilled in the hub area but still guitars, drums, etc. I might not be able to get exactly what I'm looking for, as I am looking at free music and not paying someone to make what I ask for, but there's plenty of music online I'm sure there will be something similar to what I'd like.

The two songs I decided to go with (for now, at least) are 1756 by an artist on Newsground called adamNoSeriously, and for in-game I decided to use a song called Last Life by a band called Trick Shot Radio. They both fit the theme I wanted really well and both loop after I trimmed them slightly. There is one problem that I have with them though, and that's the transition from the chilled hub music to the hardcore in-game music feels weird. You go from being relaxed to metal music blasting without really any warning. I'd like to change this but I need to look at how other games handle this as I'm not sure how I'd fix it. They're both now in the game, as you can see from the following video.

Logo

Ever since I made the game's logo there's something I don't like about it, it just doesn't really fit with the game well and I think it looks unprofessional. I can't quite put my finger on what it is, as I like the overall design, but I do want to change it a bit so it looks better in-game and just fits the overall theme.

Here's a pixel art version I made, I feel like this might fit better because the rest of the text in the game is pixel text and the rest of the game is pixelated. I'm going to make a few different logo's then try them all in-game at once to decide which looks best.

Next I decided to overlay blood onto the logo to make it feel more grungy in hopes to make it fit better with the game, I'm not sure if I really like how it looks, I like how it makes it more grungy but at the same time I think it makes it slightly harder to read and takes away from the fact the red and white in the logo is meant to represent the Polish flag.

After these I decided to try and re-design the logo slightly by making the text all capital letters. I really like how this looks, although it was hard to get the swastika to fit with the font, I do much prefer the look of this logo over the previous one with lowercase letters.

I then applied the previous two effects to this new logo, here are the outcomes.

After looking at these in-game, I've decided to go with the pixelated version of the new logo. I think it works best in-game but also shows it's going to be a retro-styled game if you see the logo outside of the game too. Here's the logo in-game.

Stretch Goals

The game I'd planned is finished now, from now on I'll just be doing QA/Bug Fixing and working toward a few stretch goals. I know I won't be able to do all of the stretch goals I wrote down, but I do want to try and finish a few of the smaller ones. Here's the list I currently have, I've just been noting any ideas that came to my head which could be good to add after. An example of something I probably won't have time for anymore would be the boss battle, although it would be good for the game, I don't think I have time to finish designing / modelling / programming / testing a boss battle in time, this isn't too much of a problem though as I didn't originally plan for any of that, this is just extras to add to the game with extra time I have. I'll start on these next week.

Conclusion

In conclusion, I like the progress this week. I feel like I spent too much time on the sound and looking for sound tracks, implementing different sounds, etc but at least it's done now and I don't have to worry about it in the future. I also really like the new logo, I feel like it fits the theme of the game much better and I'm a lot more happy with it.

Week 20 (21/5/18)

Leaderboard Flares

One of the stretch goals I had was flares on the leaderboard for people who worked on the game. I thought this would be a fun idea, as other games and websites do similar things. I got the idea from games such as Call of Duty where only devs could have the 1337 clan tag. Or on Reddit where game-specific subreddits often have flairs for developers so you know it's an official developer replying to a post. It doesn't add much as far as gameplay goes, except players might enjoy the challenge of overtaking a dev at their own game on the leaderboard, but it's something interesting and different, and shouldn't take long to implement.

To edit the text for the leaderboard I have a text document with usernames which the developers use. After this in the DisplayHighscores script, as the script changes the text in-game, I check if the username is equal to any of the usernames in the text document, if it is, change the text to purple and add [dev] before the name. Here is the code.

Here is the finished effect. I've made it so the leaderboard colour changes, and a [dev] tag is added before the name. At the moment it's just a local file in the game but I'd also like to make it access an online text document so I can change it without having to post a new build of the game. In the end, it's just a bit of fun and there's no protection to stop someone just putting their username as a developer name, but I think if I were playing a game, I'd find it interesting to be competing with the developer, which is why I implemented it.

Later in the week, I came back to this and decided to put the file online like I'd prefer, rather than a local file. First, I needed to get the file online, so I added it to a web server which would let me access the file the same way I access the actual highscores list. Unity can just access websites and return the text it finds.

Next I needed to replace the code which uses the local text file to use the text on this web address. To do this I need to have a function which assigns the text on the webpage to a string, which is then used by the code I already wrote to know the developer usernames.

The final result is exactly the same as before except now the file is online and I can update it without the player having to download a new version of the game or anything. Again, this doesn't really add anything to the gameplay but it's something fun and I did want to experiment with something similar to this, so this was a good opportunity to do that.

Environment Details

While looking back on my reflective journal, I realised I forgot to add the posters which I drew into the game. Today I added them to a few of the level blocks. I didn't want to put them in all of the blocks as I don't have enough different pictures to keep variation throughout the level, and I don't want players to see the same painting 3-4 times throughout a level. Here is how they look in-game.

As you can see it loses some of it's detail when the filter is applied, but you can still make out what the pictures are which is the main thing. The player isn't really supposed to look at them much, but they're more just to break up the flat grey concrete of the walls. I may do some more of these at some point but at the moment I need to focus on a few other things due to the small amount of time I have left.

Bug Fixes

I've had problems with the pathfinding all the way through the project, and I'm still having problems now. At the moment the problem is that the pathfinding grid doesn't completely update when I want it to (when a new level is generated, for when player goes to next floor). This means the enemies are following the previous level's pathfinding grid and not the current level layout, so they walk through walls, float in the air, get stuck on invisible walls, etc after the first level is complete.

As you can see below, the left picture is the first floor, the pathfinding grid aligns to the map perfectly and the paths from each enemy to the player moves around the level as it should. Whereas on the second floor, the pathfinding grid is all over the place, with random rooms, random parts of rooms, parts outside of the map which aren't there, etc are being mapped. This is the problem I'm having at the moment.

After researching to see if I'm doing something wrong, or if it's the AStar asset's fault, or something else, I finally found what was causing the problem, I just needed to scan the pathfinding after a small delay. So I added a 0.3 second delay and now the problem is gone, here is what the pathfinding grids look like now.

Conclusion

I cleared up a few loose ends which were bugging me this week, I wasn't sure how I'd fix the pathfinding bug so now that it's fixed I'm much happier. I also have been meaning to add the paintings around the map for a while but kept getting distracted by other things, I'm glad they're in the game now. The leaderboard flares were also fun to implement, it was nice to experiment with putting the file on a web server and I'm more confident doing things like that in the future now. I'd like to do something similar to do a username/password feature in the future, but I'm not doing it in this game, although it would be good so only one person can use a certain username. I might do this after hand-in, just in my own time, but I don't think I should add something like that so close to the deadline.

Week 21 (28/5/18 - Half Term)

Delay

I won't be able to get much work done this week due to moving house. Most of my week is more-or-less going to be spent packing boxes and moving things, and I also won't have a computer for part of it due to it being packed away. I would like to work on it at least a small amount though when I get the chance.

Bug Fix

A bug I had was with returning to the hub from the pause menu. For some reason the player couldn't move, but they also didn't seem to be affected by anything such as gravity either, they can just look around. This bug is really confusing because you can return to the hub from the end of the level but not from the pause menu, they also do the exact same thing which makes it even harder to figure the problem.

y first attempt at fixing the bug was trying to simulate the same 'conditions' as when the player returns to the hub from the end of level, such as disabling the player before loading the scene, unlocking the cursor before loading the scene, etc. This didn't work at all, it just gave the same results as not doing it. I wasn't sure why that would make a difference either but it's the only difference I can see that affects the player at the moment. I'm going to need to look some more to find the root of the problem.

After looking at every difference, in the debug inspector view, I realised it was something really simple, I never set the timescale back to 1 when the player goes back to the hub. I just assumed it'd automatically reset on a new scene being loaded but it doesn't, this is why nothing was affecting the player. Small bugs like this are often some of the most frustrating to fix so I'm glad it's fixed now, it's also the last bug I had noted in the Trello feedback submission page so I'm glad to have everything from that fixed again. I'll be doing more QA soon to get a big final bug fix done but for now I'm happy all of the known bugs are gone.

Conclusion

Unfortunately I couldn't get much work done this week, I'm glad I managed to work a bit on the game before moving house but the majority of the week was taken up by packing, moving and unpacking. I'm not worried about affecting any progress on the game as I've finished what I planned and am just doing extras, but it would've been helpful to have an extra bit of time working through any bugs. Next week I'd like to get more feedback and QA done so I can finalise the game before hand-in.

Week 22 (4/6/18)

Feedback

To start this week I've been getting feedback and final QA for my game. I've been asking people to play it and let me know what they think then noting what they say on my phone. It's helpful to know small things to add near the end of development such as UI to let the player know what to do.

This is the feedback I managed to get for my game from friends and the tutor. It's mostly just small tweaks which need to be done and nothing big, the most time consuming part will probably trying to add directions for the player in the hub, even that shouldn't take too long though and I can work on it without having internet at home at the moment.

Itch.io

I want to put my game on itch.io to get more feedback and to let others play the game without having to personally giving it to them. The easiest way to do this is to put it on itch.io, and it also means the game will be on my profile page with my other work, which I use as a portfolio.

The first thing to do was add the description and title images to the page, I did this by getting a blood splatter screenshot from in-game, adding text over it then finally adding a fade off to the right of the title image. I also made the gif which is used as the cover image of the game and is the first thing people see when looking through the games on itch. Here is what they look like.

After that was finished the page needed a background and banner for the page to really set the theme of the game, at the moment a grey background with some text doesn't really let the player know what atmosphere the game will have.

This is the final page, as you can see it has the background, logo, information and screenshots so the player can see exactly what the game is like before downloading it. I really like how the game page turned out, I think it fits the theme and atmosphere of the game well and looks clean. Itch.io is a really great website for smaller developers to publish their work and get feedback, I'm hoping a few people will play it by next week so I can apply their feedback to the game for hand-in to make it as good as it can be in the time remaining. Of course I won't be able to add anything huge to the game with the time remaining, but any small bugs or user experience improvements I can add would be good to know. Here is a link to the page.

Conclusion

I'm glad I've got the game published now and I'm looking forward to hearing what people say about it and how many people will play it. I know it's not going be perfect straight away but I'm hoping people will give me feedback so I can make it better soon. It will also be good to have opinions from people I don't know as they're less likely to sugar-coat any opinions they have, they also don't have me next to them telling them how to play the game so if they get stuck I won't be able to give any hints and hopefully they'll comment on the page letting me know they got stuck.

Week 23 (11/6/18)

Feedback

Over the weekend I received some feedback on Case White through the itch page. Surprisingly, the game is doing very well in comparison to my other games I've released, and I'm not sure why. If I compare the analytics for last year's FMP game, Secret of Malarith, which has been published for just over a year, and the analytics for Case White, which has been published for just over 3 days, it's clear that for some reason Case White is doing much better.

When looking at the comments on Case White, people seem to be enjoying the game too. One user wrote a paragraph about how he enjoys the game, but feels as though the ranged enemy AI is too tough, and can't be dodged. This comment was very motivating for me, and made me really happy that people are actually playing and enjoying the game.

Two other users were a bit more critical of the game, saying how they were confused or offended about certain aspects of the game. Although these comments aren't extremely positive about the game, I wouldn't consider them to be negative either, and they provide helpful feedback which will allow me to make the game better or give me more insight for when making future games.

Lastly, one user made a YouTube video playing the game, which was also very exciting for me. It's fun watching other people playing my game, but also very helpful for feedback as I can see exactly where they get stuck, confused, bored, excited, etc. Here's the video:

From all this feedback and feedback from last week, I managed to make a list of changes and improvements to add to the game. Most of them are small tasks so I'll definitely add them, others such as the improved AI, won't be added due to how long it may take, although I would like to keep updating the game and add it maybe in a few weeks, for now I want to focus on getting the game completely finished and final for hand-in though.

Later this week I went in and made the the changes on the list, most only took a few minutes to change or add, the longest parts were adding the UI pop-ups, here's how they look in-game.

Evaluation

The concept of Case White was an FPS with procedurally generated levels and weapons with a retro aesthetic.

The most influential research I did for the project was looking at different procedural level generation techniques, and specifically researching how Spelunky generates levels. After finding an explanation of the technique used by creator Derek Yu, it made it a lot easier for me to code it as I knew exactly what I needed to achieve and how it would work. Derek Yu's book also explains how the level generation explains but with less detail, it was still good read it from the actual creator though, and the book also gave more information about the rest of the game's development and design, not just the level generator. This researched influenced the project in a few ways. Firstly it introduced me to this method of level generation, I think it fits best with the game I made as other techniques such as a voxel terrain generator would have made levels which don't work with this style of game. Secondly, it helped speed up the process of programming the level generator, if I had to work it out all by myself with no explanation, it could've taken weeks meaning I wouldn't have been able to get on with other mechanics nearly as quickly. Having the explanation of how the system worked allowed me to just focus on turning the method which was explained into code.

Case White is a retro themed FPS game, with a procedural level generator, randomly generated weapons, pathfinding, an inventory system a skills system and online leaderboards. The game was created in Unity using C#, and the models were modeled in 3DS Max then textured using Photoshop, I had to get the sounds online, or record and edit them using Audacity, the music was found on Newsground Audio Portal, which is a website where people can upload their music for people to use, it helps get their name out when starting as an artist and gives them a platform to publish their music. For certain mechanics I had to use ready-made assets due to me struggling to make my own or not knowing how to make my own, for example, I tried making pathfinding for the game but struggled on making it 3D rather than just on a 2D plane, also the retro post processing shader, I'm not sure how to make post processing effects as I haven't looked into it yet much and it's difficult to learn about it, so buying an asset off of the asset store made the most sense for this game, although I would like to look into shader writing and post processing in the near future as it's interesting and can change a game's atmosphere a lot depending on what effects you use.

Comparing the complete game to the original idea, I think they're very similar and the game turned out more-or-less how I first imagined it. I tried sticking to the timetable as accurately as possible, but ended up timing a few things wrong, in future I know to give myself more time for 3D modeling as that took longer than I expected, but other mechanics such as shooting took less time than I imagined which is how I made up the time to stick to the timetable when some things took longer. I had to also do a few things in a different order than planned in the timetable due to it being easier or making more sense to finish one thing before the other. In the end I managed to finish a bit before I planned with the timetable though, allowing me to add a few extras and spend more time on QA, getting feedback and bug fixing which I'm really happy I did, as I think it made the project much better just doing small bits at the end and making the user experience better. Feedback from peers was also very helpful as I got to see people play the game in front of me, which let me know where people get stuck, when people started getting bored, excited, and generally just let me know where the game needs tweaking in places. For example people didn't understand how to get out of the inventory, so I added a back button on there incase people didn't know to press Escape.

The research done at the beginning of the project was very useful for getting a general idea in my head about how I want to design the game, from UI to environment design, it was good to take inspiration from different places and have them brought together in one place so I can go back and reference them, I also learnt a lot from just doing the research which I believe improved the project overall.

Case White is complete as far as I planned for the FMP. I don't have anything left to do at the moment, but I would like to update later on as the game is published now and I want it to be as good as it can be for people who play it. Some things I'd like to add in the future are more weapons, attachments and level blocks to make the game feel less flat and give players more content to explore. Further stretch goals would be to add different types of bases and better online support to make the game feel even more multiplayer than just the leaderboard, but this would cost money and would be much more difficult so I don't think I'll be able to add that any time soon. I think I had enough feedback from peers and people playing the game on itch.io to improve it to a fun and playable state. I'm happy with the outcome of Case White, it came out how I wanted it to and it's been really rewarding to develop, I've learnt a lot from the development process and feel like I've pushed myself throughout the project.

Created By
Anthony Sturdy
Appreciate

Report Abuse

If you feel that this video content violates the Adobe Terms of Use, you may report this content by filling out this quick form.

To report a Copyright Violation, please follow Section 17 in the Terms of Use.