Showing posts with label Unity. Show all posts
Showing posts with label Unity. Show all posts

Thursday, 30 January 2014

Global Game Jam 2014 - Face/Off and lessons learned

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.


Credits:
Mark Melville Miller (7thsanctum)
Sam Serrels (dooglz)
David Strachan (Halcyon)
Kenneth Benzie (infektor)

Our game jam page can be found here : http://globalgamejam.org/2014/games/face


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

Origin: 7thsanctum
Youtube: 7thsanctum
Github: 7thsanctum

Saturday, 14 December 2013

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

Origin: 7thsanctum
Youtube: 7thsanctum
Github: 7thsanctum

Saturday, 9 November 2013

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

Origin: 7thsanctum
Youtube: 7thsanctum
Github: 7thsanctum

Sunday, 31 March 2013

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

Thursday, 14 March 2013

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

Friday, 1 March 2013

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.



Friday, 9 November 2012

Collaborative Map Making in Minecraft

So today I decided to do some experimentation with Minecraft, using it as a tool to create objects and analyzing it's potential to be used as a multiplayer map maker for games other than itself.

The building we are going to export

JMC2OBJ allows you to export segments of a Minecraft map as an .obj file. For this test I created a simple building (see above) and will attempt to export that into Blender.

Blenders Rendition of the Exported Building
Once the building has been imported to blender we can see a fairly accurate rendition of the building. Minus the correct textures. After adding normals and putting this into a format that my OpenGL program understands we can then try and run it!

OpenGL with SDL

My current application for reading in .obj files for OpenGl sucks and has no camera controls but we can see here that the building itself has rendered correctly. It doesn't have the correct shading but it is a start at least! Also, the .obj can be successfully imported into other programs such as Unity with ease.

.obj with Unity
Although this only gives us simple shapes and basic objects. using this allows us to create simple version of our 3D levels that we can explore and interact with firsts, we can then test the game without the use of artists. At a later stage we can forward these to map artists for texturing and to redo in our own visual style. 

The use of Minecraft as the tool for map creation also allows the team to collaborate on a single level whilst being at many different computers, making edits in real time and seeing the changes immediately.