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