Moving slowly forward August 6, 2010
Posted by Jesse in : Hero In Training , add a commentWe started work on a new test level. When it’s finished, I’ll be uploading to playtest on the Xbox Live Indie Games, so that we can get lots of feedback. I’ve got a new video showing off some of that level.
We’re having some technical difficulties with the videos we posted on Youtube. The video is running at half speed with distorted audio. Youtube says they have engineers working on the problem. So for the time being, I’ll post my update videos on Vimeo, instead. (I don’t have a paid Vimeo account, so I can’t embed high def, but you can see the high def version over on Vimeo.)
Hero In Training – Progress Update August 5, 2010 from Jesse Chounard on Vimeo.
Sloped platform collision July 28, 2010
Posted by Jesse in : Game Development , 6 commentsRecently on the XNA Creator’s Club forums there have been several posts on how to handle collisions with a sloped platform in a 2d platformer. I wrote up a short description of the system I’m using:
How to determine if a player is about to land on a line segment:
What we need:
- Foot position of the player. (Bottom center of the player’s collision rectangle works well.)
- Line segment we’re checking for collisions with, specified by its end points A and B.
- Player’s velocity.
Let’s get to it:
- Is the player moving down? If not, we can stop here.
- Is the player’s expected position (foot position + velocity) within the horizontal region of the segment? If not, we can stop.
- Calculate the interpolated Y position on the line segment of the player’s X position both before and after the move.
- If the Y position before moving is above the segment, and the Y position after moving is below, then the player is landing.
And today I’ve put together a quick sample project to go with that. You’re welcome to do whatever you want with the code. (License – Ms-PL.) I hope it’s helpful. Feel free to hit me with any questions.
Boss fight! July 6, 2010
Posted by Jesse in : Game Development , add a commentWe’ve added the first boss fight into the game. Bossfrog is a giant version of the existing frogs you’ve seen before. After taunting our hero, he proceeds to try to stomp him into the ground. Twice during the fight, he’ll roar with anger and summon a bunch of his minion frogs to join in the battle.
Here’s a video:
Enemies! June 3, 2010
Posted by Jesse in : Game Development , add a commentI’ve gotten two enemies into the game. I also added boomerangs that the player can throw to attack.
Bullyfrog is a frogman who simply runs across the screen. If he reaches the edge of a ledge, he’ll leap to the next ledge. (If he can reach.) He’s really quick, and not very easy to dodge. I think we’ll do a palette swapped version of this character who is a bit tougher and will stop to throw projectiles at the player.
Spikey is a big spike covered block who waits for the player to get near and then smashes down trying to squash them. I added a neat screen shake effect when he hits. He’s completely immune to boomerangs, they just bounce off of him.
Changing directions May 21, 2010
Posted by Jesse in : Game Development , 3 commentsIn the last few days, I’ve been looking at the best way to start putting the art into the game. For characters, the new animation system seems to be working really well. For the static background elements that Mollie has been drawing, however, the tiled system aren’t really cutting it. She’s put together a bunch of separate little texture elements, and the only decent way I could have gotten them into the game would be to composite the graphics in photoshop, and then break them down into tiles and add them to the game. While that would work, it would mean a large number of tile sheets, and it would be very cumbersome to edit levels.
I was left with two options:
- Add the ability to attach textures to the custom objects in Tiled.
- Change to a different level editor.
Option one sounds reasonable, and the source code is really clean and pretty easy to edit. But I’d need to add a bunch of functionality to support rotation, scaling, and draw order for the textures. It would take me awhile. After spending so much time on Demina, I’m very tired of working on tools. I want to write my game!
So I asked my friend Google for help, and I wound up finding Gleed2D. I’ve spent a few days playing with it, and it seems really nice. It supports all of the features I was looking for. It has support for a few primitive types, so you can set up region boxes, or collision polygons pretty easily. You can attach custom properties to any element into the editor, so the automatic game entity creation system I used with Tiled works perfectly without much change. It also has support for parallax layers right in the editor. Nice!
There is a pretty big drawback to Gleed2D, though. The creator uploaded a flurry of updates during July of last year, and then went silent. On the forums (if you dig through the heavy spam) are a bunch of requests for updates or access to the source code. But there’s been no response. This isn’t an insurmountable problem, since the editor is in an easily usable state, but it still stinks.
It took me a little while to get it up and running, since I had to rewrite the collision system to allow for slopes, but it’s looking pretty nice. Here’s a new work in progress video. (The graphics are just random stuff I had lying around.)
It moves! May 17, 2010
Posted by Jesse in : Game Development , 2 commentsOver the last couple of weeks, I’ve been working on a new animation system. Instead of using traditional 2d animations (where you replace the entire image each frame) I’ve switched to using a keyframe based skeletal animation system. While not the norm, this isn’t an uncommon practice (the same style was used in both Aquaria and The Dishwasher: Dead Samurai). Strangely, I was unable to find a good tool for creating the animations.
So I made my own, and I made it open source, so anybody can use it. It’s called Demina.
Using it, we’ve managed to make a little progress, and I can finally show you a work in progress video. There’s not much to see yet, but now that the animation system is usable this game should really start taking shape in the next few weeks.
More concept drawings May 2, 2010
Posted by Jesse in : Game Development , 1 comment so farI’ve got more concept drawings to share. I’m super thrilled about how these are turning out. These are the enemies for the new game.
Comments are welcome.
Character concept drawing April 24, 2010
Posted by Jesse in : Game Development , add a commentI’ve been dying to share what I’ve been working on, but I don’t have permission to share the placeholder art I’m using. Luckily, my wife has joined the project, and I have something great to share. Here’s a concept drawing of the main character from the game we’re working on.
I’m beyond thrilled with what she’s done so far, and I’ll share more as I can.
Game actor state management April 14, 2010
Posted by Jesse in : Game Development , 1 comment so farI could use a little advice.
Slowly but surely, my new game is starting to take shape. Recently, however, I’ve run into a bit of problem.
In Being, controlling the state of a game actor (both physics and animation) was very straightforward. After all, there were only a few options. Standing still, walking, jumping, and reacting to taking damage. There was no special work to transition between those states, and they were all very clearly defined so there was never any ambiguity about the status of the player.
I started out with a switch statement. Here’s a trimmed down version:
switch(state)
{
case State.Idle:
if(playerHit())
{
state = State.Hit;
velocity.Y = HIT_VELOCITY;
playAnimation("Hit");
playSound("Ouch");
}
else if(playerJumped())
{
state = State.InAir;
velocity.Y = JUMP_VELOCITY;
playAnimation("Jump");
}
else if(playerLeft())
{
state = State.Walking;
direction = Direction.Left;
velocity.X = -WALK_VELOCITY;
playAnimation("Walk");
}
else if(playerLeft())
{
state = State.Walking;
direction = Direction.Right;
velocity.X = WALK_VELOCITY;
playAnimation("Walk");
}
break;
case State.InAir:
...
}
You can see, for even something as simple as this basic player, this becomes a very long chunk of code quickly. I read an article showing how I might break each state up into a class. You’d have a basic ActorState class, and derive from that to have an IdleState, InAirState, WalkingState, etc. This would simplify a few things, since any transition effects of changing state would be handled in the OnEnter method of the correct class.
An example of that:
class WalkingState : ActorState
{
public override void OnEnter()
{
playAnimation("Walk");
}
public override string Update(GameTime gameTime)
{
if(playerRight())
{
velocity.X = WALK_VELOCITY;
direction = Direction.Right;
return "Walking";
}
else if (playerLeft())
{
...
}
...
return "Idle";
}
}
Well, that works, and certainly looks a little cleaner to me. But now I’ve got a whole mess of classes in a really big file, or I can stretch the player’s state code over a whole mess of little files. And if I do that for every Actor in the game, it would be a huge nightmare to find anything if I needed to make a change.
And now my big problem. While simple, my new game is significantly more complicated than Being. Currently the player can stand idle, walk, jump, double jump, and throw weapons. I’d also like to add wall jumping and possibly melee attacks. This pile of options leaves room for all sorts of ambiguity, as well as a bunch of transition issues. My code is starting to become unwieldy and impossible to maintain. I know it’s time to refactor, but I’m not really sure how to make it better.
And this is still a pretty simple game, all things considered. I can’t imagine how complicated things are in a modern big budget game.
Since every game needs this sort of system, this is a pretty well solved problem, right? I welcome all advice anyone wants to share.
Tiled Map Editor (Part 3) April 1, 2010
Posted by Jesse in : Game Development , 6 commentsUpdate: Due to recent updates of the TiledLib project, the inline code below will no longer work without a few modifications. I may update it at some point in the future, but even in the current form, the concepts are still valid.
Since my last post, Nick has uploaded the TiledLib project to CodePlex. There have been a bunch of pretty cool updates. You should check it out!
I’ve been having a blast playing around with a new game using Tiled as my level editor, and it’s been a great opportunity for me to play around C# features I’ve never had much use for, but wanted to learn about. In my last post, I showed how we could use reflection to find classes that matched the types in our Tiled map objects, and automatically generate them. In this article, I’ll take that a step farther, and do the same thing to automatically fill out the properties of that class.