SIE App Jam Day (2013) - Super Santa Brawl

Apologies for the delayed post but I've had a bunch of project work that needed to be finished which will be discussed later. 

Anyways, two weeks ago on November 30th the Scottish Institute for Enterprise hosted an app jam at Heriot-watt university organised by one of my fellow game dev students who is also acting as the Napier representative for SIE. The main purpose of the app jam is to make some kind of application that might have some form of business potential and other elements that are awarded are things like completeness, originality and how interesting your idea actually is. Naturally, as a game student, I used this chance to instead spend time making a game. If you remember back to one of my previous posts I attempted to also make a game at the same app jam but didn't manage to fully complete it and as such didn't do very well in the scope of the competition. Luckily this time I managed to make a bit of a better and more complete game and won one of the top prizes which were £40 amazon vouchers and a Raspberry Pi with case.

The jam itself lasts around 10 hours over the course of a day. Unity was used to develop the game, as well as this Unity had recently released some new features to support 2D game development and as such I used this as an opportunity to learn how to use them. The theme for the jam was "Christmas" and to keep inline with this theme I investigated some Christmas themed sprite sheets. I found one that had a fairly nice santa sprite taken from the game Daze before Christmas for the NES. The first several hours were spent wrestling with and understanding Unitys new sprite animation system but after a while I managed to get things working, a lot of my understanding of how collisions work with the character as well were learned from the Unity2D tutorial on 2D platforming which showed how to use the new 2D physics system as well.

Figure 1 - The final game

The game itself was based on the likes of Super Smash Bros and involves two players running and jumping around the arena throwing snowballs at each other. To allow multiplayer I set up and used two Xbox 360 controllers. This was the first time I had used controllers for a game as well and Unity itself does not currently support rumble for gamepads so to get this feature I used XInput. Using the right stick the player can aim the direction of the fire balls, fire with the right trigger, jump using A and move with the left stick. If a player is hit with a ball directly they will lose a health point, 4 hits results in a death and the player respawning whilst the other player gains a point. The rumble intensity is modified based on the distance of an explosion to the player so the further away the player is from an exploding ball the lower the intensity versus a direct hit which will cause significant rumble.

Overall I was quite pleased with what I had learned over the 10 hours making this game as it had been a while since I actually made one. More work is needed before this is fully finished and I will need to change many of the art assets but I will do this when I next get a chance.

I took some videos using fraps but I'm currently having problems getting it to actually work. As such the video linked below is an older prototype version and was only what was made within the first few hours of the jam. I will update this once I actually fix my movie maker problems.

---

Email: markmmiller@hotmail.co.uk
Xbox Live: Dr Death MK 2
Steam: 7thsanctum
Follow @7thsanctum
Origin: 7thsanctum
Youtube: 7thsanctum
Github: 7thsanctum

Voxel Engine Update - DirectX

As part of my honours project I have been rejigging the particle engine I made last year to a voxel engine. The plan for this project is to optimise the engine for use with the GPU, investigating the effectiveness of the Geometry shader for rendering cubes and perhaps using other elements such as Computer shaders to provide further speedups.

Currently I have a 64^3 (262144 cubes) data set rendered at a steady 30fps on GTX 550 Ti. This is currently without optimisations. I can increase the total to 128 ^3 or 256^3 successfully but these suffer significant slowdown, resulting in 5fps and less than 1fps which are difficult/impossible to interact with.

The images below show 128*64*64 cubes. The image on the left has some cubes removed to demonstrate that there are cubes below the surface and each coloured dot is an individual cube. Click on the images for higher resolution versions.

I have several things that I need to work on next, namely arrays over 512^3 run out of memory or cannot be defined and as such I will have to find a way to deal with this. After performing several calculations as well many optimisations will have to be performed to achieve a dataset much larger that 512^3, to simply store all of the vertices required for the number of vertices for a 1024^3 grid we would need 128GB. This would be a feat using even HDDs let alone in memory. As such to have a world of 1024^3 we would need to store this info on disc and perhaps load chunks of it into memory.

