 |
| Here we see about 1.9% of the 48 Hour Competition entries for Ludum Dare 28. Mine's third from the left on the bottom row. |
(Less that 24 hours, but more than 12, at least. I wasn't needed continually at the movie shoot, and managed to get in a little work on the game there, and likewise a bit at the Solstice party. Still, if I had to estimate the total time I put in at the game, I... I guess I'd put it somewhere between 15 and 20 hours? I think?)
Oh, it's a flawed game, certainly. There's plenty I'd have liked to do differently, if I had more time. But it's a complete game, with five levels (though I'd have liked to have more, of course), and a working level editor.
If anyone wants to try it out, here's the game. And you can see the source files here, should you care to look.
 |
| The final art assets for the game. There's so much blank space mostly because at first I'd intended to have multiple frames of animation for the player and monsters... |
In a recent post, I mentioned that the standard for tile-based editors was to have the user choose a tile from a menu, and then paint with those tiles. I went on to opine that it made since that this method was so widespread, since was probably the most user-friendly way of creating tile-based maps. That being the case, one might expect that I would use that method in making a level editor for a tile-based game of my own.
I didn't. No, I fell back on the old Lode Runner method of selecting tiles to lay down via a hotkey. (Though, unlike in Lode Runner, the tiles are actually placed with the mouse.) Why? Well, not because I thought it was really a better approach. Really, just because time was limited and it was easier to implement. That's it. Worse yet, there's no documentation of what key corresponds to what tile, so you have to figure it out by trial and error, I guess. In case anyone wants to make their own levels, though, here's a bit of a cheat sheet: (Tiles with more than one key listed can be placed in multiple directions; the keys listed correspond to the directions up, left, right, and down, in that order.)
- Q
- Blank floor tile
- Z
- Wall
- P
- Pit
- Y
- Cracked Wall
- M
- Bars
- V
- Locked Door
- 2/4/6/8
- Fireball Machine
- W/A/S/D
- Monster Type 1
- T/F/G/H
- Monster Type 2 (fireball spitter)
- I/J/K/L
- Monster Type 3 (invulnerable to arrows)
- B
- Gem
- X
- Start
- C
- Goal
 |
| An early test of the level editor |
And hey, if I managed to finish a game on my first time attempting Ludum Dare, and after having gotten such a late start and having so many other commitments to deal with... yeah, I'm definitely doing this again next time. Unless it happens to fall on a weekend even busier than this one, I guess.
For the record, here are a few things I would have liked to have done differently, had I had more time:
- Better graphics. Obviously. In particular, I'd have liked the player and the monsters to be animated. I'd originally intended for them to be, but I realized there'd be no time to do multiple frames of animation if I still wanted to have time left for the coding. Had I more time, I'd also intended for the player sprite to have different graphics for the direction he's facing. And maybe also for the item he chose.
- More levels. This is another big one. Five levels is something, but it isn't much. I'd intended for a theme for the levels to be that there's a fairly obvious and straightforward way through with one item, but if you wanted to pick up the gem you'd have to use a different tool and take a less obvious and more tortuous route.
- Better collision detection. Yeah. Sometimes the player kind of slides his shoulder through a wall. I was trying to improve this right up until the deadline, with limited success. I think I know now what I'd have to do to fix it, but of course now I don't have time.
- Boundary enforcement. Unless your map is surrounded by walls, there's nothing prohibiting monsters, or even the player, from wandering off the edge of the map and getting lost. For this reason, I recommend surrounding all your maps by walls. (Though unfortunately I realized after the submission deadline has passed that there is a way to break out of the walls and wander out of bounds in one of the game's built-in levels... oh well.)
- More error catching in general. The program's pretty sloppy right now in general as far as letting the user do things it probably shouldn't. For instance, it's possible to put in multiple starting points in a map. This doesn't crash the program, or anything—basically, because of how the program reads the map, I'm pretty sure it should just use the lowest starting point, or in the case of a tie the rightmost of those tied for lowest—but it still should probably have been disallowed.
- As briefly referenced in the instructions, I'd wanted to have pressure plates that would create or cancel walls of energy or something elsewhere in the maps. I realized pretty early on that I wasn't likely to have time to implement that, though, which is a bit of a pity since it could have led to some nice puzzles.
- Sound. A scream when the player falls in a pit, a crackle of a fireball... would have added something.
- A more attractive intro and instructions. The all-text intro that's there now was of course quick and easy to create, but some graphics and a better layout would have greatly improved it.
- A better win routine, too. Slapping "You win!" over the screen in big letters is arguably somewhat anticlimactic.
- Cookies to keep track of what level the player reached if he quits the game and comes back to it later.
- Possibly implementing some simple data compression on the maps, so they're not all stored as strings exactly 256 characters long with lots of repetition.
- A catchier name. Seriously. "Underequipped"? What was I thinking?
 |
| The screenshot of my game I submitted to the Ludum Dare site. |
And for now... I'm going to get some sleep.
