Hello OTN!



Attack of the Utahs! Ultimately there will be more than just teapotheads to play as.

So like I discussed in the last blog, we have moved onto a new game idea called Optimise the Null, which we based on feasibility, scope, and our teams abilities. So what the heck is Optimise the Null? It’s basically Mario Kart… yup, we thought, ‘Hey! Whats something that would be easy for us to make? Mario Kart! Yeah.. that’ll be easy!’

Ok, so it’s not exactly Mario Kart, for obvious reasons, such as Nintendo would skin us, but it is a racer type of game, in the same vein with some twists and hijinx thrown in that make it a unique beast.

The basic premise is fast actiony racing on hoverboards, with similar kart racing mechanics such as pick ups giving the players the ability to fire at each other, lay traps on the track, or get a quick speed boost. You can also ‘drift’ to get round tight corners, which also gives you a speed boost if you drift long enough. Where our game differs is that the players can jump off their boards at any point, and start gunning each other down in a third person over the shoulder mode with an assortment of high powered weaponry.

Stylistically we wanted to do something a little different to what we have done before, and add a little more of our humor and personality to this game. Previously we have always designed the brief with a customer in mind, or keeping it very beige and PG-13 style stuff.
With OTN we decided early on we wanted to cuss, a lot. We all grew up with classic kart games, and we loved them, and still do, but we are now adults, and whilst the gameplay suits our tastes, the characters and content is… lacking.

So we want the characters to have attitudes, break the fourth wall, be hyper violent, and swear like fucking sailors. We don’t want to make a game for kids, kids aren’t allowed, and if you let your kid play our game then you are a negligent parent, and a horrible human being.

We also thought, hey, we are on boards, why not add tricks like kickflips and front flips? A good why not would be the fact that the required animations per player were already insane, and this just adds to that mess, but it’s also badassed. Tricks can be chained, and earn you cash, which can be spent to buy instant access to power ups.

Oh also, you can grind, I mean of course you can right? You are on a flippin hoverboard, omitting grinding would be sacrilege, but once again requires more animations, yay…

Let’s keep the scope down they said, let’s concentrate on our strengths and biting off what we can chew they said, then right out the gate we decide we want basically two player controllers. To be fair, nothing within the core mechanics of the game is outside of what we as a team are capable of, in fact the first iterations and prototypes came together very quickly.

The very first prototype that Wade put together with PlayMaker discussed in my last post can be seen below:

One of the main issues we are going to face is that this is one of the first multiplayer games we’ve really done, so while we have a small amount of experience with networking (enough to know what questions to ask, where to look, and where to start), it’s going to be new and tough ground to cover.

The main focus of the game is in fact multiplayer, we can do split screen stuff quite easily, which is great and there’s not enough couch games anymore. We won’t really be happy though until we can do multiplayer across a network though.

So basically, we still hate ourselves, just a little less… maybe.

Goodbye ADA

So as usual, we here at Trilum have been smashed by the real world and university commitments, and have totally left this blog to rot. A lot has happened in the last little while, and the team has done a lot of soul searching, bonding, and a lot of introspection. The biggest change has been that we have changed our core project.

ADA was a great learning experience, and we still love the idea and are proud as heck of what we achieved, but in terms of feasibility it didn’t make much sense to continue working on it. The project was a freakin beast, and during its creation we learnt so much… if we were to start again, there is so much we would do differently, and to make an honest attempt at finishing the game, we would have to do just that. There is also the fact that it would take us forever to finish, and as a small team really wanting to put something out into the world, it no longer made sense to continue pushing in that direction.

So we sat down and felt very sorry for ourselves, and asked ourselves what we had learnt. One of the main criticisms of ADA was that it simply didn’t ‘feel’ right. That the controls were too loose, and that the animations didn’t convey what we intended the player to ‘feel’. This will happen when you are:
A) Students
B) Trying to do something completely different
C) Your peers and mentors really can’t give you input.
Game feel is a big deal, and it’s not like we didn’t agree with any of the criticism, it’s just that ADA was a technical beast.

So during the last couple of weeks of the semester, I assigned our brilliant and handsome technical artist Wade to the task of researching humanoid animations within Unity using Mecanim. We had previously just kind of hacked and slashed at the issue, and the person doing most of the animation tree work was actually one of our programmers. So with Wade being our expert at rigging and weird animation issues, I thought his input and knowledge on this would help.

So ol Wade basically ignored what I asked him to do, which is common, and got a cool plug-in for Unity called PlayMaker, which is essentially a node based programming system ala Blueprints for Unreal, and put together a prototype third person player controller.

