Dissertation time!
I am currently trying to get my head in a place where I can begin researching (properly, with references) and writing my dissertation, and thus far I do have a very loose subject matter and some ‘chapter’ titles I want to cover – but to get myself in the mood for talking about a very specific subject, I thought it would be healthy to try and talk about what I want to get across here.
My dissertation is looking at the creativity that can come from freedom within a game – be it trying to distort the physics in a simple puzzle game, or organising trips across the land instead of slaying demons in your favourite MMO.
(Sidenote: If you are like me, You would instead play ‘Smash Bros’ and ‘Mario Kart’ and use the characters as toys, giving them little voices and such, instead of racing and fighting!)
In the same way that children can create all manner of games from something as simple as a few chalk lines or a ball and some jumpers – can such a thing be accomplished in game? And if it can, should it be designed, or should it be left to the end user to look at what they are given and say “I want to drive around following the rules of the road – instead of mugging hookers and squishing old ladies.”
The players creativity can come from simply projecting their own narrative onto a game – and often this can be distorted when that cube you’ve named ‘Cindy’ and asked to marry you is ordered into the furnace by an unfriendly voice from above.
The way I am currently looking at it is that it shouldn’t be tampered with – users, especially in groups, will always have their own ideas of how to play. Cheating, not cheating, agreeing on certain rules or simply competing in something as trivial as ‘Who can climb the highest.’
Design can adapt to include such elements, and perhaps incorporate tools to simplify such activities, or perhaps create a tool create new possibilities, but without letting people play the game, you don’t know quite how people will take to a particular mechanic, object or environment and make it their own.
Monday 14 November 2011
Wednesday 9 November 2011
The one with the waggly tail
In the spirit of chitchatting about stuff I haven’t done before/prattled on about here, today I will be covering something that gave me its own special brand of trouble.
Opponent characters!
Opponent characters!
This is a Guard Dog.
A loyal but some what moronic individual that patrols the many allotments of Bunny Robber – obviously because of the outbreak of thieving rabbits.
The problem was that I needed the character to follow 8 pre-set paths.
Presumably I could use Unity’s ‘path’ system to control its movement, and give each its own unique path – but this was not something that allowed for a great deal of speed, for two reasons.
1) I would have to create an individual path for each guard Dog.
2) The animations would have to be tweaked for each
motions such as turning corners would be at different times for different paths, and unless the speed could be controlled (which would presumably take a lot of tweaking to get it to be uniform) – The walk cycles would move at the same speed while the character moves at different speeds.
The solution? Animation!
Each of the 8 paths where fully animated – the timing was right, and this would mean I would simply have to change the animation preset on the model in Unity.
The extra benefit of this is that parts of the level can all be uniformly sized – making the creation of new levels fairly quick.
Monday 7 November 2011
Yup, it’s me – the guy who hasn’t posted in a while. To all my billions of loyal fans, I’m sorry! I’m still making you some good games though, of course. I’ve not posted much for two reasons – the first being that as far as I know, this is no longer a submission requirement, and the second being that I don’t wish to repeat myself.
As I’m still working in the Unity engine, I’m not doing anything new, but I am instead doing it better. Quicker, sleeker, and nicer looking.
To appease you (My billions of fans.) – I will tell you what I HAVE been earning, what’s new! The brand new little extras to add the sleek awesomeness to both of my games.
Custom Shader
For my Stealth game (Now ‘Bunny Robber’) – the style I wanted couldn’t be achieved from the default materials available in Unity, or even by using the texture.
As such, I created a “Shader” – Essentially a material. Starting with a simple flat shader (A toon shader – A brightly coloured look) I had it so that it would respond to light. (This was so that it would darken to help suit the mood) – Where a flat Toon shade stays its colour no matter what colour the light is, a lighted version would adapt. Next up was the shading – the option was no shading what so ever or hard lines for the shading – but also there was an option within the shader to assign a secondary texture to map the lighting – assigning a subtle gradient here gave my models a soft shade to it, giving them smooth edges.
The final problem was making the shader “Two sided” – some of
the plant life in my level was made from very few polygons, so when rendered with a one sided material, it would not appear as it should. Again, this was solved with a custom shader.
Curve of difficulty
With the skipping game, I changed the demo, in which the rope remained at one speed, the current version has a rope that gets progressively quicker before it settles on a top speed.
The problem with this is that when testing, I had a lot of trouble with a low speed, so when trying out the top speed, while it may have been too difficult for me (Or too easy once I had experience) other people may find it incredibly easy.
Deciding no the top difficulty – and settling on something that is fair (and possible.) but wile still presenting a challenge has been hard, and as such the demo was given to several guinea pigs, and found a difficulty that was suitable.
While the top speed may now be quite possible, and not as hard as I would like it, making it just two frames quicker makes it quite impossible – the rope turning quicker than the character jumps.
Working for a target platform and exporting to iPhone
While the touch screen controls gave me a lot of trouble near the start of the project – Actually exporting it to the iPhone has proven to be a completely different kettle of fish.
Everything from Licencing issues to well… other stuff that I can’t seem to identify to repair.
Each attempt has bought me one step closer to testing the game on the iPhone – I’ve been able to get a simulator working to at least test the graphics scaling and resolution size – but it seems that the world is dead set against it working on the actual iPod touch.
Anyway – That’s enough for now, I’m writing that having just watched all my decorated levels crash in Maya and become unusable. Good thing I had backups!
Monday 10 October 2011
Design Sandwich. (Development Pipeline)
(This is mostly meant as advice for anyone hoping to use Unity and not knowing where to start!)
Being on my second and third games, I now have a good idea of what order to do things in, having gone into my second semester game without a clue and having to continually go back and change thing, I learnt what was important to do and when.
To better explain my idea, I will use one of the games I am making - “Bunny Robber” as an example.
This is of course the way I do it, it may not be the BEST way.
Initial mechanic
The most important thing after designing a mechanic is making sure you can make it work. In its simplest form, being able to interact with certain objects in a certain way and have them causing a desired effect.
In the instance of Bunny Robber, this was the initial demo I did with the other 5 games. No texture of fancy 3D modelling here.
Player, controls and camera
Now that the nuts and bolts of the game are working, it is time to get the player character in, make sure that specific animations can be triggered at the right time, have it look good, and be sure to clean up any issues it may have slotting into the mechanic.
This also informs the rest of the design, both puzzles and environment.
Blockmap and important 3D assets
Now that the character is moving about and the game works, it is time to make some test levels. The initial demo should give you some idea of what works and what doesn’t, but this will allow you to stretch out and begin adding other mechanics if you wish.
As well as this, one of the MOST impotent things I found was to not use “test” models, and instead use final assets.
My guard dogs for example have been fully animated and their hit boxes organised. This allows me to design the level around them and means I do not have to keep going back to keep doing more (But if there is something else I need, I can add it in.)
Another example of this was in my first game, the blocks that where pushed. I modelled and textured it then added all the code and animation triggers to it. This meant I could simply duplicate it and had an accurate idea of how my character and obstacles and objects would work in the block map.
Menu system and environment
Ideally, the transition between scenes should be working with the block map – but here you implement and decorate the various game over and front end screens. (And if you have one – the GUI)
The environment should also be properly implemented now – Lighting, props, floors, walls and even the sky all need to be here to give a well finished game.
IF you are feeling particularly smart, you could even add sound!
Being on my second and third games, I now have a good idea of what order to do things in, having gone into my second semester game without a clue and having to continually go back and change thing, I learnt what was important to do and when.
To better explain my idea, I will use one of the games I am making - “Bunny Robber” as an example.
This is of course the way I do it, it may not be the BEST way.
Initial mechanic
The most important thing after designing a mechanic is making sure you can make it work. In its simplest form, being able to interact with certain objects in a certain way and have them causing a desired effect.
In the instance of Bunny Robber, this was the initial demo I did with the other 5 games. No texture of fancy 3D modelling here.
Player, controls and camera
Now that the nuts and bolts of the game are working, it is time to get the player character in, make sure that specific animations can be triggered at the right time, have it look good, and be sure to clean up any issues it may have slotting into the mechanic.
This also informs the rest of the design, both puzzles and environment.
Blockmap and important 3D assets
Now that the character is moving about and the game works, it is time to make some test levels. The initial demo should give you some idea of what works and what doesn’t, but this will allow you to stretch out and begin adding other mechanics if you wish.
As well as this, one of the MOST impotent things I found was to not use “test” models, and instead use final assets.
My guard dogs for example have been fully animated and their hit boxes organised. This allows me to design the level around them and means I do not have to keep going back to keep doing more (But if there is something else I need, I can add it in.)
Another example of this was in my first game, the blocks that where pushed. I modelled and textured it then added all the code and animation triggers to it. This meant I could simply duplicate it and had an accurate idea of how my character and obstacles and objects would work in the block map.
Menu system and environment
Ideally, the transition between scenes should be working with the block map – but here you implement and decorate the various game over and front end screens. (And if you have one – the GUI)
The environment should also be properly implemented now – Lighting, props, floors, walls and even the sky all need to be here to give a well finished game.
IF you are feeling particularly smart, you could even add sound!
Wednesday 28 September 2011
Settings & Characters
In the last two weeks, as you can probably guess, I have narrowed down my choice in games, as well as chosen a theme (Designed several options too..) and begun creating the final assets for the game.
What game did I pick, you ask?
Well, it would appear the fan favourite was…
*Drumroll*
Skipping game!
Yea, I didn’t think that would happen either, but as I’ve always said, my worst ideas turn out to be my best. (Crazy Cubes and Paradox pals – both of which none of you will recognise.)
BUT WAIT! There is more.
With that being a relatively tiny game, I have been told I need to create something that allows me to design levels. So congratulations to runner up Stealth Game – You will also be bought into existence!
Now, having said that, a theme had to be picked.
Skipping game was given some consideration, and the schoolyard theme has been stuck with – however I will be re-creating the characters and improving on it. (Improvements discussed next post.)
Stealthy game was harder – The man with the plan, Josh (Tutor. I realise all my readers are fellow game designers, but at least let me PRETEND someone else is reading.) suggested to me that it would be best to see a stealthy game that didn’t involve shadowy corridors and a glowing green visor in a bank vault.
And after much deliberation – Bunny Robber was born.
Want to see the unused characters? Here you go:
Yup. Ugly. Well here is the low poly characters that will be the starts of my games.
And in case you like the style I have rendered them in, here is me reproducing the same look in Unity. (In the form of a low quality Jpeg.)
What game did I pick, you ask?
Well, it would appear the fan favourite was…
*Drumroll*
Skipping game!
Yea, I didn’t think that would happen either, but as I’ve always said, my worst ideas turn out to be my best. (Crazy Cubes and Paradox pals – both of which none of you will recognise.)
BUT WAIT! There is more.
With that being a relatively tiny game, I have been told I need to create something that allows me to design levels. So congratulations to runner up Stealth Game – You will also be bought into existence!
Now, having said that, a theme had to be picked.
Skipping game was given some consideration, and the schoolyard theme has been stuck with – however I will be re-creating the characters and improving on it. (Improvements discussed next post.)
Stealthy game was harder – The man with the plan, Josh (Tutor. I realise all my readers are fellow game designers, but at least let me PRETEND someone else is reading.) suggested to me that it would be best to see a stealthy game that didn’t involve shadowy corridors and a glowing green visor in a bank vault.
And after much deliberation – Bunny Robber was born.
Want to see the unused characters? Here you go:
Yup. Ugly. Well here is the low poly characters that will be the starts of my games.
And in case you like the style I have rendered them in, here is me reproducing the same look in Unity. (In the form of a low quality Jpeg.)
The Old (and mostly scrapped) game ideas
Ok, I lied, I can not be bothered to post every day about my games (Also, I missed yesterday) so instead I will sum them all up in one Giga-post before rounding off my first week with an update as to where I am now that I have begun the year.
Runny game
Probably the earliest of my ideas – this one came before I had even created the touch screen controls.
The basic idea of this game is that you gain immense speed after a few seconds of moving. As a whole, this works quite well, but in terms of game play, the world would have to be HUGE and incredibly open.
Not only that, it is a basic mechanic, several additional mechanics would need to be added to make even one level. (For example, an objective, an opponent of some sort, types of obstacle)
Floating Game
Originally this concept was more complex – you where a balloon that would inflate and deflate as you hit things, sort of like a primitive ‘life’ system’
Of course, this was not to be, as I do not know how to make a counter work, and I do not know how to have that influence the size/speed of an object.
As it stands, the game is still about not hitting anything, with numerous traps designed to throw you off.
While these are neatly summed up in the documents for submission, they basically consist of things to block your view, things to influence your movement, and boody-traps.
Also, I designed a whole 3 minute level for it!
Skipping Game
Probably my least favourite, this game constitutes two simple things. a constant animation (A rope) and a button to play an animation (Jumping the rope).
This is ridiculously simple - a collision between these two ends the game.
As you can tell from my tone, this isn’t my favourite - but the ability to quickly restart the game, and the addictive nature of continually trying to top yourself might be just what I need for an iPhone game.
The potential to expand this isn’t particularly great - Skipping only has so many variations, really.
In case your wondering where the idea came from? Press button, play a jump animation - simple? Yes. Genius? Who knows.
Stealth game
This idea came to me when I created my second semester game – it is basically a series of moving triggers that the player must avoid while trying to achieve whatever it is the levels aims are.
This game is good, but the controls gave me a few problems (Notably the character walking straight.)
Ideally, I would love to make this a ‘Break out of prison’ game or something similar, but at the same time I don’t want to create anything too dark like I did last semester.
This gives me a lot of scope for level design too, but at the same time the controls and camera would make it feel a LOT like my second semester game.
Flip
A miracle of my Unity ingenuity, this is a game I would be tempted to produce on my own if I do not take it forward.
The idea is simple. A button flips gravity so that you can either walk no the ceiling or the floor.
From the demo I built, I realised the puzzles I concocted where too easy and too linear – but this was designed before I knew the specifics of how the mechanic would work, as I had planned for it not to work as intended. (But then it worked flawlessly, and here I am.)
Torture
More "App" than "Game" - This interactive man will respond to 'touch' – and in doing so, it simlulates the character being hurt.
The very basic version I made has the man simply stood still and playing 4 animations, but in an ideal world he would respond to touches in all sorts of places, and move when he is idle, and even be able to be ‘made’ into a person you know using the iPhone camera.
As I said – this isn’t really a game, and offers nothing in the way of level design. If I where studying realistic animation, I would use this to present my work maybe.
Gingerbread man
Almost identical to the Floating game in every way, except for the fact that you run along the ground and the camera perspective e is different. This game has the player running away from (something) towards the camera and avoiding obstacles as they pop up.
The design of this is somewhat simple, but like floating game, could be adapted to have different obstacles. In terms of levels, it could be quite broad.
The issue I had here was the feeling of speed – the man felt like he was strolling slowly towards the camera instead of fleeing from a fox.
Licensing may also be an issue.
Online versions of the links to follow!
Runny game
Probably the earliest of my ideas – this one came before I had even created the touch screen controls.
The basic idea of this game is that you gain immense speed after a few seconds of moving. As a whole, this works quite well, but in terms of game play, the world would have to be HUGE and incredibly open.
Not only that, it is a basic mechanic, several additional mechanics would need to be added to make even one level. (For example, an objective, an opponent of some sort, types of obstacle)
Floating Game
Originally this concept was more complex – you where a balloon that would inflate and deflate as you hit things, sort of like a primitive ‘life’ system’
Of course, this was not to be, as I do not know how to make a counter work, and I do not know how to have that influence the size/speed of an object.
As it stands, the game is still about not hitting anything, with numerous traps designed to throw you off.
While these are neatly summed up in the documents for submission, they basically consist of things to block your view, things to influence your movement, and boody-traps.
Also, I designed a whole 3 minute level for it!
Skipping Game
Probably my least favourite, this game constitutes two simple things. a constant animation (A rope) and a button to play an animation (Jumping the rope).
This is ridiculously simple - a collision between these two ends the game.
As you can tell from my tone, this isn’t my favourite - but the ability to quickly restart the game, and the addictive nature of continually trying to top yourself might be just what I need for an iPhone game.
The potential to expand this isn’t particularly great - Skipping only has so many variations, really.
In case your wondering where the idea came from? Press button, play a jump animation - simple? Yes. Genius? Who knows.
Stealth game
This idea came to me when I created my second semester game – it is basically a series of moving triggers that the player must avoid while trying to achieve whatever it is the levels aims are.
This game is good, but the controls gave me a few problems (Notably the character walking straight.)
Ideally, I would love to make this a ‘Break out of prison’ game or something similar, but at the same time I don’t want to create anything too dark like I did last semester.
This gives me a lot of scope for level design too, but at the same time the controls and camera would make it feel a LOT like my second semester game.
Flip
A miracle of my Unity ingenuity, this is a game I would be tempted to produce on my own if I do not take it forward.
The idea is simple. A button flips gravity so that you can either walk no the ceiling or the floor.
From the demo I built, I realised the puzzles I concocted where too easy and too linear – but this was designed before I knew the specifics of how the mechanic would work, as I had planned for it not to work as intended. (But then it worked flawlessly, and here I am.)
Torture
More "App" than "Game" - This interactive man will respond to 'touch' – and in doing so, it simlulates the character being hurt.
The very basic version I made has the man simply stood still and playing 4 animations, but in an ideal world he would respond to touches in all sorts of places, and move when he is idle, and even be able to be ‘made’ into a person you know using the iPhone camera.
As I said – this isn’t really a game, and offers nothing in the way of level design. If I where studying realistic animation, I would use this to present my work maybe.
Gingerbread man
Almost identical to the Floating game in every way, except for the fact that you run along the ground and the camera perspective e is different. This game has the player running away from (something) towards the camera and avoiding obstacles as they pop up.
The design of this is somewhat simple, but like floating game, could be adapted to have different obstacles. In terms of levels, it could be quite broad.
The issue I had here was the feeling of speed – the man felt like he was strolling slowly towards the camera instead of fleeing from a fox.
Licensing may also be an issue.
Online versions of the links to follow!
Sunday 25 September 2011
Loss of data is not a valid extenuating circumstance.
While I had intended to post about each of my 7 game ideas/concept demos each day since my last post, I have suffered a minor loss at the hands of technology.
My mouse died on me (and without a mouse, it is hard to do anything to fix it on a computer!) so I rolled back my computer 7 days – of course, all my files where fine.
This of course doesn’t account for two things.
a) any file edited recently seems to have reverted
b) Any JavaScript I had created since then has gone – but it is still referenced as a blanks script in unity
c) Any script changes/fixes I had made are also gone, back to their old broken selves.
While this isn’t such a problem, as it only dates back to September 18th – it still means I have had to go back through and fix a lot of problems. More annoyingly, the demos I had exported also went kaput, so I can not share them until I have fixed them all.
The good news? The two games I’ll be working on game out relatively unscratched (Completely unscratched.)
So while I have lost some work, I will be able to proceed, and share my unused demos with you all (all? I have what, 2 readers?) in the future!
Side note: Sequencing animations is hard/impossible.
Side note 2: I had backed it all up before the rollback, I just need to know whats missing. Mwahaha
My mouse died on me (and without a mouse, it is hard to do anything to fix it on a computer!) so I rolled back my computer 7 days – of course, all my files where fine.
This of course doesn’t account for two things.
a) any file edited recently seems to have reverted
b) Any JavaScript I had created since then has gone – but it is still referenced as a blanks script in unity
c) Any script changes/fixes I had made are also gone, back to their old broken selves.
While this isn’t such a problem, as it only dates back to September 18th – it still means I have had to go back through and fix a lot of problems. More annoyingly, the demos I had exported also went kaput, so I can not share them until I have fixed them all.
The good news? The two games I’ll be working on game out relatively unscratched (Completely unscratched.)
So while I have lost some work, I will be able to proceed, and share my unused demos with you all (all? I have what, 2 readers?) in the future!
Side note: Sequencing animations is hard/impossible.
Side note 2: I had backed it all up before the rollback, I just need to know whats missing. Mwahaha
Subscribe to:
Posts (Atom)