During the third year of university, for my dissertation I wanted to focus on game AI and the techniques that are used to create AI, or at least, the semblance of AI, in video games.
For this task I had to research various techniques which are used to create AI, such as Hierarchical Task Management and Goal Orientated Action Processing. It was a great opportunity to learn a lot more about a field I had only briefly glanced over during my first year of university. It was great to hear how the logic of game AI worked and has helped me in my further projects when thinking about how to create AI.
The actual dissertation project was to 'Create an AI which mimicked real world Platoon Level Tactics'. Now, to the uninitiated in military organisational structure, a platoon is simply a group of men. No doubt you will have heard the term 'squad', well, a platoon is essentially a group of 'squads' alongside machine gunner teams, mortar teams and under the leadership of a lieutenant. Squad AI is something which has been done before, but I was more interested in creating a simple algorithm which could control a group of groups effectively.
The demo itself uses SFML to represent graphics. There are two teams of dots, red and green. The yellow and blue dots are 'officers' of each team. They act as rally points for the squad members, but I will explain more about that later. The blue squares are 'cover' which improves survivability, and the green squares are open ground
The algorithm itself is separated into two specific parts. The individual soldier's logic, and the platoon order logic.
The individual soldiers use a GOAP algorithm to decide their actions. They take in information about the world such as how far they are from enemies, where their officer is located and where cover is, as well as what their orders are in order to make a decision about what they are going to do.
The Platoon order Logic uses a basic HTM system to decide whether the soldiers orders should be to attack or defend. The soldiers then use this information to work out their preferential tactics.
Overall the system is a good representation of the techniques, however it lacks a little in quality of life features and debug information to properly showcase the algorithm. I also feel I did not use enough C++11 features during development, and that is something I will continue to work on.
You can download the codebase for your leisurely browsing from the github link below.
You will need Visual Studio 2015 in order to run the demo. It currently does not run in release, you will have to build it and run it in debug. You will also have to use the visual studio 'stop debugging' button in order to quit, as the window quit function does not work.
https://github.com/Falsan/AIPlatoonProject
My Signature Projects
Wednesday, 14 June 2017
Saturday, 3 June 2017
Galaxy Defender TV
Galaxy Defender TV is my first independent project. I started this just after I finished most of my university work. It's a pet project which is designed to be a fighter shooting arcade game, similar to R-type. I have created this game in Unity and I created everything from scratch.
I built an Audio manager entirely from scratch which works very well. This manages all the sounds and audio in the game, and so long as there are sound clips in the resources folder, you can just pass the manager a string and it will create that sound at that specific time. It's a really nice system, and it even does fade ins and fade outs.
I also created a generic 'Application Manager' which utilises Unity's scene management tech. I use this manager to use the additive scenes which are now common in Unity, to load in things on top of each other, and load out what I need to get rid of. It needs some work, but it is a nice system so far for what I need.
I made every single enemy produce a simple behaviour pattern and I made each enemy shoot at the player, or not if they were tagged as a shooting enemy and I also designed the levels and bosses for each of the levels too. I wanted these to be huge screen filling enemies in custom with similar bosses and games of the time.
I also created all of the models and all of my own foley for the game as well as UI elements and particle effects.
The game isn't finished yet of course, there are quite a few things that need to go in. Some proper in game UI, a pause menu, a score system, several new models, several new levels, some better menus, scaling for screen resolution and some background music. There is background music in there at the time of writing of course, but it is not my own.
If you wish to download and play the current build, you can find it at the link below.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXOGFWTE12UG1pSUk?usp=sharing
I built an Audio manager entirely from scratch which works very well. This manages all the sounds and audio in the game, and so long as there are sound clips in the resources folder, you can just pass the manager a string and it will create that sound at that specific time. It's a really nice system, and it even does fade ins and fade outs.
I also created a generic 'Application Manager' which utilises Unity's scene management tech. I use this manager to use the additive scenes which are now common in Unity, to load in things on top of each other, and load out what I need to get rid of. It needs some work, but it is a nice system so far for what I need.
I made every single enemy produce a simple behaviour pattern and I made each enemy shoot at the player, or not if they were tagged as a shooting enemy and I also designed the levels and bosses for each of the levels too. I wanted these to be huge screen filling enemies in custom with similar bosses and games of the time.
I also created all of the models and all of my own foley for the game as well as UI elements and particle effects.
The game isn't finished yet of course, there are quite a few things that need to go in. Some proper in game UI, a pause menu, a score system, several new models, several new levels, some better menus, scaling for screen resolution and some background music. There is background music in there at the time of writing of course, but it is not my own.
If you wish to download and play the current build, you can find it at the link below.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXOGFWTE12UG1pSUk?usp=sharing
Friday, 2 June 2017
Kojima Drive
At the end of our game jam module in the third year of university, the entire cohort had to work on a game together. This was a highly ambitious project and the largest one I have done to date. Kojima drive was the brief that was given to us. We started off having to come up with game modes for a party driving game which were to form the mini games in the game.
We created a game mode which we entitled 'drive and seek' which was a kind of hide and seek. The player who was the 'hider' got a head start and had to evade the 'chasers' before finally reaching an end point.
I was in charge of the initial game mode logic which was then scrapped and replaced with a better system which utilised Unity's events. This system then later went on to be made with all of the game modes in Kojima.
I then went on to create several little systems such as waypoints, teleporters and decoys which never went into the game in the end. I also was given a 'twist' mechanic to create a manager for, however, due to poor inter team communication, this feature was never implemented in the game. It is widely the consensus of my team that this was not my fault, but nobody who was meant to be figuring out what to do with the system were actually thinking about what to do with the system.
I also helped to fix plenty of bugs in the game code with my group's systems, and I worked with my team throughout to support the systems that they were making
Overall, Kojima turned out to be a decent game, however most of the features that were made for it that I created didn't end up getting put in, which is a bit of a shame.
We created a game mode which we entitled 'drive and seek' which was a kind of hide and seek. The player who was the 'hider' got a head start and had to evade the 'chasers' before finally reaching an end point.
I was in charge of the initial game mode logic which was then scrapped and replaced with a better system which utilised Unity's events. This system then later went on to be made with all of the game modes in Kojima.
I then went on to create several little systems such as waypoints, teleporters and decoys which never went into the game in the end. I also was given a 'twist' mechanic to create a manager for, however, due to poor inter team communication, this feature was never implemented in the game. It is widely the consensus of my team that this was not my fault, but nobody who was meant to be figuring out what to do with the system were actually thinking about what to do with the system.
I also helped to fix plenty of bugs in the game code with my group's systems, and I worked with my team throughout to support the systems that they were making
Overall, Kojima turned out to be a decent game, however most of the features that were made for it that I created didn't end up getting put in, which is a bit of a shame.
Event Horrizon
During my third year of university, in the last part of our game jam module, I was able to work on a 'day jam' as it came to be called. We worked on the project for one day and one day only, creating a small and enjoyable game.
The theme was old style black and white graphics, but other than that, the game could be anything we wanted and had to be playable with old NES controllers.
We ended up with a simple game based on the last scene from Star Trek where the enterprise is trying to escape the 'Event Horizon' of a black hole. We then made this competitive and introduced four players into the mix. The players could attempt to knock others into the black hole and try to be the last man standing.
For this project I was mostly in charge of the asteroids and debris which came in from the sides of the screen to knock and push the players into the black hole. I also worked on the audio for the game and I made the title screen.
Overall I really feel this was our strongest game we made in the game jam. It is really simple, but the game is quite likeable and enjoyable.
Feel free to download the project on a link below to take a look.
In order to play you will need to connect 4 NES controllers however.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXbnBSZmtGc0E1ZTg?usp=sharing
The theme was old style black and white graphics, but other than that, the game could be anything we wanted and had to be playable with old NES controllers.
We ended up with a simple game based on the last scene from Star Trek where the enterprise is trying to escape the 'Event Horizon' of a black hole. We then made this competitive and introduced four players into the mix. The players could attempt to knock others into the black hole and try to be the last man standing.
For this project I was mostly in charge of the asteroids and debris which came in from the sides of the screen to knock and push the players into the black hole. I also worked on the audio for the game and I made the title screen.
Overall I really feel this was our strongest game we made in the game jam. It is really simple, but the game is quite likeable and enjoyable.
Feel free to download the project on a link below to take a look.
In order to play you will need to connect 4 NES controllers however.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXbnBSZmtGc0E1ZTg?usp=sharing
Sunday, 28 May 2017
MAK OS Game Project
The second game jam that I did in my third year was on a game we later dubbed 'MAK OS'. The concept of which was randomly generated to be, "A game with no interactivity at all where you taunt fish."
Suffice to say, this was hardly the best brief we could have hoped for. However, we pressed on and eventually we made a game out of it, even if we had to scrap the 'no interactivity' part of the game. After all, we decided that was just a walking simulator or a screensaver.
We settled with the player controlling an AI which was trapped in a company building owned by 'Fish Co'. They were fed up of the annoying humans and decided to annoy them back.
I created the Ai system which controlled the human workers that the player was trying to annoy. This utilised the navmesh system that Unity provides, and uses a decision algorithm of my own design to select places for the worker to go.
In my opinion the gameplay is somewhat limited by the fact you are indirectly effecting the annoyance of the humans. You tweak items of office equipment in order to annoy them which doesn't really give much sense of immediacy or satisfaction. There are a lot of issues with the gameplay, and we decided later that MAK OS was more of a piece of tech than a fully fledged game.
Nonetheless, if you wish to take a look, feel free to download the project on the link below.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXSktENHlRSjlFWGc?usp=sharing
Suffice to say, this was hardly the best brief we could have hoped for. However, we pressed on and eventually we made a game out of it, even if we had to scrap the 'no interactivity' part of the game. After all, we decided that was just a walking simulator or a screensaver.
We settled with the player controlling an AI which was trapped in a company building owned by 'Fish Co'. They were fed up of the annoying humans and decided to annoy them back.
I created the Ai system which controlled the human workers that the player was trying to annoy. This utilised the navmesh system that Unity provides, and uses a decision algorithm of my own design to select places for the worker to go.
In my opinion the gameplay is somewhat limited by the fact you are indirectly effecting the annoyance of the humans. You tweak items of office equipment in order to annoy them which doesn't really give much sense of immediacy or satisfaction. There are a lot of issues with the gameplay, and we decided later that MAK OS was more of a piece of tech than a fully fledged game.
Nonetheless, if you wish to take a look, feel free to download the project on the link below.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXSktENHlRSjlFWGc?usp=sharing
Ascension Game Project
During my third year of university, I really found my footing with programming and games design. This can perhaps, most clearly be seen in the several game jams which I did as part of my course.
The first game jam that we did was for a game that we called 'Ascension'. The theme of the jam was to make a 'sticky' game, the idea was that there was one main core mechanic that could be easily repeated and would always be fun. In that respect, we decided that a competitive element was the be the key to our stickiness, thus, we made a 2 player competitive game.
I was in charge of the AI for the game which was designed to shoot down projectiles at the players in order to hinder their progress. The player's aim was to get to the top of the screen before the other, and they would be hindered in this by obstacles and AI opponents which would shoot down at them.
The first Ai I designed merely strafed from left to right and back again, shooting as it did. While the other tracked the player in first place and tried to shoot it down.
Ascension was a success, however there were some technical issues with it's implementation. Systems conflicted, and this showed. It really needed another pass to polish and fix the bugs which were inherent in it's systems. My strafing shooter can actually be broken by the screenshake effect if it is close to a wall, as it relies on the walls to change direction.
The project can be downloaded via a link should you wish to check it out.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXbWc2WDFGWEVxcFU?usp=sharing
The first game jam that we did was for a game that we called 'Ascension'. The theme of the jam was to make a 'sticky' game, the idea was that there was one main core mechanic that could be easily repeated and would always be fun. In that respect, we decided that a competitive element was the be the key to our stickiness, thus, we made a 2 player competitive game.
I was in charge of the AI for the game which was designed to shoot down projectiles at the players in order to hinder their progress. The player's aim was to get to the top of the screen before the other, and they would be hindered in this by obstacles and AI opponents which would shoot down at them.
The first Ai I designed merely strafed from left to right and back again, shooting as it did. While the other tracked the player in first place and tried to shoot it down.
Ascension was a success, however there were some technical issues with it's implementation. Systems conflicted, and this showed. It really needed another pass to polish and fix the bugs which were inherent in it's systems. My strafing shooter can actually be broken by the screenshake effect if it is close to a wall, as it relies on the walls to change direction.
The project can be downloaded via a link should you wish to check it out.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXbWc2WDFGWEVxcFU?usp=sharing
Monday, 17 April 2017
Unity Email Reciever
During my University third year, I was given the opportunity of creating a number of small research projects. During the first part of the year, I chose to create a email receiver and game for Unity.
The brief was to create a game which would allow the user to manage their email in a unique and interesting way. In essence we had to gamify email. The brief was to create a garden of 'email' and allow the user to manage their inbox using typical garden tools. Messages could be visualised as flowers which would need to be cleared eventually, and one could even group emails by sender in plots of land.
It was an interesting project, and I took it on happily. This required utilising the .Net library to find out what Unity could do, and it turns out that Unity by itself cannot receive emails, however, it contains a framework to allow it to do so, and it can even send emails using an SMTP (Simple Mail Transfer Protocall) format.
I ended up using a third party library to integrate into Unity which was OpenPop. This allowed me to build an email client for Unity which utilised the Pop3 message sending protocall and allowed me to create an email client for Gmail.
This was the main task of the project, to create a working email client, and I believe I accomplished that quite well. However, the client only works for Gmail clients, and it circumvents the traditional security checks that are put in place by an email client.
Along with a whole host of other minor issues, this email client however does work. It's just a little finicky
.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXd3ZpVzQtcG1fVG8?usp=sharing
The brief was to create a game which would allow the user to manage their email in a unique and interesting way. In essence we had to gamify email. The brief was to create a garden of 'email' and allow the user to manage their inbox using typical garden tools. Messages could be visualised as flowers which would need to be cleared eventually, and one could even group emails by sender in plots of land.
It was an interesting project, and I took it on happily. This required utilising the .Net library to find out what Unity could do, and it turns out that Unity by itself cannot receive emails, however, it contains a framework to allow it to do so, and it can even send emails using an SMTP (Simple Mail Transfer Protocall) format.
I ended up using a third party library to integrate into Unity which was OpenPop. This allowed me to build an email client for Unity which utilised the Pop3 message sending protocall and allowed me to create an email client for Gmail.
This was the main task of the project, to create a working email client, and I believe I accomplished that quite well. However, the client only works for Gmail clients, and it circumvents the traditional security checks that are put in place by an email client.
Along with a whole host of other minor issues, this email client however does work. It's just a little finicky
.
https://drive.google.com/drive/folders/0B2-4-3Aj27LXd3ZpVzQtcG1fVG8?usp=sharing
Unreal 4 Procedural Fire System
During my University third year, I was given the opportunity of creating a number of small research projects. During the second part of the year, I chose to create a procedural fire system for the Unreal engine.
The brief was, just that, to create procedural fire for Unreal 4. Naturally, this meant coping with the intricacies and limitations of the unreal engine as well as the technical challenge of creating a procedural algorithm for creating a spreading fire.
Fire has of course been used in many games. The first time that I recall a procedural fire being used in an AAA title was Farcry 2, and it has been used in many iterations since. It is a heavy system as it requires a lot of particle effects to generate and depending on the aesthetic of the fire, it could potentially cause framerate drops. Nonetheless, the aesthetics of the fire was not a concern, the actual generation was the main project here.
Firstly, I attempted to do the project in Unreal's C++, however, none of the tutorials actually worked for me and I seem incapable of doing anything with that other than breaking things, even when I follow the official Unreal tutorials word for word. They are of course out of date and people have reported similar difficulty, and thus I fell back to creating the system using Unreal's Blueprint coding language.
Blueprint, while restrictive and finicky got the job done, and I managed to create a generator for the fire system which could be placed anywhere in the level. The idea was for it to be placed down as a result of a grenade impact, and from there it would generate fire out.
The generator searches out for objects which are tagged flammable and then generates a flame square on top of the object. The flame square then does the same thing. It also searches for flammable objects around it and compounds their fuel variables, so fires in the centre of a 'fire' will burn for longer whereas fires on the edge will burn out.
Feel free to download the project and try it out.
Unreal Version 4.8.3 required
https://drive.google.com/drive/folders/0B2-4-3Aj27LXUHplanhaQjY0TTg?usp=sharing
I will be posting a video of the system in action soon.
The brief was, just that, to create procedural fire for Unreal 4. Naturally, this meant coping with the intricacies and limitations of the unreal engine as well as the technical challenge of creating a procedural algorithm for creating a spreading fire.
Fire has of course been used in many games. The first time that I recall a procedural fire being used in an AAA title was Farcry 2, and it has been used in many iterations since. It is a heavy system as it requires a lot of particle effects to generate and depending on the aesthetic of the fire, it could potentially cause framerate drops. Nonetheless, the aesthetics of the fire was not a concern, the actual generation was the main project here.
Firstly, I attempted to do the project in Unreal's C++, however, none of the tutorials actually worked for me and I seem incapable of doing anything with that other than breaking things, even when I follow the official Unreal tutorials word for word. They are of course out of date and people have reported similar difficulty, and thus I fell back to creating the system using Unreal's Blueprint coding language.
Blueprint, while restrictive and finicky got the job done, and I managed to create a generator for the fire system which could be placed anywhere in the level. The idea was for it to be placed down as a result of a grenade impact, and from there it would generate fire out.
The generator searches out for objects which are tagged flammable and then generates a flame square on top of the object. The flame square then does the same thing. It also searches for flammable objects around it and compounds their fuel variables, so fires in the centre of a 'fire' will burn for longer whereas fires on the edge will burn out.
Feel free to download the project and try it out.
Unreal Version 4.8.3 required
https://drive.google.com/drive/folders/0B2-4-3Aj27LXUHplanhaQjY0TTg?usp=sharing
I will be posting a video of the system in action soon.
Friday, 31 March 2017
Unity Custom Profiler
During my University third year, I was given the opportunity of creating a number of small research projects. During the third part of the year, I chose to create a custom profiler for the Unity engine.
The brief was that Unity's profiler is somewhat limited in what data it shows. It doesn't really give much in the way of helpful information such as the amount of memory an object is taking up. Thus, the task was to create a custom profiler which showed the memory usage of individual objects, including audio, meshes, textures, physics and scripts.
In many ways, I did just that, the profiler I created shows the memory usage of individual objects in a Unity scene. I had to use the old Unity Editor GUI functions to show this in an editor window utilising Unity's editor scripts. This meant I could create a window in the editor to run my profiler with, to incorporate it in any Unity project that I create.
The profiler shows the number of bytes of memory usage of each object in a hierarchy view not too dissimilar to the hierarchy view in Unity itself.
It is also shown in a bar graph and can also perform some limited analysis on objects in the scene to see if they are above a certain data threshold before reporting back with a warning message to the console to allow the user to track down problem objects.
The profiler does use some of Unity's internal functions, and one has to keep in mind that we just need to trust that they are doing the correct thing.
Unity also separates it's functionality in components, and as ingenious as this system is, it means that each Unity object doesn't contain much memory use. It just contains metadata. The components themselves are the things which take up the memory, and it is difficult to know if every component is being retrieved to create the total memory usage used. Unity uses, a lot of components after all.
Should you wish, please copy and paste the download link below. There you can download the project and inspect it yourself.
Unity version 5.3.2 required
https://drive.google.com/drive/folders/0B2-4-3Aj27LXM2g3R21mYkotdzQ?usp=sharing
The brief was that Unity's profiler is somewhat limited in what data it shows. It doesn't really give much in the way of helpful information such as the amount of memory an object is taking up. Thus, the task was to create a custom profiler which showed the memory usage of individual objects, including audio, meshes, textures, physics and scripts.
In many ways, I did just that, the profiler I created shows the memory usage of individual objects in a Unity scene. I had to use the old Unity Editor GUI functions to show this in an editor window utilising Unity's editor scripts. This meant I could create a window in the editor to run my profiler with, to incorporate it in any Unity project that I create.
The profiler shows the number of bytes of memory usage of each object in a hierarchy view not too dissimilar to the hierarchy view in Unity itself.
It is also shown in a bar graph and can also perform some limited analysis on objects in the scene to see if they are above a certain data threshold before reporting back with a warning message to the console to allow the user to track down problem objects.
The profiler does use some of Unity's internal functions, and one has to keep in mind that we just need to trust that they are doing the correct thing.
Unity also separates it's functionality in components, and as ingenious as this system is, it means that each Unity object doesn't contain much memory use. It just contains metadata. The components themselves are the things which take up the memory, and it is difficult to know if every component is being retrieved to create the total memory usage used. Unity uses, a lot of components after all.
Should you wish, please copy and paste the download link below. There you can download the project and inspect it yourself.
Unity version 5.3.2 required
https://drive.google.com/drive/folders/0B2-4-3Aj27LXM2g3R21mYkotdzQ?usp=sharing
Blog introduction
Hello there, and welcome to my portfolio blog. Please, allow me to introduce myself.
I am Sam Britnell, games designer, programmer, writer and gaming enthusiast. I am an aspiring English gentleman with many hobbies and interests. For this blog post, I will seek to tell you a little about myself and introduce my portfolio blog.
As you can well see, this blog is a dedicated portfolio to showcase work I have completed, and projects I have been a part of. Here you can find a complete record of personal projects, and professional work which I can be accredited to.
On the main blog page, you can find a list of links to pages on this blog which showcase the best of my work for your consideration. If I am applying for a job under you, or you are seeking to recruit me, I encourage you to browse these showcase projects at your leisure so you might get a better understanding of my abilities.
Should you be interested in just who I am as a person, I encourage you to read on.
So, who am I? Well, I like to think of myself as a well rounded person. People seem to like and get on with me. It has been said that I am quite a humble individual, not one to shout out about my successes or my failures. I'm quiet when in a crowd, but when I do speak people find it is often something quite poignant. It is 'one on one' or in a small group I feel most comfortable and it has been said I can be an engaging conversationalist despite my introverted tendencies. I can work well in teams, and often I can think outside the box and come up with a fresh perspective that most do not take. Above all, I am polite and respectful to everyone.
I write short stories and hope to finish a novel in my spare time someday. I also paint small miniature wargaming models. I code and design games in my spare time. I also have an interest in the paranormal, as well as military history.
I would hope this brief introduction gives you a better understanding of who I am as a person. Now. I wish you a good day, and thank you for reading.
Subscribe to:
Posts (Atom)