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.
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.
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.
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.
Week 4 (29/1/18)
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.
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.
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.
Week 5 (2/5/18)
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).
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.
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.
Week 6 (12/2/18)
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.
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:
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.
Week 7 (19/02/18)
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.
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:
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.
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.
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)
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.
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).
Week 9 (05/03/18)
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.
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.
Week 11 (19/03/18)
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.
Week 12 (26/3/18)
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.
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.
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.
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.
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.
Week 13 (2/4/18)
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.
Week 14 (9/4/18)
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 18 (7/5/18)
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.
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.
Week 19 (14/5/18)
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.
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.
Week 20 (21/5/18)
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.
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.
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.
Week 23 (11/6/18)
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.
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.