I thought I would give this its own post as I am that excited about it.

For school, our end of year project is to work in groups to make a game over the next 6 months which is pretty exciting. So far the longest we have had to make a project is just under 3 months, and that was when our group made Genepool (not to brag but it's pretty damn good :P). About a month ago our teachers mentioned that there were some internships coming up that would take place of our end of year project. The first to be brought up was with FMOD, their office is 5 floors above our school in the Melbourne World Trade Centre, after having used their low level library in a recent project (Game Sound System ) I was super excited about this opportunity.

It has been a little while since my last post so I will split this one up into two as quite a bit has happened. I will start with my last school assessment, Physics.

Over the past month and a bit, I have been working on a game system to show off some game audio features. At first, I wasn't sure what I could do or how to even do it, but I definitely aimed big. Although I didn't end up where I originally wanted to at the end of the project, I am very happy with the result I came up with, and plan to continue on so that I can meet my initial goals. Below is a picture of the visualisation I am using.

Now that we have made basic game engine, our next assignment is to choose a complex system and implement it. The topics suggested are:

• Threading
• Cache Coherence
• GPGPU
• Behavioural Mathematics
• Fuzzy Logic
• Machine Learning
• Networking
• Audio
• Automated Build Systems
• Analytics

Initially I was interested in using AI, but I thought I should have a look at some of the others to see if they interest me. Audio grabbed my interest right away. In part to my slight addiction to anything Marvel these days and a Gif I saw on reddit recently (Nocturne Heartbeat), I am aiming for something along the lines of a DareDevil-ish interactive scene. Basically the scene will be almost blank, with objects that emit any sound also emit a wave/pulse, which then reveals the objects it interacts with.

The beginning of the year has just flown by already. Our first assessment for school this year, was to create our own basic game engine using OpenGL and GLFW (along with a few other more specialized libraries too). This was a lot of fun and also very interesting, because we were learning all the workings that go on deep down behind the scenes.

• Rendering basic geometry (everything is broken down to triangles)
• Texturing models
• Animations
• Lighting (Direction/Spot/Point)
• Particle Systems (Both CPU and GPU based)
• GUI (Graphical User Interface)
• Procedural Generation
• Frustum Culling
• Render Targets (eg. reflections seen in mirrors)
• and more

I was really impressed at the difference between the two Particle Systems we made. The CPU based system couldn't handle more than a couple thousand separate particles without struggling. Whereas the GPU based system didn't break a sweat until we got into the millions of particles (see below, using around 50,000 particles).

Learning all these topics while trying to build something useful of our own was a challenge. Although just like anything new or foreign, it can seem daunting to begin with. Once I got my head around the general concepts and understood how everything fits together, it all seemed to all fall into place.

Over the past week, I have been trying to turn our "Grey Box Arena" into something that resembles an actual game that people pay money for. Previously all we had was an arena that loads straight up when you open the game, adding things like a Main Menu and a character selection screen have been my main goals. And it is proving to be harder than I fist imagined.

While I didn't think it was going to be the easiest job to do, the character selection screen keeps making me second guess myself. There have been a number of smaller issues that I have managed to work through and solve (eg. Static Input Manager Class, Game Manager OnStateChange loop, controllers sometimes working). Oh and speaking of controllers, the issues we were having last week with the Unity Input Manager, the best solution I could find was to use a third party free asset that handles everything for you. It seems to work perfectly every time, while I would have loved to make something myself to handle this, I just don't have the knowledge of Unity just yet and we only have about 5 weeks left until the end of this assessment!

The custom Input Manager I used can be found here. This has made my life so much easier for the time being, maybe some day I will be able to come back to it with my own creation. With this I can map out all the controller inputs for one player and then clone it for however many players there are. We still have no idea what the problem with Unity and controllers is, hopefully it will get fixed soon though.

The way I have decided to write the Game Manager and Game States is that each one belongs to a different scene.  I'm sure there are cons to using this setup but I feel it works best with what we are doing. By using this method, currently the character selection screen passes the information (eg. number of players, character selected) to the Game Manager, which when ready, then creates the appropriate players in the game scene. All sound fairly straight forward, but problems always pop up to make things fun! Debugging in Unity and C# can be fairly easy and intuitive, but there are times when you will get an error code that just makes no sense at all.

The Input Manager was quiet easy to implement, basically import the asset, drag it onto an empty gameObject, it even has its own GUI to set up whatever controller you want. There are also more settings in the Unity menu bar under TeamUtility. Then all you really need to do is "#include TeamUtility.IO" and instead of using Input.GetInput() you can use InputManager.GetInput(). It includes a huge range of methods used in the Unity Input Manager, plus a few additional ones to make things even easier. I have a feeling as we get closer to the end of our assessment, I may be helping other groups implement this, if they are needing multiple controllers that is.

Yesterday our team had our second official presentation to a group of our teachers and a couple people from the Melbourne gaming scene. in the morning we had the game running fine, it was beautiful and quite a bit of fun to have four people running around burning/shooting each other. And then it happened...

Over the past three weeks, I have made use of the painful Unity Input Manager. It has been painful in the sense that it is very long-winded and repetitive, programmers are taught to build around repetition. I had a bit of a look into making my own Input manger to replace Unity's, there are a few different examples and walk-through's that can be found, but still being quite unfamiliar with Unity I thought I'd give it a miss for now.

We have really only been testing our game with two controllers at most, up until yesterday, and at first we had no problems. Everything ran smooth, controls worked fine, not the prettiest thing to look at but the gameplay was there. I quit the game and reopened, without changing a single thing! Not one single letter or number! The game loaded up, everything looked fine, as the players try to move their character things get well... a little odd. Player 1 controller now controls the third character's movement but the first character's shooting. Weird right? Player 3 controller now controls the first character's movement but the third's shooting. And Player 2 movement was fine, but could only shoot when player three also shot.

This made me pull my hair out for four hours leading up to our presentation. Got the help from one of our teachers, he couldn't understand why it was doing what it was doing. We couldn't even reproduce the bug at will. Sometimes it would work, close and reopen, BAM! controls stuffed!

We ended up finding out, that this seems to be a fairly common issue with Unity, many people have had "issues" with this Input Manager for quite some time and Unity are yet to fix it.

When it came time to play the demo in our presentation, the first time we ran it, no controller worked. That's ok we were prepared to try a few times, then fake it if we had to. All of a sudden, the Unity gods were kind and allowed the controllers to work normally! No need for a blood sacrifice or anything!

Needless to say, the next few weeks will be a mix of fixing general bugs, polishing and going back to the input manager to see if we can spot the problem and hopefully find a fix.

Cameron here, also known by some as Randy because during Movember I look a bit like Randy Marsh, and this is the start of a series of blogs about my adventure. This year I decided to go back to school, after a...little break, I have decided to take on the challenge of Programming. More directly, Programming in games. Our current assessment is to create a game in a group over approximately two months in Unity.

This is my first real attempt in Unity, I have completed a couple of tutorials, but that's about it really. We started the year learning C++ and progressed onto C# recently. This gave us a great insight into the inner workings and memory management behind C# and taught us that even though C# is "easier", it may not always be the best option to use.

Our group, which we have dubbed "Majestic Prawn Studio", consist of two artists, two designers and two programmers. Everyone seems to be very keen and level-headed so far. I don't think we have been aiming too high with our initial ideas or concepts either. We are going for a "Gangbeasts" style, twin-stick, local multiplayer, arena-shooter... or something like that. After many hours discussion we have named it "Genepool". (Greybox arena prototype pictured below)

Myself and Eli, the other programmer in our group, have been working very well together. We have managed to split up the work fairly evenly so far, I enjoy working on collision and managers and Eli likes weapons/mechanics and particles.

So far I have set up a GameManager to handle the changing of Scene's; currently we have a Main Menu, Character Selection Screen and The Main Game. The Character Select Screen uses four separate cameras for each of the controllers which won't be active until the start button is pressed on the corresponding controller. The camera then moves to view the next character as you scroll through the options (see image below). I did have trouble with moving the camera's initially, because I was using a RigidBody to change their transform and I believe there were some floating point errors.

The default Unity Input Manager took a while to setup for all four players and there is no keyboard options just yet. After doing a lot of searching online, it looks like the general consensus is that the default Input Manager could use an overhaul. But as we are not supposed to use any third party assets, it will have to do for now. I have tried to make editing the controls easier by adding a Serializable class to the Player class which allows changes to made through the Unity Inspector.

This week I am hoping to have the Character Selection Screen working in a build for our second group presentation, once that is good to go I will be making scripts for a pause screen and end screen. Eventually I am looking forward to making some level dynamics (eg. moving walls, traps, etc.).

I will be making an update after our presentation this week, fingers crossed they love what we have so far. Thanks for reading!