Final

Been busy programming so thought I'd update my blog as haven't done it for awhile.

Feel fairly happy with the game to date. We had the following weapon implementation.

• playstation - stunn effect. Freezes Fred in place. Affinity: Simon (i.e. only he can use it). Usage single shot (not implemented). Range: long.


• marijuana (bong) - slows movement (by 1/2). Affinity: Simon (was going to make Fred hungry till he finds something to eat. That part wasn't implemented. I think it just slows him down. Range: short.


• deodorant - Affinity: Fred. Slows movement same as the bong. Range: short.


• comb - Affinity Fred. Disables pickups. Range: short.

There is a bit of imbalance between the weapons that we didn't get a chance to rectify. Simon has the advantage with the playstation as he can just stunn you and you can't run away. Simon can keep firing, so as soon as the weapon effect wears off you get stunned again. Not so hot. Was going to implement single use or limited use weapons, but didn't get time. I'd make them so they'd disappear and respawn after a certain amount of time.

Sam suggested shortening the gameplay time, making it a singleshot win or lose game i.e. make it more frantic. Also character special abilities/weapons. That would be quite interesting too.

Update

Sorry, no update for a while - been caned with design.

Spent te weekend sorting out character movements. changed the code from a Key listener to an onEnterFrame execution. This has made the movements smoother and less jerky, and fixed the key lockouts that we were getting before.

Also sorted out the character facing different directions. Greg told me about using negative _xscale numbers to flip the characters horizontally. A bit of jiggery-pokery to sort out which way the characters are facing, but working pretty good now.
Implemented the new character walk animations with the head bobbing up and down too.

Working on weapon hit testing next.

ShadowedObject class

Gonna talk code now. This is a new class I created. MovieClips (aka Drawable objects) are usually drawn on one side of the screen. When characters are in the same room, the objects need to be drawn on both sides. This means keeping track of two objects, and moving both of them when movement keys are pressed. It's a bit a tedious updating two objects all the time, so experimented with overriding superclass methods.

You have main one object DrawableObject (simplified) with methods relating to position:

class DrawableObject extends Object implements Drawable {

private var xx:Number;
private var yy:Number;

public function getXx():Number {
return xx;
}

public function setXx(xx:Number):Void {
this.xx = xx;
}

public function getYy():Number {
return yy;
}

public function setYy(yy:Number):Void {
this.yy = yy;
}

}

Then I created a class ShadowedObject (simplified) as follows:

class ShadowedObject extends DrawableObject {

private var shadowObj:Drawable;

public function ShadowedObject() {
super();
shadowObj = new DrawableObject();
}

function getShadowObject():Drawable {
return shadowObj;
}

// superclass override.
public function setXx(xx:Number):Void {
super.setXx(xx);
shadowObj.setXx(xx);
}

// superclass override.
public function setYy(yy:Number):Void {
super.setYy(yy);
shadowObj.setYy(yy);
}

}

so when I do this:

var someDrawableObject:Drawable = new ShadowedObject();
someDrawableObject.setXx(200);

the shadow object 'shadowObj' gets updated as well, so I don't need to duplicate calls.
It also highlights the advantages of encapsulation (i.e. using function/method calls) because I couldn't do this if I was referring to the properties directly (eg. someDrawableObject.xx, yy).

Quite surprised as it actually works!

Double Vision

Well I have been doing some more coding. It is surprising how long it can take for such a little difference. I have split the display into two. I added two empty movieclips that are for each side of the display/stage. They are associated with a 'Screen' class, and there is once instance created for each side of the screen i.e. a left and a right. Each character and associated control gets assigned to a screen.
Coordinates systems are relative to the screen (and not the stage), so are the same for each side, which means no code changes in that regard. Although there is a lot of changes regarding assigning characters to screens, and double drawing.

In terms of control I have the 'Controller' which is the main object and in charge of everything (what happens when etc). It gets kicked off in the _root AS frame at the start.
I also have two keylistener objects (same KeyboardControl class, just two instances - one for each control (left and right). It seemed like the simplest thing to do rather than having one object handling both controls at once.

I don't know if flash is multi-threaded or not, but I am assuming not. i.e. listeners are executed sequentially one after the other, rather than in parallel. Things could get a bit messy otherwise!!!!

The room switching has broken again, but that is because the url for the door clips have changed since adding screens to the hierarchy. Will fix that tomorrow before the meeting. I'd rather not use relative urls to reference the door clips (e.g. _root.left.rooms.kitchen_lounge), but that seems to be the only way. I don't think that you can get/find an instance of a movieclip unless you know its unique id (which I do have) and it's depth (which I don't have)... unless that whole movie clip is treated as one. An example would be the SideCroller.fla file with the ball. There is a reference to a symbol 'level', and 'ground' and 'ground2' within that. How many depths would be assigned when the 'level' moviclip is added to the stage? 1 (just for 'level') or 3 (one for 'level', 'ground', and 'ground2')???

I am raving here, but it has given me some thoughts for tomorrow...

I also restructured the character symbols so they are only one layer and a single frame. We were doing some frame switching before to display character labels at the 'Choose Character' screen, but it is easier just having different movieclips rather than having different frames within a single movieclip. The later has a limitation in that timelines can't run/play backwards (I think that's right?), so it doing it this way is probably better.

