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.

Bike!

After finding out about a place at the bottom of town that sells used bikes taken from the recycling center we thought we'd better have a look and see what's available. Idea was to find a relatively small bike (BMX sized) and we did. Picked up a nice little purple and silver bike for the bargain price of a fiver!

Bike Layout Diagram

Above is an annotated diagram of what sensors and electronics will be fitted to the bike and the positions in which they will be fitted to achieve what we want the bike to do.

Scheduled Meeting (2)

Ok so we have had our second meeting with Dan, and explained our progress since the last meet. In this meeting we discussed the type of "Company" we going to be. This was one thing we hadn't really discussed and there was quite a blank idea of what we actually were. We aren't a games company in the traditional sense, we aren't just a manufacturer of technological devices but both! It was DAn who then describe us as being a 'Bespoke Entertainment' company, which deals with the creation and development of custom design.

We are still currently working on web designs for our company site and all three of us are set to work on our individual critiques which will be directly linked to the technologies used within our system which will help in further development of our system.

Scheduled Meeting No.1

So we had our first scheduled meeting together with Dan and basically discussed what needs to be added to the bike in order to control the game and to give user feedback whilst playing.

Firstly we decided that feedback needed to be added to the bike controller to simulate various aspects of the game and to give the user a physical indication of what is happening. The use of rumble packs in key areas of the bike will provide good feedback for the user. The rumble packs will be taken from existing controllers (possibly PS1 dual shocks) and positioned on the handle bars, in the seat and underneath the pedals. The handlebars packs may have to be incased in custom bar grips in order for them to vibrate efficiently. The seat and the pedal mounts may also have to be incased. The rumble packs themselves tend to be cam like ovals which are offset and rotated at speed to create a vibrating shock simulation.

The second aspect of the bikes functionality as a controller will be the use of the existing brake levers in which the possibility of adding electro magnets to measure the distance between lever and handlebar to act as a way of slowing the game character down. The other option is to add springs to the levers that will then use a sensor to measure the distance. This is still in the process of being decided.

The next idea that was discussed was how we would interact with the game when it came to delivering the paper. The initial idea was to have numerous physical papers (rolled up) that the user would actually throw at a pressure pad in time with the game. Upon further discussion we all felt that this was going to cause potential problems. These would include accuracy of the throw as well as timing issues due to the game not providing feedback when the paper is thrown as it has no way of knowing when the paper is in mid flight. Another idea was to hang these physical papers from a zip wire that would be dropped down onto the pressure pad. This solved the accuracy of throwing but still the problem with game feedback and timing wasn't solved. The idea of using a Nintendo Wii remote to trigger the throwing of the newspaper. This would then solves the timing and feedback issues as the game would be able to see the remote and provide visual feedback for the user. This idea would also be a solution to the accuracy issues as the user is not physically throwing anything across the room so there is less chance of failure and user annoyance.

Next stage of project is to plan out an annotated design of the bike controller and create a solid visual plan of the technology that needs to be included.

Proposed Idea

For this module The aim is to design and create an entertainment system, be it a new form of interactive controller, game or a new and improved version of an existing system. Our idea is as follows:

We intend to design and create an innovative version of the Gameboy classic “paperboy”. The game will be controlled by the user sitting on an actual bike which is on a stand so that it cannot move. The movement of the handlebars will control the movement of the game character’s direction and the pedals will control the speed and forward movement of the character. The aim of the game will be to deliver papers to the correct houses just like the original game but to do this the user will have to throw actual papers at a sensor at the correct time to score points. The game will also have obstacles, which the user will need to avoid in order to complete the game. The first step in creating this will be to get hold of a bike which we can use to create the game. In order to transport and move the game easily we are going to try and use a children’s bike, it will also be cheaper. The next stage will be to understand which sensors we will require and how they work so that we can use them properly and make sure the game is useable. All of the technical functions will be programmed in Max and the level design will be created in flash. We will use the flash server function with Max MSP to join the functionality with the game itself.

The “hook” in our game is that the player becomes immersed in to the experience by actually participating in a realistic manner. The use of physical controls, in this case the bike allows the user to experience the game in a more realistic way compared to a conventional hand held controller. Throwing a newspaper at a pressure pad will add to the addictiveness as the player has to not only throw a physical object but throw at the right time. The game itself will feature a timer in which the longer the player continues the level of difficulty will increase. i.e. more objects to avoid, bike increases in speed. We also intend to add some kind of controller feedback such as rumble packs on the bike in an attempt to make the game experience more realistic.

The target audience for this game could be just about anyone. People who have played the classic paperboy game will be interested and people who enjoy playing innovative games with a unique control system will hopefully be interested. We need to ensure that both game and control system work well together to ensure the game is playable and enjoyable.

Mike will be responsible for creating level design and coding of the game. Will, will be responsible for creating sound effects needed for the game and the physical programming of the bike within Max/MSP along with Rob