I also need to get some more interesting volume data sets to render to make it most interesting. Noise or other 3D models etc.

Anyways enjoy these close ups and I will have some more updates in future once I've finished some of my other courseworks.

128*64*64 - 524288 cubes

For the vertices alone we are using approximately 64MB on the GPU, this is being generated for every frame.

---

Email: markmmiller@hotmail.co.uk
Xbox Live: Dr Death MK 2
Steam: 7thsanctum
Follow @7thsanctum
Origin: 7thsanctum
Youtube: 7thsanctum
Github: 7thsanctum

3D Tilt Virtual Reality App - Unity3D

This post is a bit late but I only just realised I never made it!

Last year I worked on a group project developing an application designed for mobiles that was meant to demonstrate a "3D effect", the idea being we could bring 3D virtual reality to the masses via smartphones and gyroscopes. The main inspiration for our client was a video of a ballerina inside of a box. The video can be seen below.

From this vague description we were to research and make our own application that demonstrated a similar style of 3D effect. During the project we went through several different iterations and drastically different ideas before the final product was implemented. The first view versions focused mainly on being a game where you fly around the universe, go to different planets and space stations and witness all sorts of interesting and scripted events. Sadly when we approached the client with what we had made the 3D effect wasn't so good or prominent due to the set up of the scene. This resulted in a big change where we decided to try and create a holographic projector type set up.

A video of the application so far can be scene below:

To get this effect we made use of camera distortion technique known as the offset projection matrix. This is where the camera view frustum is distorted allowing various visual effects to be achieved. A regular view frustum is uniform in shape as can be seen in the image below.

Figure 1 - Example View Frustum

The view frustum in most cases is defined simply by the distance and sizes of the far and near planes, they are usually centre aligned and thus symmetrical giving all the objects in the world the correct appearance. For our phone application the users perspective relative to the phones screen has changed, what we wanted to do in this case was alter the frustum relative to the rotation of the phone so that we maintain the users perspective and distort the objects in a manner which would be correct from their point of view.

Figure 2 - Far plane shifting (I apologise for the use of paint)

In the above image we can see how the far plan must be shifted relative to the users position where the near plane is fixed and still parallel with the far plane. This is required because of the users change in position, simply rotating the camera on it's axis will not achieve the required distortion, feel free to attempt this and you will see exactly what I mean.

The only major problem that was not solved over the course of this project was the drift caused by the gyroscope on the mobile device. This drift meant that when the phone was righted back to it's original position it wouldn't quite be right or perhaps when rotating upon any axis it would detect false movement ruining the illusion if the application was used for too long. For just now we implemented a reset button that allowed the user to reset the view which helped alleviate most of the problem. As well as this I kept meaning to add in more of the application to bring it up to a complete level, the original idea being to create an "educational, hologram viewer" application, this would include information about each object that was shown but this is still a work in progress whilst I am at University.

Anyways thanks for reading. I will upload an APK of the application when I can.

---

Email: markmmiller@hotmail.co.uk
Xbox Live: Dr Death MK 2
Steam: 7thsanctum
Follow @7thsanctum
Origin: 7thsanctum
Youtube: 7thsanctum
Github: 7thsanctum

New term, C++11, Fractals and futures!

It's been a while, I really ought to get to updating this blog more often. It's the new trimester and the beginning of the final year at university though so I should have some interesting things in store for the coming months! The current modules I've been working on are Concurrency and Parallel Systems as well as Management of Software Projects, both have their ups and downs. Aside from that I have my honours project that I will be working over the next several months until April next year which will take up a big bulk of my time. Hopefully I will be able to make some interesting posts as I progress with that.

Anyways enough talk, first up we have a C++11 concurrency project that I've been working on over the past few days.

