new module organization

[freeman-lab]

Hey everybody, wanted to share the new organization of hexaworld into separate core and renderer modules. The motivation is to support a wider variety of renderers (e.g. 2d/3d, multi-modality) and programmatic access (e.g. APIs, AI agents), and make it easier to separately test, optimize, and develop the components.

The following two repos reflect an attempt to achieve this goal, learning from the good and bad parts of our initial prototypes, and from all of our discussions!

• hexaworld-core
• hexaworld-renderer-3d

If you npm link hexaworld-core you should be able to npm start inside the renderer, and use the arrow keys to fly around the world.

overview

I deliberately started with a subset of the full game we had before, so that the code footprint is small enough to easily reason about the API (the README's are also fairly detailed). But I also made sure this version has all the pieces we'll need, in some form or other.

The basic layout is that core builds the primary game objects and runs the gameplay loop, and renderer uses its static object set and dynamic events to render the game. core only requires a controller and a schema, and the renderer requires a webgl context and an instance of core. This 3d renderer is itself composed of a more general scene module that I bet could be split off nicely into it's own thing.

In terms of performance, @andrewosh and I confirmed that this renders on desktop very well (time per frame is ~3ms in Chrome), for worlds up to 50+ tiles, and so far seems good on mobile too (will need to add proper mobile controls to test more thoroughly). Most important optimziations were merging geometries (during scene building) to minimize the number of draws, and for geometries that couldn't easily be combined (e.g. dynamic things like the "bits"), we used a draw distance to avoid rendering everything on every frame.

next steps

Main TODOs are adding back a few graphical and gameplay elements, and the UI.

Curious to get feedback from all on the overall API, and I have a few specific questions for people. Will also now create some issues for repo-specific stuff...

@mathisonian very curious to get your input on the scene module, and whether it seems worth splitting off, and with what API. It would be at a higher-level than much of stack.gl, but as a result risks becoming too opinionated and/or frameworky.

@sethvincent does the gameloop handling seem reasonable? In particular, I eventually decided to try breaking the convention of sticking the renderer target on the gameloop, which while super convenient in most cases, made it hard here to cleanly separate core from renderer.

@sofroniewn does core seem close enough to the kind of thing we'd want for experiments? To get a rough sense, just run npm start inside core and you can basically play the game from the terminal. Also, we should pair on how to clean up the points/transform stuff.

also cc @hughsk who might have fun thoughts on all this!