Why did we choose Flash / Actionscript
- One of the main reasons why we choose to develop the game in flash/actionscript was that we wanted to learn a language/tool, which we also could use outside this class. If we for instance had chosen Game Maker, we thought that we wouldn’t be able to use this knowledge when we come out in the industry.
- Its easy to get started with making small and “simple” games in flash, because flash has a lot of help functionalities.
- It is very easy to share games with others over the Internet.
- Flash can be used to more than just making games. A lot of advertisements etc. is made in flash, so it’s a good language to know.
Physics / Collision Detection
We have chosen to develop most of the physics in the game like gravity for Lou and boxes, eye swinging, eye collision at a specific point on other objects like Platforms, floor etc. The reason for this was that we then would have a lot more control over what we could do or couldn't do with the game. If we had used a physic engine to help us with the physics, we would have been limited to the features the engine has set for us.
A consequence has been that we have had to spent a lot of extra development hours, which we maybe could have saved and used on more design planning, for example to make an analog tutorial version of the game, which could have been thrown away easier than if with a fully functional developed tutorial version.
For the collision detection between Lou and boxes/doors and between Eye and boxes/buttons we have saved a lot of time using the ActionScript build-in functionality Hittest, that checks if Movieclips intersect with each other.
Parallax Scrolling
Parallax scrolling is a special scrolling technique, that uses different layers, where the background layers move slower than the foreground layers, to give a 3d kind of effect. This technique is used in all 3 levels of the game. The foreground contains all the graphics for what Lou, boxes and the eye can collide with. The middleground and background is just graphic, and is not a part of the overall collision detection.
The parallax scrolling forground for the torturial level
The parallax scrolling middleground for the torturial level
Eye
Limited View
Currently we've got a working version of the limited view, connected only to Lou and not the eye. Apparently, ActionScript cannot add more than one mask to each layer in the .fla file, which basically rules out limited view dependant on both Lou and his eye. That being said, it seems that the desired effect can be achieved by hacking flash. Either we can duplicate each layer in the game and apply two types of masks to each, or we can dynamically draw a complex mask for each iteration. The latter involves creating x number of mask variables, x being the number of layers in the game, and then, on the fly, applying each variable to the corresponding layer…
The problem with both solutions are, that we will get a lot of redundancy in the code, not speaking of potential conflicts with already existing implementations. Furthermore, it will take quite a while to implement, which is why we should consider alternatives.
Thomas suggested, that the view distance might increase, when the eye is shot out, and vice versa. In any case, we should make a decision, as the limited view deal will have a huge impact on the level design and gameplay in general.
Example of tech-related difficulties
This case study describes how different parts of code and animation can create problems, in spite of each part being created with flexibility in mind. It also illustrates how versatility can be extremely fragile and quickly be shattered by inflexible methods, like the many easy-to-use features provided by Flash and ActionScript.
The collision in the game was initially designed so that the zombie coordinates were measured against a matrix. The fields in this matrix, henceforth referred to as blocks, each contain a number that corresponds to the material of the block. Initially we planned to have different kinds of materials (like for instance a material that can only be passed from below, a material that can never be passed, a material that the eye doesn't stick on and so forth). It turned out that Lou was too immobile for the different types of materials to actually have a significant effect, so we scrapped these plans to stick with two types; blocked and not blocked.
Note that this structure allow for easy expansion of the code - if we for instance wished for at type of material that would teleport Lou or launch him into the air we could merely associate a new number with our material and expand our collision check to treat this number in a particular way.
The initial collision method was chosen as it allowed for more flexibility (which might come in handy when we needed to calculate swinging). How many blocks Lou occupies vertically or horizontally was determined by a few variables, and hence changing the dimensions of Lou (for instance when crouching) would be rather easy.
For the collision with objects (like the boxes and body parts) we went with the somewhat simpler flash "hit test"-method, which lets us know whether or not the outline of two MovieClips overlap. Depending on the relation between the positions of the two colliding object and the type of the object (Lou might push a crate while picking up the nail gun) we then determine which effects in the game this should have.
These two forms of collision worked just fine alongside each other. They did not work so well with the logic for crouching though: Our graphics artist had created a movie clip of a walking zombie to replace the early static prototype zombie. He then produced a movie clip of a crouching zombie. Both had height and width equal to a number of the previously mentioned collision blocks. It was necessary to keep this as two movie clips because having both in one would mean a movie clip with crouching width and standing height, i.e. a larger movie clip than the actual animation. This would enable the zombie to push crates or pick up object over a distance which would appear rather unnatural and confusing for the player.
Creating crouching seemed easy none the less; all we would have to do was display a different movie clip and call the method for changing the dimensions of Lou (the height and width in blocks) and the collision logic would supposedly take care of the rest. We handled changing the animation by constantly keeping the animation we did not intend to display outside the screen. When wanting to exchange animations we would simply move the current animation out of the screen and drag the needed one in.
This created a conflict with the pickup logic - Lou would suddenly pick up object or push crates not displayed, simply because the flash hit test logic compares coordinates of movie clips, not the global coordinates we used for the "current" zombie. This was fixed by moving the various animations out of the screen vertically instead of horizontally (an easy solution that ruined the room we had previously made in the code for easily converting the game so that up-down scrolling was also possible). Furthermore it required additional coding to have both movie clips capable of picking up item (not having Lou pick up stuff while crouching would again be really unintuitive to the player).
A new problem occurred though - our graphics artist had somehow placed the point on the movie clip that corresponds to the x-y coordinates in the centre of the standing animation and in the top-left corner of the couching animation. This meant that the normal collision would appear rather confusing to the player, as Lou could easily crouch and ram 80% of his body into a wall while getting stopped once he was trying to drag his ass through. Changing this point where the movie clip is displayed turned out difficult for animations as the similar points for each independent part of the animation is displayed in relation to this point. Every part would move around and basically our graphics artist would have to start from scratch.
At this point a general consensus was reached that the game would not really lose anything by not including crouching.
A screenshot from the some ActionScript code in Flash
