October 2018 challenge: “Flow”

Flowing Magic - The Post-mortem, Post-release, post

Posted by saluk on 2018/12/06 21:32

Thanks for all of the feedback everyone! It was a really successful pyweek and everyone made cool games. Your responses will help as I continue to work on the game (and engine). 66% reported not working shows that I was too ambitious, which I pretty much knew by thursday when I had yet to have a functioning game of any kind. I was actually shocked that the final version, at least from what I could tell, "worked". I finally solved the main remaining issues Saturday morning and implemented the rest of the game logic in the next few hours.

Making a mulitplayer game for a contest like this is not recommended. The biggest issue is with the judging process - the game requires 2 players to play, and none of the judges are going to sit around and wait for an opponent. (I didn't really implement any real matchmaking either). I certainly wouldn't! I also made a poor decision of randomly choosing which player is "first" - since you are restricted from making moves during your opponents turn, the effect this had was that new players are randomly going to have a "frozen" screen with no way to interact, and aren't going to sit around and wait for the opponent to join to take the first turn.

Beyond the multiplayer "mistakes", I also was using a new framework, kivy. Some of the "not working" were probably due to issues getting that framework installed. I didn't really provide guidance on this requirement or the version the game was meant for, so not doing myself any favors there! I actually had a difficult time getting this framework to lay out the widgets the way I wanted them to. That was actually a bigger technical challenge for me than building the netcode. I don't know if it's a case of my brain not working the way the kivy creatores set it up, if I made too many assumptions and didn't read the documentation clearly, or if the documentation is lacking. There are some patterns it uses that I haven't had a lot of experience with, so I'm happy to blame myself.

I think the main features that fell on the floor due to my slow start with the framework, are player feedback. There is no description in the game of how the game works or what you are supposed to be doing. There's very little clear feedback showing why you couldn't do a thing, or what change your doing a thing actually did, making everything very confusing. I probably could have polished these elements if I had gotten the game part done a day earlier. Although I don't know - each new widget or animation was going to be hours of tweaking values to make kivy display it where and how big I wanted it to.


My main goal was to get a jump start building a multiplayer card game engine. I knew going in it was very ambitious, and wasn't sure I'd be able to pull it off. I'm pretty happy with the results, and now have something to build on for this and future card game experiments I'd like to do. The next step is to clean up the code a bit, and then work on those feedback pieces to make it easier to keep things clear. I'm interested in the possibilities, and because I used kivy, I can actually make apps - which is the real goal here!

Congrats all!

Add a comment

Just Flow - Afterthoughts

Posted by chrisyan2000 on 2018/11/13 15:47

Thank you so much for your support and comments!

I'm so sorry for the ones that didn't work... I really should test on Mac and Linux for the next Pyweek.

From the comments I saw three major problem:

  • The game is not working because certain module or file is not found
  • The story that was told is not clear
  • There weren't much gameplay

The first issue has two possible causes. My texture loading module was glitchy and it reports a texture loading error, or noisepy was not install and it returns a module not installed error. I recently fixed the texture module and it should be working correctly, and I simply forgot to include noisepy when I was using py2exe D:.

For the second issue, here is the answer: this game emphasized my first year in university, which is basically me at the moment :D. And how did I emphasized that in the game? here goes:

  • The controllable character is headless, there were a couple of achievements related to "losing direction".
  • The first scene is basically, you were forced to type unwanted things to continue -> my TAs were like that, yep.
  • When you've waited too long in one scene, the narrator gets mad and the box becomes unstable -> deadlines basically.
  • In the shooting stars part you make choices, it starts off obvious but it soon got harder, and you have to decide on your intuitions
  • At this point of life I realized the actual value of time. In the third stage, with the choices you've made to either skip or wait determines your attitude with time. However, this became completely ionic because you are actually wasting time waiting in reality. And for the little "aren't you a smart boy" reaction after you've chosen to skip, the reason is that.... usually the people who think they are smart tend to waste a lot of their time.
  • Walking in the forest part is basically the entertainment and socializing. The true meaning behind the question "do you flow with it?", is asking whether or not you have the urge to socialize and do everything together with other people. I actually felt quite lonely during the first month of university, and if I could paint how that period of time felt like, a lone man in the forest, a current which doesn't carry you, he walks around in circles, and touching the flags that were 'unreachable'(relate to the 'unclickable' achievement). The final achievement in the forest scene is 'take a walk', it firstly relates to the 'Take a Walk' song by Passion Pit, and it also relates to how it managed to meet friends later on :D.
  • The result paper looked like the diploma paper, that's actually the intention behind it.
  • The background music is played by guitar -> I've just started learning guitar in September!
  • Furthermore, there were some meaning or some story of mine behind each achievement! But that's too much to write here.
  • DMG is a acronym me and my friends made up for Doris McCarthy Gallery... and I just decided to put it there :P

The third issue, no gameplay... Sorry, I was so into composing my stories in there that I basically had no time left for gameplay D; . I will add more gameplay in my next Pyweek entry.

Again, thank you so much for your feedbacks!

Add a comment

Road Rage - Post-Mortem

Posted by OrionDark7 on 2018/11/12 15:50

I did good. Tied for 4th Place Overall and 3rd Place in Fun, not too bad. Feedback was generally positive, which is a first for me (probably because of the new grading system I'm going to guess, as well as I just did better).

I'm now going to try to respond to all of the individual comments I got, mostly just for self reference on what I did really well on and what I could improve.


You control traffic lights at intersections by clicking on them with your mouse and toggling them from red to green. Clear crashes by right-clicking on crashed cars. That's the game! The game ran great, and it was clear from moment to moment what was going on. Not exactly my kind of game; it ultimately kind of devolves into a game of simply having quick & accurate mouse movement.

Tip for getting the game to run on Linux, and maybe Mac too: go into the "sfx" directory and copy all the uppercase sound effect files to their lowercase equivalents. For example, copy "Horn.wav" to "horn.wav".

I agree that you had to have very precise and fast mouse movement, at least for some of the harder levels. I did get a couple of comments about the "Horn.wav" problem for Linux. Linux was the one platform I did not test my game on (Probably should have, because that's what most of you are using). One easy way I could do that is by checking all the caps and non-caps on file names. Thank you for the feedback.


It's visible the amount of work you put into this; it looks very complete. I appreciate all the different modes and levels and that's not easy to pull off in one week. I admit that this style of gameplay (multitasking-type games) doesn't appeal to me in particular too much, but I enjoyed it nevertheless. It's nicely executed and well polished overall.

I agree with the statement that making levels and different modes is not easy to pull off in a week, but not for this game. For the past two Pyweeks I competed in I did have a lot of trouble with this as you had so many objects that make up one level, and you have to design the level very well. For Road Rage there were not as many objects in one level, all you really needed to figure out is how many makes the balance between not too easy and not too hard to make the level go smooth. The only thing that really took time was testing the levels to see if they were too hard or too easy and then constantly adjusting them to get them to an equilibrium. Thanks for the positive feedback. :)


I feel like I've played pretty similar games before, but this is very well done. Good job making a lot of different levels with a good progression of difficulty out of just a couple simple mechanics. The half-controlled intersections - in particular Level 8 - felt just a bit unfair whenever I had to decide whether to let a bus through with no way of knowing whether it would make it in time. (Some sort of indicator at each edge of how long until the next car appeared is one possible fix.) But for the most part, I liked the challenges.

Half-Controlled intersections were really supposed to make you make decisions on wether you wanted to risk a crash or make people mad. The decisions probably varied from Level to Level (like when you went from trying to avoid crashes to trying to avoid angry drivers). I agree that these were very challenging and a little unfair, which is why I tried to put them only on harder levels. I like your idea of putting indicators on the edge specifying when the next car would come, and I'll probably do that in a Post-Mortem. Thank you for the feedback!


nice game, 3 game modes (I haven't tried them all)

Thanks for the positive feedback!


Well made!

Road crossings without lights are disaster.

That's what they were supposed to be, >:). Thanks for the positive feedback.


Nice game.

I'm not sure the system to punish letting on way being always red is well balanced or even work: in survival, the time still increases for ages.

Also, when one line is without control and a bus is coming on a perpendicular line, I have the feeling the chance of success are just random: it depends if you are lucky and no new car appears on the line without control, as they go faster than the bus.

The car/bus can also appear and disappear outside of the screen, so they just not pop out of thin air.

I had fun playing around and I appreciated the existence of a menu, of options and of different levels and different mode.

About the system on punishing for keeping to many people on red, that was just a very bad attempt at an anti-cheat system. I didn't want people to cheat through the game by leaving every light on red, leaving the game on for a long period of time, and then come back and win every level. I agree with your point that system was unfairly balanced and I probably should've messed with it from level to make it more fair.

Another comment about the half-controlled intersections, success doesn't really depend on if cars and buses go, you kind of just had to make a decision on wether a line of cars would make it in time or if you needed them to stay put. Thanks for the feedback!


Great job! I rage quit around level 8 or 9 because I got irritated with the hitboxes on the cars. I feel like once they are half or more across the opposing light they should continue even if you change the light to red. But they are stopping even if they are a little PAST the light. Numerous cases of having a crash because the last car in a line stopped moving when I felt like changing the light was the right move got very frustrating.

The cars stopping past the light was a "feature" if you know what I mean. I understand that stuff like that doesn't happen in real life and it keeps going, but the way I had the system for Traffic Lights set up that didn't happen. I only kept it in because I felt like if cars kept going then there would be less possibility of having a crash and I didn't really want to make it too easy. Thanks for the feedback.


Game was pretty fun: very similar to another entry this comp. I think this game did a bit better job than the other in the more steady progression of levels, and the use of the time limit and other objectives: made for a more challenging and interesting experience. Also nice to see the tutorial and other support information in the game.

Thanks for the positive feedback! I spent a some time trying to get the levels to have steady progression as well as have them playable. I put the Tutorial and more detailed support information into the game because of people getting really confused on my past PyWeek and Ludum Dare projects, so that was something very well needed.


I really enjoyed playing this game. It's a great puzzler / coordination problem. Nice and simple yet effective..!

Thanks for the positive feedback!


very nice feel, lag between levels. how to package? its so hard???!

When you say lag between levels do you mean the loading and intro screen? I don't see why you would need to package unless you were on Linux, because that's the only distro I didn't make. When you say it's hard do you mean the game is hard or are you continuing your previous statement of how to package it? Nevertheless, thank you for the feedback.

Unicorn Markets

Reminded me of the NetLogo traffic simulation. Although, unfortunately I didn't find it very fun. Screens took a while to load and the flow seemed like it hadn't been tested enough.

I probably shouldn't have added a loading screen. Nowhere on the screen does it say it's loading and it's really just annoying. I did spend a little time testing levels but I agree and I probably should've tested them a little more. Thanks for feedback!


The cars are cute; I especially liked it when darkness fell and they turned on their headlights. The horn sounds really add to the urgency.

It's a difficult game! I kept messing up and causing pile ups. I found that when you cause a crash it's hard to unpick it without causing loads more crashes.

I agree that it's pretty difficult to clear crashes without causing more. Usually I would've just turned all the lights red until it was all clear, but I understand that you didn't have that much time to do that in all the levels. Thanks for the positive feedback!


Nice idea - elegant

One small glitch: On Linux I had to rename Horn.wav to horn.wav to get it to work (files taken from the repo)

Yeah I should've caught the Linux glitch. At least I didn't get any DNWs for it. Thanks for the feedback!


Creative application of the theme, and overall fairly well-polished game (though some music and less jarring bleep sounds would have been nice). The clickboxes were a bit confusing at first and I opened traffic in both directions by accident more than once (but part of that is probably that it was a tiny window on my high-DPI display). It was fun to play around with for a while, but it feels like the core gameplay might need to be extended with a bit more for it to be even more fun.

For some reason I always forget about music until the last minute and then I forget to add it. I probably should've edited the horn sound to be a little less sudden and less aggressive. I agree with the statement that the clickboxes were confusing, I couldn't find a really good way to do it, you probably could've made it fullscreen to make it easier to see and click, but I still could improve that. I tried to add 3 different modes to extend the gameplay a little bit, but I probably could've done a couple of more levels. Thanks for the feedback!


Nice traffic simulation. Very intuitive controls for switching the traffic lights. It's quite fun to optimize the traffic flow.

Thanks for the positive feedback!


Has the filename case sensitivity issue where the filename in the source doesn't match the case of the actual filename.

pygame.error: Unable to open file './sfx/horn.wav'

Good execution. I'm not too sure how to beat the later levels though. The different light conditions was a nice touch.

I probably should test Linux next time. Later levels required a bit of thinking and decision making. Thanks for the positive feedback!


Simple concept, good execution, fun to play - occasionally all lights turn green on a junction at the same time, not sure if that's my missclick, a feature or a bug.

Opening all of the traffic was a probably a miss click, oddly a feature, and unfortunately a bug. Either way, thanks for the positive feedback.


The game was fun and provided quite a few game modes. However the controls are a little too uncomfortable, it would be great if you can use the numpad as shortcut keys for the traffic lights. I didn't see much creativity in this game as traffic flow appears to be one of the most common theme here. The production is fine, the background music and certain strange animations are a little disturbing.

I really like the idea of using the numpad as shortcut keys, except that my keyboard doesn't have a numpad to test on. I don't understand what you mean by strange animations, unless it's the one where cars start and stop repetitively behind a bus, then I understand. Thank you for the feedback!

Road Rage's success outside of PyWeek

Some of you might know that Road Rage has an itch.io page. After posting it around the internet for a bit, it gained a lot of popularity. As of today, Road Rage has 230+ views and 190+ downloads on itch.io. On October 29th it was the most popular game made with pygame on itch.io, and even made the list of New and Popular games for a brief period of time. I'm very happy with the results that I got from it as well as the results I got from here.

Yet again I'm really happy that I get to compete in PyWeek, it is both fun and challenging and every time I learn ways I can improve. Thanks for a great PyWeek, and I'll see you all in 6 months.

Add a comment

Let There Be Light - Woah, thanks!

Posted by rdb on 2018/11/11 23:33

Thanks to everyone who reviewed my entry!  I was quite surprised to see that it was rated so highly among the individual entries, despite the fact that the gameplay still needs quite some work.  There were many other really great entries that I expected to be rated higher.  It feels like quite a boost of confidence for me.

Congratulations to everyone who participated; I know that even completing a game can be quite a challenge in itself that deserves recognition.  I have really enjoyed participating in PyWeek, and in particular the amicable spirit in which people are encouraging and helping each other.  Many thanks to all participants for their involvement, and to @mauve in particular for managing the website.

The game feels as yet not quite complete, as the reviews have rightly pointed out; the mechanics need to be developed out more. Options to consider are allowing more generators to be built, or expanding the network complexity by introducing a distinction between high-voltage and low-voltage wires and allowing distribution stations to be built.  Lots to consider, but I don't know if I'll have the time to continue developing the game.  But I'll probably clean up my code at least before people notice what a terrible mess of hacks I've made. ;-)

I'm happy to see that this time, there were no complaints or issues with the use of Panda3D in my entry.  I guess it has come a long way since the days when it only supported Python 2 and could not yet be installed using pip.  It is encouraging since I think Panda3D is a fantastic tool for prototyping 3D games in Python within a short period of time.

I'm looking forward to the next PyWeek!

PS. As an anecdote, Let There Be Light was not even intended to be the final name for the game, as it no longer really reflects the gameplay very well; it was just a working title as I was thinking of incorporating light into the visual theming more.  But I only remembered that I still had to come up with a permanent title minutes before the deadline, and I did not manage to come up with a new title before the time ran out.  Oh well!

Add a comment

Storm Drain Odyssey - Postmortem

Posted by Cosmologicon on 2018/11/11 21:32

Thanks for the feedback, everyone! I think there are some lessons learned here. First, a couple things I think there are quick fixes for:

  • Out of bounds bugs.
  • Performance.
  • "When swimming against current it's kind of random what direction key you must use" and "the controls sometimes seem to steer in the opposite direction" - I strongly suspect these players were using the manual camera mode, where the direction an arrow key takes you depends on which direction you're pointing the camera. I can easily imagine controlling both at the same time is hard for many players. It might be best to force automatic camera mode for some parts.
  • "The whirlpool part was frustrating, especially because I didn't realize that you could get the fish food by swimming closer instead of trying to jump above the hole." - In this case putting the fish food around the first whirlpool instead of the last one would have let you experiment faster.
  • "that puzzle level... I think you needed something that could be done and undone to make it more puzzly" - absolutely, this was planned, we just ran out of time here. I suspect most people had to skip this section, so maybe it should have been cut entirely.

"The boss level... was not challenging" vs "I couldn't figure out the octopus". I agree the boss could use some tweaking. Right now the tentacles are just there for decoration, but they could be actual hazards. There's no health meter or way to die, and this was done as a stopgap to deal with the lack of save function, but I kind of like it. I wonder if there's a good way to add a challenge without requiring a lose condition. Perhaps  have a timer that closes drains you've opened after a time. Any other ideas are welcome.

It seems like most people didn't find a need to bother with the core water pressure mechanic, which I understand (although I'm surprised if you managed to beat the puzzle without paying attention to the pressure). I was worried this would happen and I tried hard to force players to watch the pressure level in the tutorial, but I didn't really succeed. There may be a way to salvage it, but ultimately I think this mechanic doesn't work 100%, and I would replace it with something slightly different. I don't have any great ideas, though.

I don't think we really made any mistakes in choosing this mechanic, it just never quite came together despite several iterations. It happens sometimes in PyWeek!

Now, about navigation. This is a very important topic for me. There were mixed responses in how difficult the game was when it came to finding your way. Ranging from "playing the game properly would require lots of notes and graph paper to plot out where you are", to "the game just solved itself". Overall, though, it does seem like a little more help not getting lost would have improved things.

To review, the game has six sections: a tutorial, four challenges that can be completed in any order, and a final boss challenge. They're all connected by a large room in the center of the map. I wonder whether people were having more trouble finding their way through each section, or finding their way between sections (e.g. knowing where to go next). But each section is fairly linear so I tend to suspect the latter. I'm glad I spent time getting the minimap and main map working, because I think they both help keeping track of how the different sections connect, but what more could be done? Two ideas I have are closing off paths to challenges that have been completed, and putting a label on the minimap showing what area you're currently in.

My big question is whether having one large connected world contributed to the disorientation. We could easily have made the game six separate levels that you select from a menu, but I really like making a single seamlessly-connected world whenever I can. It makes the game feel more complete somehow. None of the judges mentioned this aspect negatively or positively, so maybe it's just me. But I'm interested in what I can do to make it work.

What about appearance? One comment references Colossal Cave Adventure with "it's a maze of twisty little passages that all look alike". I'm guessing was meant negatively, so I wonder whether making the different sections have somewhat different appearances, say with different textures, would have helped. My first thought is that limited graphical range shouldn't necessarily be a problem for PyWeek. Nobody gets "lost" playing a game like Dynamite Valley or Deep Breath, even though every level has pretty much the same graphical assets. But maybe making a game where navigation is involved means also committing to more graphics.

I'd be happy to hear any further thoughts people had about this!

Big thanks to mauve for putting this on, and congratulations to the winners and everyone who entered!


Evaporating Kenneth - Few comments

Posted by cauch on 2018/11/11 14:13

Thank you very much to everybody rating my entry (and to all participants making pyweek a fun event) (and to the organizers).

A lot of comments to my game were totally fair, and I guess it all comes down to the same problem as my other games in pyweek: when creating them, I learn to play them, and I don't see how difficult it will be for brand new players (honestly, I think you get use to it quite rapidly, but with so many games to judge, I understand people did not spend more time practising a frustratingly difficult game).

I still have few questions / comments:

1) Not sure why I got so many "below average" on "innovation". The corresponding feedback comments don't even mention this aspect.

