Day 9: Rudimentary physics
January 11, 2010 by pekuja · Leave a Comment
Sorry about missing a couple of updates. Was in a bit of a coding slump over the weekend. I think I’m back on track now though.
Today, I whipped up some basic physics for my character. Well, all it is is basically a jump action, but I did end up changing my state system a bit because I found it too clunky to have separate states for left and right facing states, so I changed that into a little variable, since I was adding internal state to the states anyhow because I needed to keep track of the character’s vertical velocity. I’m currently implementing the jump action with a separate jump state and fall state. The point being that the character can only hit a ceiling while he’s jumping, and only land on the floor when he’s falling. My state changes are currently a bit wonky because they end up taking a frame where nothing happens. I think the way to fix this is by making the collision checks *before* the character actually collides with anything.
Now that I think about it, adding the jump physics is actually a significant step, because after the collision detection and jumping works, I can actually start making levels and roam them. Well, after I add scrolling, but that should be easy enough.
In other news, I’ve decided that I’m going to stop switching libraries/environments and stick to one. I chose the winning library with a fair dice roll, and it ended up being my own library/basecode, which I’m calling Scratchy. That doesn’t really change much right now, because I was using it anyways, but I’ve now decided I won’t change it anymore. I wonder if I should do this for IDE’s as well… I’ve so far switched from Code::Blocks to NetBeans to Eclipse to NetBeans again. I also just switched from Windows to Linux, but that doesn’t change much unless I decide to develop on the command line.
Day 2: Finite state machine
January 3, 2010 by pekuja · Leave a Comment
I’m actually not quite done for today, but I wanted to write my blog entry in time before midnight.
So, today’s task has been writing a finite state machine for controlling the player character. So far, I have states for standing and running left and right. Pretty simple stuff. The player character starts in the “stand” state, which basically just does nothing right now. The state’s update function will also read user input, and if the player is pressing left or right, the state will change to a “run left” state or “run right” state. Currently they do nothing but move the player character around. I actually did have some rudimentary collision detection in before I decided to use state machines, but currently the player just floats in space and moves left and right.
I also attempted to create a player input system such that would handle joysticks and keyboards all the same. Doing that made me find some quirks in SFML’s input system. Namely, there is no way to ask for how many joysticks are connected, or how many axes or buttons they have. This is not a huge problem if I’m handling joystick input as events, but I’m instead reading the input state every frame. I have to say, I’m not quite happy with these limitations, but they might not be that big of a deal since I’m currently writing a single player game, but I will have to keep this in mind for the future.
Tomorrow, I will probably keep on working on the state machine, and I also have plans for two new systems: a sprite animation system and a configuration file system. The animations should be very useful with the state machine, so that a state can just fire off an animation and keep checking for when it’s done. That way the state changes can be tied to animations, and the state doesn’t have to worry about anything but starting the animation, not actually running it. The configuration file system should be very useful for separating data from logic. I currently have a whole bunch of hardcoded constants in my code, and I have a plan for a nice config file system that solves that.
Until tomorrow.