First off, always having to use the number keys to change weapons can be a major inconvenience. Let's assume we're dealing with a gamer who hasn't rebound the controls from the standard wasd + mouse configuration. If this is the case, they have to take their left hand off the wasd keys, stop moving, and press the number they want. In the middle of a fire fight, the last thing you want to do is stop moving. This is why so many games also allow you to change weapons with the mousewheel. Sure you have to scroll through your weapons to get the one you want, but that's a very small price to pay especially when you consider that we're only dealing with five weapons. The upshot of that is that the player can switch to any weapon no more two two jumps. Implementing this was easy, but should have been easier. SFML wanted to be a jerk about handling mouse wheel events. Ten lines of code instead of five is a very small drawback compared to the many awesome advantages and features you get with SFML though.
Next I notice that the player's actual collision sphere is very tiny.
Aside from the overly stylized and highly unrealistic aesthetic of the player being able to be halfway inside a wall, there is another issue. If you look, you will notice that although I am firing the dual chaingun, only one chaingun shot is present. This is because the other one is starting inside of the wall. As you can see, this is a big problem for the gameplay and appearance. It should be easy to fix though, right?
Two days pass.
Okay, maybe it isn't quite as simple as it looks. See, Box2D doesn't let you control the mass of your objects. Instead, you add "fixtures" to the object, each with properties like density, size, shape, friction, restitution, etc. Box2D takes all of those fixtures and their properties and figures out the mass for us. The problem with this is that once I increased the size of the player's bounding circle to the appropriate size of about 300 times the original, the player's mass also increased to 300 times the original. This should be easy to correct though, right? Just decrease the friction or density, or maybe increase the amount of thrust the ship gets when the player is pressing a movement key, right? Well yes, this should be easy to correct, and those changes should correct it, but now we have another problem. Now whenever the ship runs up against a wall, it suddenly slides along the wall at a huge velocity. We're talking running into a horizontal wall with completely vertical motion and sliding to the left at three times the speed you hit the wall. This is worse because changing things back reveals that we had this problem before, just to a degree that was more difficult to notice because the mass involved was smaller. Want to know how this gets topped off? I have no idea where this behavior could possibly be coming from. Two days of investigation didn't even help much.
I guess now is probably the best time to write up some code that allows us to choose to see what's going on under the hood with the physics.
Blue indicates a barrier, green tells us about the player, and red is for enemies. This is effective, unbroken, and theoretically very useful. Also it does absolutely nothing to help me fix the bug at hand. At least now I know what Box2D sees in terms of bounding boxes and bounding circles: exactly what it is supposed to see. The unavoidable truth is that this bug has stumped me. It has apparently been around for quite some time, probably somewhere in my core implementation of the physics. Of course I have no idea where. Taking the physics system apart and spreading the pieces all over the room didn't help either. This is just another one of those bugs. You know, the kind that haunts you for months and then makes you feel stupid when you figure it out. I think I'll get back to setting up the enemies and come back to this problem later. It needs a little time to simmer in the vast pot of boiling awesome that is my mind. Dig my awesome metaphors?
--LazerBlade
No comments:
Post a Comment