EPTPart Two - Technical Foundation
Part Three - Game Design
This Week
Hello again TeamLiquid!
Welcome back to my blog about the development of The Adventures of Sam the Pirate, the 2D platformer I'm creating as the final game project for my Bachelor of Software Engineering degree. Last week I covered some of the initial game design thoughts for Sam the Pirate. This week I'll be talking about how input events are handled, and the start of writing the physics code for Sam the Pirate.
Input
Handling input events in Sam the Pirate is designed around the observer pattern. Any class I create that needs to know about input inherits from an observer interface, and implements a Notify function on that interface.
class IInputObserver
{
public:
IInputObserver() {}
virtual ~IInputObserver() {}
virtual void Notify(SDL_Event* _e) = 0;
};
class CPlayer : public IInputObserver
{
public:
CPlayer();
virtual ~CPlayer();
virtual void Notify(SDL_Event* _e)
{
// Handle the event.
}
};
The CPlayer class then registers with the input manager, and the input manager notifies all observers whenever an SDL_Event happens. SDL_Event is a structure that contains all the information related to the event, like what type of event, key down, key up, controller joystick axis movement, etc, and any further information related to that event, such as what key was pressed/released, what direction the controller joystick was moved. For instance, basic left/right movement from pressing the left/right arrow keys would be detected like this:
virtual void Notify(SDL_Event* _e)
{
if (_e->type == SDL_KEYDOWN)
{
switch (_e->key.keysym.sym)
;{
case SDLK_LEFT:
// move left
break;
case SDLK_RIGHT:
// move right
break;
}
}
}
Currently, observers get notified about any event. I did consider breaking it up, so they could register for specific event, say keyboard input, and only be notified about keyboard input, but given I want to get the physics done (or mostly done!) before christmas, decided I don't have time to do that. It would certainly make things more efficient however.
Starting the physics
So when I started working on the physics I had a couple links from some previous research into whether or not I should use an existing 2D physics engine, one of which included a tutorial on using Runge Kutta, or RK4 to handle movement. We'd briefly covered RK4 in our physics paper, so I thought this sounded good and followed the tutorial. Upon implementation however, I ran into a couple of problems.
The first problem cropped up when I noticed, that even though I only have horizontal movement implemented, my character would gradually travel up the screen as I was moving it back and forth. It turned out, that for whatever reason, it wanted to head in the direction of (0,0) on the screen, which is the top left corner.
The second problem cropped up when I changed the fps to a fixed value around, or below, the fixed rate the physics was being calculated at, as covered in the 2nd tutorial I followed. When this happened, the character would either speed up or slow down, depending on which direction the fps changed. Obviously this is not desired behaviour, the character should behave the same regardless of if the fps is fixed or not.
With these two problems in mind, and after a bit of thinking on how to solve it, I realised that actually, RK4 is far too complicated for what I want to do. I don't need the level of accuracy that RK4 can provide, so I'm scrapping it, starting over and keeping things much simpler. This has cost me a couple days of work, but that's ok! I wasn't expecting things to always work out the first time anyway. I'm planning on implementing acceleration, force, gravity etc, but as simple as possible. Just good enough to get characters behaving how they should.
The plan is still to have a character moving around and jumping on platforms by christmas, and I'm still confident of being able to achieve this. I had been planning to have an interface framework setup by then too, but I don't think that'll be happening.
What's next?
Next week I'll go over where I'm at with the physics code, and cover some of my plans for the levels, including how you progress from one level to the next. I have plans for how the first few levels will be laid out on paper, so if I can figure out scanning works around here I'll look at putting up a couple of those as well.
Keep up to date!
Be sure to follow me on Twitter, and like the Facebook page to stay up to date on future content and blog posts when they happen. If you have any questions don't hesitate to ask, either through Twitter or Facebook!
