Level: Extra Extrapolation

Hi, I just finished creating a level about movement prediction. Could someone try it out?

Could you complete it? Was it hard? etc.

6 Likes

I could complete it, no problem! The obvious solution (to me) works, hereās what I did:

var shell_air_time = 3.4; // in seconds
var ogre = this.getNearestCombatant();
var x = 0;
var y = 0;
if(ogre) {
x = ogre.pos.x + ogre.velocity.x * shell_air_time;
y = ogre.pos.y + ogre.velocity.y * shell_air_time;
this.attackXY(x, y);
}

I like it, itās a solid level and it works. If anyone solved it some other way, be sure to put it here. The more varied solutions it can handle, the better.

Some ideas to improve:

• Add a specific article to the guide. Some story description (āthe ogre is literally running circles around our artillery! Cheeky ogreā¦ā), and a hint as to how to do it, and anything else specific to the level you want to say to learners. You can add documentation on the settings tab of the level editor.
• Have Anya come in and narrate and add a goal with the scripts so that you have an objective specified on the upper left (probably not necessary in this level, I certainly understood the goal but good to learn how to do).
• Some minor spelling and grammar errors in the default code comments. āOh noā, āogreās movementā, āwhere he isā.

Advanced ideas for improvement

• Maybe have the ogre taunting the artillery in the level. Something along the lines of āNyeh nyeh nyeh you canāt hit meeeeeā unless his health is less than maximum in which case he might say āOw! Lucky shotā¦ā
• Try adding a ācool camā at the end, that is when the goal is finished, have it play through from the beginning to the end with the artillery and ogre having a spirited dialogue. See other levels and how their victory scripts are constructed to see how we do it, in particular Emphasis On Aim with its āsuccessā script, which gets triggered when all goals are successful.
• Add a āgeneral articleā to the guide, that is something on a topic this level teaches that could be used in other levels teaching the same topic. Iām working on one teaching if/else for another level, to give you an idea what Iām thinking.

Hope that helps!

Oh and, if you have any ideas for improvement for the editor that you thought of while making this, please tell us as well!

Edit: hid my solution.

1 Like

I enjoyed this level. It always gives a good feeling when we successfuly predict something .
It can be hard for people with lack of physics knowledge, though.

The design is not professional, but it can soon become .

Mine:

``````var shell_air_time = 3.4; // in seconds

var ogre = this.getNearestCombatant();
if(ogre) {
predictedX = ogre.pos.x + ogre.velocity.x*shell_air_time;
predictedY = ogre.pos.y + ogre.velocity.y*shell_air_time;
this.attackXY(predictedX, predictedY);
}
``````

To the staff and Discourse team: isnāt it possible to add a āspoilerā (hide) option? It could be useful, just a suggestion.

1 Like

Ah, I like this! Nice tree in the lower left. This munchkin is surprisingly resilientāperhaps a larger ogre (with increased movement speed in the Patrols Component) instead? Amazed that you were able to make such a good level using the level editor in its current state! Would love to hear any feedback on the editor itself that you have. Anything you were trying to do but couldnāt figure out how?

If you have trouble figuring out how to add scripts to do the stuff Scott suggested above, we could help you through it, maybe in a Google Hangout or in HipChat. The script editor is pretty opaque right now.

Iād also make the default code use `shellAirTime` instead of `shell_air_time` to follow our convention of lower camel case instead of snake case for JavaScript. And probably `getNearestEnemy` makes more sense than `getNearestCombatant` in this one.

Let me try the spoiler with my solution:

var shellAirTime = 3.4; // in seconds
var ogre = this.getNearestCombatant();
if(ogre) {
this.attackXY(target.x, target.y);
}

Yeah, so you surround spoilers in [spoiler ] [ /spoiler] tags (without those spaces), but it currently doesnāt work with code formatting. I see Discourse is soon introducing a much cooler spoiler plugin, so maybe that one will handle code.

2 Likes

Well in this engine you can do a lot <3! Iām just poking around. Treema has a few issues but i added them on the github issue page. The editor could use a delete button.

1 Like

I like the level a lot, simple to the point. I am also fairly new to coding so it felt good to get this one right. Also this is more for Nick and the team, levels should show you other ways you could have coded it once you have beaten it. Maybe collect the code of others who have beaten it and have a sort of rating system so people could get new ideas? just a thought.

Heres mine:

var shellAirTime = 3.4; // in seconds

var ogre = this.getNearestEnemy();
if(ogre) {
this.attackXY(ogre.pos.x + shellAirTime * ogre.velocity.x, ogre.pos.y + shellAirTime * ogre.velocity.y);
}

1 Like

Itās an amazing level and whether liking it or not, people that solved this had their physics skills improved a little, which for me is the best of all. Iād encourage A LOT if people could build a mathematics section of levels, where the focus wouldnāt be JavaScript learning, but mathematics logic applied. This way, we could use such section to explain how Bhaskara, Pythagoras and other mathematicians concepts are applied to the real world.

