Vim Racer
vim-racer.com
vim-racer.com
In regards to how the leaderboard is constructed, i noticed some of the top players are at 1 second, which doesn't seem humanly possible to me (that would amount to < 0.05 seconds per move). my assumption is they are using scripted input, which with this interface will be hard to prevent. i read you are still figuring out how to regulate everything, so here's an idea: if you rank the leaderboard by number of keystrokes (might consider special handling for shift etc.) instead of time elapsed, you will get the most efficient leaders instead of the fastest ones - that way scripting wouldn't help cheaters anymore.
All the best moving forward!
I wish there was a mode where you minimise the keypresses rather than the speed; that way the best solution is Vim golfing rather than fast hjkl'ing.
Quick bug report: the character '`' appears as "Unsupported" in the leaderboard. This is very visible when following Duff's device using marks.
I think I'm working off a white list, so I should just be able to add that to it.
Or maybe if they keep adding level, we could pay per level, so that the levels that have already been paid would stay forever? I don't know.
I do really appreciate you mentioning it though because it helps in prioritization.
(Tried in Chrome and Firefox)
Really handy for relative movements like 5j or 12k :)
The game description could clarify what the "target" is.
I'm conflicted about keypress count because I really want the focus to be about speed. VimGolf does a great job of covering those types of puzzles/scenarios. The differentiator here is speed. I'm hoping that I'll be able to do some sort of data analysis on key strokes. An interesting finding might be that www is faster than f<a character>.
One of my hypothesis was that searching with 'f' and 'F' is not as efficient as simply navigating with more commong motions like w, e, h, j etc. I've already been proved wrong, Although, I should phrase it like "many top performers use 'f' and 'F'." Which would suggest that they might be fast, or using them isn't too much of a detriment
F and f are fast (ditto T and t) because , and ; are faster.
It's going to be a challenge to protect the leaderboard against fake scores. There weren't a whole lot of them before, but it's starting to increase as the site grows.
That may not equate to raw speed, but it does equate to pleasantness of use vis-à-vis other text editors, which matters a lot to the typing experience.
I'm actually not 100% sure if I can achieve that with dynamo db and my current data structure though. It has a great free tier, but the query language and limitations are very foreign to me.
If I wanted to sort by timeTaken, I had to set it to be one of the two keys. This also has the unfortunate consequence of blocking duplicate times.
It might just be my implementation that is strange, or the dynamo is significantly less featureful than an SQL server.
The donate feature has a goal now to replace dynamo db with a sql db because it will make development and maintenance easier.
1st himom 0min 1.001s 490
2nd elmoFOOBAR 0min 1.002s 400
3rd VeryFastTyper 0min 1.003s 708
4th EmacsUser 0min 1.004s 717
5th ShawnT 0min 1.005s 720
6th benbp 0min 1.008s 714
7th hehe 0min 1.023s 604
8th anthony 0min 1.274s 565
9th chris 0min 1.327s 543
10th MasterWq 0min 1.333s 540
11th blake 0min 1.334s 540
12th jbp 0min 1.381s 521
13th test12345 0min 1.437s 20
14th jonmv 0min 1.476s 488
15th spektrokalter 0min 1.577s 457
You'd be interested in something a bit more organized, so you can see how they got specifically from one target to the next. I do have a ton on the roadmap right now, but that has been added as well!
I think is why I like the jumping plugins
ArrowRight, ArrowRight, ArrowDown, ArrowRight, ArrowUp, ArrowRight, ArrowRight, ArrowRight, ArrowDown, ArrowLeft, ArrowLeft, Shift, ArrowUp, ArrowUp, Shift, ArrowRight, ArrowRight, ArrowRight, ArrowDown, ArrowDown, ArrowLeft, ArrowUp, ArrowRight, Shift, :, 4, Enter, ArrowDown, ArrowDown, ArrowDown, ArrowLeft, ArrowUp, ArrowLeft, ArrowDown, ArrowLeft, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowUp, ArrowLeft, ArrowDown, ArrowDown, ArrowLeft, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowLeft, Escape, Shift, :, 1, 1, Enter, Shift, :, 1, 0, 0, 0, Enter, ArrowDown, ArrowDown, ArrowDown, ArrowRight, ArrowLeft, ArrowLeft, ArrowLeft, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowDown, ArrowLeft, Shift, :, 5, Enter, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowRight, ArrowRight, ArrowRight, ArrowUp, ArrowRight, ArrowRight, ArrowRight, ArrowRight, ArrowLeft, Shift, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowUp, ArrowLeft, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowDown, ArrowLeft
...
I should provide the ability to disable relative lines though
Changing to a more distinct color for the targets could already help a lot to improve on those parts I think.
Well done!
My understanding is that Shift + G should be absolute positioning, so 12G will bring you to the twelfth line.
I do deviate slightly from default VIM in that relative lines are one, so the line count starts at 0, respective to your cursor. Is there a chance that this plays into your experience of the bug?
I'd really love to be able to specify whether I want absolute or relative numbering (or both or neither); the :set commands don't seem to be implemented?
It's just a shallowish vim, so there's mostly only key bindings. I'd like to support more in the future though.
Half the Vim users navigate large spaces by doing `42j`; have some thought for the other half that does `142G` :-)
I guess I can see the appeal; it's not for me though, I'm swimming in the local minimum of absolute line number dependence :)
I use relative numbers while in normal mode, and absolute numbers in insert mode. That way you get easy vertical jumps, but you still have a sense of your line numbers.
For maximum vimness you could let players mod an empty vinrc from start
The library seems great at the time, but I might need to look into alternatives in the future.
It sounds like allowing toggles for a few key options would probably satisfy most people while keeping the spirit of the exercise.
Quite nice otherwise.
However, using the mouse to navigate is flaky here, probably because of how the terminal and decorations are rendered, it lands a character to the right or left when clicking the target.
I'm actually curious who would win that race. Because you're right; mouse users have a huge advantage right now, but no one just clicks on code haha!