Large Isometric world and a few general questions.

Hi all,

I came across Wade looking for an engine for an isometric hobby project. My background is mostly in backend programming with a little bit of Javascript knowledge. From what I gather from the documentation Wade fits my requirements nicely, but it'd be great if someone with some experience could confirm the basic concept is possible. (Or any changes I should make to keep things running smoothly.)

What I want to do:

1) Have a large isometric map. At least 8k by 8k tiles, but possibly 2-8 times larger.

Would Wade be able to handle an isometric map of this size? The responses here appear to be very promising but I'm not sure about the significantly larger scale. There would be very few unique tile textures (less than 100) with each tile being around 32 or 64 pixels.

I'd very much like to not have to implement paging manually. Even better, if tiles outside of the screen are not being drawn is there a function I can hook into for loading data when certain tiles enter the visible area?

For loading this whole thing I'm hoping to use an image. (Each specific color corresponding to a tile type.) Is this reasonable?

2) Smooth movement (not tile based) of some entities with other entities moving tile based.

Does the engine support this out of the box? The examples appear to go either or.

3) Multiplayer

I understand the engine doesn't have any built in support for this. I'm planning to use Firebase to handle this aspect, loading non-map elements from here dynamically. This would include vegetation, but also creatures and other players. Is there anything in the engine that would make this problematic?












All 2 Comments

Hi Varen

Interesting questions. Let's start with the ones that are easy to answer:

2) yes you can mix and match

3) there should be no problems there, we do something similar for our own games. Our game server sends a mesage to the client who then calls wade.iso.createObject, wade.iso.setTile or any appropriate wade function.

Now about your first question, that's a bit more complicated :)

First of all, in terms of memory, I don't think that 8k x 8x is a problem if you have mostly the same type of tiles.

The scene file generated by WADE may be quite big, but if you don't fill all the map with all the details to start with, it will be very easy to compress. Meaning that despite its size, it will not use much bandwidth if your server enables gzip compression.

You may use your image approach if you like, and I think that the logic for handling that wouldn't be too difficult. It will make the file smaller, but remember it's usually the g-zipped size that counts, so I'm not sure it would be worth the effort.

Either way I wouldn't worry about memory. However in terms of performance there are some things to consider.

WADE uses a quadtree system (optional but it's active unless you disable it) to keep track of the objects in the game world. This means it can very quickly know what objects are currently in a given area, without having to iterate over all the objects in the world. 

It uses this quadtree system to determine what needs to be drawn onto the screen for each frame of the game. So in that respect, having a 100x100 map or a 8k x 8k map will make little difference, assuming that you are only looking at a small portion of the map it will take approximately the same time to draw.

However WADE currently does not use this system to decide what objects need to update their status. For example if they are moving WADE needs to caclulate their new positions, taking in to account collisions, etc. If they have active animations WADE will keep track of which frame is supposed to be playing. If they have onUpdate functions, WADE will execute them. And so on.

Right now this logic is applied to all the objects in the world. We do have a plan for WADE 3.8 to change that and give you more options rather than just updating all the objects in the world. You'll be able to decide if you want to restrict updates to objects in an a specific area, or an area around the camera. But we are currently on version 3.6, so that's a few months away.

With the current system, you'd have to handle that logic yourself. Updating a single animation may take a fraction of a millisecond, but if you have thousands of them it quickly adds up. Custom onUpdate funcitons (depending on how you write them) can be slow - if a single one takes a millisecond to run, you don't want to have more than a dozen active at anyone time.

To answer your more specific question:

> Even better, if tiles outside of the screen are not being drawn is there a function I can hook into for loading data when certain tiles enter the visible area?

Yes you can do that, but I wouldn't recommend it :)

Each tile is associated with a Sprite, which is ultimately the entity that gets drawn onto the screen

var sprite = wade.iso.getTileSprite(x, z);

You could use a custom draw function of the sprite that is triggered when the sprite is drawn, like this:

sprite.originalDrawFunction = sprite.getDrawFunction();
    // add code to execute when the sprite is drawn

    // then call the original draw function

While this may work, it breaks the separation between drawing and simulating your objects, and that is rarely a good idea. But if you understand the implications you can go ahead with this approach.

Alternatively you could create a main loop (which is executed once for each simulation step, as opposed to each drawing step) to monitor which tiles are on the screen:

    var halfWidth = wade.getScreenWidth() / 2;
    var halfHeight = wade.getScreenHeight() / 2;
    var visibleArea = {minX: -halfWidth, minY: -halfHeight, maxX: halfWidth, maxY: halfHeight};

    // Do this to get all the objects in the visible area
    var visibleObjects = wade.getSpritesInScreenArea(visibleArea);

    // Do this to get all the tiles in the visible area (only objects on the terrain layer)
    // We first need to transform the screen coordinates into the terrain's world coordinate system
    var terrainLayer = wade.iso.getTerrainLayerId();
    var terrainArea = wade.screenBoxToWorld(terrainLayer, visibleArea);
    var visibleTileSprites = wade.getSpritesInArea(terrainArea, terrainLayer);
},'check visible objects');



Hi Gio,

Thanks for the answers, that should help a lot.

I'll definitely stay away from draw and I don't think tracking entities with the getSpritesInScreenArea is going to suffice. Creating my own entity management code shouldn't be too complicated though, not worrying about the terrain there saves a lot of work.



Post a reply
Add Attachment
Submit Reply
Login to Reply