Qiso isometric tile engine now available

[richard11]

Our isometric tilemap engine, Qiso, was released to the Corona marketplace this morning. I really, really hope some of you find it useful.

https://marketplace.coronalabs.com/corona-plugins/qiso-isometric-tilemap-engine

Full documentation including quick-start guide, sample codes, videos, and sample tilemap+sprites available on the Qiso website:

https://qiso.qweb.co.uk/

The engine is a work in progress. Currently it’ll import maps created in the Tiled map engine, and implements all of the functions you need for adding and moving characters around (A* path-finding is built in) or manipulating tile layers on the fly. In the coming weeks we’ll be adding a dynamic lighting system, positional audio system, a menu system for multi-action tile clicks, and a layer opacity system for when characters disappear behind roof/wall type layers. In a nutshell Qiso will grow alongside the games we produce using it ourselves. Such additions will of course be implemented with backwards compatibility in mind.

The engine is built entirely in Lua with absolutely no dependencies on platform specific libraries. It’s very fast, and incredibly lightweight (about 28kb at the moment) and our goal is to keep it that way.

Please do consider our engine for your next game and if you think it’s worth telling others about, get sharing. Qiso marks QWeb’s entry into gaming and your support is very much appreciated.

Let me know if you’ve any questions or feedback at all.

For anybody who does give this engine a shot - I’d absolutely LOVE to see what you use it for, so please do get in touch when the time comes. We may even feature your game on the Qiso website if you’re happy for us to!

[agramonte]

Very cool.

[sporkfin]

Thanks @richard11, I just bought it but won’t have time to play around with it until next month.  It looks cool and useful.  I’ve never build an isometric world so this is a good excuse to get me going!

[richard11]

Thanks!

We’ll be updating over the coming weeks with some improvements and the aforementioned features, so by the time you get started there may well be more to play with =).

It goes without saying but do drop me a line if you need any help or have any feedback at all.

[richard11]

Just pushed some performance improvements live. Check out this video of Qiso handling a 1000x1000 grid with 50 NPC wizards!

https://www.youtube.com/watch?v=53l6T8FXYjQ

I’m trying not to impose any restrictions into the engine itself, leaving it up to developers to just be sensible when supporting lower end devices. We’ll update the documentation with various pointers asap but in a nutshell:

• the bigger a world is, the more data the engine needs to keep track of so although Qiso is capable of grids like the above, keep in mind that each additional tile increases the amount of memory used up by the game so probably best to try to keep maps smaller if you want to support more devices. Personally I quite like games where walking to a specific area ‘teleports’ you to a new map entirely.

• Qiso only renders the visible area of a map, but if you allow players to zoom out the number of tiles within the visible area increases, so again some devices might start to struggle when too many sprites are on screen at once. In which case I’d recommend restricting how far a player can zoom out. Reducing to 30fps might also help. The above 1000x1000 test is at 60fps though!

• A* path-finding algorithms are expensive because of how path scoring works, so telling a character to traverse thousands of tiles could be disastrous. Better off checking a characters current location and limiting movement to a sensible radius.

[oquesada]

Hello, Do you have any update on performance improvements? I’m planning on creating an RTS game using isometric maps and your engine looks great, but I’d like to know about their limitations.

[richard11]

As far as our testing has shown, performance only drops when trying to render an insane number of sprites at the same time.

Basically, sprites only exist if on screen. The data for sprites that are off screen still exists, but not the sprite ifself. So holding huge maps is totally possible so long as the individual device has adequate memory to hold that much data, but you might want to restrict the zoom level to something sensible to avoid trying to actually draw thousands of sprites at once.

Additionally, A* path finding works by churning through all of the tile data to figure out tile scores in order to find the best path between two tiles, so you might find that figuring out a reeeeaaaally long path takes a little time on slower processors, but to date we’ve not had such issues in our own tests. Again, just be sensible with zoom levels and you should be fine.

[agramonte]

Very cool.

[sporkfin]

Thanks @richard11, I just bought it but won’t have time to play around with it until next month.  It looks cool and useful.  I’ve never build an isometric world so this is a good excuse to get me going!

[richard11]

Thanks!

We’ll be updating over the coming weeks with some improvements and the aforementioned features, so by the time you get started there may well be more to play with =).

It goes without saying but do drop me a line if you need any help or have any feedback at all.

[richard11]

Just pushed some performance improvements live. Check out this video of Qiso handling a 1000x1000 grid with 50 NPC wizards!

https://www.youtube.com/watch?v=53l6T8FXYjQ

I’m trying not to impose any restrictions into the engine itself, leaving it up to developers to just be sensible when supporting lower end devices. We’ll update the documentation with various pointers asap but in a nutshell:

• the bigger a world is, the more data the engine needs to keep track of so although Qiso is capable of grids like the above, keep in mind that each additional tile increases the amount of memory used up by the game so probably best to try to keep maps smaller if you want to support more devices. Personally I quite like games where walking to a specific area ‘teleports’ you to a new map entirely.

• Qiso only renders the visible area of a map, but if you allow players to zoom out the number of tiles within the visible area increases, so again some devices might start to struggle when too many sprites are on screen at once. In which case I’d recommend restricting how far a player can zoom out. Reducing to 30fps might also help. The above 1000x1000 test is at 60fps though!

• A* path-finding algorithms are expensive because of how path scoring works, so telling a character to traverse thousands of tiles could be disastrous. Better off checking a characters current location and limiting movement to a sensible radius.

[oquesada]

Hello, Do you have any update on performance improvements? I’m planning on creating an RTS game using isometric maps and your engine looks great, but I’d like to know about their limitations.

[richard11]

As far as our testing has shown, performance only drops when trying to render an insane number of sprites at the same time.

Basically, sprites only exist if on screen. The data for sprites that are off screen still exists, but not the sprite ifself. So holding huge maps is totally possible so long as the individual device has adequate memory to hold that much data, but you might want to restrict the zoom level to something sensible to avoid trying to actually draw thousands of sprites at once.

Additionally, A* path finding works by churning through all of the tile data to figure out tile scores in order to find the best path between two tiles, so you might find that figuring out a reeeeaaaally long path takes a little time on slower processors, but to date we’ve not had such issues in our own tests. Again, just be sensible with zoom levels and you should be fine.