Changes to Final Outcome

With the game and controller completed ready for the game test tomorrow, we decided to explain the changes to our project that have differed from our original brief and specs. Overall the game and bike controller has gone according to plan and has more or less stuck to our original plans. A few changes in the types of sensors used for various aspects of the controller have changed, but the changes all still do what was intended. Our biggest change or lack of inclusion is force feedback. Originally we intended to place rumble packs under the seats and pedals, but due to time restraints this was held off as the focus was on the game and the controlling of it primarily.

The use of the Nintendo Wii remote as the handheld paper throwing control, we found that the Wii patch being used in Max/MSP supported the rumble pack inside the controller. With this integration we decided that rather than fit rumble packs to the bike itself we could use the handheld controller to provide force feedback due to the gamer always holding the controller whilst playing the game. This is where we ran into technical issues with the Wii remote.

The Wii remote is set up so that a paper is thrown using the remotes accelerometer and at a specific value a paper is released. This method proved to be successful in that when the controller is flicked the accelerated value will deploy a paper within flash. With this setup we thought we can use the values for the paper deployment and set them to trigger the Wii remote rumble pack so when a paper is thrown the controller will vibrate each time. We spent time setting up the patch so it would trigger the vibration when the correct paper throwing value was met. Unfortunately for reasons still unknown each time the accelerometer and rumble pack ran simultaneously the values would constantly change, which meant the accuracy and continuity of the in game paper throwing was failing, and became unusable whilst the vibration setting was connected.

The Flash Server also created problems in the area of force feedback in the sense that we could have set up features in Flash to communicated back to Max/MSP to trigger the vibration of the controller that would be independent of the accelerometer. However it is a stated fact from the creators of the Flash Server, that if Flash is working on any thing other than the server communication then the two way Flash to Max/MSP communication is lost and is only drawing data from Max to Flash but not back.

Force feedback is certainly a feature we wish we could have added and with more time would have. Technical issues were at fault and we couldn't risk jeopardising the games control functions for the sake of force feedback if the controls are in fact unusable.

Customised Bike

So right now the game itself if more or less complete, the sensors are all connected and tested and we have decided to give the bike it self a lick of paint. We have sprayed it a two tone colour of black and yellow. Not necessarily
anything to do with our company colour scheme or the game, but it looks a great deal more lively than it used to.

Game Progress

The majority of the in game functionality and detail had been added and tested, we are just in the process of finalising the game by adding menu screens including instructions, as well as visual feedback in the form of a 'Win' and 'Lose' screen which includes the end score of the 3 levels.

Company Launch

Wednesday saw us presenting our company to the rest of the module groups. It went well and we provided information to everyone as to who we are and what we do. The other teams had the chance to see what the demo day will include and vice versa.

Below are a couple of additional images that we have taken of the bike and game working together.

Showreel

We have put together a short 30 second clip of the game and controller working together. This is a demo version of the final game and controller setup, a few more tweeks here and there are needed.

New Website Online

So this week I have designed and put our new electric moose website online. The original wasn't really cutting the mustard and was simply a quick job to get us online. Dan suggested to us in the last meeting that we changed it to look more professional rather than student blog-esq. We went with a design that was clean and clear yet not as corporate as you would expect from some companies.

Have a look at http://electricmoose.co.uk

Meanwhile heres some screen grabs

Sensor Building and Testing

Myself and Rob have been busy the past week soldering and testing the sensors we need in order for the flash game to be controlled. So far we have finished building two volume pots that will control the bikes steering and braking function, as well as an LDR sensor with LED for the forward movement of the bike to be fitted to the bikes pedal crank.

Once we had these sensors fitted, with the help of Dan hooked them up to the iCube and into Max/MSP where we built a simple patch that would display the readouts of the values of each

sensor. From there we got hold of the flash server object for Max and with some fiddling successfully connected to a Flash application where we got the values to read from the sensors into Max/MSP into Flash. This now means that we can add the required code into our Flash game and start connecting the readouts to the required Flash Animations

Here are a few pics of our handy work....

LDR Sensor:

LED Connected to 9V Batt Snap:

Volume Pot for Steering & Brakes:

Meeting With Dan (3)

This meeting with Dan was just after our Presentation at the end of term one. He spoke to us about how the whole thing went and what our plans were next in terms of the project.

The main point Dan made to us was whether we wanted the focus of the project to be on the game or on the controller and gave us the option as to build a controller system that can run on an existing game, or continue with both game and controller. We decided to continue with both game and controller system in order to make the whole project our own.

The games dynamics were also brought up in this meeting following comments from the presentation as to how we were planning on representing the game character to that of the user on the bike. Initially our first thoughts were to create the game first person as it would be for the gamer on the bike, possibly just a shot of the handlebars and hands etc, but after some thought we realised that this would be both very difficult to create in terms of accurate perspective as well as not being able to properly judge the timing of the paper throwing. So with this in mind we decided upon a 3rd person character view similar to that of the original Paperboy. This would give the gamer much better visual feedback for timing and positing of the character as well as giving a different take on game play in the sense that you would be riding a bike watching effectively yourself in the person!

The game style in our version is to be different to that of the original. Paperboy was set on a street with standard houses, obstacles and characters as you would expect on a paper round, but we have decided to update and change the games style to that of our own. Mike will be designing the in game content with a unique look. The sound for the game is also to be provided by Mike. He is currently creating a sound application for the sound module of iDat that involves creating music autonomously so the sounds we create from this app will be included in our game, which results in not having to use third party sounds and music. It will be all original.