Academic Work
SEARCH BY TAGS:
RECENT POSTS:
THE BIT BLOCK:
Welcome to The BIT!
​
My name is Rhys Sellars. Currently a Game Development student Majoring in Design at SAE Institute in Melbourne, however I am looking at also studying Programming to broaden my skill set in the future.
​
On The BIT, you will be able to view my current portfolio of work, as well as blogs relating to Game Dev and current progress at SAE.
​
Breath of Life
Breath of Life is an exploration based puzzle game available on Android mobile devices. The player plays as the wind or 'The Guardian,' who must blow a lost spirit back to it's dying body before it is too late. The game aims to have a mysterious/ominous feel to it, and draws inspiration from titles such as Ori and the Blind Forest. The player must manage their available air, avoid traps/enemies and reach the level goal within a time limit. This project is my first major mobile/Android based project, as well as first major collaborative project. I was the Project Creator/Manager and Lead Developer. I also completed all of the Level Art as well as Level Designs. Below are the game's credits:​
​
Rhys Sellars – Project Creator/Level Art/Level Designer/Assistant Programmer
Cameron Ogilvie – Programmer
Chantel Levin - Graphic Artist: UI/Logo
James Chandler - Graphic Artist: Spirits
Corey Taylor - Audio
​
The game is available to download from itch.io. The link is below:
​
https://camerono98.itch.io/breath-of-life
​
Dish Pig Dilemma
Dish Pig Dilemma was intended to be a comedic, whacky physics based game for PC. The game drew heavy inspiration from titles such as I Am Bread and Surgeon Simulator. In the game, the player takes on the role of Spud, a hopeless individual who is tasked with cleaning dishes. The idea was the controls would be erratic and unpredictable and the physics would be overall clunky to emphasise the character's unpredictable nature, as well as mirror what many would recognise as a 'bad housemate' situation.
​
Unfortunately the game was not completed. This was due to many issues that arose during the development cycle. Despite the project being extremely organised and prepared early, persistent issues pulled the project to pieces. There were mainly two sources of issue: 1) GitHub and; 2) Character Model/Rigging/Animation.
​
Git was a constant bane to our existence. It was a large learning curve for the team, who had not previously used it before. Git overwrote our project a total of four times, usually after significant work days. At one point it felt as though our 'backups' were working against us, and caused severe project clashes when branches weren't being recognised, as well as a host of other issues. In the end we had to use Git via Command Prompt when Git Desktop was not working.
​
The Character on the other hand was, again, another completely new thing for the entire team. Eventually we managed to have a properly rigged character that was able to be implemented and imported into Unreal Engine 4, however by then it was too late. The way I had thought about programming the character was completely different to that what my programmer had done. This was problematic in itself, as it rendered my assistance useless for many areas.
​
Despite eventually ironing out and working through the many issues, it was too late, and the game was basically a very pretty looking prototype. The art, UI, audio and menus were great, and were definitely completed as intended (As well as completed very early due to not having a game to work on for most the time frame.). What control was available for the character still didn't 'feel' wonky or clunky, and it is my belief that it is due to how the character was rigged/programmed.
​
My main issue, from a Project Management perspective, is that the programmatic/character issues lulled me into a false sense of security. For every step of progress made, something else went wrong...or Git screwed us over. What should have occurred was forcing an alternative to the rigged model/method of programming sooner. Unfortunately by the point we knew we would be struggling it was too late to make changes, so as a team we fought tooth and nail to iron out and overcome the issues we faced.
​
The project was a valuable lesson on how easy it is to have games go horribly wrong, regardless on how much preparation and planning there is, as well as learning when alternative plans need to be put in place. I am proud of the work that everyone did, and that we didn't falter despite the odds. Especially our programmer, Ali El Ali, who worked tirelessly (Literally) each week to try and get the game functioning.
​
Below is a link to itch.io of the prototype. Any further updates to the game will be available on there:
https://koalazub.itch.io/dish-pig-dilemma
​
Game Credits:
Rhys Sellars - Project Manager/Model Textures/Level & Menu Design
Sandstone - Character Modeller
Dionisis Spindzos - Modeller Environmental
Ali El Ali - Programmer
Corey Taylor - Audio
Jordan Duggan - Audio Support
Chantel Levin - Graphic Art
Zoe Teakel - Graphic Art
Dylan Dyson - Voice Actor
Sarah Elliott - Animator/Rigger
2D ART
 |  |