3 Likes

Hi,
Wonderful engine you created here.

Forked this level to create a quick pattern recognition type level. Shortening the ogreās path was kinda enough, but allows targeting through coordinates. As component scripts are read-only then I canāt add random coordinates that are generated when the spell is cast/script is compiled and ran.

Even so I canāt actually do any pattern recognition since the event chooseAction triggers only when the artillery is ready to fire again. I donāt have per frame event nor an event that would trigger when the ogre changes velocity.

Also no idea why the arty got bugged visuals, that is the cannon itself has an offset.

1 Like

Thanks @pendrokar! Since weāre nearing the end of our great raster -> vector migration, Iām somewhat surprised that you were able to get the level editor to work at the moment! Iāll upload a gigantic set of fixes in the next day or two that should fix, among other things, the artillery offset problem.

Would you like to be able to add new Components or improve the current ones? I could get your account enabled for editing them. (We donāt have super-fine-grained permissions on them yet, so weād just trust you to not break any of the existing Components.)

This new level is pretty coolāthe idea is to track the ogreās path and then fire at him after the second time he goes through it and you know where heāll be? What would the desired code look like, in an ideal world where you had all the programming tools you needed for the level? I may be able to figure something out.

1 Like

Either an event that is dispatched per frame or an event that dispatches when Ogre changes velocity. Then I can add them to an array until the position and velocity repeats, allowing me to confirm a pattern and then calculate along that path.

1 Like

The levels have to run deterministically based solely on the playerās code, but that doesnāt mean that we canāt use randomness. Just thought of this: what if there was a Component that allowed the Ogre to use random numbers based on the input source code? So if you made any change to the code, the ogre would move to completely different places. With enough variation in ogre pathing (and shots required), it would take a ton of random tweaking before the ogre happened to move to the target positions you had in the code.

Another alternative is to have a more explicit way of setting random seeds, so that you as a player could make sure your code works on one seed, then switch the seed a few times to make sure the code can handle other possibilities. The code would have to work on several different seeds to be counted as victorious.

Something like this is needed for a lot of levels, actually. The other obvious way to prevent hard-coding of values is to limit the number of statements used, but then that requires the level require more statementsā worth of values than the code needed to generate them, which can make the levels much larger than theyād otherwise need to be.

Iām kind of digging the random-seed-based-on-player-code idea, actually.

`chooseAction()` is dispatched per frame, but only when the artillery is ready to act. So you could just `setAction("idle")` when you donāt want to shoot. Itās also possible to add event handlers for things like enemy target changes; would just need new Components that work kind of like `Says` and `Hears` but limited to the `visualRange` of `Sees`.

1 Like

For some reason, when the game loads I win immediately. When the ogre gets to (35,12), it runs into the tree and just stops, and the artillery kills it.

1 Like

Oops, youāre right! Try refreshing the page and playing againāIāve removed the offending trees.

2 Likes

I am a beginner at coding and this level really has me stumped.

This is my code, but whenever I cast it it says it is āout of range.ā Can someone please help me figure out the error in my code?

var shellAirTime = 3.4; // in seconds

var ogre = this.getNearestEnemy();
if(ogre) {
this.attackXY(ogre.pos.x + ogre.pos.xshellAirTime, ogre.pos.y + ogre.pos.yshellAirTime);
}

1 Like

I think you almost have it, but youāre adding the ogreās `pos` times the time to the pos, where it should be his `velocity`. Make sense?

2 Likes

Oh I see, because Distance = Rate * Time. Thanks for your help!

1 Like

my solution is:

``````var shellAirTime = 3.4; // in seconds

var ogre = this.getNearestEnemy();
if (ogre!==null)
{

ogre.velocity.z=10;
ogre.velocity.y=5;
}
if(ogre) {

this.attackXY(ogre.pos.x, ogre.pos.y);

}
else
{

}``````
1 Like

Hereās another solution, tried to minimize the memory required, and the code altogether.

var t = 3.4; // in seconds
var o = this.getNearestEnemy();
if(o) { this.attackXY(o.pos.x+o.velocity.xt, o.pos.y+o.velocity.yt); }

3 Likes

I had a strange problem with this level (maybe a bug?)
The Ogre is actually killed after 3 shoots (?), but but the level still runs.

Here is my code. looks very close to the codes posted hereā¦

``````var shellAirTime = 3.4; // in seconds
var ogre = this.getNearestEnemy();

if (ogre) {
var predictionX = ogre.pos.x + ogre.velocity.x * shellAirTime;
var predictionY = ogre.pos.y + ogre.velocity.y * shellAirTime;

this.say("Shooting!");
this.attackXY(predictionX, predictionY);
}``````
2 Likes

Me too.
And I copy the code above, and find it also has this problem.

1 Like