Mandelbrot Set

As a part of an exercise in understanding futures in the C++11 standard I parallelised the Mandelbrot set. The Mandelbrot set is famous for being used in the generation of the Mandelbrot fractal which can be seen in the image below.

Figure 1 - Mandelbrot Fractal

The generation of a fractal image such as the Mandelbrot above is commonly parallelised and is done so by simply splitting up the image into different section and then assigning the different work loads to different threads. By using std::async we are returned a std::future object instead of a std::thread. The std::future object will eventually hold the value being returned, in this case the pixel values of the image. [C++ Concurrency in Action Practical Multithreading]

int main()
{
 auto num_threads = thread::hardware_concurrency();

 // Calculate the range of pixels each thread will work on
 auto strip_height = dimension / num_threads;

 // Create futures for each thread
 vector<future<vector<float>>> futures;

 // We give each thread the calculation and the data range
 // with which we want it to work on. We also make it 
 // asynchronous so that we get a std::future reference back
 // so that we may retrieve the value we want later
 for(int i = 0; i < num_threads; ++i)
  futures.push_back(async(mandelbrotcalculation, 
     i * strip_height, 
     (i + 1) * strip_height));

 // The results of the calculation
 vector<vector<float>> results;
 // Get the results from the future! 
 // Bear in mind that f.get() can only be called once
 for (auto& f : futures)
  results.push_back(f.get());

 return 0;
}

The code above shows  the main for the application generating the fractals and how we would operate the futures for this mandelbrot generation. Bear in mind instead of creating std::thread objects we are using std::futures which allow us to get the returning value from the thread later. "Mandelbrotcalculation" is simply out function for calculating the colour for a single pixel, the maths of which will be covered in a later post. A more indepth discussion on how it works can be read here on Wolfram Mathworld.

The resulting application still takes some time and I still need to measure timings to see how much faster it is than just calculating everything on a single thread would be but results in the following image.

Figure 2 - Part of the Mandelbrot Rendered

Currently I still need to fix my application so that it renders the whole image rather than just a part but in the course of writing this blog post I have realised partially where I have gone wrong so I will have to get working on that asap.

---

Email : markmmiller@hotmail.co.uk
Xbox Live : Dr Death MK 2
Steam : 7thsanctum
Follow @7thsanctum