|---|---|
 |  |
 |  |
 |  |
 |  |
|---|---|
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
 |  |
3D MODELLING
(MAYA)
PROTOTYPES
 |  |
|---|---|
 |  |
 |  |
 |  |
 |
Game design document ~Forgotten hope~
-Forgotten Hope-
Forgotten Hope was the first High Level Game Design Document that I completed, henceforth called GDD. The main difficulty with this document was to not exceed 25 pages of text (Excluding images) that was tasked within the brief itself. The purpose of the brief was to design a GDD based around a game design idea we had previously pitched. It was a valuable learning tool as both went hand in hand on how to demonstrate and get information across to the ‘reader’ in such a way that doesn’t require too many words. Careful use of images that can ‘tell what you want’ was the key here.
The GDD uses series of images in a 'comic book' type format that details step by step what the specific action should do and roughly what it should look like. For example, each character within the game is capable of performing various actions. The diagrams show step by step the ‘before, during and after’ states to show what can happen within the possibility space.
​
Key Points of the Document:
​
-
Document Formatting. This includes hyperlinks for easy access to various sections, Numbered Chapters/Sections for quick reference and most importantly table of contents.
-
Careful use of images. The right images or image flow can get more information across faster than someone reading page after page. They provide clarity of information.
-
Legibility of the document and getting the information across for mechanics. Again this is largely assisted through use of lots of imagery and annotations.
level design document ~spaceship~
 |  |
|---|---|
 |  |
 |  |
 |  |
 |
-Space Ship Level-
Spaceship is the first Level Design Document that I have completed. This document was 80 pages in size and was created for a multiplayer First Person Shooter Team Death Match in Unreal Tournament.
This document conceptually started similar to the High Level Game Design Document that was created for Forgotten Hope, however was tweaked and changed to fit the artistic nature of Level Design. The document was crafted in such a way that should it be printed, it would act as an easy reference for the team who are working on it by using colour coded sections. Example, I need X section so will turn to the blue pages.
The most difficult part of this document is working out level sizing proportions, which was overcome by visualising real world environments. For example, I thought ‘Okay if I am X high, it takes me roughly X amount of time to walk from one side of a room to another.’ Having been the first time constructing something like this, I had no knowledge on Unreal Tournament unit sizing until I was actually in the program, so this was my work around.
Since I am not by any means a skilled artist with pen and paper or amazing at Photoshop, I had to devise alternative ways of getting information across. This resulted in lots of Mood Boards and reference images. Using these images, I directly took the average colour schemes from them to devise how my level should look.
Similarly, since the spaceship is fully enclosed with no external visual references, land marking was something of an obstacle. My solution was to look at similar enclosed environments such as hospitals or military bases that include door codes or coloured lines/lighting elements.
​
Key Aspects of the Document:
​
-
Document formatting. Coloured edges for easy and quick references. Hotlinks for digital clicking to required sections.
-
Mood Boards and Colour Pallets. These are a vital aid in any Level Design Document, and even more invaluable in this instance since I lack drawing abilities currently.
-
Sub-Area breakdowns that detail what is required in every aspect of the level. What props are required, lighting etc.
-
Legibility of the document. Making sure that a team member won’t have to spend lengthy amounts of time searching page after page or reading lengthy amounts of text. Again, imagery is key here.
physics based game
 |
|---|
 |
 |
 |
 |
