How powerful is the Stencyl calculator?

Hi. If you're not interested in background, scroll down for the question.
Background on my question:
I'm playing around with infinite maps, and the way I've made this work is with 2 map attributes and a list attribute.
One map attribute has all actor names (key format is "faction|#" and value format is [type,x,y,xspeed,yspeed,direction,health,damage]) and I'm doing all calculations off of a scene. Different actors are custom blocks, activated by the type key.
The other map attribute contains all loaded actors, and when actors are in range they are loaded. When unloaded, they copy their value to the map with all the actors.

Question:
How powerful is Stencyl's calculator? Would it be able to support hundreds of generated values, or would the constant checking of the distance of all the objects be too much?
Also, is there a more efficient way of making this type of infinite open world map?

Thanks in advance,
VoidShard.

I read a forum post where someone said they had thousands upon thousands of values stored in maps and lists.

Code is a very efficient way of working. I'm sure that you won't have any problems.

This is a question that has a fairly complex answer. First, there isn't a "Stencyl Calculator". Stencyl's design mode produces Haxe code, which is then compiled for the desired platform: Desktop, iOS, Android, etc. The efficiency of the code that is generated depends on several variables... most of which doesn't matter at all unless you're writing code that is executed every step (in an "always" event) or frame (in a "drawing" event)... and sometimes in a collision event.

So the answer to your question will depend on how many values, how often distance is checked (what do you mean by "constantly"?), and how distance is checked.

When these things do matter, keep in mind:

Using strings to look up data (game attributes, actor values) is more costly than direct reference to a variable.
To ensure code compiles and supports all expected features, using design mode generates redundant code that you wouldn't write in code mode.

This link that @merrek found way back maybe of some use for performance wise.

https://streamcomputing.eu/blog/2012-07-16/how-expensive-is-an-operation-on-a-cpu/

Ouch, trigonometry is very consuming, especially since I'm calculating it for every single object! Thanks for the link, it was very helpful. I just sped up my math by about 40x.

I don't think you're at the point where you need to worry about individual arithmetic operations. In fact, the scale you mentioned (hundreds) doesn't sound large enough to cause a problem anyway. But in case you do need to do some analysis,  the cost of an arithmetic operation is marginal compared to the cost of, say, searching for a particular value in the map to do arithmetic on. For certain types of attributes, like the two I mentioned earlier, Stencyl uses strings to look up a value. The cost of looking up such a value is far more than the arithmetic.

For efficiency, I'd think about how the computation time scales up with the size of your map. For example, if you're checking the distance of every actor from every other actor, then the number of distance checks is a multiple of the square of the number of actors. i.e. the time your check needs to run is a polynomial function of degree 2 of the number of actors. If you can accomplish the same goal by writing a procedure whose time function is of lower degree, you'll gain some speed.

If you are concerned with resource usage, you could always decide a minimum requirement for constantly checking the distance. For example, if the distance check is for a live updated map and for rendering the graphics for two or more players in a multiplayer game, you only need the rendering to be constant (in an Always event).

The player won't be affected too much by the map only updating once every half a second (about every 50th frame on Flash with default settings), so there you could save yourself a lot of the process power by only running that calculation twice per second.

The rendering of the other player don't need to happen until it is in view, so you can have a function to check if the other player is feasibly within rendering distance within the next 10 seconds, then move it to check every 5 seconds, then every second before finally going to constant monitoring to save a lot of processing power.

But for most applications, you can run thousands of these calculations without noticing any performance loss, even on lower spec machines.

There are mathematical ways around these problems?

Depending on what you're trying to accomplish and how you're currently doing it, there could be a better way. If you read up about sorting algorithms, for example, you'll see computer science experts talking about "best case" and "worst case" scenarios. Depending on what you already know about the data you feed to a sorting algorithm, then, you could pick one that would be the most performant for your use.

Obviously that's just an example and there are plenty more possible. As always, it depends on the "problem".