Bunny Spawning completed

I reworked the collision function and it now has better functionality for future use. The bunny system is almost complete, as far as spawning and killing bunnies onto the stage without errors of collision occuring. Tonight I’m going to have to probably put this project on hold while I finish up some other things, but I’m going to try and implement the plants onto the stage at least before it is do tomorrow. We have a meeting for class tonight to show the work that we have done so far, so I guess I’ll find out how much I need to add before tomorrow’s class.

Brain shutdown and Bunny Spawning

Inside of the game, bunnies will begin to spawn from various holes through out the stage. I had this implemented in my original version well enough, but with the new collision detection system, I need to develop a new way of spawning bunnies. The problem arises because the hole itself has it’s own collision sprite. As the bunny gets spawned, it obviously must be outside of the collision sprite of the hole, otherwise it is stuck in permanent “collide” mode and will never move. This is simply enough, but the real problem comes about when I want the bunny to spawn into a location where another bunny already is.

I think a simple rework of my collision detection function will make this work. As it is, the collision function is called whenever there is an update to the object array of the graphics engine and checks against a fixed color value. I need to update the function to be called by the object that is moving, instead of the engine, and pass an argument with a color value so that I can get more functionality out of the… function.

Unfortunately, my brain has shutdown for the day and I’m not sure if I can get it to keep working for the next couple of hours. I also need to work on my outline for Speech class that’s due this week, so I might have to put this project on hold for the rest of the day and get back to it tomorrow.

EUREKA!!

I had a moment of epiphany for the collision detection of my game. And it works! Perfectly! With over 100 objects on the stage. No lag what so ever from what I can tell.

How it works

Pretty easy actually, once I thought about it. Each sprite on the stage has a corresponding collision sprite, just like in the old system. The flaw I ran into was that I had to either A) Draw a separate collision buffer for each of the objects on the stage (resulting in lag from redrawing an image multiple times) B) if I drew a single map, then the object would collide with itself, since it would register it’s own collision sprite. The solution was so simple I can’t believe I didn’t think of it earlier.

Right now, the collision sprite is automated by the code. When I create a new sprite, a collision sprite is automatically made for it. The collision sprite is exactly twice the size of the normal sprite with a color of 0×88000000, IE semi-transparent. This way, the sprite will only detect a collision if the sprite interacts with another collision sprite. The value of a single collision sprite is not strong enough to stop it.

I’ve also created two functions to update sprite registration points (right now it’s just set for the middle of the image) along with updating a collision sprite. This way, in the future, when I start creating background images, I can make a custom collision sprite so that it doesn’t fill the entire screen.

You can see all this here. Pressing the space bar will show you the collision buffer instead of the frame buffer.

On a side note, it does seem that WordPress doesn’t like Safari, so I’m going to have to switch back over to Firefox when I want to post on WordPress. No big deal, just an inconvenience.

WordPress and Safari

So far, posting with the Safari browser has been a major headache. It seems that the functionality of the posting feature through WordPress’s posting forum is not compatible with Safari. I’m trying out firefox right now to see if it is any better. Hopefully I won’t have to go back and manually fix this post like I have had to do with my previous ones.

Check. 1. 2.

Simplified collision detection works well

So, I replaced my original collision detection system for the graphics engine with a more simplified version. What it does is given three arguments, an index value of the sprite to check collision for, a sprite type for the types of objects to check collision against and the distance to check against collision, it cycles through all objects on the stage. If the object is of the right sprite type and isn’t the sprite being checked, it then checks to see if it is at least within the distance in both the x and y direction. If so, a specific distance using the Pythagorean theorem (Yay for Pythagoras), is used to see if it is less than distance away. If so, it returns true. If not, false. Obviously a simplistic form of my previous version. It works very well though, with 50 objects on the stage, I see little to no performance decrease.

I was wrong

Collision detection isn’t the bane of my existance. My redraw functions were. It seems that a “small fix” I had implemented last night is what was causing all of my problems. Instead of, as I had originally done, calling my DrawBuffer() and SwapBuffer() functions on each EnterFrame event for the root mc, I had changed it to only be called when a sprite or objects is added, updated or removed from my rendering array. Once I implemented the automated movement function, the image was being updated many, many times more than it should have been. Once I switched back to my original onEnterFrame handler, it runs much smoother with collision detection enabled.