This was the very first game that I created while at SAE. The brief was fairly open to creativity and required physics based movements which included jumping, as well as weapons that used physics based projectiles and ray casts. A ray cast is where a line is “drawn” from one point to another, and the computer says ‘Okay if the line crosses paths with X item, then do this.’
This project was made using Unity 5.3.0, and demonstrates some of my basic C# programming skills. This has been included to reflect my interest on developing further in this area. This project is not in any means perfect, and has a few issues such as being able to get stuck on walls if the player holds down left or right. My understanding is this due to physics calculations perpetually ’forcing’ the character into the wall.
I was able to create my own co-routine, which runs during gameplay to calculate how many smaller enemies are in the level at any given time, and when they are all destroyed, a larger and faster boss will appear.
​
Key Points of the Project:
-
Physics based movement as opposed to ‘translation’ style movement. Translation is merely ‘pushing’ an object as opposed to providing physics aspects to it.
-
Two weapons, one using ray casts (Which is unseen as I was unable to add a particle effect) and the other using physics to create a ‘cannon like’ slow weapon.
-
Use of a ray cast to determine if the character was grounded before allowing them to jump/double jump.
-
Use of Audio/Visual assets. This was very much drag and drop into the scene.
-
Well commented C# code which allows anyone reading it to have a grasp on what I was doing/trying to do.
-
​
Difficulties Overcome:
-
Understanding the various aspects of the C# programming language. This was largely aided by lots of self-directly learning and teaching myself various things, as well as collaboration with fellow students.
-
Correctly spawning projectiles so they don’t spawn inside the object and ‘catapult’ them towards the player/enemy. This was trial and error.
rave runner
 |
|---|
 |
 |
 |
 |
 |
Rave Runner was created using Unreal Engine 4.11.0. The brief detailed creating an Endless Runner style game in the same vein as Temple Run, Subway Surfers et al. The game had to contain varying floor tiles that the player would automatically run on, obstacles, collectables, UI elements and various menus. The project started by following a standard Unreal Engine tutorial available on Youtube, and then expanding on it.
This was the first project that I created using Unreal Engine and I was quite pleased with the outcome. The Visual Scripting component called ‘Blueprints’ was what was used. This was quite a big change from the C# language used in the Physics game as seen on Page 4. The purpose of Blueprints visual scripting is to allow non-programmers to quickly create aspects of a game. Having gotten used to scripting in code this was somewhat of an obstacle at first to overcome.
​
The main aspect of this project was to create a procedural generated level that would vary each time the player starts a game. This was done by creating a series of floor tiles and obstacles that get placed into a couple of arrays, and get called on to spawn a certain amount at random. This opened the project up for a lot of creative freedom. In my level, I have various narrow pathways, death pits, hurdles, pillars and corners that the player must successfully traverse.
​
The next step was to incorporate various collectable items. This is where difficulty came into the project as far as blueprints go. Blueprints left me feeling a bit lost initially, however the documentation available on the internet and various tutorials a big help. The most difficult part is knowing ‘what’ you need within the program itself, and after lots of trial and error and collaboration with other students, a much deeper understanding of the system was formed.
​
Key Aspects of the Game:
-
Various floor tiles and obstacles that randomly spawn. Obstacles like the pillar are set to spawn at 4 specific spawn points that are randomly selected in an array.
-
Various items. These spawn within a single ‘item box.’ I had one collectable that enable the player to jump twice as high for 5 seconds, one that enabled 10 seconds of invincibility, one that slightly slowed down the player speed, one that replenishes the player’s jump counter and standard coin items. I had one additional item that unfortunately was not functioning correctly. It was a magnet item that would draw certain coins towards the player. I managed to get it working, however the magnet would forever stay on after the item was collected.
-
​
Regarding the magnet, what I have learnt is that I might be able to incorporate a sphere collider around the player that can be added and destroyed that will ‘draw’ the coins towards them for a set amount of time. I had looked at numerous different tutorials on ideas on how to do this however was unable to get it working correctly. I believe I had done this in reverse and was the source of my problem.
Overall I would like to revisit this project to correct this issue as well as expand on it in some way when I have more knowledge.