While doing this he worked out how to really get what we wanted out of Mecanim, and solve some issues that we have had for a while. Hopefully he will be so lovely as to do a post on that first iteration at some point.

His success with setting up a nice player controller and animation system really impacted our decision to move onto a new project, and what we wanted out of that next project. Ultimately we went back to a game design I had created in my first year of study, but did not have the know how to pull off. We extrapolated on that idea and started steam rolling ahead with prototyping and setting up systems to make the game.

So that’s a kind of general update on where the team is at, and why we have abandoned (for now) ADA and moved on. Ill talk about the new project called Optimise the Null in another blog post, but its something the whole team is really passionate and hyped to be working on.

As usual… its scope is pretty ridic, but… at least its not an entire fucking solar system. 😉

Making an Object-based Database

Hey it’s me, the GOOD programmer, Liam. Thought I’d fill you guys in on what I’ve been working on during the past few weeks. This post will be focusing on the object based Database system I made a while back.

After the team all agreed on the goals of this project, the first thing I worked on was the Encyclopedia Database. We wanted players in ADA to be able to scan objects in the game-world and view them in a Pokedex-esque UI system. This was one of the game-play mechanics that we wanted implemented before the games showcase at the end of semester.

Before I get into the boring nitty-gritty of what I did and how I did it, I just want to say that I went into this hoping to make this system as modular as possible. I wanted to reuse this system in future projects, so I tried to make sure not to tie it into ADA too harshly.

When I began, I knew that I wanted to use Generics to handle storing and editing each object in the system. I ended up using multiple Lists in this system though in hindsight, Dictionaries would have been a better choice. I created one list to hold ALL the objects and three sub-lists to sort out each individual object-type. This would have worked better with a Dictionary as it is easier to sort and file each of the objects in it and I wouldn’t have had to create three separate variables.

While making this system, I wanted to try and incorporate as many static methods as I could, as I knew our game was going to be a behemoth in terms of cpu usage. I made about 9 of these static methods, all of which interact with the lists in some way or another. For example, one of the functions is called FindAllDatabaseObjects and it, you guessed it, would find all of the relevant objects in the current scene.

After getting the main plan of attack down, I decided that I wanted to use some custom editor shenanigans to streamline to process of adding new database objects to the scene. Here’s how the database object looked in the editor after my first pass on the custom editor stuff:

ADA DatabaseObject

By hiding any unnecessary variables, I could prevent any artists from breaking my shiet. An example of this would be when the object type is set to Fauna, you won’t be able to set it’s Flora type in the inspector as its not a Flora object. Doing it this way allowed me to store all the variables for any object type in the one script and just hide the unrelated ones.

Here’s what the main database script that held all of the lists looked like in-editor:

ADA DatabaseManager

Those buttons were put in place so I could test the system without initiating the main game-loop. This cut down the time I spent adjusting the various finer points of the script such as the positions in which each UI would be instantiated. After creating these systems and customizing the Unity Editor to fit my needs, I designed the basic layout of the in-game UI. This is the first and, as of this post, current look of the UI:

ADA DatabaseUI


My week in review

This week for me started with an awesome talk from Prideful Sloth, with their Pre Mortem on their game Project Columbus. So much information to process, but it is definitely clear they know what they’re talking about!

I’ve been battling with FMOD most of this week. With the need to implement 3D sound I was on a quest to find out why the hell the events are not being played when the game starts. I embarrassed myself on the FMOD forums which inadvertently lead me to the realisation that the events were not being loaded when the game was running. Or so I thought. Sounds that I made 2D worked fine, but 3D sounds still eluded me. I thought it had something to do with the pathing of files which had been changing when we’ve been doing our manual build updates (shudder) It turns out that I wasn’t setting the position of the sounds when they are playing. Once I told the sounds to be playing at the object’s transform position, everything started working.


The most frustrating part was finding out how to do that, which took me the better part of a day and I found the answer in a Reddit post, where one of the commenters put it in there as a reminder to the OP of something that needs to be done for 3D panning sound. So, ADA’s audio is in game with placeholder audio and so is the Jorm’s audio.

We’ve made a lot of progress this week with the first 5 minutes of ADA coming together nicely. The intro cinematic has been blocked out and we’ve got the tutorial in a playable state. Our plan of getting people to test our game has been pushed back due to the team’s realisation that we’re not happy with where the character controls are, so there’s no point asking what other people think of them if we’re not happy with them ourselves.

