Post-mortem

Jjp137 on 2015/08/30 01:55 of Jjp-pyweek20

Now that the judging period is over, I'll go ahead and share some thoughts about the game and its development, both good and bad :)

Overall, I enjoyed reading all of the feedback, and I'm glad that most of you enjoyed the game. No game is perfect, of course, and many of you brought up several points that I agree with. Thus, let's start with the bad parts first and get them out of the way :p

One of the most obvious areas of improvement that can be made to the gameplay, at least to me, that could have been improved was the difficulty of the game. It could have been toned down a lot and still be fun. The last group of levels, which not many people reached, should have just been simplified or demoted to post-game bonus level status. What's an even bigger problem is that there are bad difficulty spikes in some of the 2-x levels that could have been easily smoothed out. I think I tend to make levels too hard instead of too easy, and it's probably because I like playing challenging games, so I make levels that would be satisfying to beat for me. However, a while after I uploaded the final version, I thought "this might actually be too hard overall", but by that time it was too late by then. My PyWeek #16 entry had this problem as well, but all the levels were unlocked from the start in that game, so it didn't really matter there. Of course, there could have been difficulty levels, but I think that's easier to implement and test for games that don't have fixed level designs. I really wouldn't want to test every level twice :p I suppose it's better to make levels that are a bit too easy instead of too hard while still maintaining a smooth difficulty curve, and if I have leftover time, I could put the really tough levels in some sort of bonus category. The ideal situation, I think, is that people are able to finish at least the main portion of the game.

Another way I could have made the game less frustrating was to shrink the player's hitbox so that the blue part of it only counted when collision with enemies or firewalls is being checked. Clipdeaths are not fun (just look at that award :p), and I wish I thought of that while developing the game, not several days afterwards. Little things like this can really make a difference.

Something that I should experiment with in future entries, which at least one person in the feedback brought up, is adding some acceleration or other physics to the player character. So far, all my entries have been either "the player moves x units or the player doesn't move at all," which can be rather boring.

There's also a few things on the development side that I could have done differently, too. When I was adding sounds to the game, I found myself searching through 1000+ lines for the right location to play the sound in, which was a waste of time. I could have easily avoided that if I put a placeholder print() statement that said something like "the fire burning sound would play here" or something like that. Then I could Ctrl+F later and find that line easily. Also, I was reading through PyGame documentation a few days after the week was over, and I realized that I forgot to call convert() on basically every surface that represents an opened .png. That would explain why the FPS on the title screen is so much lower than in every other screen in the game since the title of the game is a relatively large .png file. I have to remember to do that next time. Finally, menus.py is over a thousand lines long and I hope I don't have a file that big again, especially since there's a fair amount of copied and pasted code in that file.

With most of the bad parts out of the way, I suppose I should mention some aspects of the game that I'm proud of. First of all, the main difference between this entry and my previous ones is that the production aspect is much better, and that's mainly because I devoted a lot of time to searching for appropriately licensed assets and modifying them using my very limited GIMP and Audacity skills. Some of the work was a bit tedious, such as scaling those locked wall tiles from 16x16 to 32x32 or lowering the volume of most of the sounds. It paid off, though! I also added music this time around, and I have no idea why I didn't do so in earlier PyWeek entries, as it really makes a difference and doesn't take much time at all if you know where to look.

Also, I really liked how the Tetris-like puzzle sequences turned out, although perhaps I should have made the later puzzles a bit easier. It's my first time figuring out how to do something drag-and-drop-based like that, though, and I'm glad that I was able to implement it. If I resorted to an alternate keyboard-based implementation, it would probably be less satisfying to use.

As for the story, I'm glad that some of you liked it :) There's probably all sorts of newbie storytelling mistakes and plot holes in it due to it being written near the deadline, but at least it was entertaining enough. I personally don't like how the story turned out, but that's just me being critical of my own work :p

I suppose that's it for now. There's probably a few things that I forgot to bring up, but this post-mortem is long enough. Hopefully I'll be able to participate in the next PyWeek :) Maybe I'll try to make something that is more out of my comfort zone next time.