All very good ideas, we'll do our best to implement these features for the 1.1 release. Please keep suggesting if you have any more ideas for improvements that we could make.

-startWandering - the targetObject parameter should be optional, in case you want to wander aimlessly.

This is already possible. It's just the documentation that needs updating to say that targetObject is optional, but you can omit it and it should work.

Can you elaborate on this point or describe an example?

Gio,

>This is already possible. It's just the documentation that needs updating to say that targetObject is optional, but you can omit it and it should work.

When I call startWandering with the target parameter blank or null, I get "Uncaught ReferenceError: detination is not defined" what is that error referring to if not the targetObject ?

>Can you elaborate on this point or describe an example?

Lets say you have two characters wolf and sheep. The wolf approaches the sheep and you want the sheep to run away. Now you know what direction the wolf is coming from because you know the grid coordinates of everything. You want to figure out where the sheep should runaway to. If the wolf is far away, then the sheep will only run a short distance,say 2 grids. If the wolf is close, they you want the sheep to run a longer distance say 6 grids. But which way can the sheep run ? If you had a call like getValidMovmentDirections(sheep,2) which returned an array that represented valid movement direcitons, (invalid movement directions result in collisions or off the map), [n,s,e,w,ne,nw,se,sw] like [0,0,0,1,0,1,0,1] then you would know that the sheep can run away  [w,nw,sw]  two grids. Now since you know where the wolf is coming from say w, then you could set destination of the sheep to be either nw or sw two grids and the sheep has escaped for now.

It's basically pathfinding without an actual target.

Hope that wasn't too rambling.

cheers,

Shri

Another nice thing is if we could set a scale factor for each tile, transition and detail. You know, just a number in the tileData that you can use when you call setTile, in the same way you do this for objects.

Gio,

I have a couple of questions / requests for the iso engine.

1.Is it possible to add iso world rotation to the plugin ? In the Labirinto game, I provide the functionality because with the walls, there is not another easy way to see around them.

Unfortunately, that means keeping track of all the objects and replacing them after a rotation. You already provide other array manipulation calls in the engine and that's all the rotation is.

However, II don't know how complicating this would make other stuff like path finding, etc.

2. Can you add an  isoGetOverlappingObjects() call added. Right now, for collision checking, I use getOverlappingObjects on the scene object. Then I check to see if the overlapping object is in the same grid. If both conditions are true, then there is a collision. Otherwise, there is no collision. Alternatively, can you suggest a better way to check for isometric cell collisions ?

3. The iso updates you made for the 1.1 release, and your explanation for why some stuff will be postponed was appreciated. The only thing that is lacking / missed is the documentation.

For example the new getGridCoords() call is not in the latest documentation ? (or at least I could not find it).

Still waiting on

-For the iso 'states' would be nice. I get "Idle_iso_" and "Walk_iso_", but are there others, and are there ways to define your own, what events trigger the switching, etc.

-A list of the supported events which objects and iso objects can receive. These can be found, but one list which has a line about what they do and when they are triggered would be nice.

I realize documenting stuff may not be your hightest priority, but as the engine grows, it becomes more critical.

Anyway, just my two cents again (which puts me up to 4 cents now).

Still think the engine is a lot of fun. I was surprised at how fast it could do the object removal and redraws on rotation.

cheers,

Shri

1. Yes, that's something we could add, but we'd need to think about it a bit. First of all, it wouldn't work for everything - it works for "square" objects, i.e. objects that look the same regardless of where you're looking from - but there may be objects that will appear incorrectly following a "rotation". Also we don't want to confuse people - what happens when you set the direction of your character to "North" after a rotation has occurred? Does he look like he's facing "east", or does he still appear to face "north"?

So in short - if we can find a way to do this that doesn't confuse people we'll do it :)

2. I would have thought that checking if the objects are in the same cell would be enough - i.e. if your character is in cell (x, z), then you could just do wade.iso.getObjectsInCell(x, z) and if it returns an array whose length is > 1, then your character must be colliding with something. This should work provided that cells are small enough, i.e. a cell is just big enough to contain a character. Would this not work for what you're trying to do?

3. You are absolutely right about the documentation, on both points - we'll try to add this info as soon as possible. Thanks for reminding me!

Gio,

Thanks for the reply.

1. Rotation - Yea I figured there would be issues with it. I just rotate the iso world and the characters facing doesn't change.

You could implement roation with the caveat that - works only with square objects, does not modify facing ... But wahtever you guys decide is cool with me.

2 Collision - Doing it with just wade.iso.getObjectsInCell never seemed to perform quite right ?

i.e. lots of missed collisions and collisions happening after characters moved apart.

Especially at faster (shorter) time intervals Are the implementations for getObjectsInCell and getOverlappingObjects similar ?

Overall, I get the impression that the iso engine was built with strategy type games in mind (like Zirma) and not faster action type games.

Where the pathfinding, movement, tile, details, transitions are brilliant, other parts like iso collision checking seem rougher ? Implementing an isometric shooter or some of the physics stuff into an isometric game  would be a good test.

Then again, maybe it is just me :) .

Anyway, what I do for collision checking is:

In the collision loop

- isoCharacter.owner.getOverlappingObjects()

- for the overlapping objects, check if the overlapping objects have some flag - say isGhost==true  in the labirinto game

- do an additional check using what you suggested wade.iso.getObjectsInCell

- if both conditions are true, then the character has collided with a ghost - so do the ghost collision stuff.

3.  Documentation - I would prefer to see higher level descriptions first rather than the specifics of the calls. Your sample games were a great start and the snippets helped a lot too.

Then,  if you have a list of all the events a scene object can receive with a one sentence description of when they fire you could write a bit of code yourself to figure out the nitty gritty details.

Ok I'll go back to programming now.

cheers,

Shri

You are correct in saying that the isometric plug-in by itself is designed for strategy games and role-playing games mostly.

What you are doing to detect collisions may work depending on the shape and size of your sprites, but getOverlappingObjects() only considers the bounding box of the sprites, and doesn't know about the isometric perspective.

However there's nothing stopping you from using the isometric plug-in together with the physics plug-in, for example, in case you want very accurate collisions. In this case, you have to be careful about the way you set your collision meshes, to take into account the isometric perspective. Something like a circle or ellipse around the feet of your characters should work. Most likely, you want to set wade.physics.gravity to {x:0, y:0} too.

I know this is a big request, but... wouldn't it be great if you could save your map, after generating it in code?