Monday, 24 November 2014

end of game


Studio Work Evaluatio


Creating a prototype in BA4 has been a mixed bag of applying what I already know and new techniques in a time efficient and priority based way. The main goal was not to create a fancy looking level with mechanics tacked on, but a level/example of a game that conveys the game mechanics first, and theme second. Throughout the level there are little to no use of normal or specular maps, I just used diffuse maps to get the general feeling of the environment across to the player. By doing all this I was able to achieve a lengthy level that feels like it could be a single level in a game (length wise).
Throughout the construction of my game level I have received constant critique and feedback from friends, family and the game testing sessions. Feedback about the resource system, sense of speed and movement where all taken into account and resolved. From the feedback I’ve learned how to properly prioritise the important feedback, and cover lesser feedback that’s not so important later on when the larger kinks have been ironed out.
One of my biggest aims was to get the game to feel like the player was falling through a scientific testing facility. I started off with making the diagram of the level, showing all the points which the player will fall through. These included areas such as the tesla facility and particle accelerator. I feel these were important parts to make as they would become vital in conveying a purpose to the player’s presence. The second aim was giving the player a reason to be in the game. I did this by including the resource system. I knew the main games focus would be to make it through the level without hitting anything, but I also wanted to include something for players who wanted more from the game than just an obstacle course. The inclusion of the resource system adds risks and an extra layer to the game. If players choose to take these risks then they are rewarded for doing so.
In terms of things that where challenging in the BA4 assignment, I would say it was the scripting side. The game that I thought would be simple enough to script, ended up being one of the hardest. There were little to no pre-sets to be found on the internet, and finding resolves for issues I had turned out to need quite a large work around, never the less with the help of other student and tutors I managed to end up with a presentable prototype.
Overall this unit has been a really great for expanding the fundamentals of game design. Instead of just the visual and technical side of creating an asset/scene, there has been a lot more to now think about. It’s been a good introduction for me into the basics of designing and then developing a concept into a prototype. I look forward to developing my own projects outside of the course in the future.

Friday, 7 November 2014

Vial Counters & Speed indicator




I want to have one UI element and I wanted it to contain all the information the player needs to know. In the case of my game, the UI shows the vial amount either side of the speed indicator. This means the UI isn't dotted around the screen which allows the player to concentrate. The player only has to look at one part of the screen to get all the information they need.

Start screen





Friday, 24 October 2014

resources


These are the "resource" tokens found in the game.  the pink vial will be the speed decrease, and the green vial will be part of the point system.

Thursday, 23 October 2014

Adding Collision meshes.



This is the type of collision meshing I've been applying to my game. I've basically added very simple shapes to act as a barrier for the player and to prevent clipping. The reason I'm using simple low poly prefab shapes and not applied a full collision mesh to the asset is because adding a collision mesh to a very complex asset is extremely taxing on a systems performance.

This example is a pretty rough version of what I would like to do if this wasn't a prototype. I would later on add extra polygons for the pipes and canisters If I had more time.



Above are some more examples of my addition of collision to objects. The idea behind this obstacle is that the player hits the box collider that is hidden within the fire, since its invisible in-game, the player will assume the fire killed them, and not the collider.

Monday, 20 October 2014

WEAPON!



This is a design of the weapon (that you upgrade) that will be used by the player to destroy obstacles.