Ludum Dare 22 – Shadow
Ludum Dare, for those that don't know, is a competition to create a game in just 48 hours (for solo participants, teams can join the 72 hour competition). You have 48 hours to create a game from scratch but you can use publicly available libraries and personal code bases as long as they're open to everyone to use.
This was my first time entering and I wasn't real sure on how much I could get done in the time frame so I decided to start with something really simple and expand on that if I had more time. Overall, I'm pretty happy with how it turned out even though it has only a few sound effects and no music at all. I would've liked to get a story implemented but I just ran out of time. It was a good change of pace just being able to hack some code together without having to worry about cleanliness or robustness. 
You can view the submission and play the game here: http://www.ludumdare.com/compo/ludum-dare-22/?action=preview&uid=5580
Here's a playthrough of the game below, don't watch if you're going to play the game!
Level Editor For Your XNA Platformer Based Games
When I first started out a level editor was beyond my abilities (or so I thought) but thanks to Nick Gravelyn's Tile Engine video series it's actually quite easy to get the basics of a level editor set up! It was also the first time I actually made something out of WinForms so it was a learning process along the way. The editor is very simple and comes with all of the source code so if you were ever wondering how you might tackle making one yourself it's an excellent starting point to just tinker around and learn how the pieces fit together.
You can check out the project page on bitbucket to download and get more information but the general features of the editor are:
- Open and Save .txt files (the format used for levels)
- Paint/Erase/Fill tools so you can quickly change the appearance of your levels without editing them by hand
- Tiles are displayed as images so you can easily see what you're editing with.
The project comes with a default XNA 4.0 version of the PSK so if you just want to check it out and play around with the editor you can do so (if you have Visual Studio).
Check out the Wiki Page if you want to get it working with your own PSK-based game.
I also made a video showing off just how easy it is to add it to your game (Nomis: Legacy Islands). I'm adding the Editor to my first game (which was based on the PSK) in the video.
Farseer Physics Platformer 3.3.1 Update
It sucks when updates to a project break existing tutorials out there, so I'm posting the 3.3.1 update to @RoyTries XNA Farseer Platform Physics Tutorial that he wrote. @RabidLionGames updated it when the 3.2 update came out and a few things got broken in the 3.3.1 update so hopefully this helps out anyone who's looking for a working version in 3.3.1!
This post is just going to show the breaking changes from 3.2 to 3.3.1. Make sure you complete the original tutorial to get the project setup and read the 3.2 update to see the changes made in that version. Make sure to read the part about the unit conversion from 2.1.3 to 3.2 otherwise you'll have massively huge objects on your screen! After those 2 are done and set up there's a handful of changes below that you can make below to have a working version with 3.3.1.
Changes from 3.2 to 3.3.1:
PhysicsObject.cs
Find the following variable and remove it altogether:
public Fixture fixture;
Here is what the 3.2 version of our SetupPhysics method looked like:
fixture = FixtureFactory.CreateRectangle(world, ConvertUnits.ToSimUnits(width), ConvertUnits.ToSimUnits(height), mass, ConvertUnits.ToSimUnits(position)); body = fixture.Body; fixture.Body.BodyType = BodyType.Dynamic; fixture.Restitution = 0.3f; fixture.Friction = 0.5f;
In 3.3.1 we have a BodyFactory that will create a Body and attach a Fixture to it so we don't have a need for the explicit 'fixture' object that was declared at the top (that's why we removed it!). Your new SetupPhysics method should now look like the following:
body = BodyFactory.CreateRectangle(world, ConvertUnits.ToSimUnits(width), ConvertUnits.ToSimUnits(height), mass, ConvertUnits.ToSimUnits(position)); body.BodyType = BodyType.Dynamic; body.Restitution = 0.3f; body.Friction = 0.5f;
In StaticPhysicsObject.cs find the following line:
fixture.Body.BodyType = BodyType.Static;
and replace it with this (once again, 'fixture' is gone so we update it):
body.BodyType = BodyType.Static;
In CompositePhysicsObject.cs the following:
revJoint = JointFactory.CreateRevoluteJoint(world, physObA.fixture.Body, physObB.fixture.Body, ConvertUnits.ToSimUnits(relativeJointPosition)); physObA.fixture.CollisionFilter.IgnoreCollisionWith(physObB.fixture); physObB.fixture.CollisionFilter.IgnoreCollisionWith(physObA.fixture);
Gets changed to:
revJoint = JointFactory.CreateRevoluteJoint(world, physObA.body, physObB.body, ConvertUnits.ToSimUnits(relativeJointPosition)); physObA.body.IgnoreCollisionWith(physObB.body); physObB.body.IgnoreCollisionWith(physObA.body);
Once again, we simply removed anything that referred to the 'fixture' object since we're not using it.
In SpringPhysicsObject.cs find the following line:
springJoint = JointFactory.CreateAngleJoint(world, physObA.fixture.Body, physObB.fixture.Body);
and replace it with this (guess what... no 'fixture' object so we cut it out!):
springJoint = JointFactory.CreateAngleJoint(world, physObA.body, physObB.body);
Character.cs remains the same as the 3.2 version.
Now for the bread and butter, CompositeCharacter.cs. Change:
public Fixture wheel;
to:
public Body wheel;
Inside of the SetupPhysics method you can remove these two lines:
fixture = FixtureFactory.CreateRectangle(world, (float)ConvertUnits.ToSimUnits(width), (float)ConvertUnits.ToSimUnits(upperBodyHeight), mass / 2); body = fixture.Body;
and replace them with this line:
body = BodyFactory.CreateRectangle(world, (float)ConvertUnits.ToSimUnits(width), (float)ConvertUnits.ToSimUnits(upperBodyHeight), mass / 2);
a little further down in the SetupPhysics method you'll find these lines:
wheel = FixtureFactory.CreateCircle(world, (float)ConvertUnits.ToSimUnits(width / 2), mass / 2); wheel.Body.Position = body.Position + ConvertUnits.ToSimUnits(Vector2.UnitY * (upperBodyHeight / 2)); wheel.Body.BodyType = BodyType.Dynamic;
and you can change them to this (using the BodyFactory to create the Body and attach a Fixture. Since wheel is a Body instead of a Fixture now, we remove the extra ".Body" found in the bottom two lines):
wheel = BodyFactory.CreateCircle(world, (float)ConvertUnits.ToSimUnits(width / 2), mass / 2); wheel.Position = body.Position + ConvertUnits.ToSimUnits(Vector2.UnitY * (upperBodyHeight / 2)); wheel.BodyType = BodyType.Dynamic;
The last change near the bottom of the SetupPhysics method is to update these two lines since we're not using the fixture variable anymore:
wheel.CollisionFilter.IgnoreCollisionWith(fixture); fixture.CollisionFilter.IgnoreCollisionWith(wheel);
becomes:
wheel.IgnoreCollisionWith(body); body.IgnoreCollisionWith(wheel);
You can download a ZIP file of all of these updated classes here to check for differences if something didn't work.
Imagine Me Progress Nov 25th
Last week I talked about the Editor and what I wanted it to consist of and it's pretty much at that point right now! It has some more work to be done on it since a few things came up that I wanted to implement but first let's see what works.
This was the first time I really dove into Windows Forms with the intention of coming out with something I'd use on a regular basic. Nick Gravelyn has a video tutorial series where he creates a tile engine and an editor for it and it helped out tremendously since it's very similar to what I wanted to build. If you're looking to get into WinForms or you want to create an editor yourself I highly suggest checking it out! The Editor is based on the idea that each level is a map. Inside of that map there can be multiple layers. Right now the Editor only consists of a single layer and that's the display/collision layer. This layer only has platforms and static things that the player can collide but not interact with, so items/objects are not included in this layer. This way I can use the display/collision layer to create the platforms/walls/boundaries of the game and not have to worry about checking for items and such. My next task for the Editor is to create a layer of dynamic objects that the player can interact with. This will include blocks that the player can push to solve puzzles, etc.
If you remember from last week I described how I was going to work out collisions by doing a horizontal pass and combining all adjacent tiles into a larger rectangle. After that a vertical pass would be done to combine adjacent vertical tile. Here's what the collision looks like after doing a horizontal pass:
In this particular scenario you can see that the horizontal pass covers nearly all of the tile before even doing the vertical pass. There's plenty of room for improvement with the left column of tiles being the most obvious. Those should be combined into 2 rectangles instead of 15 but I got the idea I was shooting for implemented and it works in-game so it's good enough at this very early stage. After the horizontal pass, the vertical pass is done to cleanup any remaining tiles that were missed and combine them if they're vertically adjacent:
The above was simply a testbed to stress test and fix any bugs that came up with odd shapes. The level design isn't solidified so what a level may look like is still up in the air. What would be about 120 tiles or so is only 74 with this method with some vast room for improvement. I have a little character that I can use to jump around inside of here and everything seems to play out nicely besides an invisible collision box that seems to stay where my character starts...
This next week I'll get some dynamic objects implemented so I can move things with my character in-game and hopefully get some levels/puzzles setup so I can start testing those out.
Oh, and here's a screenshot of the Editor!
Imagine Me Progress Nov 18th
This week's update focuses on the level editor. It's the first thing that's being worked on so I can save some time later when it comes time to push out levels and levels and levels.
Before I even started to work on the editor I fleshed out some ideas on what I wanted it to do:
- Being a tile based game, it needs basic tile editing functionality (painting, saving, the basics)
- Play nice with Farseer Physics. Since Imagine Me will have physics-based puzzles I figured I'd jump straight into a physics engine and integrate that into my editor.
And that is about it. There's no reason to come up with this grand scheme and have no idea where to start so I'll start small and work my way up. Nothing too fancy, I just wanted to be able to pump out a level without having to edit a level by hand through notepad. Currently I have #1 all set in place so basic tile editing goodness is there. Trying to figure out how to tackle collisions with Farseer is the current brain teaser. Being a platformer game I could take the simple, yet inefficient, way and just say what 1 tile = 1 object. This means that for every tile in the game which the player can collide with there would be a rectangular static physics object acting as collision for that tile. Here's a basic layout I created for testing purposes:
Doing it this way I would be creating 80 objects and that's just for colliding with the platforms. That doesn't include items and other things you might collide with. What if I wanted my levels to be 4x as big as this? I haven't stress tested Farseer to see how far it can go but you can see how it could skyrocket pretty quickly. So why not start out by thinking ahead? Instead of creating a collision object for each tile I thought I should reduce this as much as I could to try and save some performance for later should the need arise. So why not just combine adjacent horizontal tiles into a longer rectangle like so?
Here, just a single pass is checking if there is a collision tile to the left/right of the current tile and creating a longer rectangle based on that. Simply combining tiles that are horizontally adjacent like the image above reduces the number of objects to 25. After doing the initial pass that reduces horizontally adjacent tiles we can now do another pass that will reduce single tiles vertically. Doing the vertical pass brings the object count down from 25 to 10! (And I don't want to hear anyone say "well... you could bring that number down to 9 with some better techniques! Going from 10-9 is a 10% decrease in the number of objects you're creating!") 
Stay tuned next week as I'll flesh out the editor some more and explain more in-depth how the Farseer integration works out.