Well, something

Unicorn Markets on 2018/10/28 05:10 of CashFlow

I prefer last pyweek's entry, though I had a couple people who said there was "inappropriate material" in the simple ball game.


This game was suitably easy to develop and works. The ending, if you lose (less than 0 cash), is just the game to collapse. Didn't have time to engineer anything better. 


It is a fairly difficult game after fine tuning. Hope people like it more than I expect this pyweek!

(log in to comment)

Comments

rdb on 2018/10/29 12:01:

Is the game meant to be impossible?  Pressing an arrow makes the paddle immediately jump to the other side, with no fine control.  The game seems to be reaching a score of 5000 after a few seconds, after which it resets, and at some point an unavoidable torrent of some kind of new shape appears (I can't make out what it is; some kind of flame?) and the game closes.

I am wondering whether the framerate on my computer is too high, and perhaps you didn't make the game framerate-independent by multiplying speed by dt?

By the way, I needed to add this line to get it to even run:
pygame.mixer.init(44100, -16,2,2048)

Unicorn Markets on 2018/10/29 14:05:

Hey rdb, thanks for the feedback. 


I did not have these problems when running it. I ran with both python 2 and 3 but I can’t get you their versions or the version of pygame right now.


I don’t know why I didn’t need pygame.mixer.init on my end to run. For some reasons it worked anyways. I had considered adding it when some sounds were breaking, but it turned out to be corrupted sound files, not lacking pygame.mixer.init. 


I am pretty certain I made the game frame rate independent by multiplying by dt. I say “pretty” because I always like to give the benefit of the doubt in programming to doubt. I might just not know what I’m doing. but it ran on my system with nice rates so I’m sorry it isn’t working for you.


One group of coins fall at regular intervals. Another two positive groups drop with time delays based on sampling an exponential distribution. If you get the hexagon shaped ones, it creates a barrage of coins to get you cash. There is one negative vale coin. It is a black donut. If you get it, a barrage of fire comes down on you quickly, and you end up losing a lot of cash. If you don’t get it, your cash goes to 0. So it is a tough choice.


Hope you can you the game working. Again sorry, I wish i could fix it. Competition is over now otherwise I would try to handle it.

Unicorn Markets on 2018/10/29 14:05:

Hey rdb, thanks for the feedback. 


I did not have these problems when running it. I ran with both python 2 and 3 but I can’t get you their versions or the version of pygame right now.


I don’t know why I didn’t need pygame.mixer.init on my end to run. For some reasons it worked anyways. I had considered adding it when some sounds were breaking, but it turned out to be corrupted sound files, not lacking pygame.mixer.init. 


I am pretty certain I made the game frame rate independent by multiplying by dt. I say “pretty” because I always like to give the benefit of the doubt in programming to doubt. I might just not know what I’m doing. but it ran on my system with nice rates so I’m sorry it isn’t working for you.


One group of coins fall at regular intervals. Another two positive groups drop with time delays based on sampling an exponential distribution. If you get the hexagon shaped ones, it creates a barrage of coins to get you cash. There is one negative vale coin. It is a black donut. If you get it, a barrage of fire comes down on you quickly, and you end up losing a lot of cash. If you don’t get it, your cash goes to 0. So it is a tough choice.


Hope you can you the game working. Again sorry, I wish i could fix it. Competition is over now otherwise I would try to handle it.

Cosmologicon on 2018/11/04 03:27:

I had the same problem as rdb with the framerate. I believe the issue is that you're only calling clock.tick once at the beginning. To keep a steady framerate you need to call it every frame. Adding the following to line 85 of game.py fixed it for me:


            self.dt = self.clock.tick(30)

Unicorn Markets on 2018/11/04 20:27:

Thanks Cosmologicon!


I don't know why it runs fine on my machine, but now that I look, Richard Jones tutorial includes the self.clock.tick in every loop.

I've always done it this way, and it has always worked fine. I'm running a MacOS which might make the difference.

DR0ID on 2018/11/11 19:10:

oh noes, I overlooked the framerate fix

Unicorn Markets on 2018/11/11 21:01:

Thanks Droid for letting me know. I think having fixed that and including a readme would have been the easiest (and probably most worthy) ways of improving the game. I’m surprised nobody appreciated the fact that all special coins are delivered with an exponential distribution. This means that the expected time for the next special coin is always the same no matter how long you’ve been waiting, a property of natural phenomenon.


I didn’t experience the frame rate problem, so I don’t know what anyone is being frustrated with. I could imagine not scoring a game well if it “worked”, but didn’t really work for me. I crashed the game if it lost, simply because I didn’t have enough time to really make a losing ending to restart. Considering I’ve seen games that have no winning or losing or multiple screens, I figure most players would think “whatever”.


The simple fact is, you can’t really lose the game as long as you know to let the blacks pass if they might wipe you below zero. But if you do, you go back to zero, and essentially are restarting. So the game becomes frustrating. Because of the nature of exponential distributions, you actually don’t know exactly how hard the game will be. In other words, it may seem easier or more difficult, but it is entirely random. If you just play long enough eventually you will win. I tried to make “long enough” as long as this game remains fun. That is honestly about 3 minutes. In 3 to 10 minutes, you should have played the game, beat the game, and moved on with your life.