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/

Project 2 - Final

Well managed to clean up most of the tiles. It's not perfect but pretty good considering I didn't use a 3-D program to make them. Also got the key pickup to work.
It's pretty basic as it automatically unlocks the door once you pick it up, even though you are nowhere near the door, but it works. An info message might be nice.

Would of liked to of added some bots to interact with but, but that would be a whole other chapter. Also map fog, so you don't see stuff on the other sides of walls etc, when your line of sight is obstructed. That would also reduce the number of clips on the map at any one time.

Anyway here are my final files:
Flash File

Open Sesame!

Eureka! Managed to get some doors in that open and close, so v. happy about that.
Still need to do north-south facing doors. I can't do a simple _rotation = xxx on them which is a bit of a bugger as all the verticals rotate as well. We'll see if I can get that fixed by tomorrow. I think tomorrow is just going to be clean up day without any more development. A pity as I was on a roll, and was thinking about doing locked doors that you could only open with a key...that just would be too exciting!

Two days to go

Well I spent all of Saturday trying to glamourise my level with better tiling. Ended up wasting a lot of time (basically the whole day). Didn't get it finished and the way I sliced and diced the tile to prevent overlapping was a dud. For the walls I was endeavouring to use curved shapes with gradients and it all got a little complicated. Yo can't do multi-directional gradients, and splicing gradient shapes together is cumbersome and time consuming. So scrapped that. I am cranky about that as wasted a whole day.

I did manage to change the character movement to variable speed, so it accelerates and decelerates as opposed to using a set movement distance. Also changed the movement so it is multi-directional (you can press two related movement keys at once e.g. up-left). Not totally resolved as it is a bit clunky when you hit a wall), but good enough considering it's not used much. I am much happy about that as it is in line with the original game and makes it a lot more fluid and smoother. It also introduces an element of momentum and its corresponding lack of control or delay of movement response.

I have also been having another look around the community blogs. Matt Grainger's work is most similar to my own. He is doing isometeric tiles, but the principles are the same. I am very impressed with his 3ds-max character! I'd like to do a 3ds robot but I don't think time will permit.

It's a toss up between doing some character walk cycles or making some opening and closing doors....(flip a coin?). My character is just a moving pyramid at the moment!!! 0 points for character design.

Also noticed the project brief talks about two flash files, and I only really have one development stream. I hope that won't be a problem ;-)

Out of my Depth

Came across a few major problems.

1/ The whole area tile thing was a dud. There were issues with moving the character from on area tile to the next because the depths of the area tiles were different. When the character was spanning area tiles half of it would disappear underneath the adjacent one.

2/ Ditched using the original map array data definition to determine tile/char positions. Once it is loaded into the virtual map grid it is no longer used. The virtual map grid is organised by vertical and horizontal tile slots, and is easier to work with (no tricky array index calculations).

3/ There were rounding errors occurring converting virtual map distances to axonometric ones. The errors were cumulative. The more the character moved around the screen the greater the discrepancy between the virtual and axonometric map. I had to do some nasty coding to compensate for this.

4/ Character Depth - *sigh*. On the whole this is ok, but there are conditions when either the adjacent top-right or bottom-left tile is wrong (either it is in the foreground when it should be in the background, or vice-versa). Could spend more time on this but would rather look at more interesting things like opening/closing doors, etc.

Foreground vs Background

Been doing some more work on this and got my virtual map things going. You can see it on the right hand side. (You can switch it off by setting debug.generate to false).
It took me a couple of days to iron out the wrinkles, but it seems to be moving around ok, even if it is a little jerky. Also need to reinstate the board move/scroll as well.

Focusing on foreground/background stuff at the moment. Trying to change foreground clips (i.e. walls, etc), to have a higher depth than the character if they are in the foreground. This would make the character go behind walls, and remove the floating appearance.

