Day 25: Grenades

February 11, 2010 by pekuja · Leave a Comment 

mato_grenade

The game got its second weapon today. It’s a basic grenade. The red circle in the screenshot is the explosion. I should really make a better explosion effect, but that’s not important right now. The grenade bounces pretty nicely off walls, and deals more damage than the assault rifle. With the introduction of the grenade, the player can now switch weapons with the face buttons on an Xbox 360 controller, with more crucial functions on the shoulder triggers and bumpers, so that you can keep moving and aiming while jumping and shooting, even though you have to stop aiming to switch weapons. A pretty decent tradeoff I think.

I had kinda promised to make a pre-alpha release over the weekend, but I decided against it because currently not many people could enjoy the game because you basically need two Xbox 360 controllers and a friend to play against. I am realizing that this won’t be a common setup for people, so I’m hoping to create an online multiplayer mode for the game, although in a lot of ways the purpose of this project is to create a game much like Liero that you could play with a friend in the same room without the limitation of having to use a jam-prone keyboard to play.

Implementing a couple more weapons should be pretty easy with my current codebase. The remaining major hurdle is implementing a grappling hook or “ninja rope”, if you will. It’s going to be an essential part of your mobility in this game. On the ground, you’re slow, so you’ll want to use the grappling hook to fly through levels that have been blown to smithereens.

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.