Ratings (show detail)
Final (?) version
Starting room; no enemies implemented yet
Randomly generated maze; debug drawing code
No, I don't use Python between challenges. Why do you ask?
The game will crash whenever you move into a room in the same column as the cavern exit. The ability to actually finish a game was hacked in at the last minute, and not tested at all; clearly this sucks. :(
Open up "src/spGame.py" and change "self.__pmazeY" to "self.pmazey" on line 353. Then, it is actually possible to finish the game.The final line should read:
if (self.__pmazex == self.__exitX and self.__pmazey == globals.gMazeH - 1 and 3 in self.__player.heldKeys):
Another challenge over. Mood: foiled again!
At some point in the distant future, I will have to actually finish a game within the week.
For the first challenge, I bit off a bit more than I could chew, and feel that I did quite well under the circumstances: using a programming language I wasn't familiar with; making the decision to go 3D despite having previously never done much more than the odd rotating cube where OpenGL was concerned. I made something playable within the week, but it wasn't polished, and had a couple of reasonably major flaws given the game type - both aiming and collision detection were awful at high speeds, which is kinda fundamental for a high speed shooting game. How I placed second in the individuals is beyond me.
For the second challenge, I stuck with a 2D game and no dependencies beyond PyGame, but actually managed to do considerably worse in my opinion. In retrospect I should have been less strict in my determination to do everything myself; using an existing isometric map engine might have saved a lot of time. I ended up backtracking a lot and spending so much time getting something working at all that I never had time to make it actually feel like a game. To be honest, I'm surprised I placed only one lower than in the first challenge.
This time round, I think I did OK. I kept my expectations low at first: 2D game, non isometric, screen-by-screen progression instead of scrolling landscape, heavy use of randomisation instead of having to design levels. My use of PyGame was better, in the sense that I actually made proper use of SpriteGroups and the built-in collision tests instead of rolling my own. The biggest issue I faced was circumstances; specifically, the fact that I wasn't going to be anywhere near a computer on the last 2 days. Fortunately it only ended up being the last day, but by then my expectations had grown and my time hadn't all been spent productively.
It's really disappointing to know that I've uploaded something that isn't polished. One more day would have meant the third boss was implemented, even if not as elaborately as intended (the second boss is already more basic than originally imagined); sound could have been added; high scores might have appeared, and saved games if I really pushed myself, but probably not. There's code in there to disable various bits of the game logic, intending to have a more pure maze game as a second game mode, but I never had time to test it so it wasn't made accessible from the starting screen. The ship would REALLY benefit from some kind of graphical effect on the thrusters, since at the moment it just drifts around on what might as well be a strong breeze.
The fact of the matter is, I haven't actually played a Super Spelunker game to completion. If you go through the trouble of getting all three keys and the artifact, then get to the last room, for all I know the game crashes. Even if it works, all you'll get is some lame "congratulations" screen knocked up in all of 2 minutes. The maze size has been picked with little thought. I also have a sneaking suspicion that I might not have completely squashed the bug which leads one or more of the keycards sometimes not actually being on the map. The game description also mentions puzzles: I won't even go into what I had planned at one point, because I was living in cloud cuckoo land thinking it was possible during a working week.
On the plus side, the explosion graphics don't suck as much as I thought they would after I originally drew them. The bosses blow up in a very satisfying retro style, and to a large extent I did actually make the game I wanted to make in terms of look and feel, excepting some tweaking of difficulty levels. Ship control is dead on, and I like the way it bounces (and the fact that I haven't been able to make it get stuck inside any walls; very important!).
In summary, I feel happier than at the end of the second challenge, but something about the feel of what I ended up with has me thinking that I won't place as highly. After the second challenge, I was so disheartened that I didn't enter the third (even after placing third in the individuals - I'm such a perfectionist). This time I'm looking forward to doing it again, but only if I can have the whole week. :)
Out of time :(
Not everybody wants to risk getting distracted during the week by playing someone else's prototype, which has no doubt just become playable enough to be vaguely fun (otherwise why would they upload it?). Also, I reasoned that anything that gets our little contest a tiny amount of free publicity can't be a bad thing.
Here we go then: instead of uploading a prototype of my game, I recorded myself playing for a minute or so using XVidCap, and uploaded it to YouTube here. The actual game is slightly faster (XVidCap CPU usage gets in the way) and smoother, obviously, but there you have it.
Now, if I can tear myself away from flying through tunnels for long enough, it's time to add some enemies. Oh, and a respawn action would be nice, too. ;)
My maze-fu is strong
Super Spelunker is born!
What you see below is a randomly generated maze. I started with the standard depth-first search algorithm, added the width limitation which gives it the upside-down-pyramid shape, then tweaked the algorithm slightly to give more pleasing results.
- A "weighted roulette wheel" technique was used to give a bias towards horizontal corridors, which is both a game design decision and a measure to counteract the natural bias towards long vertical corridors, which presumably results from the X-axis limitation (i.e. pyramid shape).
- The algorithm keeps an explicit stack rather than using recursion; there is a small random chance that at the top of each iteration, a random item shall be chosen from the stack (instead of the top item). This greatly increases the amount of branching in the maze, as otherwise the algorithm effectively creates a single path from the start point, and branches more than a few cells long aren't seen until quite a way along it.
I'm not sure if the pyramid shape will be kept yet, or if it will be kept but turned upside down. I'm also not yet going to release any details of gameplay in the sense of how you will actually get around the maze (other than what's already written in my entry description); partly because they aren't finalised, but mostly because it's mysteeeerious.