DirectX - Geometry Shader (Lot's of cubes and particles!)

Just posting a quick update for my geometry shader experiments. I managed to increase the particle count by a crazy amount to just above 450,000 ! The first program I made to do this created just plain old particles, billboarded towards the camera and with basic blending.

Be sure to click to view in HD

This was pretty cool and I easily managed to get above the 450,000 target. At this amount the system runs smoothly and gets a nice steady 52 FPS. This is at fullscreen 1920*1080 resolution.

Look at those pretty particles!

 After this I played about with multiple emitters and pumping up the emission rate but none of these gave me any satisfaction. Then I remembered  the geometry shader isn't just for particles, I could create any geometry from a single point, so what about cubes? I then did some jiggery pokery inside the shader, spent far too long working out how to create a cube using a triangle strip and voila, the cube demo was born.

Over 450,000 of the finest cubes known to man

Now for this system you would think it would run 6 times slower due to the extra faces, dropping from 52 to about 9 fps. You'd be wrong though, with this system the application still manages an impressive 28 FPS at fullscreen 1920*1080, this is all without any form of instancing, culling or other optimization techniques.

For a bunch of cubes they sure are colourful

Although this program isn't a significant achievement in the realms of computer technology it goes to demonstrate the significant power of the Geometry Shader as well as the GPU. This level of geometry would simply not be possible on the CPU in real time. Anyways, check out some realtime videos of this stuff below, be sure to watch in full HD for the best quality!  Due to the way youtube compresses videos down I had to alter the brightness which is why there is a colour difference with the screenshots above. I really should modify this in shader but that would be sensible.

Also check out some random cool patterns I made below.

---

Email : markmmiller@hotmail.co.uk
Xbox Live : Dr Death MK 2
Steam : 7thsanctum
Follow @7thsanctum

Unity - Conway's Game of Life

Hey everyone. So instead of working on my coursework, I decided instead to recreate Conway's Game of Life. Now I know I could have used DirectX or some other render framework to create this, but instead I was working in Unity at the time so I chose to use that. If you'd like to play the game go ahead, read on for some more information about the project.

For those who don't know, Conway's Game of Life is a so called 'Zero-player game' the purpose of which is for the user to devise a starting state and watch it grow. To allow this to happen there are a few rules that are specified to allow the system to progress. Firstly there are two states which each cell has, namely Dead or Alive. Each cell has 8 neighbouring cells and after each time step or generation the following rules are applied:

1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
2. Any live cell with two or three live neighbours lives on to the next generation.
3. Any live cell with more than three live neighbours dies, as if by overcrowding.
4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

Although basic, these rules lead to some very interesting patterns. For example, one of my favourites, the 'beehive'.

The Beehive

Classed as a still life and one of the more common of the randomly occurring patterns. Although if you add a life to one of the corners it will result in four more beehives.

An interesting pattern

Now if you do the same for each of these four, like this: 

 This results in a really cool explosion type system that last for quite a few generations. A so called "Methuselah".

Wacky patterns!

After a few hundred generations, this system eventually results in 8 gliders and stabalises.

System begins stablising, note the 8 gliders.

There are an infinite variation of patterns, new and interesting ones are discovered all the time. The system has got to the stage where automated processes are used to try to discover new patterns.

If you'd like to give it a shot, play the version I made here on my blog. It's still a bit buggy and requires some new features which I will get around to implementing when I have a chance but it has the full functionality of the game. 

Anyways, enjoy and please tell me what you think! Until next time.

---

Email : markmmiller@hotmail.co.uk
Xbox Live : Dr Death MK 2
Steam : 7thsanctum
Follow @7thsanctum

DirectX - Particle System

Made some changes and upgraded my particle system. Finally set it up so it works on the geometry shader which has improved performance by quite a lot. I get around 680 fps with around 80,000 particles.

Looks almost like snow!

The main problem I'm having currently is separating the emission rate from the frame rate, just now every frame it emits a new particle so it does this as fast as it can. This means that when the frame rate drops the number of particles emitted per second will be less.

Spiral particles

Currently my goal is to fix this, I've already got it generating 10 times as many points but there are some problems with actually getting them all to render in the same pass. Other than that, hopefully I will get finished up this week then can do some data analysis next week, comparing this system against the older CPU based one.

Still gets 680 fps with most of them visible

---

Email : markmmiller@hotmail.co.uk
Xbox Live : Dr Death MK 2
Steam : 7thsanctum
Follow @7thsanctum

Gaming Discussion - The Free-To-Play Model

Free-to-play mobile games are pretty rubbish. Here is why.

Recently, even more so than in the past. The free-to-play model for video games has become an increasingly popular method of marketing your game. In today's economic climate, why would you drop £40 on a so called 'AAA' title when it is just a rehash of previous game ideas or another sequel in a never ending saga.

You can have any character you want as long as he's brown haired and in his thirties

Originally the popularity of the free-to-play was due to several Massively Multiplayer Online Roleplaying Games (MMORPG), such as Neopets and Maplestory as well as their ease of access. Practically anyone with a computer could play. Things got even better for free-to-play with the creation of Runescape by Jagex, a web based RPG with great graphics and sound gameplay. These games are still amongst the most widely played of the free-to-play games out there, and what they lack in sheer graphical fidelity and immersion that mainstream 'AAA' titles might have they make up for it in being wide reaching, affordable and not requiring advanced technology to run them.

It was no surprise then that the mobile gaming platforms of iOS and Android lapped up this model and soon a whole host of developers churned out so called "free-to-play" games like there was no tomorrow. This has led to a mass of games which are all identical in but name and graphical style. How naive was I to think that Jurassic Park Builder, The Simpsons : Tapped Out and Tiny Tower would have anything but identical gameplay. (I would mention many others as well but sadly I have no space here to list them all) They all follow the same format of building things, early on they emphasise the fact everything you do takes time (real time) and that you can speed things up with the use of money (real money). This inherently has nothing wrong with it, if your user is impatient why not give them the option to speed things up a little bit? That itself is fine, but when it gets to the point that a game is pretty much unplayable because you are sitting and waiting for the game to let you play then I think it is unreasonable. I got to a stage where the time it took to build a new floor was something along the lines of two real life days (48 hours), there is nothing else to do in that game other than collect rent and change the uniforms of your staff. There are no tactics, no thought. Nothing that can go wrong other than your lack of efficiency. It's matter of order building, collect money and then wait. Rinse, cycle and repeat. This can be said for every single of those games in those formats and is what I call preventative gameplay. Where a game actively tries to stop you from playing.

Another notable example is CSR Racing, a game in which you participate in drag races against other AI controlled cars. Each race requires a certain amount of fuel and you start off with around 10 units of fuel. Each race results in credits which you can then spend upgrading and buying new cars so that you can win bigger and better races, thus rewarding you with more credits. The main gripe I have with this game is the 10 units of fuel limit and the inability to just play races for the fun of it. If I use up all my fuel I have to pay real money to restock or wait through the timer. It's not like I can even play skirmish races that don't result in extra money but allow me to hone my skills. Of course, developers have to recoup their costs somewhere but I don't think it's fair for a game to advertise itself as free-to-play when in reality it's free-to-play (for a bit). It's not impossible to take this model and make it work.

Look at all those races I can't play 

Take for example World Of Tanks, a free-to-play tanks battling game much in the same way as CSR Racing has cars in it's garage you are instead filling up your garage with tanks. The main notable difference I find with World Of Tanks is that it does not restrict you from playing the game. At no point does it actively stop you from playing and ask you for money. Each tank battle nets you credits and before you head out into the next battle you need to repair and rearm your tank with credits. The amount you earn from a battle, even if you lost is usually more than enough to recoup the costs. I'm pretty rubbish and my tank finances are still in the black. Now is this model so hard to do? One of the incentives that the wargaming.net team always said was paying allows you to progress faster through the game. Double XP/Credits plus rarer tanks (which don't necessarily mean superior). Even other mobile games like Zombie Gunship don't stop you from playing just to ask for money. 

Not a single fuel indicator in site

There are many notable games out there that follow this free-to-play model that I would be more than willing to invest money into and have already done so in the past. Games such as Hawken, Age of Empires Online, Planetside 2, World of Tanks and Firefall stand at the forefront of my mind. Even notable games such as APB and Star Wars : The Old Republic switched from being subscription based to the free-to-play model and have been just as successful if not more so than in the past.

I think showing the player what they could get for subscribing but not forcing them too is always good.

The thing to note is all these games I have mentioned are PC games. Even Runescape and MapleStory are PC based games. Where are all the mobile games? Who knows my friend. Currently on my mobile device I have these free-to-play games; Zombie Gunship, Curiosity, Jurassic Park Builder, Showdown, Checkers and Wordament. Of all the games in this lot the only one I would put money towards are Checkers and Wordament and for those two I can't even work out how.

Do I think free-to-play is bad? Of course not, just certain ways companies and marketers push it out there harm it's effectiveness, sometimes even to the detriment of the game itself. This is what I think needs to change in free-to-play mobile games.

---

Email : markmmiller@hotmail.co.uk
Xbox Live : Dr Death MK 2
Steam : 7thsanctum
Follow @7thsanctum

Unity - Trail Renderer (with colliders)

Hey guys, just a quick post to show what I'm working on just now. I really ought to be doing some coursework but that's just no fun sometimes. 

So I was poking about in Unity and noticed that they have something called the Trail Renderer which acts like a particle effect that is produced as an object moves and leaves behind a trail. Simple stuff eh?

More info can be found in the Unity Documentation.

So after reading about this and trying it out with just basic colours my first thought was Tron! This inspired me to try and recreate the famous light bike scene from both the original and the recent sequel. Sadly though the light trails have no native colliders which made things a tiny bit more difficult. Instead of just leaving it at that I started adding in box colliders so that collisions with the light trail can be made easier.

Figure 1. Light Trail with Colliders

 As you can see, I'm currently finding it difficult to match up the length of the trail to the length of the trail of box colliders! Currently I have a few ideas how to match it up which I have yet to implement but another easier solution would be to just get rid of the light trail entirely and replace the code I have with textured boxes. I've yet to decide which technique will be better for this.

Figure2 . Close up of the trails Colliders still need resizing.

Anyways it's still a work in progress so I'll post updates when I can. You can find the latest version of this prototype on my Unity blog.

Also check out the following video which inspired me to make this :

---

Email : markmmiller@hotmail.co.uk
Xbox Live : Dr Death MK 2
Steam : 7thsanctum
Follow @7thsanctum

DirectX - Particle System

Currently working on particle systems and creating fire with smoke effects in DirectX 11. Things are coming along slowly but looking good so far.

I still need to implement fire as well as porting this to the geometry shader.

Check out this video for it in action.

Make sure to check out my OpenGL coursework from last year and stay tuned for more unity updates. I've also uploaded a new idea I'm working on in Unity to the Unity dev blog so check that out too!

---

Email : markmmiller@hotmail.co.uk
Xbox Live : Dr Death MK 2
Steam : 7thsanctum
Follow @7thsanctum

SIE App Jam Day - Super Trolley 2

On the 27th of February I participated in the very first App Jam hosted by the Scottish Institute for Enterprise at Napier Univeristy. The task was to make an application for mobile devices in less than 9 hours.

I decided to make a game in which you had to run around a supermarket and try to cram as much stuff into your trolley as you could within a certain time frame. (If you've ever seen Supermarket Sweep you will understand where the inspiration comes from)

I developed the game in Unity3D with the aim to get the core gameplay elements in and then port to Android. Since I didn't have much time I avoided spending too much time in sourcing or creating assets, instead finding the main items free online. I figured getting the game playing well was most important.

Figure 1. The Player's Character.

After setting up the scene and setting up a system for spawning different items along the shelves I had to create the player. My original plan was to have the player attached to the trolley via their hands, left clicking with the mouse would lift up the left arm and right clicking the right arm. This would mean that the player had to maintain control over the trolley whilst trying to swipe as much stuff off of the shelves as possible. Sadly though I couldn't get the arms acting the way I wanted in the time I had so I instead opted to attach the player to the trolley through the use of a spring and have the arms fixed in place, extended.

Figure 2. The player after collecting lots of items

After trying to get the arms working which was my main goal, I realised I'd spent too long on this part which meant other parts of the project suffered. I finally added in a method of counting up the players score and measuring time. The game so far includes 2 items but adding more won't be too difficult.

I have many places I wish to improve this game, people at the Jam seemed to enjoy the parts they played despite numerous glitches so I will work on this some more when I get a chance to. Hopefully with more time I will be able to get the arms working!

Anyways that's enough from me, I haven't slept enough over the past few days so I better catch up this weekend. See you guys next time. 

Oh and here is a quick gameplay video where you can see how it works as well as numerous problems, I will upload a version for webplayer soon when I get some of the problems fixed.

Also thank you to Darren Whigham for organising this event check out his twitter here for some cool game development stuff. Thank you also to SIE as well as Informatics Ventures and Codeplay for attending.