4 kyu
Top Down Movement System
83 of 206EatYourBeetS
Loading description...
Games
Logic
Puzzles
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
Integer
constructor deprecation warning in Java's full tests:The preferred method nowadays is
Integer.valueOf(j)
.I rarely say bad things about a kata, but this one was confusing in Java.
My main problem was that my direction always should be something of 2/4/6/8, it is constantly tested, just as my initial direction as 8. But at the same time if the player presses 8, I cannot start moving into that direction, even though basically I was facing that direction already. I let that go, because initial state and stuff.
But then random tests started failing, because apparently if every key is released, I should "lose" my direction (well, obviously not actually lose it, because the tests will still test it, there was a rule that I should not change direction if nothing is pressed). But then once again, I am facing a direction, and if that key is pressed, i should not start moving, but should face into that direction even more. I mean I could figure it out, but I think the rules of this game are a bit unclear.
Even if you do not accept something like direction -1 for "rest state" (just from the top of my head), it could be clarified in the rules, that even if you technically face a direction at the beginning of the game and after all keys were relesed, you should never start moving instantly. Technically rule #2 implies something like you should never start moving before the second iteration of a key being pressed, but the first rule implies that you should not start moving because you should first change your direction.
Still gave it a Somewhat though, the idea is really cool.
I liked the kata but I agree, this part about always having a direction even when no keys are pressed at all and therefore there is no movement is weird. An invalid/uninitialized direction like e.g.
-1
or0
would have made the API clearer. The defaultUP
direction does not make much sense either.In Python the description mentions
enum
, but there is no enum to be found. You have to get direction numbers from sample test cases.How about actually adding
IntEnum
holding directions? It does not break the existing solutions (and doesn't even require changing tests) sinceIntEnum
instances are treated as integers.Fork
.
It should be stated that the key-press always resets the direction, even when the character is already facing in that same direction.
Great kata but very tedious to debug!
Overall, very instructive. Thanks!
Not all language have
enum
construct, these part of the description should be made language specific.Not as difficult as what the kyu rating suggests.
sampleTests(SolutionTest) Log Press Down Press Left Press Right Wrong direction after update; expected:<4> but was:<2>
Hi, I have a question here. When I was running the sample test, it said the expected direction was 4, which was Left. However, the precedence of Down was over that of Left. Could someone explain to me why the expected direction was not Down??
Hello, the order of precedence is considered only when you press multiple keys in the same frame e.g
Press Down, Press Left, Move -> should be down because of precedence
Press Down, Move, Press Left -> should be left because it wasn't pressed at the same time as down
Why Direction enum is 8, 2, 4, 6? Why not 0, 1, 2, 3?
It's done for many old games because this allows you to:
In any case, it's arbitrarily defined anyway and it's perfectly fine to define them as
sqrt(2)
,pi
,e
,Infinity
too (even though that'd be bad and ridiculous).for those still interested: 8, 2, 4, 6 are obviously numbers on the keypad on the keyboard. Like, literally, if you look at the right-hand-side of the full-sized keyboard, these four numbers have arrows printed on them: 8 is up, 2 is down, 4 is left and 6 is right.
Nice Kata, but one thing in my opinion is not explained well.
Ok, understandable, but then you set the direction to 8 in the very beginning, thus implying that first direction is UP, and if UP is the first move, we can move straight away, and do not need to change direction to the one that is already set properly (I thought I don't need to change from 8 to 8, but I was wrong).
Also, when you press some keys, and a direction is set, let's say, to 8, then we release all the keys (but the direction stays as 8), then we press 8 again, I thought that the player can move straight away, because his direction was already set in the proper direction. It wasn't obvious from the instructions that you need to change direction once again from 8 to 8.
In my opinion, you should state in the instructions, that in the beginning, and whenever there's a situation that ALL the keys are released, the direction is set to NONE.
During the first "frame" when a new key is pressed the direction doesn't matter at all, it is just updated as I stated on point 1 (I didn't emphasize that but I never said you should skip the direction update and go straigth to the movement). So when I set the starting direction to 8 I just assign an arbitrary default value, which is irrelevant to the rest of the code and could be any other direction, since it is updated on the first frame anyway.
Fair, but was still unclear to me.
That is also what irritated me. It would make more sense if you could move if the direction is already correct. The code would have been so much clear without that case...
Was approvable, but all solutions invalid except the one of the author and mine (due to some changes in the tests)... So I approved to 4 kyu, but might be a bit high. Let see what the others will say about that.
I think 4 kyu is adequate (not high) for this kata, at least for Python. It is a nice little challenge to find out how to work with existing OOP code.
Ok, cool. Thx for your feedback. :)
Hi,
Java translation here!
Cheers!
Ok, python version updated with random tests and display of the pressed/released buttons between each updates.
Important note: if tests are done in C# the same way than in Java (meaning, if other tests can be run after a failed one), you'll have to verify the place where you put the
Input.clear()
commands: in that case, they have to be at the beginning of each tests rather than at the end (in this last case, the subsequent tests may fail with a good code because the STATE isn't properly restted in the previous test).Hi,
There's something weird with the code blocks in the description: both C# and python version shouldn't be visible at the same time. I tried to update the thing in the edit panel (you used
Python
instead ofpython
; I don't know how c# is expected there... I triedc#
andC#
instead ofcsharp
but I still can see both blocks in the description... :/This comment has been hidden.
good to know!
Hi,
It's a nice one you did there. :)
I added the
__str__
method to the Tile class in python, so that Tiles objects are easily printable for debugging stuff. I don't know C# to add it there too.Verifying the validations, I saw that you inverted
test cases
andexample tests
in C# and that you had all tests in the example tests of python. So I inverted them in C# and I removed the second bunch of tests in the example tests of python.'Hope you won't mind... ;)
Hi there, I don't mind at all, thank you very much for helping!
cool :)
BTW, I didn't think about it earlier, but you might want to add to the description the availability of the
__str__
method. ;)