Play Home Contribute Github Join Us! Discourse Staff Members Github Contribution Guides Team

What does it mean a Hard Execution Limit of 1000000 exceeded?

Like I mentioned here, I’m trying to use Machine Learning to solve one of the levels in the game. I believe I finished my implementation and when I press play, it seems to me that it’s working pretty good for a first attempt (Sure, it might achieve a better result with some more working, but it looks somewhat nice). My problem is the post title, after about 35~40 seconds of execution, it gives me that error. Does it mean that I’m demanding too much resource? Can I conclude from this that it will not be possible to use Machine Learning in any level? Thanks.

it means that youre in an infinite loop. check your loops.

It’s unlike that the algorithm runs smooth for 30 seconds and then detects an infinite loop.
I do, though, have a loop{ }, but a lot of levels doesn’t detect it as infinite loop. So far, the code has about 120 line of code and for each interaction of the loop, it has 1 for inside 1 for and 1 separated for.

i think thats a level to high for me o.O
i get the problem when my char is going to do the same for to long. f.e.:

   if x:
   else: move()

that means hes doing the same for like 5 secs and he “thinks” thats an infinite loop. So you mostly can ignore this. But for your complex programming, i dont know what it means.

usually hard limit means “infinite-loop” but it could be achieved by heavy computation per loop iteration.

@deleugyn That’s really interesting; I’d love to make it so that you can test out your machine learning approach. The hard execution limit can be raised by increasing this number in our client code: – which I can easily do locally, but I’d need to code up a way to enable higher limits for certain cases (while keeping it fair so that, for example, players don’t end up playing multiplayer matches against a solution which uses a billion statements and takes ten minutes to simulate). Can you let me know what level and what team your solution is for so I can check it out?

@nick, I’m playing the level “Multiplayer Treasure Groove” on the 2nd world, I guess as a human, I’m not sure.

But as pointed out by @bmmtstb, it is possible to get an infinite-loop by moving to the same spot over and over again and I realized that my code runs a lot more faster than the hero moves, which end up causing a “go to this item” more than once. Thank you @bmmtstb

I managed to implement one newer version of the code that took almost 50 seconds to blow the Hard Execution error, but the moving performance was awful due to the fact that my hero would move to a coin even though it had already been taken by the enemy hero. Aside from that, I think the reason why it allowed me 15 seconds more of computation was that I was preventing the command this.move to be called until I reached the goal I set from the previous call.

I rolled back to the code that takes about 35 to blow, but have a better movement performance (in terms of the game goal). I’m going to think more about a better move implementation tomorrow.

Little bit tiny merged doublepost (Hint: Editing also bumps)

Little bit tiny bump in the topic ,-,

Hello there,

I’m currently working (8h a day) on the new tournament Zero sums. I’ve been crafting some pretty efficient code in several aspect of the game : coin looting, smart summoning, smart fighting for every single summoned unit, smart yeti-kiting. All that with a whole lot of barycenters and vectorial stuff computed each frame.