The internal test that we did produced a list for us to work on for our next sprint cycle. The plan is to polish what we have and only add to the game with assets that help achieve the level of polish we’re looking for, for our assessment build. The next few weeks should be spit and polish with a few additions that make sense for the game play that we’re trying to achieve. That’s it from me, until next week…

ADA Character Animations

This week I will be discussing different kinds of walk cycles we made for the main character for our game ADA – Automated Discovery Android.  Whilst the character is not humanoid, it has many humanoid elements, and a rig that in a lot of ways is far more complex than a standard biped rig.



One of the major considerations for this character and rig, were to make it as animated and filled with personality as possible. The rig consists of 72 bones in total, with 27 controllers. In a rig of this complexity, a lot of the bones are simply used as constraints, or in conjunction with other bones for example in Inverse Kinematic setups. As such, not having a good controller system for the actual animation phase, would make life very difficult.


Left: Bones    Right: Controllers

The rig consists of many similar controllers you would see in a standard humanoid, such as hips, ears, and a body controller to lift and drop the body as the robot moves. These were specifically designed into the concept; realistically a robot does not need to move its hips as it moves, nor does its body need to lift and drop with footsteps, but it adds a great deal of character, personality and most importantly sass.

In terms of reference, most of ADA’s design and movement was created uniquely through the creation process itself, inspiration however was drawn from certain cartoons, namely Adventure Time. Our colour palette especially was created with the idea of a bright cartoon aesthetic, and it was important that we were able to recreate bombastic over the top animations such as bendy stretchy arms for example.

An example of this in practice can be seen below.

Actually animating this character, especially in the arms can prove problematic. The arms are very complex, but moreover it is difficult to recreate a natural look to rope like arms moving. To create this look in the second animation, it was necessary for us to draw a sine wave to follow and animate the arm along; this is a bit of a tedious process, but really the only way of getting this sort of look and feel.


Previously on Triluminati!!

Our big main project right now is ‘ADA – Automated Discovery Android’, the game is a third person platformer, centering mainly on adventure, and story elements. You play as a robot, and the game takes place in a solar system. You can navigate the solar system in a spaceship, and land on planets, basically anything you can see you can fly to and land on.

Each core planet is essentially a level and has a unique theme (ice, desert, forest), the player can explore to find wildlife, predators, resources, and dungeons.

The dungeons are in theme with the planet, and involve platforming, puzzle solving, and story based elements as well as basic combat. Wow, that was all direct and to the point huh?

ADA Concept

This was a project myself and Chris Osmond thought about in earlier semesters, with the basic concept of making a game that involves the player navigating spheres or small worlds akin to Mario Galaxy.

So when asked what project we wanted to do over an eleven week period, with three other subjects to worry about in the second semester of our second year, we pitched this idea… because deep down inside we fucking hate ourselves.

The first ever prototype I put together looked like this:

Wow! Yay! The thingie moves around the moon whatsit! This is obviously going to work and be cake! We all left early and got sandwiches.

Obviously it wasn’t going to be so easy. What you see here is a very basic gravitation system and player controller, which over time, we had to change completely.

You see we didn’t like the idea of the planets floating static in space, so wanted to add rotations for real time day night cycles. We also didn’t like the idea of load screens, so the entire solar system was to be visible at all times. We didn’t want the player to just appear on the planet, we wanted the player to fly to the planet, have the ship get caught in its atmosphere, and beam down.

Did I mention we were second years with no industry experience that fucking hate ourselves?


Basically our project pitch was a combination of all these kinds of systems in a kind of alpha, and a whole tonne more, like shaders, optimisation magics, and a player controller that behaved like a regular third person platformer but on a spheroid type planet.

Through sheer determination, luck, and a bunch of moxxy, we actually got it all done.

Yay! Leave early for sandwiches!



What we didn’t have was gameplay… I mean, it WAS an Alpha, we damn well never promised gameplay, and in fact took umbrage to the fact it seems like no one knows what a damned Alpha version of a game is. Also: Did I mention we were second years at the time with eleven weeks to do this in? I MEAN GET OFF MY CASE YEEEEESH.

The team was pretty broken up over it all, and everyone was ready to ditch the project and make phone games for the rest of our lives. After a nice relaxing holiday period, we decided we still hated ourselves too much to ditch it, so here we are, back at the base of the mountain pushing that boulder.

This year we hope to get AI and gameplay popping off, and extend what started as an uni project into something special. Me and the team will be updating this space on the regular with the projects progress, and fun write ups on some of our cooler processes.