Lost Viking Guide Suggestions

1

After doing Lost Viking, I found that while the Guide was definitely important, it also may be causing others undue difficulty. Here are some suggestions to avoid the “How do I do this” and “What does this mean?” posts.

  • It gives a clear example of how to use SKIP, SWITCH and SLIDE, but portrays the example as rules, not an illustration of the rules.
    • Suggestion: Explain at the top that the values in the guide are an example.
    • Suggestion: Use the actual words rather than the numbers… and make the larger example 3 smaller examples.
  • The example for SWITCHing is not clear.
    • Suggestion: Instead of saying 7th step is north, 8th is south, I recommend 7th step is north, the rest are south until you SWITCH again.
  • BOUNDARIES is particularly confusing for some. I think this can only be resolved if the 1st two suggestions are followed.

Great level, BTW. There’s a couple of really important concepts in here.

2

Thanks for the feedback :slight_smile: I’ve made some changes to the guide.

3

Thanks for the quick turnaround. Overall, I think that is much more clear and should give other players the proper guidance. Again, great level.

4

SLIDE = 9
SWITCH = 5
SKIP = 7
[1,1]->[2,2]->[3,3]->[4,4]->[5,5]->SWITCH->[6,4]->[7,3]-> SKIP->[8,1]
Is my SKIP OK ?

5

Perfect! Yes, your SWITCH is working correctly. As should be your SKIP. Now you just have to get your SLIDE and you should be golden.

6

SLIDE = 9
SWITCH = 5
SKIP = 7
[1,1]->[2,2]->[3,3]->[4,4]->[5,5]->SWITCH->[6,4]->[7,3]-> SKIP->[8,1]->SLIDE->[9,9]->and BOOM ->[10,8]
Is my SLIDE working correctly ?

7

By george! I think you have got it. Just keep in mind that after [10,8] you will be SWITCHing again, which will lead to another SLIDE. If you’ve got that all in mind, your code should be close to done…

8

But it seems already [10,8] is wrong. Why ?

[1,1]->[2,2]->[3,3]->[4,4]->[5,5]->SWITCH->[6,4]->[7,3]-> SKIP->[8,1]->SLIDE->[9,9]->and BOOM ->[10,8]->[11,9]->SLIDE->[12,1]->[13,2]

9

[10,8] should be correct according to your SKIP, SLIDE and SWITCH values. If it is not working, there might be something else wrong with your code. You might consider posting it.

10

Whoa, what a level ! Nice work here, really.

I need to mention that I solved it with my old boots. But with the +2.5 boots, and the speed ring, it fails. I search a little bit and I found that it was because I add a this.say call, and it cause the hero to slide after the position. And boom.
Without say call, it works with all shoes and ring.

I did not read the first version of the help, but I think the actual one need also a slight rework.
About the slide, I misunderstand it just because I read it too fast (and also maybe English is not my favorite langage :slight_smile: )
I was just doing -1 when reaching 10 instead of going to 1. But in fact, my fault.
The part I think that needs more clarity is the SWITCH. The first switch is very clear with the example. But we don’t know if we need to switch again in the other direction when the value can be divided again. After searching a little bit, it seems that yes, but I think it should be mentioned in the help text.
Then for the skip, we would like to do the same. I mean change the step to 2 and keep 2 as the standard step. But ok, if we read carefully, it’s written : for that step. Maybe you can add ONLY, to differentiate from the Switch case.
And also we would like to do it for the step number 11 ( if SKIP == 11), but for me it works only If I do that for step 12. And for this I think the txt seems not correct. So we could have in the help txt: for the Next step Only.

I also need to change <=35 to < 35 to avoid to explode at the end (even if the level was successful). Strange.

I reload the page, but never get an other version with different values. An idea to allow players to get values without entering them by hand: Put somewhere some coins, and ask player to count coins : silver coins for slide, golden for skip,…

