First of all, thanks for your comments! It felt really nice to know that people actually had fun playing your game.
Plus it really helped me to find out what was right, what was wrong and what needed to be enhanced.
It got me quite motivated, and tadaa, here comes the 1.1 release that fixes most of the problems you guys noticed.

Rigid key mapping:

The key mapping has been changed to work on all keyboards layout.

• Player 1: RDFG + X or Space
• Player 2: Arrows + P or Enter (keypad)
• Controller: Hat or Axis + Button 0 (A)
• Reset: U or Button 3 (Y)
• Quit: Escape

Now, both platformer and FPS players have a conformable jump key.

Unclear gameplay:

Direction auras have been added to make the direction system intuitive.
Same thing for the jump loading system.
Also, all animations have been enhanced.

Button mashing:

There should be no button mashing since no input is required to kick.
The game is only about directions, jumping and collisions.
The new background and the gameplay enhancements make that clearer.

Unclear collisions:

There was a bug in the collision detection, this is why it felt non intuitive.
I added a slow motion mode when the players get really close.
So the first contact will appear clearer.

"Wish it had some sounds."

If anyone is interested in making some nice 8 bit sound effects, please let me know.
I'll be happy to add them to the game ;)

Thanks to all who played and rated my game. I've very grateful to all for the helpful comments.

Many people commented that my game was too random and that the dice weighed much too heavily in the outcome compared to the cards that you played. This is definitely true.

I did play quite a few rounds myself after the submission deadline and the game played much more like patience than a game of strategy and skill. I could defintely improve my chances of making it through six contracts but I only ever came even slightly close to wining six of them one time!

Anyone who made it passed six contracts will see that I didn't even put in any special UI for winning as I suspected it was impossible with the tuning as it was!

I am happy that everyone seemed to get the idea of the game. That was one of my main worries once I got started. I had chosen a card game as I thought I could build a relatively simple engine and hoped to get some emergent gameplay (from the randomness) quite cheaply, and I knew I didn't have too much time to develop the game.

However, once I got started I noticed that I needed to spend much more time making the flow of the game events transparent to the user than I had anticipated. This was quite a learning for me. Although the game engine was simple, the game state was complex and communicating this state and developing the players concept of the state required work on the UI, visuals, and sound.

As an example, the game was fully playable, and essentially didn't change, by the end of day 3. Day 4 was spent making it look nice. And the remaining days were spent tuning the design (not the gameplay) to make it more understandable. Probably 1/3 of that time was spent on the "contract widget" on the bottom left of the screen. This was time well spent but it took away from playing the game and tuning the scoring.

In the end this showed through in the comments, where I should have reduced the dice score considerably.

Anyway I learned a lot from developing this one. Generators are awesome for building highly stateful systems!

Thanks to all and congrats to everyone on the excellent games.

Hello everyone,

I haven't posted a diary entry yet, so here it is.

I'm fairly satisfied with how this Pyweek went. Even though time was tight as usual, I was comfortable with the general idea since the beginning and I had the schedule and the scope of the game in check, which is something that most of the time does not happen. I didn't have time to balance it though, and I also wanted to add some sound effects but I ran out of time. I only had the levels in within the last two hours of the deadline, and I only did a full test of the game one hour from the deadline. I received a comment that it would be nice to see the rooms at the end of the game, and that was in the original plan but I had to scrap it due to time. I was also thinking of having more features to help identify the room, but in the end I'm glad I scrapped that because it made things simpler. (I find that simple is usually good in Pyweek, at least for me, so that's what I try to aim for.)

If you're familiar with my Pyweek history, you know that I'm always trying to implement a single idea that I haven't seen before, so it's always hard to measure how fun it is. Most of the time, due to the time constraint, I just test it myself, so I'm never sure about how fun it is. Your comments help in this aspect and I'm glad that some of you had fun! I understand that it might get boring as a few commented: a reason this may happen is that it is a bit of a waiting game, and most of the time you're just paying attention to a few windows waiting for something to happen. I thought however that it would be nice to do a slower-paced game compared to my previous entry, where you had to react every couple of seconds. In fact, if you've been following my games you'll see that I tend to go back and forward between fast-paced games and slow-paced games.

I personally like this idea because it mixes three different elements. There is a bit of logic, a bit of perception, and a bit of chance. I can't think off the top of my head of any game that blends these three elements together, though I'm sure it exists. I'd say however that the logic part is very superficial: the challenge of the game is obtaining as much information as possible by paying attention, and crossing off rooms once you have that information is very easy. The chance element wasn't planned from the beginning, but I realized at the end that it was kind of exciting to take the best guess, and I thought it fit well with the game. But even this chance element has a little bit of logic to it: you can think of certain windows to be more likely than others based on their locations and the ones you crossed off (e.g. if the sniper is in a room with 3 windows, and there is a cluster of two windows separated from the rest, chances are that that is not the room).

