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:
1 | public Fixture fixture; |
Here is what the 3.2 version of our SetupPhysics method looked like:
1 2 3 4 5 | 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:
1 2 3 4 | 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:
1 | fixture.Body.BodyType = BodyType.Static; |
and replace it with this (once again, 'fixture' is gone so we update it):
1 | body.BodyType = BodyType.Static; |
In CompositePhysicsObject.cs the following:
1 2 3 | 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:
1 2 3 | 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:
1 | 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!):
1 | 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:
1 | public Fixture wheel; |
to:
1 | public Body wheel; |
Inside of the SetupPhysics method you can remove these two lines:
1 2 | fixture = FixtureFactory.CreateRectangle(world, (float)ConvertUnits.ToSimUnits(width), (float)ConvertUnits.ToSimUnits(upperBodyHeight), mass / 2); body = fixture.Body; |
and replace them with this line:
1 | 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:
1 2 3 | 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):
1 2 3 | 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:
1 2 | wheel.CollisionFilter.IgnoreCollisionWith(fixture); fixture.CollisionFilter.IgnoreCollisionWith(wheel); |
becomes:
1 2 | 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.
Imagine Me Coming to Xbox Indies!
Kinifi Games recently got funded on Kickstarer to create a game called Imagine Me:
Imagine me is a platformer game about a boy that wakes up in an unknown place. He doesn't remember how he got there or why but he will soon find out. Travel and discover the memories and adventures of a young boy in a lost world.
Imagine Me is being created with Unity and has plans to be released on Mac, PC, iOS, iPad and Android this holiday season.
Robot Foot Games (that's us!) has signed on to bring Imagine Me to Xbox Live Indie Games! Development will be done side by side with his version (instead of a direct port) and since this is only an announcement there isn't much to be shown at the moment. I'll be posting weekly progress updates here so subscribe to your feed of choice on the right to follow the development of Imagine Me!
All info relating to the development of the Mac/PC/iOS/Android versions of Imagine Me can be found over at kinifigames.com and you can follow him on Twitter @kinifi.
What does it mean to be “indie”
It popped up in a few places in the #xna community on twitter the past couple days with different opinions on what one might consider "indie" to be. I had my idea of what it meant to be indie but it's slightly changed after reading other people's perceptions of the idea.
-Gerald Terveen, via indienerds, says:
You are indie …
… if your game design decisions are not based on exterior influences (like money, a boss …)
… if the motivation to create a game comes from yourself and not an exterior influence (like like the need for money, or a boss…)
… if you´d rather give away your game for free then see it getting lost
… if you know everyone involved in the creation process by name
… if you are free in the choice of your distribution channel (no that does not mean you need to be able to publish via XBLA!)
… if nobody else has a sayso in any decisions in your “company” (if you want a yellow bath duck in your company logo, then you can have it!)
-Philippe Da Silva, via indiefreaks, says:
“Indie” is simply a translation of “Startup” or if you prefer, “Indie” is synonym of “Underground” or “Garage company”.
Basically, he says that funding, or having a publisher, is just fine and you can still be considered an indie. Developers creating games and targeting the Xbox Live Indie Games marketplace might be considered hobby or garage developers because of XBLIGs track record. Much time and effort has been made by many small companies but with little return because it's just the wrong target audience. He suggests putting more effort into finding a publisher "that will bring the visibility they need" to reach a more mainstream audience which will likely result in more exposure, more downloads and, in return, more sales.
-George Clingerman posted via Google+:
"This is easy. Indie games have less than 100 people in the credits."
It was actually one of his kids who came up with the response above but it's relating to the fact that indie companies are usually comprised of a small number of developers. 100 people might be quite a bit high but the premise of "indie = small" is still true. I would guess that 99% of "indie" companies are less than 15 or so people.
Before reading all these different opinions I think my perspective of what it meant to be indie was the following: a small team of less then a dozen people, self funded and a 'do what you want when you want' attitude.
Size. I think it's safe to say that the size of a company has a correlation to the indie meaning. Sure, there's professional companies, with a publisher, made of only a handful of people and there's probably companies out there consisting of 20+ people that are self-funded but I think those examples are few and far between.
Funding. When a publisher comes into the picture your ideas will likely be influenced, for better or worse, but the game will turn out differently than how you first envisioned it. A publisher will most likely push your game to be more polished, along with other things, in the long run but you might lose some of your 'initial vision' along the way. My initial stance on this changed because of Philippe's argument that if you want to reach a more mainstream audience, a publisher is a very good way of going about that. Trying to reach a huge audience of people is made much much easier through Steam or XBLA. Thinking you're going to reach the masses Minecraft-style is silly because that's a very rare situation.
Do what you want. Most indie companies start this way. You come up with a great idea, make a prototype (or possibly the whole game) and then decide what to do with it. If you want complete control with what you can do with your game then it's probably in your best interest to keep the IP close to your heart. Taking this route though is a path less traveled: you'll release it yourself, do the marketing yourself, do the support yourself, etc. Going the route of finding a publisher has its benefits in taking some of the load off of your shoulders but anyone that knows about the Super Meat Boy story also knows how terribly wrong it can go.