Day 15: Digging holes
January 23, 2010 by pekuja · Leave a Comment
Hey, this actually is kinda like a game now. I can move around with the red worm and dig holes. Well, I guess I’ve got the destructible terrain covered already, even though I thought that would be a really difficult thing to nail. Frankly, I expected the simple approach of modifying the image on the fly not to work fast enough, especially because Löve is using OpenGL behind the scenes, so I basically need to upload the fullscreen texture to the GPU every time I modify the terrain. I guess the real hard part will be making the different weapons.
Day 14: Mini LD plans
January 23, 2010 by pekuja · Leave a Comment
So, Mini LD 15 started today. The theme is “Clone”, and the idea is to make a clone of your favoritest game ever. Well, Liero is definitely up there for me, so I’m attempting to make a quick clone of it. I thought about it for a bit, and I think I should be able to manage something like the original over the weekend, at least if I make some shortcuts. I might end up cutting destructible terrain, and the weapon selection will definitely be smaller than the original. Actually, it’ll be smaller by design also, because I want the selection to be actually somewhat balanced. The original is great, but not all of the weapons are exactly great. Would you ever deliberately pick a gun that creates mounds of dirt? Or a weak pistol with bad aim? I think maybe I would start with a selection like: mini nuke, bazooka, uzi. Uzi is the weakest of the three, but I’d probably make it more powerful than in the original. Perhaps make it an assault rifle.
I started some initial code in Lua using the Löve game engine. I haven’t used either before, but I’m mostly finished with the Programming in Lua book now, and Löve looks pretty easy to get into. I might still end up going with C code for the backend with Lua scripting, but so far this looks like a decent approach.
Day 13: Still learning Lua
January 20, 2010 by pekuja · Leave a Comment
Well, this isn’t actually day 13 by any reasonable calculations, since I’ve been reading through the Programming in Lua book every night. In a move some might call completely stupid and productivity killing, I am not actually writing any code except for small test stuff in a Lua console. I am also not a very fast reader, so I’m still working my way through the book. I’m about halfway through it. Most of the important stuff is in the beginning though, so in that sense I’m doing pretty well.
If you’re interested in Lua, the book is available online at: http://www.lua.org/pil/index.html . There is a more recent edition that covers 5.1, while the free online version only covers 5.0, but I’m making do with this for now.
Day 12: Learning Lua
January 17, 2010 by pekuja · Leave a Comment
I was going to take a little detour from the current project and make another game. Then as I started to copy parts of my other project to reuse in the new project, I noticed that some parts were such that I couldn’t directly reuse the code because the data was going to be different, so I started thinking of what I could do to make the code generic and just input data into it. This is something I was doing already in an earlier version of my project, but the config file format I was using wasn’t very flexible, so I gave it some thought, and decided on using Lua for my game data files. I want to add scripting capabilities anyhow, so this way I hit two birds with one stone. I also have some thoughts about making some editors for the data I’ll need, such as modifying parameters for animations. Optimally, I would have to do very little redundant boring work, and only focus on stuff that’s new for the project at hand.
Day 11: Miscellaneous small stuff
January 13, 2010 by pekuja · 2 Comments
Well, today I’ve done some small stuff. I adjusted the gravity so that my character can jump two tiles high. I also toyed around with the level editor and made some platforms to jump on. Added a little concrete road block that’s just background graphics right now. It also doesn’t look much like a concrete road block because it’s just hard to make identifiable things in 8×8 resolution. I also added a little attack swoop animation. The character himself isn’t actually animated for the attack, it’s more like a little arc that appears in front of him.
What I’m realising again when trying to figure out what to do next is that this concept is kind of boring. Parking garages aren’t very exciting, and it’s hard to figure out interesting things to add. I could probably add some small details here and there, but as far as actual level layout elements go, I feel pretty limited. I don’t know, maybe I don’t need that much. I could just keep using cars and lamps for level layout. Will see. I do have some ideas for this design, but I’m just not feeling it as a whole, so I might take a break from it and pursue some other designs.
Day 10: Fixing the physics
January 13, 2010 by pekuja · Leave a Comment
Well, yesterday I worked on the physics, but they were still a bit broken. Now I feel like they mostly work like they should, although the code is still a bit messy. Yesterday, the character would be able to stand on walls, because the collision check saw the tile right next to him. I eventually fixed this by making collision checks and checks for whether the character has walked off a ledge two separate things. Before I was running into the problem that checking outside the character was wrong for collisions, but checking inside the character was wrong for standing. While I was at it, I got rid of all internal state for the state machine states (yo dawg), and instead store all relevant information in the player character’s object. Another thing I realized I needed for the collision detection, was checking which direction the character hit a tile in. Basically checking whether the tiles being checked against have changed, and in which direction, so if the character moved over a tile boundary on the left, and is now in collision with a tile, we assume that it was a horizontal hit, which currently will bump the character back right a little. If the character instead had crossed a tile boundary on the bottom, we would assume the character just landed on a tile and change him to a standing state.
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 8: Animation again, and frame times
January 9, 2010 by pekuja · Leave a Comment
I was hoping to write a bit of a longer post tonight, but I ended up taking a long nap and not having time to write a lot of new code. I do have some things I want to write about though.
What I did do today is I rewrote my animation system to work with my new base code. It isn’t quite as nice as the one I was using previously, but I can always extend it further if I need more. My current system uses one animation per file, with the individual frames in a grid. The animation speed is based on number of game ticks to display a frame of animation. I could had used a temporal frame length instead, but I figured I don’t want there to be jitter where the actual frame length varies due to game ticks not being in sync.
I also added some code to fix my frame rate. Simple enough, just check how long it’s been since the last frame and sleep for an appropriate amount of time to fix the game loop to a steady frame rate. I bumped into some weird issues with my simple code though. I was fixing the frame rate to 30FPS, but as it turns out, the game was running at 60FPS instead. What’s even stranger, is I examined my game’s CPU usage, and when I had the game set to 30FPS, the CPU usage was very low. Just a couple of percent. When I turned the FPS up even just a little bit though, the CPU usage jumped to 50%, which on a dual core system means it was pretty much running as fast as it could. I’m still not sure what exactly was happening there, but I did eventually figure out that the problem was that the sleep function wasn’t really very accurate, so it was actually sleeping a lot less than I wanted it to, which is why the game was running at 60FPS instead of 30FPS. As for the CPU usage, I think what was happening is that when I upped the target FPS, I started to hit the vsync more often, for whatever magic reason. The graphics driver uses a busy loop to wait for vsync, so that hogs all the CPU it can get. It would be interesting to examine what was happening exactly, but the way I fixed the problem is I changed my sleep period to accumulate the error from previous frames. That way, even though the sleep function isn’t quite accurate, the error accumulation fixes the error on average.
Day 7: Getting Scratchy up to date
January 8, 2010 by pekuja · Leave a Comment
I’m continuing my work on my personal game development library. I ported my map loader from my earlier SFML code and also added some of the player state machine stuff in, so now I can at least move the character around a bit. I do still need to write my own animation code though, because the old code was SFML specific and the license had the Creative Commons Share-Alike clause, so I’d rather avoid that, since this isn’t a huge deal to write my own code for.
One thing I like about writing my own base code is that I get to finally learn some OpenGL. I’ve been meaning to learn it for a while, but just never got around to it. So far, not doing much with it. Just textured quads. I did figure out how to use vertex arrays instead of immediate mode, so at least my code should be pretty portable if I want to go embedded some day.
Day 6: Scratchy
January 7, 2010 by pekuja · Leave a Comment
So, after experiencing some minor problems with SFML, I got this itching to start from scratch with a lower level library. So, today I grabbed GLFW and wrote some simple code. I also grabbed Tom Seddon’s public domain image loader library so I could load textures in. I’m not very proficient with OpenGL, so I’m not exactly off to a blazing start, but I basically have a texture loaded and displayed on the screen. I’ll wrap the code in some nicer bunches to try and see if I can get actual work done this way.
I had this little epiphany today relating to this issue with wanting to write my code more from scratch. I think my problem is that I’m a bit too much of a nerd so I tend to care too much about minor technical details. I bet most people are fine with whatever tools they happen to have picked, but when I see some minor problem with a tool, I tend to form a dislike towards that tool, even if the problem is minor or doesn’t concern me at that moment. If I make my own tools, the only problem is not having enough time to implement everything I want. I think that might be fun though, so we’ll see. I’ll try this for a little bit, see if it boosts my morale or whatever.
