NeverSayNeverPlay

[normowertest]

[normowertest]

Speeds key

After revamping my control system a number of times I have finally decided that I will use the triggers to initiate a force based on the direction of the corresponding analogue stick. I originally had a mana/power system in the game but opted to scrap it as I want to encourage the player to go as fast as I can. I have not place a cap on the max speed, instead have made the level incredibly difficult. I have noticed that due to the enormous speed you can pick up at some points you travel faster than the game can detect a collision, at first this irritated me, but as I have played more I am deciding to leave it in for now as it is essentially luck whether you skip the collision and again its another reward for high speed. I placed jumps within the level in order to force the player to pick-up speed, I also made the track very long, while you could travel slowly you wouldn't get very far and it would be rather boring.

I have opted to just use the vest on collisions as this seemed the most natural and most appropriate method in this style of game.

[normowertest]

Don't Hate, Rotate!

Formally known as QWOPDroid.

So after a bumpy and rushed development its looking like we're starting to wind down and wrap up. This post will look into some of the difficulties we faced and some of the fixes we had to implement. When creating the asteroid field, we needed to set a random position to spawn them at, however as the time gap between this random number being generated was so small quite often it would generate the same number for all the asteroids. To solve this issue we created a list and added a set of numbers to the list. We then choose the first number in the list for the x position and the last for the y position and then shuffled the list so that the next asteroid would have different values (granted there is still a chance of it being the same, but this is very small). This does mean that there are a finite number of positions that the asteroids will spawn, it provides enough variation so that the player will not recognize.

Originally are input layer only used TouchEvent.ACTION_DOWN and TouchEvent.ACTION_UP  When a finger touched the screen it would detect its position and determine which button it was on and add 1 to that colourCount. When a finger was lifted from the screen it would detect the position and determine which button it was on and remove 1 from colourCount. The problem with this is that it did not take into account movement of the finger when down. So I changed it to: switch(pSceneTouchEvent.getAction()) { case TouchEvent.ACTION_DOWN: colorList.set(pSceneTouchEvent.getPointerID(), checkColor(pSceneTouchEvent.getX(), pSceneTouchEvent.getY())); break; case TouchEvent.ACTION_MOVE:

colorList.set(pSceneTouchEvent.getPointerID(), checkColor(pSceneTouchEvent.getX(), pSceneTouchEvent.getY())); break; case TouchEvent.ACTION_UP: colorList.set(pSceneTouchEvent.getPointerID(), null);

break; }

(apologies for horrible formatting)

Then in the update function the colourCounts are set to 0 and check the list each frame.

A major problem was caused by trying to attach the engines to the main ship body. We had them attached as a child to the ship, but this then caused the body(physical component) to be incorrectly positioned. We managed to fix this by attaching the engines to the scene and using a weld join to attach them to the main ship body. Due to the nature of these joints it also offered a nice bounce effect on collisions.

[normowertest]

Back to the drawing board...again

So with another prototype not giving the me results I was hoping for and the deadline date extremely close, I'm in a bit of a pickle. I have decided to create something that's less grounded as the vest doesn't offer the realism I'd like.I enjoyed how the used the vest as means of determining the direction of an object by creating a "rain" style feedback system that points towards it.

I want to create a movement system based on magical pulses and individuality controlled arms, I will use the Xbox360 so that I can use the dual analogue systems and I feel that squeezing the triggers feels better than pressing a mouse or keyboard button.

[normowertest]

Another Failure

I have started to create a scene in which the player must cut off their own arm, in order to create a more immersive scenario I implemented the use of an Xbox360 controller using Xinput. This allowed me the use of the vibration as well as the analogue triggers which offer an input that has is more representative of actual actions than a digital button and provide me with a value based on the amount the trigger is down.

I needed to create an audio system that would cause the player discomfort,  I used freesounds.org and gathered a few clips. I then edited these to extract the sound I wanted and create looping tracks or adding fade ins/outs. I had two categories of sound: Gore and Cutting. For the gore effects I had an audio file play on loop when you started cutting and used a co-routine to play other sound clips randomly that I had put into an array.  The main loop was significantly longer to make than the other files to make loop less noticeable.