I appreciate a lot your comments (especially those who take the time to go into details) and thanks to Richard for hosting yet another Pyweek. Congratulations to the winners and to everyone else who completed a game: it is always an achievement to complete a game in such a short time frame. See you next time!

Thank you everyone for playing "The Forgotten Angel"! I had a blast participating in Pyweek and it was great to play everyone's amazing games!

A bit about me: I'm a composer full-time for things like theatre, live performance and and film, but this is only my second time ever composing for video games, so I really enjoyed the challenge!

Cosmologicon requested loopable music with an electronic feel, as well as a preference for multiple instruments that appeared and disappeared as the songs went on. When composing, I strived to come up with non-obtrusive-yet-engaging melodies, and had lots of fun trying! I also loved the graphics Cosmologicon chose for the game, and was definitely influenced by the artwork when composing the music.

Thanks so much for playing and for listening! And if you'd like to check out more of my music, feel free to visit my website here: http://www.marybichner.com

Big thanks to all who played and judged my game!

Didn't expect to turn out so well for my first participation and in fact, my first finished game ever.

I'm looking forward to the next pyweek :)

Well, reviewing is over, and some people didn't like this game, but oh well. I think it turned out great, and it has been a fantastic testing ground for the SGE Game Engine.

After the submission period ended, I made several improvements to Pacewar, and I want to report them here:

• Pacewar 1.4 and below had a bug with d-pad recognition. If you ever tried to use a d-pad, it crashed the game. This was fixed in version 1.5.
• Pacewar 1.5 also added a "colorblind" mode, activated by pressing F7. This displays a diamond shape over the green ships, and an hourglass shape over the red ships, and also displays the sameships on the appropriate sides of the score bar.
• A couple of you went ahead and tried to run the game with Python 2 even though Pacewar 1.4 and below supported only Python 3. Obviously, these people were not successful. However, Pacewar 1.5 added Python 2 support.
• Because of the added Python 2 support, I was able to build Windows binaries and 32-bit GNU/Linux binaries.
• Control configuration is now saved as of Pacewar 1.5.2.

Pacewar 1.5.2 can be found here:

• Windows (32-bit): https://pyweek.org/media/dl/19/onpon4/pacewar-1.5.2-win32.7z
• GNU/Linux (32-bit): https://pyweek.org/media/dl/19/onpon4/pacewar-1.5.2-gnulinux-i686.tar.xz
• GNU/Linux (64-bit): https://pyweek.org/media/dl/19/onpon4/pacewar-1.5.2-gnulinux-x86_64.tar.xz
• Source code: https://pyweek.org/media/dl/19/onpon4/pacewar-1.5.2-src.tar.gz

Having played through our game, no doubt the question everyone is asking is: What, exactly, is the best possible word to open with? "Millisecond" is a strong contender, checking for a bunch of individual letters and for a double letter. "Doll" is also up there, along with "firewall"... and surely it can't be "aardvark"...

This turned out to be a reasonably interesting problem: complicated enough structurally that there was no simple direct solution (well, that I could find, anyway :), large enough at 58 rules that it can't easily be brute-forced, but not so large that it's obviously out of reach. And indeed, after a bit of tinkering and solving some sub-problems, and then throwing 30 odd cpu hours at it, the answer is:

*drumroll* (that's for effect, the answer is not "drumroll")

Freeze!

The is solving for the minimum average number of words needed to determine which rule is in play (and that minimum average is ~6.79066667), using only the 1616 words we have pictures for. An interesting variation would be to solve for the minimum average number of words needed to get 5 points, though I'm not sure that's computationally feasible.

Anyway, full solution available here.

And now back to rating all the other games. :)

Please click here (google drive) for a source distribution of Soul Trip that does not require Numeric/numpy.

I know this is a problem dependency on Windows machines (I had a few DNWs from last competition for this reason). It turns out I really don't need Numeric to do what I'm using it to do this time around, so I thought I'd post an patched source distribution that only requires pygame and python 2.7.

This still has other (non-fatal) bugs that I did not fix so that everyone gets the same experience. I really didn't manage time well...

I totally forgot to put my finished game in an extra directory. Instead I zipped the project directory! I'm sorry about this. Please be careful when you extract the directory. Last time I got a TAR-Bomb award.

I got a "Zip Bomb" award, probably because I added the sources directly to the root of my zip file.
Anyway, you can find the exact same sources WITH their root directory here.

AIso, it possible to change the size, fps and fullscreen settings by editing the values in the main() function (dojo/__init__.py).
This should have been handled by command line options or a configuration file, but anyway, this is how they work:

• dojo.settings.fullscreen: set it to True for fullscreen mode, default is False.
• dojo.settings.size: the window size is completely decoupled from the game size, any value should work.
• dojo.settings.fps: same here, the actual speed of the game is not affected by this value. However, raising it up will result in a better precision for collision, but will keep you processor busier. 120 was a nice compromise for my computer.

Have fun !