I don't need to wait until the end of the day to post something, as for day 1 I will probably just prepare the structure and internal mechanic.

I am not sure I will manage to finish this pyweek, as I have a really busy week at work.

When I registered, I was hoping to explore new libraries and try totally new things, but due to the lack of time, I will not be very original and I will stick with what I know.

The game will be a platformer game with a twist.

You play Kenneth, a sentient drop of water escaping the military lab where it was created.

The twist is that each time you move, you lose a bit of water, which means you lose a bit of life.

Few game play characteristics that I would like to have:

* You can recharge your health with bonuses in the level.

* When you hit the ground after falling, you lose health in a quadratic way: falling from x pixels makes you lose something proportional to x². It means that you will lose less by falling from 3 times 10 pixels (~300) than by falling 1 time 30 pixels (~900).

* Losing health changes your size, and maybe some stuffs will depends on that (not sure yet).

* Hopefully, there will be specific stuffs in different levels (special traps, enemies, slightly different physics, ...).

The link with the theme is, I hope, obvious, as you are playing a water drop that moves by flowing, with few elements being caracteristic of a flowing liquid.

The result is not like what I had in mind, but I still like it.

I still not sure I will have time to wrap it up nicely.

The motion and the collisions are  way more fluid (ahah, "fluid") than I would have hoped.

I wonder if it will keep up with more sprites on more busy level than the test one I have.

The basic playable system is in place.

But I will need the remaining days to create the levels and to add special stuffs inside those levels.

I spend some time creating a small tool to help me designing the level, I will see if it pays off.

I really have no time for this pyweek.

The main system is working very well, but creating, testing and fine-tuning levels takes a lot of time.

I have the feeling that the amount of fun that people are feeling when playing a pyweek game plays a bigger role than the level of polishing (as soon as the game itself passes a given threshold), so I wonder where I should spend my time.

I'm not sure of "how fun" my game will be considered, especially if I will have no time to implement all the little things I had in mind to had the levels challenging and interesting.

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)

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

https://pyweek.org/d/6714/#comment-13945

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.

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).