For the cutting sound I also started a looping audio for the cutting sound this was also interspersed with other cutting sound randomly played.  To make the cutting sound more responsive I adjusted the audio pitch based on the value from the trigger and I adjusted the volume using a lerp that's position was affected by the triggers position also. I then added  breathing audio, this was a simple breath in/ breath out. I had this play in a co-routine with a delay instead of looping the audio. As you got further through the arm this delay would decrease and the audios pitch would increase. In order to incorporate the vest I used a similar system to the breathing audio, as the pain increased i reduced the delay between pulses. Then halfway through I started another co-routine to send pulses to the other front valves randomly and the delay on this decreased as it progressed to the maximum pain. This however did not provide me with the results I wanted, the main problem is that your very aware of the vest at all times and this pulls you out the experience. Also as the game is audio based the noise made by the air compressor is very distracting and again pulls you out of the moment.

From this and my previous prototypes I do not feel that the vest is suited well for these type physical interactions, as you only have a small degree of control on the valves it does not work well for subtle touches or constant contact. 

[normowertest]

Gameplay in the way of the game

I was jotting down ideas of where to take Exoculo[working title] and was thinking how the game actually lacked gameplay, so naturally I was thinking how can I make it more gamey? I then started thinking about Bioshock infinite and how while I love the game, its actual game like qualities made the overall package suffer, nothing pulls you out of the moment like searching a bin for cigarettes and apples(depending on the game of course). I then started thinking about what the vest actually provided me and what is unachievable without the vest. For me it was all about the experience, the vest provides the opportunity to really give the player a sense of belonging in the game world, a sense of realism and vulnerability. Unfortunately tech like this is normally is usually placed in unimaginative horror games built purely on jump scares. When thinking of a situation that the vest would truly enhance and bring to life my mind let me to think of 127 Hours. I won't spoil anything in the movie, but I thought about how managed to evoke incredibly agonising feelings and wanted to capture similar emotions. The lack of sight and knowledge of physical feedback put the player in an unusual situation, I wish to exploit this by creating an atmospheric game that plays on this. To clarify this is not a horror game, but an attempt at created situations that provide heavier weighted situations for the player to interact.

***SPOILERS (from 127 Hours)*** Inspired by the film I will create a demo in which the player must remove their arm in the game, I will be using the feedback from the vest, the vibration from an Xbox 360 controller combined with sound effects and voice acting to create a demo that hopefully works as a proof of concept piece. I will also include a segment where the player has control of their locomotive movement to demonstrate the deeper immersion in other situations.

***SPOILERS***

[normowertest]

QWOPDroids Android

As we had put Space Race on the side line we needed a new idea for an app/game, as I had a working prototype of QWOPDroids working on unity3D on my desktop I showed them it and suggested that we use this for our android project as its simple and would work well on a tablet.

The group agreed and we got work looking at engines/frameworks we could use to create this. Initially we looked at Cocos2D for android, however after a few hours of hassle as it was an unofficial port that had no documentation we decided there most be a better way. Another member of our team discovered AndEngine, this offered us exactly what we need and seem quite well made. When discussing the games visuals one member suggested using flat colours and basic geometric shapes, I was sceptical, but looked around at other examples of this (140). This eased my mind as it looks stunning he then drew a concept screenshot, while it looked good it lacked vibrance, as the engines are red, yellow, blue and green few other colours offset it. The background was black and the "asteroids" were different shades of grey. While we were creating this another member suggested that the engines take damage separately, i then suggested that we colour the asteroids the same as the engines and allow the player to bounce away a matching colour asteroid.

We were discussing potentially having health to each engine and that they could be destroyed. I remembered a post I was reading by one of the designers for LoL and I remembered them mentioning "Fun Fails to Exceed Anti-Fun", I was worried that if an engine could be destroyed that you could have instances where a player is out of the game and has to just wait around for their friends to die. A few mentions of having revive collectibles were mentioned but this idea was scrapped. 

