I’ve failed two LDs in a row now (first due to lack of motivation since my idea was kinda badly executed and second due to lack of time thanks to college), and looking back both of my games were rather uninteresting ideas. The evasion one for alone might have been cool, but it was dull and the controls weren’t overwhelmingly responsive. The game was rather simple, implementing a zelda or ff style overworld where you move one tile at a time, everything is one tile large, and so on. I find this a bit dull, and the only reason why I did it is because I couldn’t do anything but it, as I’ve failed horribly in the past to implement even the bare basics of collision — colliding AARs. I’ve decided to change this however, and I actually went out and did a little research on the subject. My algorithm isn’t overwhelmingly complicated and probably a bit inefficient in places, but it at least works. To attack the responsiveness problem some, instead of polling input, say, every 1/30th of a second, I poll input as fast as possible now (and simulate the world likewise, scaling speeds based on your current framerates), and since I don’t simply just set the current move or queue a new move for after that should there already be a move, you can move on diagonals, and movement is no longer tied to 16×16 blocks. The player movement is quite smooth now, and for once the collisions between entities and entities->tiles
Speaking of 16×16, I decided to also step up the way graphics will be generated. My screens were always internally 256×256 (the resolution was actually just as large as the window, though the coordinate system in OpenGL was set up so that one coord was roughly equal to one pixel on a 256×256 screen) but I’m stepping it up to a large base (640×480 minimum, maybe larger), since I’m not really a fan of generating 16×16 tiles. Tiles in the experimental engine are actually smaller, 8×8, but I don’t actually intend to use tiles as graphics, only for collision and maybe special properties for certain places (water, perhaps). The graphics are applied on a similar 8×8 grid, but they will have slightly fancier features like alpha blending for slightly better terrain, and if I don’t tie textures to individual tile types (like say, Minecraft or whatever), this can help ease repetition because one can apply larger textures over a range of tiles, If I jump into the current LD though, I’ll probably just stick with 16×16 tiles anyways, but I’ll probably stick with the higher virtual resolution so I can make higher resolution characters or whatever.
I don’t think there’s any time for this anymore, but one thing I want to experiment with for the next LD is the usage of popular utilites and engines for game development. Things like Unity and whatnot. I can kinda write some of the stuff I need on my own, but there’s a wealth of stuff out there that just works already, so why not? Unity sounds fantastic, and given that there seems to be development on a linux version, it would be more portable than my current way of doing it (C# with .net and OpenTK (which I *think* might work with mono but I’m not sure offhand)), since I could at least target the big three platforms. I guess I could switch to Java for my cross platform developement, since LWJGL could take the role of OpenTK, but honestly, my Java knowledge is just a bit lacking and simple things like importing and binding textures tends to be a pain for me, and I’m going to presume these types of utilities can help with some things like this (though I may be wrong, correct me if such!)
And this experimental game will hopefully feature the magical gunslingers with shotguns I promised for ld23, heh. There will hopefully be a fair range of weapons from swords to maces to shotguns and more! And hopefully the tracers won’t be huge diamonds this time around!