Day 5: Python
January 6, 2010 by pekuja · Leave a Comment
This update is hours late. That’s because I slept really late yesterday and didn’t have time to make an update. So, it’s the following morning, and I’ve just got my code to do pretty much the same thing it did yesterday, but with more bugs. In a possibly dumb move, I decided to switch my code over to Python.
The idea of this move was to improve my productivity over time, although obviously today’s progress is hindered by all the porting I had to do. I do now have the thing mostly ported, except for my config file loader, but that should be pretty quick to port. I also seem to have discovered a bug in SFML’s Python bindings, which is preventing me from turning image smoothing off when I have the view zoomed in, like I do to get that nice pixelated look. So basically now the game looks like an ugly mush. I’ll look into fixing the bindings soon.
Possibly the biggest part of the port was porting the map loader, because I couldn’t use much of the old code, as I wouldn’t be using the same XML library or the same base64 decoding and zlib decompression. Luckily, I was able to locate an existing Python implementation of a map loader for Tiled’s TMX map file format, written by DR0ID. Making it work with SFML made me bump into another bug in SFML or its Python bindings, when the map loader’s implementation was such that it would split a tilesheet into separate images for each tile, which seemed to fail in SFML. I decided to change the implementation so that I would just use subrects when rendering the tiles. I think that’s at least marginally faster anyhow.
I found myself also writing some particularly ugly code, when I decided to implement my player class and state machine states as Python modules with global (module wide) variables instead of encapsulating the code in a class. I suppose I just feel dirty for having “global variables” in my code. Also, I guess really the whole “singleton” approach is just harder to extend. It made the state machine states pretty simple though, as they don’t have any state information of their own. They’re just a bunch of functions.
I’ll try to make another progress post later tonight. Consider this yesterday’s post.
Day 4: Config files
January 5, 2010 by pekuja · Leave a Comment
So, today, I wasted a whole bunch of time reconsidering my choice of using SFML. The joystick support is kinda iffy. So, after I did that, I decided it was a waste of time, so I’m still using SFML. I hope the joystick support gets fixed.
Anyways, back to actual coding business. Today I wrote a simple config file system. Basically, I load up a config file, and then I have access to settings by name. I also have a default value in the code, so that the game will still run if there’s no config file. I haven’t added config file saving yet, but I think that’s next. That way, I don’t ever have to manually write the config files, but I just write the default values into the code, and the code generates the config files, which I can then experiment and fiddle with. My goal is to have no data hardcoded into the source code, apart from the fallback default values.
Currently, I have no definite plan for tomorrow. A likely task is improving upon the components I have built so far. Or, you know, work on actual gameplay or levels. 
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.