October 2018 challenge: “Flow”
Posted by asrp on 2018/10/28 22:23
Well, I think there's no question that this went poorly. At least there's something submitted.
I thought the main mechanic was simple enough that I should be able to implement it in about half a day took almost the entire time.
I'm not exactly sure what went wrong either. Maybe my library just isn't ready yet, there were still bugs found during pyweek after all. All the evals make the stack less meaningful and make debuggers and profilers less useful.
Having to setup the game for easy reload instead of a restart was also a bit of a pain. Maybe more time is spent than saved doing. It does get easier as more of the game and this process is complete though. I always thought this would be the best part. Oh well.
I think last pyweek went much better even though I didn't submit anything in the end.
Time to play all the other entries now.
Edit: Please feel free to reply here with comments, report bugs and anything else. Should have said this earlier.
Posted by cauch on 2018/10/28 21:09
It was a tough pyweek for me. I already knew I would have only limited time, but on top of that, I was a particularly busy week at work.
At first I wanted to experiment a bit in this pyweek, but due to the circumstance, I went for the quickest way and kept with the logic I already played with.
A lot of things I wanted to implement did not made it (no special boss battle, no special door-key-trap-lever logic, no nice background animation).
And I had to salvage stuffs from the last pyweek: the "cutscene" code is 90% from bing_the_robot, I apologize for that (it's still following the rule, as this code is public since 1 year).
The conclusion for me: either find a concept easier to do (for example, each level design took a lot of time, with a lot of testing), or just not compete if I cannot make enough time for it.
I'm looking forward to try the games, but there is a lot and I'm not sure I will have more time next two weeks (as I've postponed all my activities to focus on the pyweek). I hope to review the maximum, but I will still take the time to explore the game I review as thoroughly as possible (I guess few reviews of quality is better than plenty rushed reviews)
Posted by rdb on 2018/10/28 20:55
I'm curious how far people get with my game. A friend of mine got the best score I've seen so far, reaching 556.2 GJ at the end of year 14:
Oh, you can use shift+S to save a screenshot in the game folder.
Posted by DR0ID on 2018/10/28 18:53
If you want to play our entry against another player then this is possible (this went unmentioned in the readme.txt):
Just un-comment following lines in context_game.py (line 54 and following):
# # add other players
# # arrows
# canoe = Canoe(timing.Timer(scheduler=self.scheduler))
# canoe.position.y += 150 / PPU
# self.canoes.append(canoe) # uncomment for second player
The second player uses the arrow keys instead of a s d f. Same position of key does the same, but you figure that out.
There is no special treatment for multiple player, so the level will just end when the first arrives at the end.
Have fun racing the levels.
Deep Breath - Going subpixel with pygame
Posted by DR0ID on 2018/10/28 18:49
Hi
first of all, sorry to not have posted any diary entries during the pyweek itself.
This pyweek we had slow moving objects and using pygame that only knows integer coordinates for pixels resulted in a jittery movement. The reason is simple: while the position was calculated in a float that had to be rounded in some way to an integer pixel coordinate. So if the position only changed slowly this results in objects just hopping one pixel from now and then.
The downside of this is that it requires numpy. But then I remembered that I made a version that uses pygame only (with some clever surface scaling, can be found here:
SubPixelSurfacePygame ). This is what we used in our entry so the slow moving objects slide smoothly and do not hop from one pixel to another.
The downside of this sub pixel approach is 9 times more memory usage and slightly blurry images. But it still looks a lot better than without.
Let There Be Light - Whew! That was a fun but stressful week.
Posted by rdb on 2018/10/28 16:16
Whew! Despite not actually have a lose condition before the last day, and still having to hunt down sound effects in the hour before the challenge ended, I nonetheless managed to submit something in time that can unironically be called a "game". And I learned lots of cool things on the way, such as how ot do Nodal Analysis in numpy and what a catenary is.
This PyWeek was quite different for me than other ones: this is my first solo entry, I had a lot less time due to not being able to take a week off work, and I had chosen a particularly complex interpretation of the theme. I will probably choose a simpler game concept next time. The downside of a simulation is that it's hard to turn it into a game, and keep it balanced so that it stays challenging but not impossible. But it felt really rewarding to reach the point where it became game-like enough for people from the IRC channel to play my game and share their high scores with me, even beating my own.
Given more time, I would have been able to create a more sustained and balanced experience. When playing the game for a long time, you may notice that the end-game involves a gigantic mess of wires and running out of space around the generator. The plan was to make it possible to allow you to build more generators over time, but I just didn't get to that. I think it reaches a point where it just becomes mathematically impossible to proceed, but I haven't worked out the math.
I would have also improved the long-game performance; it's not bad, but it does currently solve a numpy matrix of a big linear system with Kirchoff's equations every frame, even though I could definitely optimize it to only recompute the voltages on each node when the grid has been altered. Even in a thread, if needed. So don't get the impression that it's Panda3D's fault if it runs slowly.
Panda3D had a bit of a reputation in PyWeek due to the difficulty installing, but I think that is history now since it can be easily installed using pip nowadays. And I'm not using fancy shaders, so no high-end GPU is needed. I'm not as confident about macOS, because, well, Apple seems to be committed to abandoning open standards like OpenGL. It seems to be playable on my old Mac Mini but the whole game does appear much darker than it should.
Thanks to all for a fun PyWeek experience! I'm looking forward to playing the other entries on here.
Posted by mauve on 2018/10/28 15:15
Aargh, game breaking bugs introduced at the last minute! As is customary I've uploaded a 1.0.1 with bugfixes for game-breaking issues only. I've played end-to-end now and the game is completeable.
I've not done many diary entries over the latter part of the week, despite posting a few screenshots. I was posting animations and then realised that this might include spoilers so I slowed down ;-)
As always it was a race to the finish line, and the level design was mainly left until last. We have a great engine, but only 11(?) full levels. I think there are some real challenges in there, though, so hopefully it's a good amount of content. If you can decode the level text-file format you can try creating your own levels.
I'm very happy with the game, on the whole. It is cute and colourful and challenging and satisfying. I hope you enjoy it!
Posted by LeopardShark on 2018/10/28 07:44
The game is finished!
In the last day, we got quite a lot done. The background now scrolls with the flow, we have an instructions and difficulty menu. There's a scoreboard, a nice main menu and targets are no longer circles.
If you're reviewing the game, here are a few things to bear in mind:
- There are no checks on house generation, so a target may spawn blocked in (I've never seen this actually happen, but it is possible in theory). In this case, you have to wait for the sticks to clear the way.
- The most recent upload contains a couple of fixes is one bug, which I did this morning. You can see all changes here. We didn't do anything on Sunday, and nothing today after 07:10, so I hope it balances out. You can still use QuantumPotato's earlier upload if you want.
- Ignore anything in the shell. You might want to minimise it.
- You need Python 3.6+ and Pygame 1.8+
Anyway, this has probably been the best entry I, or in this case we, have ever submitted. It's the first time I've actually implemented circle–rect collisions, as well (although they are a bit buggy), so I'm pretty pleased with how this has worked out.
CashFlow - Well, something
Posted by Unicorn Markets on 2018/10/28 05:10
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!
Posted by Cosmologicon on 2018/10/28 02:16
Get it from our team page here. Let me know if you have trouble with it!