LDJAM - FedUp - a flying delivery game

For LDJam #53 this weekend, I made a drone-flying game with Haxe and PixiJS. I wish I could have spent more time on it (church, Hockey, sleep - you know :smile: )

I have an idea for a fun additional game mechanic (with the mouse) that didn’t make it in. But I hope to add more levels and content in the coming weeks.

Anyway, give it a try and lmk what you think! Cheers!

title_640x512
jcward.com/fedup/index.html

P.S. speed the text along with key/button clicks

1 Like

I’m toying with porting this from Pixi.js to Heaps. I’ve made a little progress as you can see (browser on the right, heaps on the left)

test

It’s fascinating, heaps is a different beast, and it doesn’t seem to care much about ease of portability.

First, there are many drawable types (Sprite, Bitmap, TileGroup, SpriteBatch.) I get it, best performance in each scenario. But it creates a learning curve… but also a weird refactor. For example, in my pixi game, I have all the assets in one atlas. I’m at ~2-3 draw calls per frame. And my code is structured such that tldr; it’s all Sprites all the way up and down, all sourced from the same texture atlas.

The pixi Sprite can be a container, and have a texture, and has a pivot point. That’s extremely flexible, and I’m sure it requires extra calculations, but if it can do all that in a batched rendering, that’s pretty awesome / flexible.

With heaps 2D, I have to make some decisions with no clear good option:

  • The docs say that Bitmap is not good for performance / is not batched. So each one is a draw call. It doesn’t have pivot, which will be an irritation during porting. Pivot is a nice flexibility feature - anything that can rotate/scale is super handy if it has a pivot, otherwise it takes an extra layer of container to achieve the same. I get it, Tile has a pivot, but Tile is not a container.

  • So what about SpriteBatch. But now I have to decide how to refactor –

    • if there was one global SpriteBatch in my level, well, now I can’t have parent/child display list relationship between Drone and its fans (all BatchElements).
    • If I make each entity a SpriteBatch (e.g. the drone, and its fans BatchElements), that’s fine… But now each entity in my game is a SpriteBatch and causes a draw call? That’s still not great, is it?

Is it possible to create a new 2D Sprite class for heaps that:

  1. is a container (transform matrix)
  2. has a .tile (can be graphics + container)
  3. has a .pivot
  4. the whole tree batches as long as the tile is from a single texture

Or, am I structuring my code wrong. Should my logic / controllers not extend the framework classes, and rather use them? Perhaps it would have the benefit of making my code for framework agnostic? I roll my own parent/child/transform class, and I calculate all the transforms down to the textures, and I just use one big SpriteBatch renderer? At least that would be portable… :thinking:

See, the only reason to use heaps is breaking free of the browser… but in his heaps FAQ, one of the main contributors says it supports mobile “in theory”, and “use your own compiler toolchain” when compiling for windows.

I dunno, I see the amazing things people create in heaps, but I’ve never found it approachable, no matter now may times I try. (A while back, I was trying to use h3d and get blender models into it, never really got it working.) :man_shrugging:

Hello! I don’t see why you couldn’t just use the Bitmap class for your drone and the connected two fan objects. You could set the pivot point of the underlying Tiles to the center so that the fans behave the way they do in your demo.

As far as performance, it is true that reducing draw calls is more performant. But I think that SpriteBatch is more appropriate for drawing particles, etc. The following little demo is easily able to stay above 60fps:

    override function init() {
        var tile = h2d.Tile.fromColor(0xff00ff, 50, 20);

        for (i in 0...1000) {

            var bitmap = new h2d.Bitmap(tile);
            bitmap.tile = bitmap.tile.center();

            s2d.add(bitmap, 0);
            bitmap.setPosition(hxd.Math.random(s2d.width), hxd.Math.random(s2d.height));
        }
    }

    override function update(_dt:Float) {

        trace(hxd.Timer.fps());

        for (object in s2d.getLayer(0)) {

            object.rotate(1 * _dt);
        }
    }

Learning the various classes derived from h2d.Drawable is very important to developing 2d projects in Heaps!