Hi, I just engraved myself in the highscore for the jpeg level with 17 seconds. What a lovely competitive game! I had great fun just "shooting from the gut" (no minmaxing, just did the movements i would do "instinctively" to get to the requested position)
I particularly cherish the "show me the moves of leaderboard games" feature which hopefully can serve as an educational resource.
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.
Vim Adventure is great! I find it annoying that it's 25$ for 6 months, because I definitely won't pay again just to quickly redo one level. I think a one-time payment would be more fair.
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.
Agree wholeheartedly. I did pay once but the sour taste it leaves in my mouth to redo what I’ve done makes me reluctant even to recommend it to others. I do recommend it, but with a caveat that probably scares them away.
Sorry about that! Something seems to be broken with my publishing pipelines. It used to be a graceful switch. Now I have to manually invalidate a cache. Seems to only happen on some publishes.
I'd like to play, but the line numbers are following the cursor. Seems like a bug, but am I missing something? I'm not an experienced vim user but I'm normally able to navigate fine (albeit slowly).
Just wanted to mention that I've made those settings configurable now, and it'll default to the normal vim line numbers. Feedback shifted this one up the priority list!
Thats a good point! I'll have a better description by the next release.
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
There are some things that make the fake scores really obvious.
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.
I really need to second keypress minimization as a competitive factor! One reason why Vim appeals to me is not the speed (which is great) but it's ability to minimize the keypresses needed to go somewhere, or to do something.
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 think adding the ability to order by different columns would be good.
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.
Just a note, I've looked into this a bit more and it's technically possible. It would just require some redundancy and extra logic to keep everything in sync.
The donate feature has a goal now to replace dynamo db with a sql db because it will make development and maintenance easier.
I actually think the wall clock time that is used here is a more useful metric here. Using as few keystrokes is not necessarily most "efficient" in time if you have to think longer about which ones to press.
Hmmm, thats interesting. Right now it just shows every character press, regardless of what it was to achieve.
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!
sounds interesting but I don't understand what:"12 Targets (Burn Detector)"
Means. What or where are the targets?
I got it! Navigate to the yellow flashing square!
Is fun but the numbers are relative so I can't type:
:4
To go to line 4 which is the intuitive way.
I've got this feedback quite a few times, so I'm going to bump configurations up on the roadmap. I think proper vimrc configs might be impossible unless I swap out some of my libraries.
I should provide the ability to disable relative lines though
I'd echo that "what am I even aiming for" was an initial confusion for me as well. The targets are pretty subtly styled and it took a few rounds of looking to realize it was already there. Also found it confusingly visually similar to the matching-brace/paren/bracket markers. And I'd say I have sharper eyes than most. I imagine even mildly color-blind people will struggle.
Changing to a more distinct color for the targets could already help a lot to improve on those parts I think.
I've had a similar idea on my backburner for two years, as a fun project to dabble in Elixir, but this is just so much more _fun_ than my version which looks like an admin page that just happens to have a Vim canvas on it.
This was really fun! I could imagine myself really getting into this, as someone who enjoys Vim motions. It would also be great to see automated replays, based on the inputs in the leaderboard.
I've heard that feedback before, but I couldn't quite understand what was wrong. I'd really appreciate your help in troubleshooting.
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?
Not the person you're replying to, but I agree that for me (as another heavy shift-G user), vim-racer having `:relativenumber` turned on is where my own troubles are coming from.
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 using relative line numbering, at least for me this is how I've had vim set up for the last 10 years. It makes commands like 10j easier to do because you can just look to the side and see how many lines away the target is.
That’s so funny, I love relative line numbers, but I had no idea about half the tips in here.
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.
This game made me realize that even if I think it's sweet to code with keyboard only, using the mouse is generally faster, especially in this game where there's no back and forth to type something.
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.
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!