Reflection

Just to conclude and summarize though the game is not completely finished I did meet my aim which was to make a game that implements the Wiimote.

I will however continue to develop the game despite not finishing for the deadline set. I will continue to work on the score and visual effects within Sandy 3D and try to apply a more real looking bitmap material to the walls. I will also see whether or not I can get the walls to randomize so they appear in different places and not set ones.

The game in itself is very tricky, and at this point in time I can just about make it to the 5^th wall without crashing, but it’s not meant o be easy and surprisingly requires quite a lot of skill in the form of exemplary hand and eye co-ordination.

If you would like to play the game or/and download the files you can access them at:

http://davidsdomain.co.uk/final_project/Sandy_ScapeEvader1_2/ScapeEvader/ScapeEvader2.swf

I’ll keep you posted for any new developments.

Finishing Up

Though the meat and bones of the game had been developed there were still some remaining Issues such as I was unable make the walls appear in different positions at random due to some strange clash between the way AS3 implements its random method against to how Sandy 3D does it for its primitives. I’m use to how it should work in AS but since I used a Sandy primitive to make the wall it would only work using their random method. I tried to manipulate the method to how I wanted it but I kept getting odd results like a wall size increase.

As you may tell the aim of the game is to fly past as many walls you can before the plane crashed. Every time you flew past a certain number of walls the plane would speed up (through speeding up the movement of the walls towards the camera).

I used Sandy 3D primitives to develop the title screen (plane), instruction screen (plane), game over screen (plane) and buttons (boxes) and made the primitives to respond to mouse events by enabling them to button mode. The images on the primitives (i.e. the title picture, button labels etc) were made through creating a separate class for all the images and applying a bitmap material that accessed the respective image class and applied the image to the primitives. I tried to use the same technique to create material for the walls however I couldn’t get the image to tile properly so in the end I applied a simple colour material to the walls.

I tried to implement a scoring system to the game based on how many walls passed but it was proving tricking through Sandy as the text field you had to set up was not responding to the code and time was running out, so I had to leave it out.

Also as I’m not use to Sandy, it was near impossible to create effects such as explosions when the plane crashed. The particle function just didn’t work, let alone follow the plane. Still the game is very functional.

I didn’t do know vigorous user testing but my family played it and thought it was quite addictive.

ScapeEvader Game Title Screen

ScapeEvader gamplay; the plane has to make it through that gap in the centre

Wii Controls

I’ve had to change the game again. This time because the Wiimote is not responding to my plane as I thought it would. Firstly trying to get the plane to move with two Wiimotes was a nightmare. The Wiimotes didn’t correspond together plus it was tricky trying to move the plane up and down or left and right as if you swayed to rotate the plane, the plane would move to sharply up and down. This whole system was just not suitable. I developed a new system that would just work with one Wiimote with twisting the Wiimote to make the plane rotate and moving your hand whilst holding the Wiimote left or right to make the plane move likewise and the same with up and down movement.

This system didn’t work either as twisting the Wiimote through rolling it made the plane move left and right with sensorX as well as rotate the plane. As a compromise I had to get rid of rotational movement for the plane as it is more important that the plane moved left and right then rotate.

In Order to move the plane left or right you'll

have to roll the wiimote left or right

Moving the plane up or down through moving 

the wiimote up or down 

Sandy Game Development 2

As mentioned in a previous blog, Sandy 3D makes use of Actionscript. This was good for me as I’m use to Actionscript 2. Despite that though due to Wiiflash only using Actionscript 3, I had to use AS3 as well to program Sandy 3D with.  Though I’m not use to AS3 and it is quite a change to AS2 there are a lot of similarities so it wasn’t too much of a change however one crucial distinction is that with AS3 you always have to add event listeners for any event as events are all integrated into the same event handling architecture.  This means as long as the event listener is added all events from that event class will respond there eliminating the need for callback functions, making the coding shorter and more reusable.