I still need to work on the efficiency of the system, though. I can get about 20 rabbits on the scene before it starts slowing down. Without collision detection on, I can get around 200+ on the stage before I notice any sort of performance decrease. 

Collision detection is the bane of my existance

Right now I’m trying to develop a collision detection system that won’t bog down the flash scene as the number of objects increase. The current method I’m using involves drawing a collision buffer, which then gets checked against by each object in the scene. Basically, I cycle through an array which contains the location of all objects on the scene and draw a collision sprite. This buffer is a grayscale image, and I simply check each movement location for each object against this image. If the pixel that the object wants to move into is black, no movement occurs.It works flawlessly as far as actually preventing collision, no matter how many objects are on the screen. The problem arrises because I have to draw a new collision map for each object in the scene. Each single objects collision map does not include it’s own collision sprite, so that it doesn’t register as colliding with itself. As the number of objects increase, the number of collision maps that have to be draw each frame also increases. This is a problem, since basically to draw 1 frame with 10 objects, I end up having to draw 11 frames. Not efficient at all.

Some ideas that have gone through my head include setting each collision sprite to a different color, but then the problem of depth buffering comes into effect. Since the draw order is determined by the objects location in the array, the last object draw will have it’s entire collision sprite overlap other sprites, thereby making it impossible to check if it is colliding with another object. What I need to figure out is a method for ignoring the object that is checking for collision’s collision sprite.

Update on Bunny Bomb

So, I finished creating a graphics system for Bunny Bomb. It works much better than my previous system. Still a couple of bugs to flesh out inside of the Bunny Class though.

Here’s the current prototype.

Here’s the old prototype.

The big differences between the two come from collision detection and the game field. In the old version, the game field was divided into individual cells. Anytime a bunny attempted to enter a pre-occupied cell, they would fail the movement. In the new version, bunnies aren’t bound to a cell and can move freely. Any time they come within a certain distance of another bunny (IE right before collision can occur visually), the bunny stops.Each bunny class has an automated random movement function using a setInterval. With the new version, since the bunny will not move into a collision, no visual overlay of elements occurs. The random movement function is simply called 1 second later (a variation exists between the various bunnies of between 0-500ms for this function call so that all bunnies don’t move at the same time), and the bunny has the possibility of moving in a separate direction.

Some bunnies may not move upon spawning simply because I created a random value between 0 and the stage width to spawn the bunnies, and some come into existance inside of the collision prevention radius. (Hence, they will never move since they are always “collided”).

The biggest difference between the old and new prototype comes from the visual rendering method. In the old version, each bunny class had an associated movie clip which would be updated each time the bunny moved. This created a lot of redraw for the flash player, and when the number of bunnies approached around 15 bunnies on the stage, there was a noticeable decrease in performance.

I worked around this by creating a simple rendering system using the BitmapData class. This allows me to only have one visual representation for each bunny which gets redrawn on the stage for each bunny. I created Frame Buffer using a Bitmap that gets duplicated onto the screen every frame (in the current prototype). This is for simplicity, and I will probably try to increase the efficiency of the graphics system as the project continues.

Just for proof of the performance increase, I created a second prototype which contains 40 bunnies to show the performance increase. This can be seen here.

New Actionscript Plan For Bunny Bomb

The issue I was running into was that of display update with all of my movie clips. My new plan is to test to see if the BitMapData class will allow me to create a frame buffer. This way, I don’t have to associate a movie clip with every single instance, but can just use a single movie clip, visually duplicated through the frame buffer, to draw all of the instances on the stage.

The big thing to figure out, though, is collision detection without using the built in collision detection function. I would much rather it use a circular detection pattern instead of the square one used by the default hittest() function.

After reconsidering…

After taking a step back to look at my code/organization, I’ve decided to start with a clean slate. Fortunately, this only sets me back a day. I don’t have much experience with a coding project of this scale. I did, however, figure out how to fix the array issue, but I also, from that, have figure out how to remove the grid all together to create a much better game field. This is the beginning of my project, which I’m going to probably work on for the next hour or so before I crash for the night.