2) I'm not the only one in this pyweek: we are beginner developers making a game in 1 week, we don't have the psychic ability to discover that a game that run perfectly fine on the 2-3 machines we have tested will not work on another one :-) ( <- use of emoticon to avoid misreading of my tone). When we get those info, it's already too late and we usually cannot even do anything (some nice souls gave me the description of their machines, but, honestly, what am I supposed to do next? Go door to door to find a neighbour having this machine? Buy it? ...).
I have no answer on how to fix problems discovered by others. Maybe others can investigate themselves, but I understand they have other things to do.
On my side, I now know that my code is not running on some machine, and ... that's it, I have absolutely no plan on how I can fix that.
(also, please, if it obviously does not work as intended, don't put "innovation" and "fun" to the minimum)

3) I kindly disagree ( :-) ) with people saying that for my game, the controls/platforming are "not responsive" or "truly awful": I would have preferred "are not what I'm used to and therefore I did not enjoyed it". I don't think these "features" were an objective mistake in the design, just a twist of the boring-same-old to force people to play differently (and it's not that bad if you don't try to brute-force the old methods and stop and think on how you can use those features to your advantage).


ain't got that flow if it isn't a flow - Challenge over and regarding game issues

Posted by speedlimit35 on 2018/11/11 06:10

I have noticed that some people may have misunderstood the gameplay. You are supposed to hold down the keys. Maybe I should have left the print statements as output.

