Level: Zone of Danger

I just recreated a harder level we had in the preview version called Zone of Danger. It’s meant for players with some programming experience who already know how to use JavaScript for-loops. You have to write a couple different spells for your Arrow Tower to target the onrushing ogres.

Playtest it here: http://codecombat.com/play/level/zone-of-danger

If you have enough experience, please try it out and let me know about any problems you run into or ways it could be more awesome. If it works well, it will be announced on Tuesday. Thanks!

1 Like

Nice! I’m on it. It’s quite interesting…

There is a slight bug with the Cast button. If i put a while loop there, and it’s automatic casting, it says “Casting”. and remains like that. It greys out. and it will not accept it . I need to reset the chooseAction() method to make it work again…

LE: Yup, it’s an issue with the while loop. It stucks. With a for loop works just fine. Have you finished it?

LE 2: I have an issue with Grogg. Wich comes from the fact that i cannot operate on the attack(target) function.
My tower selects Grogg the Ogre as nearest enemy, but before he dies, others come in range, but i cannot select them cause i believe attack() attacks until the target is dead. and i cannot interrupt it without going into the attack method. therefore, if grogg gets selected as 1st target, then the tower dies.

One way around this, i believe, would be to lower the tower range, but i presume it would be more dificult later, with more mobs.

Without a quick primer on the Pythagorean Theorem, the distanceTo method might be a bit difficult for some younger players to complete.

Maybe not for this particular level, but it would be cool if you had to prioritize targets by health, speed, and damage rather than just by distance. In this level, it’s easy enough to kill everything without worrying about a bunch of fast units reaching your tower while you are still attacking a slow unit.

1 Like

@nightwolf, It sounds like the while-loop might not ever be finishing? I have some support in there to stop infinite loops, but it doesn’t work well yet. What was your while-loop code?

The attack() method will switch targets in between shots; it probably still thinks Grogg is the nearest enemy. Did you get the distance method written in addition to the getNearestEnemy method?

Thanks for bleeding on this one.

@Limyc I agree, it needs more introduction–you wouldn’t want many players to just jump in and calculate distances. If anyone wanted to write a quick primer on the Pythagorean Theorem and/or distance calculations as a new Article in the Article Editor, I’d happily add it in the Guide documentation tab for this level. Or I can do it myself a little later on.

There’ll be plenty of levels where targeting prioritization will get more interesting, oh yes.

I am reviewing the code now. The obvious issue is the nearest enemy remains Grogg. I fill figure it out after some sleep.

Regarding the Pythagorean Thereom, i guess depends what you learn prior to learning to program. But putting it into the Guide seems like a logical choice. Cheers.

LE: The issue was the property “length” of enemies. I wrote it wrong. Now it works just fine. One question. Is it normal for
the ogre’s to jump when they get hit? Some of them jump right after i hit them.

Well, I believe my code is right, but… what happens is that the tower keeps attacking Krogg (it stays with very low health) until the other little ogre hits the tower, then the tower starts hitting it and kills it.

@nightwolf, I don’t know what you did to fix it… I’m pretty sure enemies.length is well written lol and I applied the distance between two points formula correctly.

Also, I’ve realized that you need to cast each function after finishing it, otherwise the other edited functions which were not cast are lost to the default! It’s a bit annoying :wink:

I’ve found that the tower attacks the little ogre just because it is blocking the tower’s aim. Didn’t know that was possible :smile:

Can’t wait to get the multiplayer and code persistence working again; that would really help with me jumping in and seeing what’s going wrong here. I just confirmed that the level is winnable when the for-loop to find the nearest enemy and the distance function are both implemented correctly, so I think there might be some other mistake in there.

You can use this.say() to get at any debugging info you need.

This was a neat level, having the multiple tabs and building the method from scratch, although I took a long time in figuring it out. Here’s my feedback as someone that hasn’t learned any programming aside from this game.

The multiple tabs were a welcome sight, but I actually got pretty confused on how they interacted. Maybe putting a brief description on the tooltips for the getNearestEnemy()/distanceTo() to explain that when you use it on another tab, it jumps to this routine and that what the return statement does. The Hunter Triplets also had a return statement which was confusing for whether it was a method available or something else entirely. The distanceTo tab implied what it was for, but a small explanation saying that it makes the program return to where it jumped from, and that it can take whatever value is listed, would be helpful.