I instead proposed making the game more of a score attack where the game only lasts for a minute or so and the player tries to amass the highest score in that time. This felt like it would fit a mobile device better as it provided short bursts of gameplay and provided a quick outcome/reward(high-score). To further increase the challenge to the game we decided that if an engine is hit by a none matching colour it is disabled for 2 seconds(subject to change) and further more for each second an engine is active it provides points. One of the big talking points at the moment is how the controls are going to work, however I will create another post for this, as this one is already quite lengthy.

[normowertest]

Space Race Postponed

Unfortunately as we are uni students,some of our work has to be based around deadlines and the importance of each assignment. As this is a 10 credit module and we can meet the assignment goals with something far less time consuming we are changing the android project. As for the future of Space Race(really don't like this working title) it's something that I hope can come to life at a later time potentially over summer, this may be with the team that I was working with or as a solo project, only time will tell.

[normowertest]

QWOPDroids Prototype

I have made a quick prototype the idea is that each of the four players will use a set of 2 buttons to control a specific engine and will have to communicate to decide which direction to travel and therefore which engines to fire in what direction.

I am currently working out the design for a scoring system, I am thinking of having you earn points for surviving and placing collectibles that give you a big score boost to encourage movement. However these are just thoughts at the moment and I am still working out all the details.

[normowertest]

QWOPDroids

So basically this is an idea of taking the QWOP style mechanics in which individual joints/limbs need to interact with each other and creating a multi-player asteroids style game. A ship will have four engines attached to it each capable of firing up or down, if one is fired on its it own it will cause the ship to spin,if the correct two are fired it will move the ship (like how rowing works).

[normowertest]

Space Race

As we wanted to keep the number of players to 4 people we decided to use the roles Engineer, Mechanic, Pilot and Combat Tactician.  (Ignore that its an IPad)

Engineer: Manages and distributes power to the other departments of the ship.

Pilot: Controls the left and right engine to fly the ship.

Mechanic: Controls Robots that are sent to fix damaged areas of the ship, may also close of areas due to fire or hull breaches. (Ship shape no decided so mock up has not yet been created)

Combat Tactician: Controls the shield and weapons of the ship.

[normowertest]

Little teaser trailer for GliTCH, sorry its short on gameplay.

[normowertest]

Android Project

As another uni project were tasked with create something that does something on android device, this is a group project. As we are all computing and games development students its only natural that we want to create a game. After some discussion we have come up with the concept of a multi-player game that requires players to team up and become the crew of a spaceship. One player for example will be a pilot while another is the engineer. We looked at similar games on the market and two stick out:

Spaceteam

ARTEMIS

The game will aim to find a balance between these two games by offering more depth than spaceteam and have faster gameplay than ARTEMIS and most importantly none of these are on Android.

[normowertest]

What's Next

As I left many things to weekend before the deadline, it meant that lots of implementation was going to take place on the Saturday and Sunday. As luck would have it I spend most of my weekend very ill, so I thought I would use this to talk about features I wish to implement in the future and improvements I wish to make. I would like to create more levels aimed at specific mechanics so that I can introduce mechanics slower than I currently am. I would also like to create graphical representation for all tutorials, as people are more likely to pay attention to these. The UI is not at a place where I am happy with it, it displays necessary information, but frankly it is unattractive and pulls the player out of the experience. By creating more levels I would like to have a level unlock system that would work on the total number of stars accumulated, this would mean that the player couldn't simply one star every level, however wouldn't force them to 3 star a specific level they found difficult.

[normowertest]

Adding Mechanics

Taking into account feedback I have received, I wanted to add different type of ball(platform). I decide to add one that had a gravity effect it, however I found that this would cause it to fall far to quickly. I decided to use rigidbody.addforce() as this would allow me to have the ball fall slower.

[normowertest]

[normowertest]

Keeping it Open

Having watched a number of people play test my game for me, it became apparent that many people were finding solutions to level that I had not intended. Instead of closing these off, I have decided to embrace them. I am now trying to create levels that can be completed in more than one way.