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.
Tiled Map Editor (Part 2) March 17, 2010
Posted by Jesse in : Game Development , 3 commentsIf you haven’t already, read part one first.
Now that we can load Tiled maps into our game, what can we do with the data? In his article, Nick mentioned that you can create layers dedicated to rectangles with attached metadata. In the editor, these are called object layers. (In the code, the type is MapObjectLayer, containing a collection of type MapObject.)
Tiled Map Editor (Part 1)
Posted by Jesse in : Game Development , 2 commentsA couple of weeks ago Nick Gravelyn posted a really great article explaining why he had given up on writing his custom level editor in favor of using the Tiled Map Editor. Along with the article, he uploaded some source code for reading Tiled maps into an XNA Game Studio based game. Since I’ve been procrastinating lately on my next game, I downloaded Tiled, grabbed Nick’s code and started tinkering.
Using some of my existing code, I’ve got a basic platformer up and running in just a few hours of work. If you’re interested in writing a tile based game, I’d recommend checking it out. However, I have a couple of note on using Tiled and Nick’s code:
- Layer names must be unique.
- Don’t use a tile size that doesn’t match.
- Be aware of file path issues.
Internally, the layers are stored in a Dictionary, with the layer name as the key. If you happen to have two layers with the same name (for example they might be named “New Layer” if you failed to rename them) you will get a thrown exception.
For some reason, when you create a tileset, Tiled allows you to specify a size different from the size you used when you created your map. The result in Tiled looks somewhat strange to me, and the example renderer in Nick’s code doesn’t handle it in quite the same way. I think this is an odd feature anyway, so my advice is to just don’t do it unless you really need to.
Nick included the ability to set a custom tileset path in the map processor, which is really handy. Unfortunately, Tiled stores the tileset path using relative paths, which can confuse Path.Combine. If you keep the map and tileset in the same folder, you can ignore this problem.
Alternatively, you can slightly modify the map processor. In the file TmxProcessor.cs, change line 27 from:
string path = string.IsNullOrEmpty(TileSetDirectory) ?
tileSet.Image : Path.Combine(TileSetDirectory,
tileSet.Image);
to:
string path = string.IsNullOrEmpty(TileSetDirectory) ?
tileSet.Image : Path.Combine(TileSetDirectory,
Path.GetFileName(tileSet.Image));
That’s it for now. In part two, I’m going to take a look at how you might go about creating game objects from the object layers in your Tiled map.