[Iso Plugin] World Size limitations and Scrolling

[koobazaur]

Hey Folks,

I've started using the excellent Rotates Isometric plugin but quickly ran into an issue when trying to create a bigger world. The default examples (like this one) run great with a small grid but when I try to go above 50x50, framerate starts to drop off FAST. Since I want to create a good-sized scrolling world, I was wondering if there is any good solution to this?

Here's the options I see:

* Batch the ground tiles into one big image. BUT this still limits how many detail or dynamic sprites (trees, rocks, NPCs, etc.) I can have on top, and I can't batch those since it would mess up the sorting

* Create only enough sprites to fill the screen and implement some sort of scrolling (i.e. as player moves right tiles on the left that go off-screen get moved onto right and changed to the new image that should be there)

 

As far as I can tell tell, solution 2) is the better method, but it would still be limited to static sprites. Plus, the implementation would be a pain (unless there is a ready-made scrolling/pooling implementation somewhere?)

 

Thanks for any feedback and thoughts!

[7Dolls]

Isometric projection on a large scale is two frameworks at the moment. Isogenic Engine (http://isogenicengine.com/) (which is advanced in functionality and difficulty) and elavarion ( http://www.elvarion.com).

Both of these frameworks are open source, though both would require advanced java script coding ability to implement.

The phaser framerwork that you mentioned is great for small maps (50x50), but issues arise when you go bigger.

So far, I have not found an isometric phaser framework or a isometric framework which is easy for a novice to use.

If you are a programmer, then there is a great opportunity here!

 

 

[Milton]

I'm playing around with isometrics a bit, and wonder why you need a framework?
I only have a projection function (3 lines of code) and a depthsort class (3 functions, about 30 lines of code).

My maps can be any size, I use a viewport, and only render visible tiles of course.

No idea how it compares to 'Rotates'. Have a look at what I'm doing: Spindizzy (Canvas) or Spindizzy (WebGL)

This is a work in progress (debug version), so performance is not optimal (it has Wireframe and Aabb drawing options (press w/a, b to turn off bitmaps). Most browsers do 60fps though.
I'm working on 'perfecting' the depth sort, still a bit (lot) dodgy at the moment

It's not Phaser (Haxe/OpenFL), but it also uses Pixi to render, so performance would be similar. I draw all static tiles first (with drawTiles, only 1 gpu call). No depthsorting there, because you can just draw from top left, to right bottom. Then I draw the dynamic tile(s), that is depthsorted with its surrounding tiles, so only about 6 tiles or so. I mask this tile so the surrounding tiles are invisible.

[koobazaur]

Thanks for the responses guys, I was starting to think I wasn't going to get any  Thanks for the links, I will take a look.
Mainly I am using Phaser+Rotors because it was the most popular choice when googling and I really don't want to re-invent the wheel (I already made a iso tile engine on my first game in C++). I am a coder by trade moving more into design/writing, so coding isn't scary to me. 

And AFAIK Rotor's basically does what Milton says, just applies projection to the coords, so even if I did that myself I'd probably run into the same problems down the line. Might as well save myself half the work.

@Milton - mind sharing how you handle depth sorting for non-square objects/tiles? I made my own isometric tile engine in C++ on my first game using projection and ran into sorting/overlap problems when I used non uniform objects (i.e. a long table). Plus just the hassle of re-creating it in JS, don't really want to do it again

[Milton]

Hmm, just divide your object into tiles.

The usual (basic) solution to depth sort is : 

if ((b.minX < a.maxX) && (b.minY < a.maxY) && (b.minZ < a.maxZ)) {
    a.isoSpritesBehind[behindIndex++] = b;                  
}

So you can specify the (box) dimensions of your tile. That gets you about 90% of the way. The rest is tuning.

That's why I'm wondering why anyone would use a 'framework'. Just create a 2d game, and then use about 3 lines to project it, and another 30 or so for the topological sort.

[lewster32]

Quote

Create only enough sprites to fill the screen and implement some sort of scrolling (i.e. as player moves right tiles on the left that go off-screen get moved onto right and changed to the new image that should be there)

This is the way to go in nearly all cases. Essentially this is what's known as 'viewport culling', and combined with sprite pooling, it should perform very well. You create a batch of enough sprites to fill the screen, and as your world scrolls, sprites that leave the screen are recycled to be used as sprites coming onto the screen. The implementation is unfortunately down to you, as the isometric plug-in only provides a base level of functionality. For what it's worth, what I'm describing is essentially what the TileMap functionality in Phaser offers for standard orthographic tile-based graphics, but as yet no-one has implemented an equivalent for the isometric plug-in.

[koobazaur]

@Milton - I remember doing something like that and running into issues when the base of the entities wasn't a perfect square, hmmm...

 

@lewster32 - thanks for the official response Yea, I was hoping someone has implemented it by now and I can save myself the hassle. Ah well. I actually just ended up exporting the Tiled map as one big image to use as background, and going to use a cheap dirty pooling trick for drawing decor sprites that need sorting like grass or rocks. hopefully runs fast enough. I'm mainly just experimenting with gameplay ideas so don't want to spend too much implementing fancy/proper solutions

[koobazaur]

Hmm lewster32, is there a way to sort sprites of two separate groups together? Doesn't seem so? 

I set up a decor group for stuff like grass and wanted to take advantage of the pooling ability of groups to reuse sprites. But then they either appear under/over my gameplay group. So I had to put them into the gameplay group and not use my pooling since my other entities don't :/

Also, when I did that and did not set up body on decor (no collision needed), when anything clips into them they start flicker in front/behind. Weird. Any idea why? It got "fixed" by switching from topological sort to simple sort (Which seems good enough for now). 

[lewster32]

Unfortunately there's no way to sort items from separate groups - this is a limitation of the scene graph that forms the basis of Phaser's display hierarchy. I've discussed this limitation on a Github issue. I think clever use of masking and/or dynamically swapping objects between groups is the way things are usually done, but as I said, the implementation is left to the user; I really didn't want the plug-in to become too complex or specific. I do think there are features still to add though, so I greatly welcome and appreciate any contributions

[koobazaur]

Thanks for the clarification, that's what I thought. My biggest beef with Phaser is that the groups are used both for rendering order and physics/collisions so if you don't want the two to be synchronized you're screwed (or have to make workarounds like individual sprite vs sprite collisions instead of group vs. group which probably hampers performance in the long run). 

 

While it's not a bad framework I'm starting to consider looking at other HTML5 options

[lewster32]

I think these are the holdovers from when Phaser first extended the base Pixi.js objects. Essentially Phaser added physics and other stuff on top of a display framework, whereas the ideal solution would've been to start with generic abstract entities (like Unity's base game objects) and then add components to handle physics, sprite rendering and so on. I believe this is how Lazer will handle things, and how recent versions of Phaser have started to break things down internally, so I wouldn't jump ship just yet!

[koobazaur]

That makes sense, but yea, wish they went a different direction. Have you used any other HTML5 engines you can recommend? there are a few options out there. 

For Phaser, I made my own little Entity framework to contain logic of each object in the object's code files rather than everything being in the main game's state Update function. It also automatically handles all physics/collision callbacks to the entities and lets me easily setup various Groups + collisions between them (none/normal/overlap).

Works pretty well, the rendering order is the only kink tho that doesn't have a work around short of not using Phaser groups at all (and having my own implementation of groups, but I'd lose out on many of the internal optimizations).  

[lewster32]

I've not used any other frameworks; I chose Phaser primarily because of its similarity to the AS3 Flash SDK that I was using before. I guess using Pixi.js directly could be an option, though Pixi.js is where the scene graph display hierarchy is implemented. For what it's worth, the groups themselves don't actually offer that much in the way of optimisation - they're more for convenience. The real heavy optimisation stuff like sprite batching and other such things have their own implementations which could probably be made use of fairly easily.