Few comments

cauch on 2018/11/11 14:13 of Evaporating Kenneth

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

(log in to comment)

Comments

mauve on 2018/11/11 15:07:

I said "Truly awful". Sorry, it was supposed to be constructive criticism but I should have chosen my tone better (perhaps it needed a smiley?).

There are these elements to the platform physics in your game:

Kenneth accelerates quickly to a very high speed
He doesn't stop quickly
There's no air acceleration
Kenneth decreases in size and can no longer jump as high

Put together, these make it practically impossible to judge your jumps. You approach it with a size you're not completely in control of, at a speed you're not completely in control of (usually too fast), and you can't correct it in the air. If you make it you are likely just to slide off.

I missed jumps more often than not, and I died, a lot, practically at random, and that's just not fun.

So, I stand by the scores I gave, but once again, apologies for the tone.

cauch on 2018/11/11 15:48:

Thanks mauve.

Don't get me wrong: I did not take your comment badly. My answer was just to state my position: I see this more like a feature than a problem to be fixed.

I have no problem with your position.

My position is just different: those aspects are not fundamentally a "bad" thing, and with a bit of practice, you get used to it and find ways to control despite of (or even thanks to) those aspects (sure, sometimes you miss, but it's the same with any platformer). I disagree that it's impossible to judge your jumps: it's in fact quite easy to get the 2-3 tricks that always work, because the distance of the platforms are always the same.

To answer specifically (not that I want to challenge your position, those are just justification for my own view, showing that it's based on real things and not just denying the reality. Also, maybe you did not realized some things here):

- for the speed and the slide off after: this is the most tricky part, but you get used to it. I took the habit to only do the "winning combos" (for example: start to run on the opposite direction in a middle of a jump and release the key jump after contact). Of course sometimes you miss, but it's really not at all "practically at random".

- for the size that changes: the height of the jump is discretized ( "int(self.player.size/10)", in game/ek_play line 340): your jump will be identical with a size of 21 or 29, there are just 4 different jumps (20->29.99..., 30 -> 39.99..., 40->49.99... and 50->59.99..).

- and, yes, if you miss a jump, you need to restart a level, which is identical with Dynamite Valley when you place incorrectly a bomb not from a box. I really think one problem with my game is that people try to play it like they use to with other platformers, for example assuming that it's not normal to restart the level if a move was missed, while they have absolutely no problem with the same behaviour in another game.

On the other side, you are right to notice that the acceleration is too quick and sliding too long, those could have been fine-tuned.

I don't want you to change your score: it's your impression of the game, and the score should reflect that.

I'm happy from your feedback, and it helps me for the future (as I've said, it's a good lesson that I should step back to the newcomer level), so I thank you for that.

In fact, the point 3 is probably the least important point for me :-) I'm more concerned by point 2.

rdb on 2018/11/11 17:19:

I wrote "very frustrating", but I agree with the reviews that called it "unresponsive". I realise being more constructive is always more helpful, though it's hard to be very thorough when you have to review 30 games in limited time, and I can see how that can result in ratings unintentionally appearing brusque. I have no doubt that most if not all of the reviews are intended in the spirit of mutual improvement, since we are all in this challenge to learn.

Take this as my personal opinion/taste; it's of course totally up to you whom you are trying to target with your game, and I may simply not be among your intended audience. But as a fellow developer I find myself really easily falling into the trap of "getting used" to my own controls and losing a sense of how others might experience it. But I agree with mauve's analysis of why the controls felt more frustrating than simply "difficult". I did not realise you were trying to innovate on the mechanics with challenging execution that "twists the boring-same-old", as you say, especially since my impression of the intended focus of the game was what felt like its primary innovation: the shrinking-droplet mechanic, which the game is named after and otherwise seems like a cool mechanic with great promise. So I will elaborate a bit more on why I found the controls frustrating.

I do in fact greatly enjoy platformer games with high execution challenge (such as Hollow Knight and Super Meat Boy), but what makes the funnest games of this genre work well is that they have "tight" controls, with the character immediately and predictably responding to the player's inputs. If the player fails a jump, it should in my opinion be due to something that the player feels to be deterministic (ie. a reasonably predictable result of their direct input), and not due to a combination of multiple hard-to-control factors.

That said, I can totally imagine that a game with challenging acceleration-driven platforming controls can be pulled off effectively, but when failing a jump is as punishing as it is (since you often end up not having enough size to finish the level), making the retry arc as short as possible (like Super Meat Boy's instant reset upon failure) would really tighten up the learning arc, and better balance the feeling of reward you get when you "win" with the punishment of failing to jump out of a pit and having to reset because you were just a bit too small to make that jump. Apropos, having the jump height restricted by the character size seems unnecessarily limiting, as the player has already had to "pay a cost" to make a jump of a desired size (ie. how much water they lose in the run-up). (Intuitively, I would almost expect it to work the other way around, since the droplet is getting lighter after all.)

All in all, I found myself really wanting to like this game more, as the core mechanic is really original and cool. I do hope you keep developing this concept and experimenting with the control scheme.

As for not being able to test it on other systems, I think the intention is for reviewers to simply leave a DNW rating if they could not get the game to work on their system, which does not count towards the score. While it's ideal for all reviewers to be able to run a game, I don't think PyWeek is designed to punish entries for not meeting that ideal. That said, I would encourage you to ask for others to test towards the end of the challenge, either on the discussion boards or on the IRC channel; I've been happy to test people's games on Linux and macOS who asked in the IRC channel.

cauch on 2018/11/11 19:55:

Thank you for the detailed feedback, rdb, I really appreciate.

But now, I regret a bit having brought this point number 3, as it is definitively not worth spending more time on it, and everybody repeats things that the other has already perfectly understood.

The discussion can be concluded by a quote from you: "I can totally imagine that a game with challenging acceleration-driven platforming controls can be pulled off effectively".

This is exactly my point: I understand you don't like this aspect (or the badly tuned application of it), it does not mean this aspect itself is shit.

That's it, nothing more. I get it, you did not enjoyed it, it's perfectly fine with me. Again, in my diary entry, I say:

"I would have preferred "are not what I'm used to and therefore I did not enjoyed it""

Nothing brought by the discussion here contradicts that.

I felt obliged to precise things because some comments were implying that it's impossible to, for example, control the jump, which is just factually reductive (and I don't say it's easy or even it's not impossible, I just say I have the impression that some people saying that did not even realize that they should not use the same approach as a classical platformer).

By the way, I realize now it's not obvious for some, but the sliding and the not-controlling mid-air are THE link to the theme (Kenneth is "flowing", the definition of flowing is strongly linked to the idea of a continuous change of the momentum somehow, if you see what I mean). This is why I've forced myself to use that. Again, I get that some people don't like it, but just say "it does not work for me and I think it does not work for a lot of person because ..." instead of just saying the concept is intrinsically bad (again: I don't say you did, I just say "please try to not sound like you say that").

The last part is more interesting.

There are two things:

1) I 100% agree: pyweek being what it is, it's totally reasonable to consider that some entries will have some problems. I think the DNW way is working relatively well (as long as the game is really crashing. If the unavoidable bug is slightly affecting the gameplay, it's sometimes difficult to notice that it's a local unavoidable bug that should be ignored and not a global default of the entry that should affect the score)

2) My comment is more about what come after. I can use my entry as illustration, even if I want to point to a more general discussion. I now know that my entry crashes badly on some systems and that I have done something wrong somewhere. But I'm not the only one, some other discussions have been started on a similar subject. My question is therefore: do you have smart ideas on how something that can help those cases to be investigated, in order to progress and learn?

mauve on 2018/11/12 08:22:

Regarding bugs and errors, I think that's one of the things I want to work on in future PyWeeks. I've long thought there should be the ability to open a support thread against someone else's game. The old PyWeek tradition of commenting on the last diary entry is a workaround for missing features in that direction.

Also now we have GitHub links, a great option is to direct people towards reporting issues via GitHub (or Bitbucket/Gitlab if I add support for those).