I will probably add something on the screen to tell if you are hitting the points or not sometime in the near future.

As for the issues of not getting the game to run and the flickering screen, that is probably due to the fact that I am extremely inexperienced with programming.

Hopefully by next pyweek or next next pyweek, I will have a better understanding and more experience with programming and with different packages to use since I am only using pygame so far.

Thank you all for all the useful feedback and see you next pyweek!


1 comment

Pipeline - OSX bug

Posted by asrp on 2018/11/11 03:36

Thanks to everyone who rated this entry and reported bugs!

For those getting that OSX bug, could you try the fix suggested here? https://www.python.org/download/mac/tcltk/

I'd be very interested for the sake of the library I'm using.

Add a comment

Rush Hour - Rush Hour: Postmortem

Posted by Tee on 2018/11/11 02:36

Thank you all for the feedback! I'm glad that some of you enjoyed this game.

I had a reasonable amount of time this Pyweek but unfortunately I didn't manage it well enough to make a better game. Originally I was making a game where you would explore the secrets of a waterfall, but on Friday I realized it wasn't going to work because I needed much more time than I had, especially given at how slow I am at creating graphics (as a side note, I'm always impressed to see people creating games with great production value in one week). I had zero good ideas as I woke up on Saturday -- I also wasted my time twiddling on paper with a puzzle idea that I couldn't envision as being fun either -- and this is the best that I came up with.

Yes, this game was hard, and I apologize, but at the same time I don't regret it. :) Ok, I didn't have time for much tweaking and if I had, I would have created an actual learning curve, but I did intentionally know it was hard as I submitted it. I know from my past games that hard games get mixed reviews (despite me liking to make them), but I wanted to see if a series of 12 second bullet hell "levels" would be short enough to give players a chance. I personally enjoy quick restart games and I think the quick restart helps mitigate the difficulty. The results were again mixed; a few people liked it (and thanks for pushing through the difficulty!), some felt the difficulty was an issue, and that's all completely fair.

I think this is not the hardest game I've made, but it probably is the scariest-looking in terms of difficulty. This looks like a bullet hell, has the same mechanics as a bullet hell, but it's not truly a bullet hell. Maybe if I had hinted better at how the game is intended to be played -- which is, find a safe spot, stay completely still, and gun for it (except for the last level, which is actually kind of tricky and requires good dodging skills) -- then people might have had a better experience. But then again, I sort of wanted people to figure that out for themselves, so I just hinted at that in the README. As you would think, I didn't intend this before making the game, but as I realized that that was an option, I thought it was interesting so I tried to redesign the game around it. I made each level really short so you don't wait for too long. Then I tried to calibrate the levels so you'd still need some skill to dodge at the beginning and at the end, so it doesn't devolve to a simple gimmick. Well, it is a gimmick, but I tried to make it a fun gimmick.

Fun fact: you can solve the last level by pressing the up arrow key immediately after it starts and not letting it go until the end, and just use the left and right keys to navigate until you finish the level.

Mauve, thank you so much for all the changes to the website! I like how the site has evolved and I'm glad that you took charge in making those changes. Congratulations to rdb and The Larry And Dan Show for winning (excellent games), and to everyone for completing your games! I'm glad that I had time to rate games because there were a lot of fun ones in this batch. As always, I appreciate your feedback. See you all next time!


Evaporating Kenneth - A bit late for a bug fix

Posted by cauch on 2018/11/10 15:44

I was busy all week, but today, I had few minutes to look a bit more closely to the bug raised here:

I think the latest proposal fix the bug (not sure though, as I've said, I cannot test it).
If you have judged my game while this bug existed, it's fair enough, no need to retry everything, it's just for information.

It's one aspect of pyweek: discovering that things that works well on our machine suddenly are broken somewhere else.

Add a comment