For example, I compute barycenters (O(n²)) for each type of units, coins and corpses, distances (O(n)), alignments (O(n²), Angles, curved trajectories ((O(n)) in order to make a more clever decision process.

Each part of the code works seemingly fine on its own (looting phase, yeti phase, fighting phase etc), but now that I’m trying to bring the pieces together, I also hit the Hard Execution Limit. Especially against stronger opponents, where battles get messier.

Even though I could have coded to run more efficiently, I’m a little frustrated to have to optimize before finishing my algorithm.
Still I would like to make it work, but I need to understand how this limitation works.

Is it a limit per-frame ? (no frame can exceed an amount of time to compute itself)
Is it a limit overall ? (only the total computation time is limited)
Is there another limit I should be aware of in this tournament or in general ?

The key idea I’m going with is a “video compression” : I would like to compute only a “key frame” for variables that are heavy to compute and arn’t changing much (best example : the BaryCenter of the coins), and to keep these constant until the next key frame (every 25, 50 or nWhatever frames).
Do you think it’s efficient ? Do you think of any other way to prevent reaching this hard limit ?

Just a quick note to cover part of the limits question.

The error-message “slow code or infinite loop” means you’ve exceeded the “between actions” limit. (My understanding is that your code must “yield” (I believe is the right term for this part, someone will correct me if not) every so often or it gets grumpy. The easiest way to insure this is to take an “action”, move, attack, say, cast, and others that “take” time.)

The “hard limit” error is a total execution limit. That number of (transpilled) statements is all you get, period. (iow: overall).

Those are the limits I know of…

Don’t take my word as the last one spoken, but the Hard Execution Limit is as far as I know the total amount of instructions in JS that gets executed. So if you take more instructions before the level finishes, it’s an error.
Now the problem is that other languages are first translated to JavaScript and this translation is not perfect, that means the resulting code is usually longer, thus the original code has to be “shorter” than 1000000 executed commands. Result: JS-Programs can be more complex.

@nick can you tell way more about this, though you will have to wait another day for him (see pinned post).

I don’t know how hard it would be to change that, but maybe one could introduce a HEL-per-Frame and drop the overall-HEL. Overly complex code still won’t work, and endless loops are already catched otherwise. If your code didn’t finish until the level ends… Well, you loose. But I’m sure there is some intelligent reason why it isn’t done this way.

1 Like

Really appreciate the helpful insight. Thanks guys.

It genuinely bothers me that one can reach a hard execution limit even if they never get a slow code of infinite loop. Further, shouldn’t the limit be raised for levels with longer time limits. Aren’t we trying to teach people logical strategies which is going to require more and more instructions for each step?

That’s what I am trying to achieve with the second half of my answer. Sadly, due to the bus-factor, only Nick may be able to answer this, and he is still K.O. according to the HipChat. And after this he will need some time to catch up, as in the last 3-4 days approximately 20 new Topics and roughly that many updates on existing topics happened (personal feeling, I didn’t look in the actual stats).

You’re probably right, but one have to remember that this game changed a lot since it’s beta release. We’re now going from “Learn JavaScript” to “Apply Machine Learning Algorithms”. Two totally different worlds. Once you plan a “learn Javascript” game, you think that the mentioned 1 million would never be achieved unless on an infinite loop. Now with the multiplayer and all this programming battle, people are starting to bring optimization concepts and Non-Linear Programming to the game.
Let’s hope the developers have enough time to come up with a way to allow us to apply those concepts in a separated world.

I was not around for the beta, so I’m not aware of what it was before.

I’m not sure I agree, but I can understand why you say so.

Not true. This can easily be achieved even with efficient loops. Intermediate JS programmers are aware of this. Just a couple of complex algorithms can wipe these out quickly. Really, this was planned, and very rightly so to aid novices. The issue is that it is not progressive, nor consistent. The more language techniques you use, the faster these get used up.

Additionally, it applies to all cycles, so any while loop that doesn’t result in character action will quickly add these up. Further, a while loop will rack these up faster than the in-game loop statement. In fact, one would be surprised just how easy it is to reach the 1000000 limit. I can easily achieve it with efficient loops on every level that allows boots with move() or glasses with findEnemies(). That said, I know how to avoid it and ride the edge of that threshold to maximum effect.

Which is totally amazing!!

I have confidence that it is just a matter of time.

I think there is a strict difference between the solo campain and a tournament context. The competitive environment makes people trying to be better than an opponent, not only better than a simple AI (however hard the AI is). Trying to be creative is fun and fun is a good learning environment. However, the variety of skill range in programing is so wide on the internet, the first ranks in online tournaments will always be taken by fullly skilled programers, and could discourage the ones who are still learning.

I’m 30 and I need not to learn anything from code-combat, but I love the way this CodeCombat tournaments fulfill my childhood dreams of RobotFighting. So I take this seriously (even though my new born child doesn’t let me code for fun a lot !), and many skilled people do too apparently. But if I were 20 years younger, I couldn’t compete with those guys, and wouldn’t like to see myself so low in the ranking, even though I’m trying really hard with my middleschool knowledge/skills.

I don’t think a tournament is newbie friendly (newbie = learning student), and that’s why we see these complex concepts brought in. Keeping a low hard limit doesn’t make the tournament more fair toward them. It just make good programers scratch a little bit more their head. Which is good, but this is not what CodeCombat was meant to be. (a place for kids to learn their first coding language in a friendly and fun environment).

PS : I would love to know if there were a hard limitation on the @nick success on defeating Sarven Treasure.

Absolutely agreed, but that doesn’t necessarily imply that there are less instructions or computations, just that they are different and more unpredictable circumstances.

Totally with you there. (38, myself)

That’s not why these complex concepts are brought in. They are brought in to teach that with added function comes added capability, which means generally greater application. Many programmers (newbie and oldbie) also learn by getting schooled with superior techniques. By showing that there are many ways to approach a single situation, it inspires creativity. I’ve even seen novices attempt to use complex algorithms just to see if they can, and the multiplayer forum gives them a chance to see how and when they work.


I don’t go anywhere near this comprehensive with my code so I won’t encounter this problem ever.
Or so I thought.

Just before, I experimented with a single pair of nested for loops (O(n²)) on a multiplayer level. The code seemed to work better against the sample AI than my previous one but later I tried it in a different situation where n was larger and it hit the execution limit, causing my character to completely stop part way into the level.

Edit: I just watched one of my loss replays.
My character was getting coins at a faster rate than the opponent until he hit the execution limit. Then the opponent eventually caught up. I’m switching back to my earlier code.

I’m going to triple the hard execution limit to three million statements. I really don’t want to increase it too much, because code will always expand to fill however much room you give it, and it’s no fun to play something when it’s simulating much slower than real-time. But maybe it’ll give a little extra breathing room on Zero Sum.

My code on Sarven Treasure, against hundreds of enemies, with hundreds of coins and missiles, was hitting the execution limit on the first pass, but I made some very simple optimizations and it worked. I was able able to calculate centroids of all enemies on Zero Sum and force distance vectors of all coins without having to optimize or hitting the execution limit. There’s always some way to easily reduce the number of statements used to save a more complex algorithm, usually by not applying it to faraway things or by not doing it every frame.


That should easily accommodate the large majority of code. Much will also be fixed as gear with more advanced functions or inspection gets released, I’m sure.

Absolutely true, but that is something that is often learned at an intermediate skill level.

Ain’t that the truth…