Thursday, May 19, 2011
New Enemies, Miniboss
The latest build has some new enemies. In the forest, there will be 5 standard enemies:
1. Spider - paces back and forth between walls / ledges. Hits with touch.
2. Jumping Spider - Moves towards player, constantly jumping. Like the flying turtles in mario.
3. Throwing Bandit - Paces. Throws a dagger.
4. Slashing Bandit - Paces. Slashes his sword if you get too close.
5. Flying Birds. These "home" in on the player. I'm thinking of having these continually spawn from "nests" that must be destroyed.
I also added the miniboss that was alluded to in the previous post. The mini boss is the bandit king, and will "drop" the pistol when he's killed (probably early on in the game, lvl 2 or 3).
Basically, he'll try to maximize his distance between himself and the player, and if he has an open shot for half a second he'll start firing. The only way to beat him is to corner him and bash him down with a sword.
Next step is designing the HUD!
I'm still unsure whether I'll get the lvl/power up system working for DBP. Procedural levels are also looking doubtful for the DBP build, especially since the worst case scenario would be if the judges got a non-functional map and couldn't play. It's probably better to invest dev time in polishing the pure gameplay, animations and graphics.
Thats it for now!
Saturday, May 14, 2011
Update - Boss Fight
So the goal for today was to get a basic boss fight up and running. Here was the "design document":
Here's the end result:
Lots of work still to do polishing everything up, but the boss can kill the player...and the player can kill the boss.
Also, got 4 directional parallax scrolling working, and locked doors with collectible keys.
The mini-boss (Bandit King) will be next.
Only 1 month left!!
Here's the end result:
Lots of work still to do polishing everything up, but the boss can kill the player...and the player can kill the boss.
Also, got 4 directional parallax scrolling working, and locked doors with collectible keys.
The mini-boss (Bandit King) will be next.
Only 1 month left!!
Monday, May 9, 2011
Platform Hack Alpha Progress
The build is coming together. Here's a quick playthrough I put together that shows the latest features.
Wednesday, April 13, 2011
Grapple Hook Revisited
There was a request to go into some more detail for the grapple hook. Original Post
So what I've done is taken a fresh copy of the Platformer 4.0 solution and added only the Grapple Hook stuff. The ZIP of the solution is attached below.
Basically, there are 3 new classes and some changes to Player.cs
The three new classes are in the GrappleHook Folder:
Collision.cs - This contains the core functions used "under the hood".
DrawPrimitives.cs - This class contains some functions used to draw various shapes. The main method used is DrawLine2.
Grapple.cs - This class contains the guts of the grapple hook logic outlined in the initial blog post
Changes to Player.cs:
There are some new member variables and a few methods. I tried to comment everything that was new with "GRAPPLE HOOK"
I also added WhitePixel.bmp to the Content/Sprites/Test folder. This is used to draw the line. (Also removed the music to cut down the size of the zip)
A few changes to the logic and style of the Grapple Hook:
1. The grapple hook "rope" will now shoot out 500 pixels at a rate of 2000, which is pretty much instant.
2. The grapple hook will stay extended as long as you hold the button (instead of collapsing back to 0). This makes it easier to attach.
3. You can't shoot the grapple hook if isOnGround = true. This makes use a little more natural and prevents the odd bug where you would attach and then the grapple curve would force you under the world or the tile below you.
4. The swing itself is slightly slower (using 2000 as the gravity constant).
Places for Improvement:
1. Some games have the grapple hook continually "shrink" while it is attached (Hook Champ, etc). This gives the player the feel that the grapple is "elastic". You could implement this by moving the player slighly "up" the rope every tick, and then re-calculating the Swing Curve. The hard part is getting the velocities right so the swing is smooth, since we're not using actual angular velocities / momentum, but the path of the pendulum curve.
2. Prevent the Grapple hook from attaching to horizontal walls. This would require a change to the GrappleCollision function (and the getLineCollision function), to only attach if the Grapple "hook" is colliding through the lower X plane, instead of the Y plane.
3. Better formulas for angular velocities entering and exiting the swing. Right now I'm using some cheap hacks (delta position -> velocity) to determine the initial and launch velocities when starting or exiting the grapple swing. Some real physics might make it feel a little smoother.
Download: GrappleExample.zip
So what I've done is taken a fresh copy of the Platformer 4.0 solution and added only the Grapple Hook stuff. The ZIP of the solution is attached below.
Basically, there are 3 new classes and some changes to Player.cs
The three new classes are in the GrappleHook Folder:
Collision.cs - This contains the core functions used "under the hood".
DrawPrimitives.cs - This class contains some functions used to draw various shapes. The main method used is DrawLine2.
Grapple.cs - This class contains the guts of the grapple hook logic outlined in the initial blog post
Changes to Player.cs:
There are some new member variables and a few methods. I tried to comment everything that was new with "GRAPPLE HOOK"
I also added WhitePixel.bmp to the Content/Sprites/Test folder. This is used to draw the line. (Also removed the music to cut down the size of the zip)
A few changes to the logic and style of the Grapple Hook:
1. The grapple hook "rope" will now shoot out 500 pixels at a rate of 2000, which is pretty much instant.
2. The grapple hook will stay extended as long as you hold the button (instead of collapsing back to 0). This makes it easier to attach.
3. You can't shoot the grapple hook if isOnGround = true. This makes use a little more natural and prevents the odd bug where you would attach and then the grapple curve would force you under the world or the tile below you.
4. The swing itself is slightly slower (using 2000 as the gravity constant).
Places for Improvement:
1. Some games have the grapple hook continually "shrink" while it is attached (Hook Champ, etc). This gives the player the feel that the grapple is "elastic". You could implement this by moving the player slighly "up" the rope every tick, and then re-calculating the Swing Curve. The hard part is getting the velocities right so the swing is smooth, since we're not using actual angular velocities / momentum, but the path of the pendulum curve.
2. Prevent the Grapple hook from attaching to horizontal walls. This would require a change to the GrappleCollision function (and the getLineCollision function), to only attach if the Grapple "hook" is colliding through the lower X plane, instead of the Y plane.
3. Better formulas for angular velocities entering and exiting the swing. Right now I'm using some cheap hacks (delta position -> velocity) to determine the initial and launch velocities when starting or exiting the grapple swing. Some real physics might make it feel a little smoother.
Download: GrappleExample.zip
Monday, April 11, 2011
Playtest
A new version of Zombie Bash is in playtest.
I was hoping to get it to market sooner, but I figured you might as well do the thing right the first time, even if it takes a long time (The Blizzard philosophy). And its amazing how time consuming it is programming High Score screens to work just right...
Zombie Bash Playtest
I was hoping to get it to market sooner, but I figured you might as well do the thing right the first time, even if it takes a long time (The Blizzard philosophy). And its amazing how time consuming it is programming High Score screens to work just right...
Zombie Bash Playtest
Thursday, April 7, 2011
It's a Trap!
Traps are essential for 2D games. They present a challenge for a player that can only be defeated by timing and patience, rather than reliance on gunpower.
I decided to build 3 different types of traps for Platform Hack. Moving Blocks, Spinning Blades, and Flame Turrets. Each of these uses slightly different technology to work, but since they were similar enough I crammed all the functionality into a single class, called Trap.
The Moving Block is the simplest type. Its basically just a moving tile that hurts the player on collision. Some games have blocks that "crush" the player, and can also provide solid collision from the other directions (top, sides). I decided against this type of falling block, since it would require implement a "crushing" system of player damage. Instead, if you touch the block from any direction, the player will be damaged. Good level design (encasing the falling block inside Impassible tiles) can be used in conjunction with the trap type to good effect.
The Collision is pretty simple:
The Update function contains the only interesting piece of logic, using Linear Interpolation to smoothly move up and then slam down as a funtion of the entire TrapTimer
The Spinning Blade is the next type of trap.
This uses slightly more advanced collision and update logic. Given the same TrapTimer, we do a full rotation of both the texture, and the Rotation Matrix thats use for pixel-based collision detection:
Update:
Collision:
Draw:
One of the "gotchas" of Translation matrices in XNA (or I guess any graphics framework), is being sure to multiple by a translation of the negative origin. Matrix.CreateTranslation(new Vector3(-p.Origin, 0.0f)) This is needed whenever the texture is rendered using an origin. You need to adjust the Translation Matrix in the same way, so that the collision detection is "synched" with the drawn texture.
The collision detection with rotation is right out of the XNA tutorial found here
Lastly, the most complex type of trap is the Flame Turret.
The Flame Turret is using both Beam collision and the particle system for effect.
Beam Collision:
The benefit of using beam collision is if you have something like bullets that travel quickly. If the bullet moves 30 pixels in a single update, is has the chance to pass right through an enemy without causing collision. a Beam object can be used to represent a "line segment" in order to do collision. Of course, you can always Draw the single dot as the bullet, it just uses the Beam object to do the collision.
Here's my Beam struct:
There are two vectors, A and B. There is also a list of coordinates between the beams, which can be calculated with the following method. Note: this may not be an optimal method, comments welcome.
A beam can represent either a bullet moving quickly across the screen, or a burst of flame shooting out of a trap turret.
We can determine if the beam hits a player (or enemy) using the following collision detection method (again, possibly not optimal):
The last piece of the puzzle is a method to get a bounding rectangle around the beam. You *always* need to do bounding rectangle collision before pixel-based collision.
We can check for collision between the player and the beam in the following way:
Finally, we want our Flame Turret to look cool. This can be done using Particle Effects.
The particle engine I've used is heavily modified from the Particle Sample. The details are a topic for another post.
But briefly, we spawn fire particles along the length of the beam:
That's pretty much it for simple traps. With good art and creative level design, you can turn these three features into some pretty dastardly challenges for the player.
I decided to build 3 different types of traps for Platform Hack. Moving Blocks, Spinning Blades, and Flame Turrets. Each of these uses slightly different technology to work, but since they were similar enough I crammed all the functionality into a single class, called Trap.
The Moving Block is the simplest type. Its basically just a moving tile that hurts the player on collision. Some games have blocks that "crush" the player, and can also provide solid collision from the other directions (top, sides). I decided against this type of falling block, since it would require implement a "crushing" system of player damage. Instead, if you touch the block from any direction, the player will be damaged. Good level design (encasing the falling block inside Impassible tiles) can be used in conjunction with the trap type to good effect.
The Collision is pretty simple:
The Update function contains the only interesting piece of logic, using Linear Interpolation to smoothly move up and then slam down as a funtion of the entire TrapTimer
The Spinning Blade is the next type of trap.
This uses slightly more advanced collision and update logic. Given the same TrapTimer, we do a full rotation of both the texture, and the Rotation Matrix thats use for pixel-based collision detection:
Update:
Collision:
Draw:
One of the "gotchas" of Translation matrices in XNA (or I guess any graphics framework), is being sure to multiple by a translation of the negative origin. Matrix.CreateTranslation(new Vector3(-p.Origin, 0.0f)) This is needed whenever the texture is rendered using an origin. You need to adjust the Translation Matrix in the same way, so that the collision detection is "synched" with the drawn texture.
The collision detection with rotation is right out of the XNA tutorial found here
Lastly, the most complex type of trap is the Flame Turret.
The Flame Turret is using both Beam collision and the particle system for effect.
Beam Collision:
The benefit of using beam collision is if you have something like bullets that travel quickly. If the bullet moves 30 pixels in a single update, is has the chance to pass right through an enemy without causing collision. a Beam object can be used to represent a "line segment" in order to do collision. Of course, you can always Draw the single dot as the bullet, it just uses the Beam object to do the collision.
Here's my Beam struct:
There are two vectors, A and B. There is also a list of coordinates between the beams, which can be calculated with the following method. Note: this may not be an optimal method, comments welcome.
A beam can represent either a bullet moving quickly across the screen, or a burst of flame shooting out of a trap turret.
We can determine if the beam hits a player (or enemy) using the following collision detection method (again, possibly not optimal):
The last piece of the puzzle is a method to get a bounding rectangle around the beam. You *always* need to do bounding rectangle collision before pixel-based collision.
We can check for collision between the player and the beam in the following way:
Finally, we want our Flame Turret to look cool. This can be done using Particle Effects.
The particle engine I've used is heavily modified from the Particle Sample. The details are a topic for another post.
But briefly, we spawn fire particles along the length of the beam:
That's pretty much it for simple traps. With good art and creative level design, you can turn these three features into some pretty dastardly challenges for the player.
Monday, March 21, 2011
Web 2.0 Stuff
My game - Zombie Bash - is currently in Playtest for XBox Live Indie Games: http://forums.create.msdn.com/forums/t/78185.aspx
Also, I caved and created a twitter account. I figure its really the only way to spread the news about the games I'm building outside the small group of people I know in RL who would care ;)
Follow me at @daydalus!
Also, I caved and created a twitter account. I figure its really the only way to spread the news about the games I'm building outside the small group of people I know in RL who would care ;)
Follow me at @daydalus!
Subscribe to:
Posts (Atom)