Edit : maybe it’s a good level to learn people how to use modulo : %. Maybe it could be explained somewhere.

11

The thing with say() causing drift should be fixed now. Also the raven will say some stuff to hopefully help with debugging.

1 Like
12

This is intentional. It is unique per player, not per submit. This is because the hero code cannot read messages from others (with the currently required gear) in order to get the correct SKIP, SWITCH and SLIDE values.

13

The thing with say() causing drift was my problem …

14

For me the drift seems not solved. I just try, and it’s funny because for the first two move, it’s ok, the hero stops right on the point, but for the third and the others, she slides and stops after:

Good:

Bad:

15

Today, it’s working fine. No more sliding.
The flowers are very nice :wink:

16

To make it work, I had to check the “SWITCH”-condition after increasing the steps-variable, but not yet moved, which means the check is all about the step I’m about to take, not the one I just took as stated in the help I was following.
Just a little semantic nitpicking, really great learning level!

17

I would like to share the same enthousiasm as my fellow CodeCombaters in this thread, but I think I’ll share my negative feedbacks about this level, which I hope will be constructive.

First of all (positive), I like the use of the modulo function for the SWITCH part : changing periodically the sign of a variable is adapted to use of the modulo function.

SKIP part is fine too, I guess… It feels more like an excuse to use a modulo, but why not. Although I’m not a fan of the “minus one” in the following if statement and might put an unecessary difficulty, when the Guide is suggesting to check if sideSteps is divisible by SKIP. Didn’t work for me, but worked when steps -1 was, as shown below :

