Day 24: Splitscreen mode, some initial HUD elements, random levels, death
February 6, 2010 by pekuja · Leave a Comment
Quite a bit of new things this time. To make the game more like an actual game, I’ve added health meters to the players. They will die if their health reaches zero, granting the opponent a single point, and relocating them in a random location on the map. For this functionality to actually make sense, I’ve also added initial HUD elements that show the player’s name, health and score. And regarding randomness, I have now added randomly generated levels. I randomize some holes into the map, place some random rocks, and that’s pretty much it. When a player spawns into the level, an appropriate hole is created. While I was at it, I added a split screen view and made the level larger than the screen. No minimap yet though, so it can sometimes be kinda hard to find your opponent. I’ve also made some initial sound effects with sfxr, but I’m not quite happy with them yet, so I’ll probably have to think about them some more later.
Day 23: Simpler collision detection, arm redrawn
February 5, 2010 by pekuja · Leave a Comment
After struggling with the collision detection and response, and after realizing the collision detection was the single most expensive thing my game was doing each frame, I decided to switch to a simpler method. Madgarden had earlier suggested on IRC that I should try a plus-shaped collision shape. One vertical line of pixels, one horizontal line of pixels. This seems to work quite well, especially since I can keep checking pixels until I find a large enough area to fit the player sprite. That means that determining the player’s new location can be done at the same time as detecting whether there’s a collision at all. The only real problem I’ve noticed so far is that I can’t make the player climb steep slopes, because he needs to have ground directly below him, so steeper slopes than 45 degrees just are unclimbable due to the nature of the collision shape.
Another thing I fixed was the mole character’s arm. I had previously made the arm a part of the gun sprite, so that the arm would rotate when you aim. The rotation looked ugly though, especially since I couldn’t use any filtering on it as that would make it not fit in with the pixeled main part of the sprite. The solution was to draw a higher resolution version of the arm and gun, and use that unfiltered. This improved the results a lot, and also made me wonder whether it would be feasible to make higher resolution graphics all around. I think I’ll pass on that for now though. Maybe later.
The game is still lacking some core stuff. Namely, the players don’t take any damage or die, there is no score keeping, and there is just one weapon. That’s probably the order I’m going to start implementing these in. After I have those, the rest is all polish. 
I’m hoping to get some sort of a pre-alpha release out this weekend.
Days 20-22: Global Game Jam
Well, I kinda forgot to post during the weekend, but I attended the Global Game Jam. Specifically the local jam in Tampere. The event was very well organized and we had lots of fun. Our group was three people: Vilma Pekola as our visual artist, Juhani Hujala as our game designer, and myself as the programmer.
We went with a sort of mix of 2D and 3D for the visual style. The game is in three dimensions with perspective, but all the graphics in the game are flat, like a pop-up book. The game was put together using the Unity 3D engine. Most of the code is in C#, but some of it is Javascript. I think Unity helped a lot in putting the game together. We got some of the core elements into the game in just a few hours. The most interesting part code-wise for me was probably the string with the lanterns. I started out trying to make it a physical chain of little nodes, but it had problems, because the string would fall to the ground or act up when pulled around corners. The way I ended up implementing it is to just have the string and lanterns floating in the air, but I did attach them to spring joints so that they would sway a little, like wind was moving them. Another cool thing I added was to make the buildings turn translucent when you walked past them. That way you could still see what you were doing when you were behind a building. In retrospect I should had probably made that effect even stronger, but it works decently well even as it is.
The game is quite short and simple, but then that’s usually what you get when you have a 48h time limit. I’m very happy with the result though, as it is a complete game, and not missing any necessary features. When you’re working quickly like this, there’s always a high chance that you end up not having the time to implement some crucial thing, or that something breaks at the last minute.
The game is playable at: http://heygods.pekuja.com/
The game’s page at the GGJ site is at: http://www.globalgamejam.org/2010/hey-gods-follow-light
Day 19: New main character
January 28, 2010 by pekuja · Leave a Comment
I was thinking that the worms are kinda boring looking and make the game feel like an exact Liero-copy, which it doesn’t have to be, and probably won’t be. So I’m making it a MoleZ clone instead! Just kidding, but I did draw a new player character sprite that’s a mole. I kinda like it, although I need to work on it still. I think I’ll make the mole hold the gun single-handed to avoid having to figure out how the other hand should move in that case. I do need to animate the feet, and maybe make the nose bob around a bit when he runs. I think maybe since his other hand is free, I could make it wave a little when he digs. I’m liking this character a lot better already. Lots more possibilities for expression. Not that worms can’t be expressive, but I think they’d start looking a lot like the worms in Worms if I made them all cute and expressive. You may notice I also added drop shadows to the level. I might try them on the characters too. It’s pretty easy to do with OpenGL.
Day 18: Collision woes.
January 28, 2010 by pekuja · Leave a Comment
Well, I decided to ditch Box2D for this project. I could had probably made it work somewhat, but it’s probably a bad idea to try and vectorize a pixel based map like that. What I’m still pondering about is if the game would work better or at least as well with completely vector based levels. That of course does make level creation and destructibility a bit harder, although for the level creation I could still utilize bitmaps and the marching cubes algorithm though. I just wouldn’t be using it for the internal representation. The upside would be that in-game physics would be easier. I’ve now gone back to my own collision detection code and physics. It does work, but sometimes the worm gets stuck on things, or can’t jump even though it should be on firm ground. Of course, even with vector based levels I’d probably have similar problems. I just feel like in some ways working with vectors might be simpler because they are accurate. With pixels I need to basically make guesses about angles and such. Currently I try to guesstimate what direction the “wall” of pixels is, and I push the worm out bit by bit until it no longer collides with the map. If that doesn’t work, I just put the worm back where it was on the previous frame. I think that method might actually be more complicated than it needs to be, so I might still change it to something simpler that might work for the benefit of the playability anyhow.
My code is a lot better organized after this whole escapade. I’m only just now roughly at the point I was before I started though, but at least the collision detection is better now.
Day 17: Insert Löve pun here
January 25, 2010 by pekuja · Leave a Comment
So, today I decided my code was too much of a mess, so I would refactor and clean it up. I also thought at this point that it would be a good idea to start using Löve’s built-in physics engine (Box2D) instead of doing my own physics, especially since later I’ll want grenades to bounce from walls realistically for example. In order to achieve this, I needed to vectorize the bitmap based level. That in itself was not a big deal. I had done a marching cubes implementation before so I had reference material, even though my old code was in a different language. Anyways, after writing the algorithm up, I found that it still wouldn’t run. Turns out there’s some strange problem with using very small or slim polygons in Box2D. I’m not completely sure what the exact problem is or how to fix it. The comments in Box2D source code say “Shifting the edge inward by b2_toiSlop should not cause the plane to pass the centroid.” and “Your shape has a radius/extent less than b2_toiSlop.”. After those comments there is an assert that fails and stops my game from running. It’s apparently something to do with continuous collision detection.
On top of my Box2D woes, I was constantly annoyed by the lack of documentation for Löve. Some functions have no documentation whatsoever, which makes it all but impossible to use them. The physics engine is probably one of the most problematic cases, especially since I don’t have a lot of experience with physics engines in general.
Currently I’m not quite sure how to continue. I hope I can make Box2D work for me somehow, because even if I ditched Löve, I’d still need something for the physics. Chipmunk maybe? Or I could just roll my own. Not like I need anything fancy.
Day 16: Shooting
January 24, 2010 by pekuja · Leave a Comment
I’ve added shooting and aiming to Mato. I’ve also added gamepad controls, tailored for an Xbox 360 controller. The game currently has just one weapon, similar to the chaingun in Liero, but I’ll be adding more as I go on. The aiming is done with the second analog stick, while you can use the first analog stick to move left and right as well as control the direction of digging, so you can dig straight down, for example. The gun has analog control over the firing rate, with a maximum firing rate of 8 bullets a second. The clip is infinite right now, but that will change for the final version.
One thing I’ve noticed when writing Lua code is that it’s pretty easy to write horribly bad code. I don’t have to define classes, I’ll just use create an ad hoc table with the necessary fields. My code is a horrible mess right now, but I am going to refactor it eventually. It’s kinda nice to just make a mess of it all and write quick hacks.
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.
