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
My Signature Projects
Friday, 2 June 2017
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)