if ((steps-1)%SKIP===0){

But now, here is my real wrong feeling about this level : the SLIDE part. First, it’s not mentionned in the guide, but :

    // (1)
    if (sideSteps<1) {
        sideSteps+=SLIDE;
    }
    
    if (sideSteps>SLIDE) {
        sideSteps-=SLIDE;
    }

is equivalent to :

// (2)
sideSteps = ( ( sideSteps - 1 ) % SLIDE  ) + 1 ;

So 1st negative feedback : the use of a modulo function on the SLIDE part of this level seems VERY counter intuitive. We’re using an artificial not-continuous function (modulo) to set the next position of a Heros (which is by essence continuous as a physical function). And the motion isn’t set as in old school mario where you appear on the other side of the screen when out of boundaries, but the level makes your hero actually go to the other side THROUGH the field which is counter intuitive to me. Why not teleporting him ? At least that would make sense to me rather than WALKING from 1 to SLIDE or from SLIDE to 1.

I love the idea to teach people how to wrap around arrays and stuff, but I think in this very case of the SLIDE part, it’s not helping much to learn what a modulo is actually useful for.

2nd negative feedback : My personal preference when it comes to modulo in my programs is : never use a 1-based array when you can use a 0-based array. It’s so confusing to modify the natural interval of possible results from [ 0 , n-1 ] to [ 1 , n ]. I consider a “not optimal” way to to teach “how modulo makes things easy” when your exercice asks for a [ 1 , (SLIDE-1) +1 ] interval of work.

3rd negative feedback : The modulo function is bugged in JavaScript for the negative numbers, which makes learning a bit more difficult. That doesn’t help a new comer who has the correct idea to understand what’s wrong in his own program. Again : modulo is supposed to be much simplier than any other way to code periodic stuff. And when I solved Lost Viking, I didn’t feel that way.

I hope I wasn’t too harsh in my comments. I love the level, the ideas in it. I just think it’s a hard level with unecessary difficulty, and might discourage good faith students. Hope this is constructive. Have a good day.

posting and then editing for typos

18

This is not an antagonistic post, and hopefully will not be viewed as such. Many of the points above, I quite agree with. However, the nature of some of the comments, I believe, comes from a misconception that even I as a mathematical expert had coming into programming many years ago.

I quite disagree, personally. Modulo is perfect for limiting ranges with wrap-around behavior, as well as a huge number of applications not even touched on by our posts. I’m not sure it matters if he walks across or is teleported. Of course, modulo has other uses too, but array wrapping was not explored here. Range limitation was… This is especially true when you account for old style 8-bit games which did range wrap-arounds, even to the point that there were many bugs surrounding these behaviors because the devs back then didn’t know how to account for power gamers.

I generally agree with you, but this is all language dependent (several other languages begin indexing at 1). Consider that average person does not start counting at 0. They start at 1, but this can be reexplained and taught, much as it is in schools today. Modulo has nothing to do with index basis. It is arithmetic, so from that standpoint, how this is an less than optimal way to teach modulo is a little beyond my perspective.

[quote=“VincentMaths, post:17, topic:3345”]
The modulo function is bugged in JavaScript for the negative numbers, which makes learning a bit more difficult.
[/quote]’

This is false when it comes to the field of computing. Modulo is not a wrap-around operation for modular arithmetic. It is an arithmetic operator to specifically mean what is the remainder when x is divided by y. -5 % 4 will never be 3. It will always be -1. If you read the description of modulo, this would be correctly interpreted. This is the way that the majority of programming languages implement modulus. If you need a few sources regarding this, check:

Your definition (and the article you source) only applies to Modular Arithmetic - which is based upon but very different from the modulus operator. The difference is explained at this math based forum. This post points to the many discrepancies in definitions over time, particularly in mathematics. Even programming languages differ in this; see How does java do modulus?

19

Yea, totally agree. But so many people on the internet (me included for a long time) are confusing the two notions : Modulo and remainder. They are equal on the positive numbers, but differ on the negatives.

In JS, (and as you mentionned other languages), the natural mod operator % is actually the remainder operator and there is no actual modulo operator. So in this case I think it has to be mentionned : “No, the use of % isn’t accurate to keep a variable within a range”. This WILL confuse people if they’re not taught to be careful when the variable goes in the negatives.

This is not obvious at all that the natural “periodic operator” isn’t actually periodic.

Maybe I could have been more accurate when I said : " % operator broken". What I meant was : “we should warn new comers on the subtile use of %, as it doesn’t limit the scope of values for negative numbers.” But the actual modulo does :

Number.prototype.mod = function(n) {
    return ((this%n)+n)%n;
};

As a side note, the % operator isn’t what’s taught in schools about what a remainder is. From the definition of the euclidian division : 0 ≤ r < |b|. The % operator doesn’t obey this.

Given two integers a and b, with b ≠ 0, there exist unique integers q and r such that a = bq + r and 0 ≤ r < |b|, where |b| denotes the absolute value of b. 

The four integers that appear in this theorem have been given names: a is called the dividend, b is called the divisor, q is called the quotient and r is called the remainder.

But I guess we’re back in the arguments : the “arithmetic way” or “computer’s way” to compute remainders.

1 Like
20

Totally got your back on this.

Never said that it was. That was in regard to 0 vs 1 as index basis. This is another one of those “how does the language implement this” kind of thing. You are absolutely correct, however (with regard to remainder), computing needs are far different that mathematician’s needs, and therefore it may never match.

It does indeed limit the scope, but not in the traditional euclidean way. The scope is 0 < r < b, which is just as valid for computing purposes. Further if we desire different behavior, we can always override this behavior.

It is, in fact, periodic as one progresses from either 0 to infinity or 0 to -infinity. Just not -infinity to infinity. Again, language and computing architects have determined this to be valid for their needs. As a computer professional for over 20 years, this more than meets the majority of my needs. That said, it doesn’t meet all of my needs for such a operator, but no single operator or function ever has in any of the languages with which I am proficient.

As I linked, there is no straight across the board agreement on what this is. Until there is in both computing and mathematics in all contexts, there will always be argument. The only recourse is to refer to the language documentation.

You’re absolutely correct, but I cannot think of any way to fix this without subjecting them to even more confusion. In short, I don’t think there is any way that the level architect could have done any better.