I think the only other issues I had were just personal failings on not understanding object classes (I think that’s the right term), so I was comparing integers to whatever is stored in this.getEnemies()[i]. I don’t know if there’s a way around that other than showing the realtime of what more variables are, similar to the levels were you can view what the current action or health values are by checking the tooltip.

Here’s my finished code for getNearestEnemy() though, feel free to vet it!


loved the level! was able to complete it however it would be awesome if there was an alternate to using this.say() to print out values because there were times when the code would not work as intended after adding it (something about object is not split i forgot the exact error).

i had a “finished” code which would complete the level, but when i added a this.say() to test out some values it would bug out the tower and not be able to finish the level anymore. i think i added it to the 2nd spell, the one between the main one and this.distanceTo(), as i was trying to test out values of enemies.length throughout the fight

it was pretty hard to debug some parts because i couldn’t get the values i wanted to show. i’m not sure what is causing the error or if i was just doing something wrong because i’m not really that knowledgeable about these stuff. :frowning:

@F4E, enemies.length is the right syntax. i wronte lenght :"> . That was my issue.
Also, what yous ay happened to me, and i realised it’s because the arrows launch from the middle of the tower, and hit in a line. So if anything gets in the way, it gets hit.

@Lloyd, you are right, we need a debugging option other then say. Until we find a better way though, we should stick to say().

We do need to explain a bit of how spells are cast, for the ones with 0 knowledge of programming. I will write a bit on the article in 30 mins about that.

Well, that spell button was not working after finished coding the answer, but I feel that is because my unstable internet connection. After restarting (and just in case, copy-paste the code first to notepad, so I can just paste it again), it works. So no problem in my part.

However, I would suggest guide the player to which tab to take care first, perhaps?

Ohh I figured out what I was doing wrong.
I was just passing an argument to Math.pow(), so it returned a NaN. I frequently use a square function, so my bad here.

It could have warned me, though :smile:.

@Aftermath, you’re saying you were able to beat this level and you had never programmed before CodeCombat? If so, that’s… unexpectedly amazing!

this.say() does expect a string, so if you passed it something else, it might have complained. I want to improve this to be able to handle other things, too, or at least complain sensibly.

@Lloyd I have some incredible things in store for viewing the value of all variables in your code whenever you want, oh yes, oh yes. That will make the this.say() debugging hack much less important. You’ll be able to hover over anything in your code to see its value, and to also scrub through time to see how its value changes, and to step backwards and forwards from one statement to the next.

@vandeput good point about guiding the player where to start. Any ideas on how best to do it? Currently I have an arrow pointing toward the getNearestEnemy() tab, but perhaps we can add something else to make it more clear.

@F4E Interesting–I hadn’t thought about instrumenting the built-in Math functions to make sure their arguments are correct, but you’re right, that’s a common gotcha and we should protect against that. I have added it to my list.

1 Like

Well, @nick, I prefer if the player is limited to that tab only (other tab is grey and disabled). Of course, if this is for more advanced player, only few guide like arrow is sufficient :smile:

@nick that would be awesome! can’t wait for the changes. been enjoying this so much will continue trying to give as much feedback as i can. more power!

@nick Yeah, the only thing I had done before this was about 10 years ago, making formulas on a TI-86 for school. I did learn if/then statements, but that was pretty much all that it had available. I’ve always felt like I should have learned to program, so this game is a great first step towards actually learning it.

If I can get familiar with the editor, I think I might try making a level to explain arrays and another for for().

the level seems buggy at the moment, not sure how to explain. can’t edit the different spells properly

I think I know what might be wrong with this. I’ll see what I can do to get that fixed up.

Yes, the editor for this level seems quite buggy. It is exhibiting the same behaviors as it did yesterday. The day before it worked just fine, as I spent hours working on the level and returned yesterday to finish it up. I was hoping to be able to finish it up today, since I was not able to play the level yesterday due to the buggy state it was in.

For me all the pieces of the spells now shows up in the chooseAction() function/spell tab, instead of being broken up between the three spell tabs. Also, it was giving the brown error messages for a few different errors, as soon as it loaded up.