Sandy 3D itself has its own classes, packages and functions. However I was having an issue with the collision detection. Sandy 3D does not have a particular system for collisions and suggest you incorporate an external physic engine called WOW. However after trying to use WOW I couldn’t seem to get it working with my models I therefore had to develop a make shift collision for the game which basically works on the distance between the airplane and the walls and the space in between the gaps of the walls. See diagram below for more details.

Diagram explans how the collision works in the game

Sandy Game Development

Though Sandy is able to accept 3D models it still has its limitations. After importing my cityscape model into Sandy 3D and programming it to gradually move backwards towards the camera (giving the illusion that that the plan is moving forward), flash started to move slow. I deduce that this was down to the size of cityscape model. However after several times of scaling the model down in 3ds max and also through the AS3 Geom Class Exporter plug-in 3ds max, there was no difference. Changing the frame rate also didn’t seem to make a difference. I also imported buildings in the cityscape individually but with each building I imported Flash ran slower and slower.

I was stuck not knowing what to do. I was originally just going to accept it and work with a slow moving game but that would disrupt the other element to the game, the Wiimote controls. I decided therefore to not use the cityscapes and use walls made from simple primitives that the player had to dodge instead. The game is also now called SpaceEvader.

Cityscape buildings in Sandy 3D which I had to exclude in the end

City Buildings replaced by walls instead

The choice is Sandy

In my last post I said I would implement an open source 3D engine for flash. I decided to go through with this and chose to make use of Sandy 3D which like all other 3D Flash engines, uses Actionscript 1, 2 and 3 and can be accessed here www.flashsandy.org. You set it up with Flash in the same way you set up Wiiflash, just make sure you select the folder that holds the src folder and not the src folder itself.

I chose Sandy because they had a dedicated site with well structured tutorials on.  Through playing around and completing some of the tutorials on Sandy my fears of lack of animation and interaction in comparison to Flash were confirmed, prompting me to change the concept of the game to something else I already had in mind. Instead of someone swinging about you now had to glide a plane through the city to avoiding buildings as the plane approached them (see sketches below). Each time you past a certain section of buildings the plane would speed up and keep doing so until it crashed. The user would still make use of Wii controls through spreading arms out and forming a wingspan whilst holding the Wiimotes in either hand whilst in turn the user would also sway from side to side.

From this I also produced an airplane in Maya and eventually imported the model into Sandy via 3ds max (please see images below) via a 3ds max plug-in for Sandy called AS3 Geom Class Exporter which can be found here http://seraf.mediabox.fr/showcase/as3-geom-class-exporter-for-3ds-max-english/. Now time to do some further development and get deeper into the waters.

Now the game revolves around an airplane flying through a Cityscape avoiding buildings

The game will require avoiding City buildings as the airplane flies through

Swaying hands up and down(not in a bird motion) so that whilst one hand is up the other is down will glide the plan around.

3D model of the plane made in Maya

Airplane after imported into Sandy

3D Model Test

I developed a 3D model of a building (see images below) in Maya however I had to import it into 3ds max so I could export it as an dxf file (synonymous with AutoCAD) to import into Swift 3D. Once in Swift 3D I exported the model as a swf file to bring into Flash. The process of going from one package to another was quite frustrating, I don’t see why all these 3D software’s can’t export into other popular formats such as dxf or why can't Swift 3D be able to accept popular universal 3D files like fbx or obj.  

What was even more frustrating however was that once the model was in flash it was no longer a model, it turned into a 2D image. Because of this I decided to do away with the idea of producing the game in Flash CS4 solely unless I make all the models in Flash which I think would prove too tricky and intricate. The only alternative there is, is to make use of a 3D engine for Flash, though this way I foresee less freedom to animate and more programming into a software that is new for me. It’s probably will be wise to tone down the intricate elements of the game which involve a lot of animation such as the swinging element which I intended to implement through keyframe animation and inverse kinematics within Flash CS4. It all depends on how the 3D engine works.

I’ll keep you posted

 Model of Cityscape in Maya

Model of cityscape when brought into Flash via Swift 3D

As you can see from the picture immediately below every thing looked fine. However when you rotate the model outward you can see from the next picture below that it has no depth.