Depending on exactly how many elements you intend to store, can you not just use instance variables associated with the instances of each player sprite object? That's certainly how I maintain player stats such as health, score, money etc.

More complicated structures, such as per-player inventories get a bit more difficult because you can't use an array/dictionary as an instance variable. Instead I create separate array objects for each player, or alternatively serialise the inventory contents into a text string that can be unpacked with tokenat()

I couldn't open the attached link but, assuming from the filename alone that you're trying to create a soccer game, I highly recommend you get yourself a copy of "Programming Game AI by Example" - amazon.co.uk/Programming-Game-Example-Mat-Buckland/dp/1556220782

Not only is it an excellent introduction to game AI in general, but it has an entire chapter dedicated to creating the logic required for the computer-controlled team on a soccer game.

Ashley - thankyou for your hard work so far, and it's great to hear you've got lots of ideas for further improvement! I look forward to seeing the progress :)

edit - In fact, I see the nodelist is exposed so it is possible to implement custom movement between the nodes. Primitive example of looping through the waypoints follows:

<img src="http://i46.tinypic.com/21ci0w6.jpg" border="0" />

dancinLion - You can move obstacles, but you'll then need to explicitly call the "Regenerate obstacle map" action before next calculating the route.

Note that this totally regenerates the grid array, so you certainly wouldn't want to do it each tick ;)

Ashley - to facilitate pathfinding+flocking (or other interesting movement behaviours) it would seem to me that the best thing to do would be to decouple the planning part of the pathfinding algorithm from the actual locomotion along the path.

In other words, the acceleration/max speed properties and the "Move along path" action shouldn't really be part of the pathfinding behaviour at all. Instead, the pathfinding routine should concentrate only on finding and returning the best route in a manner that makes it easy to iterate through the list of nodes along the way. Rather than use a simple "Move along path" action, a developer can then choose to implement whatever pathfollowing behaviour they want to negotiate between these nodes in sequence.

The seperation of "planning" from "following" behaviours would make it easier to create entities that followed the route calculated while also moving in a manner that obeyed, say, car physics, flocking, or aspects of platform behaviour.

The pathfinder behaviour uses a simple grid-based A* search algorithm in order to determine routes between cells. Assuming you're using the default cell-size of 20, then your algorithm is generating and searching through 13000/20 * 6000/20 = 195000 cells.

So, yes, I'd say it's normal to expect that to slow your code down ;) Either reduce your layout size, increase the cellsize, or build an alternative routing algorithm that uses a more sparse graph.

Another suggestion - rather than having a single obstacle type that defines intersecting grid cells as non-traversable, would it be possible to define obstacle types with a variable property that added corresponding cost to the edges that crossed those obstacles?

For example, a "wall"-type obstacle would be completely impassable, a "rough terrain"-type obstacle would not be impassable, but any route that crossed a cell containing that obstacle would be given a higher path cost, making it less favourable than a (perhaps longer in distance) route over lower cost terrain.

I think this would be a relatively easy change to addCellToOpenList() where the g score is assigned (currently as var curCellCost = this.at(x_, y_) * 50; - not sure where the 50 comes from?), but don't know if it would make the behaviour more complex for users who don't need that functionality.

On a side note, I see the heuristic used in the estimateH function is dx * 10 + dy * 10;, which, technically, is not admissable for A* because it doesn't guarantee to underestimate the true cost to the target node. Was this chosen to avoid the square root needed to get a true straight line heuristic?

"....new path finding behavior included in r117..." - interesting, I wasn't aware of this feature (I'm only running r114 - the latest stable release). How many iterations does the beta normally extend to before the stable versions catch up?

I wonder how the pathfinding performance will compare to my own A* plugin..

FeatherFace - There's a fundamental guideline in all programming that you should never unnecessarily duplicate code. Rather, you write it once, and then call that same code every time you need to perform the particular function it does.

So, if you've coded some event logic that describes how a particular enemy behaves (on an event sheet), and that enemy appears on more than one level (layout), you shouldn't rewrite the behaviour logic on seperate event sheets for each layout. Instead, you write it in one event sheet and include that same event sheet on every layout.

I get the same problem with large (i.e. > 1024px) sprites, also on Windows 8. I assumed this was a Construct limitation so have been chopping them up as Wink describes - didn't occur to me that it might be a driver issue!

It really depends on what resolution of repeat interval you require, and what platform your server is running, but here's some thoughts:

I believe the shortest repeat interval for UNIX Cron tasks and Windows Task Scheduler tasks is every 1 minute. Given that you're talking about actions that last one hour, is this not sufficient resolution?

If you need something more frequent then you could create some sort of daemon or service running on the server that constantly polls the current time in a loop and calls the corresponding actions as necessary. Be careful though - badly written daemons are an easy way to kill a server (and you'll need to own the server on which it's running - shared hosts generally don't let you run ongoing processes). The way to write the daemon would obviously depend on the server OS.

My only other thought is that I'm assuming you're using a database to manage the job queue, in which case, you should check whether the database has inbuilt scheduling functionality. For example, SQL Server has an agent that lets you call a stored procedure on a schedule that can be repeated every second (if you *really* want to run it every second). That procedure can check the queue table, and process jobs accordingly. I don't know, but I guess that other databases come with equivalent scheduling functionality.

Ah great, thanks for the tip (didn't find the post at scirra.com/forum/plugin-developers-please-test-with-the-minifier_topic45502_page1.html before - think I must have searched the wrong subforum :(

I wasn't "mixing" notation, but changing all my object.property dot syntax accessors to bracket object["property"] seems to have done the trick. A marginal cost to the readability of the code, but at least it now works - thanks!