This is turning out to be a little tricky as 'char' (the character) is attached directly to 'axomap', and the 'tile' movie clips are attached to 'area' movie clips, which are then attached to 'axomap'. This seems to be doing weird things since the area depth (which the tile is attached to) is lower than 'char' depth, but the tile I have moved to the foreground (still attached to the 'area' mc) has a higher depth than 'char' depth.
AM I making sense? Basically is there any correlation between a mc's depth and its parent depth, or are they totally independent and non-related?
The reason why I ask is that my walls keep disappearing when I move them to the foreground, and I don't know why.

Here is the flash file.

Coding Headache

Been looking at Kah's ArrayMap stuff, and when I tried to use the detectKeys() function it didn't work, so ended up going back to addKeyListener stuff. That seems to be working now.
Also getting my head around Flash's Action Script implementation of object orientated programming (Oop). Quite un-Java-like in terms of how loose and weakly-typed it is though kind of similar. Will 'objectify' the code a little more as it makes more sense.

The main headache has been trying to work out where I am on the map. In axonometric it is fairly complicated because of the way the tiles are laid out, you can have multiple rows occurring on the same x-axis. (It's a little hard to explain here you would have to see the code to see what I mean. I might do a pic so you can see).

Anyways decided the easiest away around this is to have a 'virtual map' and a 'drawn map'. The virtual map is the actual tile layout in a Cartesian vertical and horizontal co-ordinate system. This facilitates the following:

• All the co-ordinates can start from 0 and be positive (i.e. don't have to worry about negative values in calculations).


• I can use the Kah's ArrayMap logic to find adjacent tiles. i.e Keep-It-Simple-Stupid (KISS). Adjacent tiles are above/below, left and right. No weird axonometric calculations involved.


• It is easy to translate 'virtual map' movements to 'drawn map' movements because an axonometric tile is just a normal square rotated 45 degrees. They have the same number of pixels.( Well that's my assumption. We'll see if it holds up).

Will have another bash at it today and see what comes up.

Recode

Spent all evening recoding what I did over the weekend. Changed it slightly. Don't know if I went overboard. Have 4 layers: the root stage -> map mc -> area_mc -> tile_mcs.

The tiles (i.e. walls, doors etc) are placed on the area tiles in a 6x6 grid. I have set it up so if there is just the floor nothing is placed (the floor isn't interactive so it's not a prob). The idea being that invisible areas (i.e. area_mc) gets switched off when not visible/off-stage.
At the moment when moving it is just moving the base movie clip (map_mc), and it seems a wee bit slow.

Eventually hoping to make it like the scrolling demo. Also you have to press the keys multiple times to make it scroll in th browser. It doesn't do that inside Flash.

Sadness

I lost my file that I was working on on Sunday. Doh! Feeling a bit upset about that as I worked 5 hours on it. Managed to get an axonometric going and was about to work on the collision factors... starting from scratch again. PS Hacking a version of Kah's ArrayMap.

Project 3 Concept V2

Ok here it is:



Here is it a bit more formally:

Concept: Stop Skanky Dred Fred from getting a job, and being respectable.
Every morning (a game pattern or level) he wakes up and tries to go to for a job interview. You have to thwart his attemptes and stop him from getting that job. If you succeed you move to the next level (i.e. another morning, where he tries again, but it is harder to stop him). If you fail, and get gets the job you lose the game.

Methods: Lies and deceit, distraction or diversion, sabotage and general misdirection.

Gameplay: hmmmm....

There are certain things Fred needs to do successfully in order to get to the job interview. These are things such as:

• Wake up on time


• Shower & shave


• Get dressed in business/interview attire (i.e. look smart)


• Have breakfast


• Have things he needs for the interview (e.g. CV, being prepared with the right info, research etc)


• Getting to the interview destination (transportation)

Basically there are lots of opportunities for mishap.

As a player you could do things like turn off his alarm clock, so he sleeps in and misses the interview, hide his work clothes, Let down his car tires making him late, as above etc.

In terms of gameplay there would be certain actions you could do when he is in the room (i.e you need to have a face to face conversation with Fred to misinform and misdirect him), and certain actions you can only do when he is out of the room e.g. sabotage like letting his tires down.
In the latter case there would be the danger of getting caught in the act and busted.



There would also been an opportunity window for performing sabotage. For example if you turned off his alarm after he woke up it wouldn't make any difference.

Your could have different levels or probability of success for different methods of "thwarting". Sabotage might have a high chance of success, but telling lies may have a 50/50 chance (i.e. there would be the opportunity for him not to believe you).

Thwarting could take the form of distractions, of using Fred's favorite pastimes against him. Drinking, getting high, playstation etc.

The gameplay isn't totally ironed out yet. You'd need to put some mechanism in to stop you doing the same thing every day. Fred could also be more unpredictable and do tasks each day in a random order.

Themes: The general themes the game touches on are drug abuse, or more specifically stoner culture and apathy. The stoner culture is something that I don't particularly like about New Zealand. There are youths out there with no aspirations or - dare I say it - a belief in a better life, and that's rather unsettling. Rather than be PC (dull) about the whole thing I thought it would be more fun if I inverted the objective and made the game about keeping someone in a rut, rather than trying to motivate them to move forward.

A sub-theme of the game is how people can be threatened by change and fight to keep the status quo.

Hold on a minute ...

After speaking with Kah, decided that a remake wasn't such a good idea.
Will have a new concept for Project 3 posted later this evening.

Project 3 Concept - Paradroid 2

Actually I don't know if it would be version 2. I actually think there is a version 2 out there. You know the basic premise: Irradiated robots gone crazy need dealing to by yours truly. Your goal is to clear the ship of robots. To be clear, the game is not a straight out shoot 'em up, there is strategy involved.

In terms of gameplay the original Paradroid was fairly limited. The basic choices you had were:

1. Which levels do I take first?
2. Should I clear the deck totally of robots or leave some left in case I need to jump to them later?
3. How do I kill the robot - shooting it versus taking it over? (the latter being more favoured unless the robots were weak).

For Paradroid 2 I'd like to revamp the gameplay:

1. Rationalise the robot classes. Make them more distinct from each other in terms of what they can do and how they can interact with the environment.e.g

Messenger Robots - Speed/Agility. Maybe the fact that they deliver messages means they have access to most levels of the ship. No weapons.

Crew Robots - Have command access or can access certain restricted or personnel only areas. They could open doors or enable certain functions. This could also be used to lock doors (temporarily?) and stop help from arriving. They'd have either small weapons or no weapons.

Security Robots - Basically the grunts. Big guns, harder to kill.

2. You could add the element of disguise to the game. So when you take over a robot you are an imposter and can move around the level unchallenged. But if you are seen doing something unauthorised or blow your cover (either by shooting or transferring to another robot) then you have an intruder alert, and are treated as hostile.

3. In the original game you can access all levels of the ship, and different levels had robots of differing toughness (e.g easy, moderate, and hard). You could restrict access to levels, so you'd have to of transferred to a robot of the equivalent strength to gain access to the level (i.e. if you were in a 300 level robot and tried to access the 400+ level you wouldn't be able to).

4. Vectorise the graphics. That's just me though .(It could be the VectorTD addict in me talking!). I think I'd still like to keep the top-down (plan) view. I think the gameplay would be hard enough to program without tweaking it for isometrics. Also the plan view gives more clarity about edges, and you wouldn't have to worry about stuff getting hidden from view behind things.

5. The original talked about 'weak' robots (i.e damaged) being easier to take over than healthy ones. I don't know if that really ever manifested in the game, but the shoot'em/transfer to them action could be used in combination.
These are just general ideas to be developed.

6. Powerups etc...

I know a remake isn't strictly a 'new' concept, but I see this as a new idea because the whole game is being re-conceptualised from the ground up.

Isometric

Since that paradroid game is a top down view, I thought it might be fun to change it to an isometric. I've tweaked the introTiles.fla so it draws diamonds instead.
Had a few problems adding some functions as Flash didn't seem to recognise them, so had to write it in the code which was no biggy.

There is a parameter in the actionscript to change the diamond angle if you want.
You can also switch it off so it does squares again.
Intro File Diamond Flash File.

Play Paradroid

For those of you keen enough out there I thought I'd post some links in case you would like to play the game.

One for the c64 emulator and one for the game itself.

I've only tried it on Windows (sorry Mac users), but ther is an OSX version of the emulator at the same site, so hopefully it works the same.

Here's what you need to do:

1. Download and install the emulator.


2. Start it up.


3. Go to Settings->Video Settings


4. Set the resolution 1280x768 (i.e less resolution probably than your current settings). The y-axis one counts the most. Reducing it down seems to make the emulator screen larger.


5. Got to Settings->Joystick Settings


6. Change the drop downs so Joystick 1->Keyset A, and Joystick 2->Keyset 2


7. Click on 'Config Keyset A' to set up your keys. Up, down, left, right, fire etc.


8. Click on 'Config Keyset B' and do the same thing. Should be different keys from Keyset A.


9. You can then test it out. At the bottom of the emulator screen there are two crosses, one for joystick 1 and the other for joystick 2. When you press the associated keys the relevant part of the cross will turn green. (If you get any junk at the cursor input on the screen press Return).


10. Go to Options and check 'Double Size', and 'Double Scan'. This makes the emulator window bigger.


11. The emulator is all set up now and you should be ready to play the game!


12. Download paradrd.t64. This is a commodore64 tape file of the game.


13. Go to File->Autostart disk/tape image, browse to the paradrd.t64 file you just downloaded, select it and press 'Attach'. The game should load and start.

The game asks for joystick in port #2 (i.e Keyset B), so I think you need to press fire for it to start.
General controls up, down, left, right. To fire your gun turrets you need to be noving when you press the Fire key. It fires your gun in the direction that you are moving.
Holding down Fire puts you in Transfer mode. You can't fire like that, but you can move around. Releasing the ket put you back to normal.

Hope this helps. The best thing is just to try it out.

Paradroid Screen Shots

Pics are worth a thousand words, so putting some screen shots of Paradroid in.

	Splash Screen
	This is where you start the game (although I think it may put you on a random deck each time. It's that or it randomises the deck colour). You are the white robot - 001, and the black ones are the baddies.
	This is the screen you get when you try and take over other robot. The goal is to get more bricks in the centre column your colour than your opponent.
You do this by scrolling up and down the wires with "beads" that you fire down the wires to turn the brick your colour. I kind of think of it as an electrical circuit that current goes down. Branches are good (2 bricks for 1 bead), inverted branches and dead ends are bad. You get to choose which side you are on, left (beige) or right (purple), so hopefully you can get a better deal. Higher robots e.g. 476 get more beads than lower ones, so if you try and jump too many steps up the tech tree you are at a disadvantage. Anyways Timer runs out - whoever has the most bricks their colour wins. Deadlocks result in a rematch. If you loose and are hosting another robot (e.g. 302) you go back to 001. If you are 001 you get burnout and die - Game Over! You only have one life.
	This is after you have successfully taken over another robot.
	This is the ship console. They are usually a few of them on each ship deck, and they all do the same thing - basically they are a map.
	Console main menu. There are 4 options: Exit Menu Robot Info Deck Plan Deck Section
	This is the deck plan. The only thing it really shows you is where the consoles and lifts are.
	This the ship section. It shows which level you are on on the ship.

Research

Doing some research on the net and came across a few games. Chasm is a good puzzle Flash game by Transience. They also do one called El Emigrante that is quite a laugh, although the movieclip is better than the game.
These weren't heading in a particular direction so decided to go back to what I knew, some the arcade games from my younger years. Defender, and a similar game called Stargate (nothing to do with the Egyptian Sci-Fi one), and Asteroids were favourites and seemed simple enough, but engaging, and also 2-D. I thought they would be good contenders.
'80s Music Lyrics has a few popular arcade games from the 80's re-engineered in Flash. Tried out Moon Patrol and Asteroids.
A really like the Vector graphics style video games, and the eerie CRT phosphorescent glow the lines used to have. So Sci-Fi and so laser like! Simple and striking! Bring it on!
Really liked the Asteroids one, but since it has already been done, decided to skip it.

Decided to go really far, back with some Commodore 64 Games from the 80's. For some reason two games (apart from Elite) stuck in my mind: Castles of Dr Creep and Paradroid.
Castles of Dr Creep is where you have to run around getting keys to unlock rooms, but there are traps, puzzles, and zombies thwarting your attempts. It's actually quite tricky (and a bit fustrating if you don't have much patience) and has a lot of switches and things that only work in a certain sequence. Tending to veer away from that one, as the gameplay is a bit slow and the programming may be too complex.

The one I did really like was Paradroid. The premise is that a transport full of robots travelling through an asteroid belt have been exposed to a radionic beam making them hyperactive. They have gone AWOL and taken over the ship and attacked the crew. (You don't actually see any humans during gameplay, so they must of all been killed).
Basically you have to clear the ship of the psycho robots. You can either do this by shooting them, or taking them over. You yourself are an Influencing Device Robot 001 (their highest goes to 999) so your guns are quite weak (especially against the more advanced robots) so the rule is generally to taken them over, jumping from robot to robot (they die when you leave them) up the robot tech tree. Unfortunately you can only take them over for a short peroid of time (the higher up the tech tree, the stronger they are, so the less time you can control them).

Project 2

Starting some research now. Since there are a plethora of video games out there. narrowing it down to 2-D games.
Came across this movie on http://www.destructoid.com. PIRATE BABYS CABANA BATTLE STREET FIGHT 2006 game concept:

I stuck this link in here, cos it has amazing graphics, animation and characterisation. Also how it has a lot of impact even being in just black and white. Makes it feel a bit retro.
The tendency for these games seems to be ultra-voilent and gory, 2-d shoot 'em ups and zombie killings and such like. Though amusing, I'd like to steer away from that if I can.

Project 1 Final

Firstly, here is the link to my left/right Discobunny ActionScript Move Test.

Unfortunately I didn't get the walk cycles completed on time :-( . Originally I started doing the walk cycle animation using my original reference sketches, each sketch corresponding to a different keyframe.
The bunny character ended up comprising of 29 elements on separate layers. In hindsight I think that was overly ambitious. Going through 29 layers for each animation frame turned out to be very time consuming.
In terms of the animation process, I tried to stay true to my original sketches, which meant having "wobbly" elements. What I mean by that is keeping variations and irregularities in the elements between frames due to the inexact sketching process, like the animations used to have in the old days e.g. Mickey Mouse.
The way I did this was having each element be a movieclip symbol on the main timeline,
and doing motion tweens there. If the actual element needed to change shape I would do a shape tween in the symbol movieclip.
This ended up taking too long as well, so unless the actual element needed to change (because of movement), variation for the sake of it was dropped. This meant that I ended up ripping out a lot of keyframes that I had created, which was unfortunate because it was wasted work.

Anyways this is how far I got. Thanks Kah for helping me with the final bit.




Here is the Flash file for it.

Animating Discobunny

Tried the Flash actionscript today, that does the left/right character movements. Hacked it for Discobunny and eventually got it to work. Sussed out the "box_mc" movie clip with the "box", "left", and"right" frames. It didn't work for me until I added a label for the main time line movie clip, but once I did that it all clicked into place. Will need to remember that in future.

Then started doing the walk cycles for DiscoBunny. The right and left moves are different, so started doing the right move first. Managed to get 3 key frames done, but it is a bit jerky. I need to add some motion tweens, so will do that next time. It'll be interesting to see how it turns out - as Discobunny is doing dance moves the transitions need to be quite fluid and smooth. Have about 7 to do all up (each way), and they are quite time-consuming. We shall see how we go.

Also noticed a few oddities. I had imported bitmaps into flash for reference during character construction, and they kept showing up in the movie even when the associated time line was hidden/invisible. Quite annoying. Eventually, someone told me that you could move the bitmaps off-stage and they wouldn't show up in the movie.

Also if you import a flash file with a bitmap in it, it always imports as a BMP type (not a movie clip), even if there is stuff/animation on other time lines. You have to remove that time line/BMP for it to import correctly. (It might have been because I only had one key frame - will have to check next time).

Another thing, the published shockwave files (swf), when you launch them from Finder, they don't work, and come up with static backgrounds. Not sure what you need to do to fix that, so I shall have a few things to go through in Studio.

Flash Bunny

I have created the bunny character in flash. I haven't tried animating it yet, but will do that next. Not sure if I need to convert all the vector graphics to symbols, but will cross that bridge when I get to it.
Here's the flash bunny. It looks pretty similar, although I have broken it up into a lot more elements.
Things differ from the tutorial as I don't have the double layer shapes (object plus outline/shadow shape), and used strokes (i.e. didn't disable it) when making shapes.

Disco Bunny

Still liked the idea of the bunny so kept that aspect. I think the killer-bunny-3 site inspired me for what good bunny characterisation could achieve. Liked the humour as well. Not quite sure how I got to John Travolta. I think watching a trailer at the movies which showed the new Hairspray sequel with him cast, nudged me in that direction. My web wanderings brought up Staying Alive and Saturday Night Fever. I thought his dance moves would be a lot more interesting than the standard walk cycles, so the body was appropriated from the "man with the threads".

Here is my sprite sheet:



(Click here for a bigger version).

Pics

Have got my hosting sorted out now, so here are some links to my original pics.












This was the first attempt. I had problems trying to organise the body to go with the head, as I had already morphed the head. As I said below, I spoke with Tom and he talked about walk cycle movements and how the character would be seen from the side. I was going to have to redraw the head, and I thought the "Dolly" aspect would be lost or at least unrecognisable. Time for version2 ...

Restart

After talking with tom it seems my character dolly bunny needs a bit of an overhaul. I drew DollyBunny face on and which isn't so good for walk cycles which view the character from the side.
Back to the drawing board. Ditching the Dolly aspect and sticking with the bunny one.
Found a really good example of a bunny character in flash: Bunny Kill 3
(Will post this and see if the links work).

Duff MediaMax

hmm...it doesn't seem to be uploading any of my files. Trying a NZ hosted site. Got some files uploaded but no hotlinks. Hope to have that sorted by tomorrow... (fingers-x'd).

Initial Concept

After spending an afternoon looking at stuff on the internet I decided on my lycanthrope. DollyBunny. Dolly Parton + Bunny = DollyBunny. I found a Warhol pic which has Dolly's face reduced to it's most significant elements. Eyes, eyeshadow, lips, and hair. I was thinking about Donny Darko and the bunny in that and I liked the idea of something that is meant to be quite cute and benign, that can be quite menacing.
The first mutation attempt didn't really work out. The Dolly essence got lost in translation. Dolly is quite soft and feminine and fluffy, and didn't really gel with the Darko bunny style. So that idea was ditched and a regular bunny substituted. The quintessential problems being how do you morph Dolly into a bunny and still keep the personality (or at least the character references).
I overlaid the bunny sketch over the face sketch and started to move Dolly's face elements, the eyes, eyebrows and lips. Also dropping the nose and adding the ears.
I'll add links to the pics when I get mediamax working.

Day 1

"In the beginning ... " - all very new. Going to check out the Flash tutorials...