Welcome to my Games Development blog! Here you can expect news and updates on daily life at university and any ongoing project work.
Thanks for looking and feel free to ask any questions you have.
A couple of interesting things, firstly I have registered the markmmiller.co.uk domain name so this blog can now be found at blog.markmmiller.co.uk. As well as this my main site is still a work in progress but I have been experimenting with Linux and have set up a Raspberry Pi to act as a web server for hosting. Again the main site at www.markmmiller.co.uk but if you head over the site is being hosted from my Raspberry Pi as we speak!
In other news I applied for the Nvidia Academic hardware donation program a few weeks back for a GPU to help with my research into parallel programming and to much surprise I managed to get approved for a GTX Titan. The Titan finally arrived today and, for once, managed to install it without too much bother.
Figure 1 - GTX Titan
Figure 2 - GTX Titan
This was a significant upgrade to my ageing GTX 460 so hopefully I will be able to levy a lot more performance in my applications and I will attempt to benchmark both give a comparison of the performance gap between the two. Although the Titan isn't a mid-range card, hopefully it is an indication of the levels of performance that will become mainstream in years to come.
Figure 3 - MSI GTX 460
The other thing I have recently embarked upon is altcoin mining, mainly Dogecoin for now. With my GTX 460 I managed to achieve a 120 K/hash rate but the Titan on the other hand doesn't work with my app so I shall update when I find out. As for the temperature, both the Hawk and Titan are running around the same temperature idle but currently the Titan is having trouble turning its fans on when it gets hot. I will look into this later. Anyways, I shall get to bench marking soon but first is a matter of installing the programs. Check out the photos below to see what it's like in the case!
Figure 4 - Case Interior
Figure 5 - Titan Closeup
Be sure to click on the above photos to see them in HD. Anyways, back to more University and Honours project work for me, I'll update you guys soon!
Email: markmmiller@hotmail.co.uk
Xbox Live: Dr Death MK 2
Steam: 7thsanctum Follow @7thsanctum
Origin: 7thsanctum
Youtube: 7thsanctum
Github: 7thsanctum
Over the weekend I participated in Global Game Jam at the Edinburgh jam site. The goal was to make a game in 48 hours, starting at 5pm on the Friday with a deadline of 5pm on Sunday. The secret theme this year was a quote from Anais Nin, "We don't see things as they are, we see them as we are". After the theme was revealed we had some time to band together with everyone else at the event and come up with some pretty interesting and wacky ideas. Some people decided to make platformers where everything in the world was not as it seemed, others worked on an Oculus Rift horror game and several awesome ideas were thought up and discarded quite early on.
One of the ideas I pitched was a game where you play in a standard FPS view against other players and the goal is to eliminate the other players. The main feature though was that at the start of the game the views of all the cameras are switched so that you would then be looking at another players view but you would still be in control of your own body. Through this 2nd person view point you then had to kill the person who had your eyes to retrieve them. Although this idea sounded quite interesting at the time it proved to be very complicated to play initially for many of the play testers. The gameplay itself when it worked was very good, mainly when two players who were trying to eliminate each other were looking at themselves and trying to take out their own view port. Sadly more often than not players would end up wedged in walls and completely stuck.
In the image below, Player 1 would be looking at the top left quadrant which is the camera view of another player. Their objective is to then work out which of the other bodies they are controlling and finally eliminate the player whose eyes they are looking out of.
Figure 1 - Original Game Idea
On the final night however we decided to add some alternative experimental game modes as we managed to get the initial game completed quite early. The first of these was a crowd hunting game, you play as a robot, mingling hiding in a crowd of other robots and your job is to find the other human player in the game who is also a robot and is also attempting to hunt you! This idea came about from one of the original ideas we had for the game which was that of crowds of NPC robots making it more difficult to spot yourself. After implementing them however we realised that it was actually more fun trying to spot others at all when people were trying to hide and blend in with the robots who were in the crowd.
Figure 2 - In-game Screenshot
Overall many lessons were learned over the course of the jam. The main one was that humans cannot survive (and functional optimally) for 48 hours on purely chocolate and water. The other was that, it doesn't matter if your idea changes from what it was initially and new ideas that you come up with along the way shouldn't necessarily be restricted.
Anyways, although what my team and I made was not the most polished looking game it was a pretty interesting concept that we managed to make up in a relatively short period of time. Check out the video below to see a game in action.
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.
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.
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.