At the moment the character has only one clip associated with it, so will probably need to augment the code so that there are different clips associated with different character actions.

Progress

Tom Reville kindly talked me through his code today for the side scroller that he made.
The method he used was checking if the character co-ordinate was in a certain range (i.e. door space) and if the space bar is pressed then the character goes through to the next room.
I think that I would rather do a hit test, than doing the math as it is a bit easier, and we will have at least one or two doors in every room. Doing a hit test also means we can have doors in difference locations and in different shapes.
I have got the hit test working (grabbed some code from the sidecroller.fla file), so just need to do the programming to set up the room links and make the character switch rooms.

OOPs...

Well I haven't managed to get access to Tom's code yet (as he has password protected it), so need to email re that. Forging ahead anyway. Been creating some classes:

• Controller - basically the game controller/logic. The master.


• Drawer - draws stuff on the stage.


• Room - contains generic information about each of the rooms.


• Kitchen - a subclass of Room containing kitchen specific stuff. Want to do that for each of the rooms (polymorphism). It may be overkill at this stage. It depends on how different each of the rooms end up being in terms of behaviour.


• Character - stuff about characters.


• ControllableCharacter - initally this is linked to the Skanky Dred Fred (SKD) movie clip, and gets instantiated when the character is attached to the map. Has key listeners attached to it so you can move him around.


• Door - the connecting elements between rooms (haven't got as far as coding this yet).


• xxxxFactory - Factory classes to get instances of objects.

Having a major problem at the moment:

1/ Linking movie clips to ActionScript 2.0 classes. It doesn't seem to be working for me at the moment. I have the ControllableCharacter class linked to a movie clip 'sdf', which is the Skanky Dred Fred character.
The clip is getting created on the stage with attachMovieClip (which works fine), and the ControllerCharacter class is getting instantiated. But then I try and refer to this._x and this._y is comes up undefined. I tried a trace with 'instanceof' to check what object type this was and it came up with:

trace(this instanceof Object) => true
trace(this instanceof MovieClip) => false
trace(this instanceof ControllerCharacter) => false

It should at least be an instanceof MovieClip as my ControllableCharacter extends the MovieClip class.

Also tried casting 'this' to a MovieClip and that didn't work either!!!!
Stumped at the moment about why this is occurring.

Not sure how useful the clip-class linking will be for our purposes as when the character moves from room to room the previous room clips will get unloaded (i.e. object deletion and associated loss of data). Because I want to keep the room data when the room is unloaded, I will need to store the data in another object/class.

signing off
the-thwarted-one

The A-Team blog

Please go here for project 3 stuff: http://skankyfred285.blogspot.com/