It's nice to be participating in PyWeek again after missing the previous two :)

Well 24 hours have passed, and I got the basics down, such as drawing a test level and making the player move with the arrow keys. There's no collision detection yet, though. I was hoping that I could come up with an idea that didn't require me to have level text files since I've done that twice already, but I don't mind designing levels again. I could have implemented some more features by now, but I was rather busy during the first six hours of PyWeek, and since I'm not good with artwork, I spent quite some time browsing through and picking resources.

The general idea of my game is that the player has to obtain data fragments from abandoned computers and piece them together. There's a story behind it, but I'm not sure if I'll actually integrate it with the game or if I'll just dump the whole story in the readme. Time will tell...

Shortly after this post, I'll upload a screenshot :)

Another 24 hours has passed, and so I'll write a quick blurb here :)

One part of the plan is that each level with a group of levels interacts with each other somewhat. For instance, you might need a key on level 1-2 to unlock a door within level 1-1. Right now, I'm in the middle of making that work.

What I have done so far since the last diary entry includes collision detection, save files, and making enemies follow a pre-determined path that is defined in the level's text file. I also gathered more graphics and even some music. There's probably other things I did that I forgot about.

I have no idea if I'm falling behind, though, so I'm going to assume that I am :)

Yet another 24 hours has gone by, there's still a lot left to be done, and I really do feel like I'm falling behind.

Recently, I got new levels to unlock when the player activates data nodes in previous ones, so I'm happy about that. After I submit this diary entry, I'll start implementing keys and their corresponding locked blocks. There's other things I've done but I already forgot the specifics. I guess that's what commit logs are for. By the way, if you have time, the Git repository can be found here.

I made a level select screen in the process as well. The bare minimum that I want is a tutorial world, although it's a relatively low bar to meet. I'll definitely want to add more worlds as well as some sort of story if time permits.

I need to start implementing the portion of the gameplay where the player puts the data fragments together by the middle of Day 4, or else I might not even accomplish the bare minimum in time. I've never implemented dragging-and-dropping stuff before, and that might be a problem. I do have alternative keyboard-only mechanics in mind if I get stuck, although that'll be less satisfying to use in my opinion, but whatever works, right?

The situation is looking alright with 72 hours left. I managed to implement the majority of the portion of the gameplay where you put the data fragments together, which can be seen in the screenshot I just uploaded. There's also other bits and pieces that I naturally forgot about already.

Other than that, I don't have much to say this time. If you're reading this and you're a participant, go work on your game :)

Over the past 24 hours, I managed to complete the "putting together the fragments" part of the gameplay, and I had some time to finish the main menu, world select menu, and the story screen. I suppose I'm going to put a story in the game itself after all. It's probably not going to be very good :p I also added music and am currently in the process of finding sounds. Of course, the commit log probably says that I did more than that...

The aforementioned part of the gameplay was tricky to implement, especially once I decided to add some features that weren't strictly necessary, such as highlighting the fragment that the mouse cursor is pointing at and showing a preview of where a fragment will be placed. I feel that it enhances that part of the game enough to be worth implementing and might help prevent some gameplay-related problems, such as in the case where two fragments of the same color are next to each other on the grid.

I still need to add additional levels, so after I find some sounds I like, I'll probably dedicate the sixth day to level creation in addition to writing the story, which I haven't really done yet either.

Naturally, the code is starting to fall apart, as evident by the 1000+ line long menus.py that has copied-and-pasted code and more than just menus, but oh well...

I'll keep this short since there's less than 24 hours left.

Basically, I've found some appropriate sounds, I've been making levels using my messily-coded level format, and I haven't wrote a word of the story at all. Also, I fixed a few bugs that popped up while making the levels, although I think there's this weird collision detection bug that occurs really rarely and that I can't reproduce. That might just stay in there, sadly :(

The code is pretty much done at least, and I'm happy about that :)

Yep, it's done! :)

For those that want to know what I did the past 24 hours: First of all, I finished making all the levels. I also wrote a story during the last 6 hours or so. I'm not a good storywriter, and it's really rushed, so it's probably not that great but oh well :p I also realized that I didn't implement pausing, so I did that really quickly.

However, I didn't really properly playtest the last group of levels, so I hope there isn't a mistake in the level files that prevent proper completion of the game. Everything before it can be completed, though. I'll probably speedrun the game to make sure that the game can be completed right after I finish this diary entry. There's also a rare collision detection bug in which the player has a sudden "jump" in position on the screen. It's still lurking around and I've only seen it once, so if it happens to you on a hard level, I'm sorry :(

Anyway, it's uploaded now so you can play it, although you should probably finish writing that readme first :) Also, the game actually has a title so I need to change this entry's details...and I should upload up-to-date screenshots. Let me know in the comments if any issues or severe bugs pop up.

Just uploaded a new version to fix some mistakes related to the title of the game. You don't really need to re-download if you already did. Changes:

• The title was incorrect in README.txt and LICENSE.txt
• Change the window title

Oh, I forgot to link this in my previous post, but here's the Git repository if you want to look at it: https://bitbucket.org/Jjp137/jjp-pyweek20

Edit: Okay I need to stop adding the save file and .pyc files on accident :\ sorry about that

Edit 2: Fixed a bug with level 3-1; oops :(

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.