React? R3F?

[andretchen0]

There was a little talk about using a more modern JS framework some time ago. I wonder if there are any feelings for/against using React and possibly React-Three-Fiber (R3F) for some future release?

In particular:

• splitting the project up into separate (data store/game logic) and (interface) seems to good sense for this kind of project and would potentially allow multiple different interfaces to be created – someone proposed a text/CLI type interface at some point, which would be possible
• (data store/logic) and (interface) split would mean that the project could eventually drop React/R3F altogether and create a fresh interface from scratch, so there wouldn't be much lock-in, except for the library used for the data store
• React is well-known and made to ease collaboration on large JS projects, so potentially easier for newcomers to hack on than jQuery/vanilla JS
• R3F is lesser known, but the community seems pretty passionate about promoting projects, which might bring in some new folks

Just looking for feedback

[DreadKnight]

We could use some JS framework for sure, just not sure about React, usually not keen about using the "go-to" ancient project. I'll have another look at react and R3F as well, as I'm somewhat way more inclined on lesser known frameworks. There are some upcoming issues regarding AB reaching a point to include the website stuff within the game itself, so that when you go to the main domain, you'll find the game straight up and you'll have a menu for documentation/artwork and one for the footer stuff (social links and ways to contribute), so a framework being adoption should nicely facilitate that nicely.

[DreadKnight]

Personally I was leaning more towards Vue/Next.js/Nuxt.js from my research over the years. I know about Svelte and Haxe; I always found Haxe to be pretty cool, but if I had more proper choices at the time I might picked Godot (had web exporter long time broken and kind of awkward anyway) or defold.com (got open sourced way after) - game engines with visual editors; while Ancient Beast doesn't need that sort of stuff much atm, I do plan for expansions given time and scale, but there's stuff like Tiled map editor for that sort of stuff that might do the job nicely...
Anyway, I'm a game developer and have way more games in mind, some even with game designs somewhat fleshed out, but figured I should focus on this one, for now at least, in order to get it to a good place.

Heaps.io seems interesting, will look more into it next week, though I wonder about how much it overlaps with Phaser itself though... there are even one or two decent editors on top of Phaser, but they tend to be too commercial. Glad we're doing things more low level, as we can poke at all the code and keep the cruft away, as wysiwyg/level editors tend to be bloated and generate heavy code that can be hard to properly get things into shape at times. We're doing things in a nerdier way, while most indies just go for commercial closed source game engine like Unity3d.

Need to wrap my head around all these to be able to make a semi-decent decision about a JS framework, so any input is always welcomed. React might not be a bad choice, but maybe something is way more suitable for Ancient Beast and the direction it's going.

[andretchen0]

Vue + Tres (for three.js) seems somewhat active – they merged a PR just yesterday. There aren't a lot of examples and the documentation is a bit sparse, but it's probably ok. I'm going to test out Vue + Tres.

Svelte + various Three.js libraries appear to all be pretty inactive. Most recent PR merges I could find were from 6 months ago.

Heaps.io is nice, but it's really low-level and needs the Haxe language. Haxe is a lot like TS, but it's probably going to be alienating for a lot of potential developers.

Godot is nice, but like Haxe, the language is a bit of a barrier for some developers. GScript is like Python, but different, unfortunately.

[DreadKnight]

Vue + Tres (for three.js) seems somewhat active – they merged a PR just yesterday. There aren't a lot of examples and the documentation is a bit sparse, but it's probably ok. I'm going to test out Vue + Tres.

Will look into this Tres thingy, this will be one of the top options; Vue is considered 3rd most popular & I'm not into Angular.
The only main bottleneck I found regarding Vue previously from my research years ago is that it had only 1 official maintainer.

Svelte + various Three.js libraries appear to all be pretty inactive. Most recent PR merges I could find were from 6 months ago.

Svelte is nice but I'm not too fond of the name tbh and I think good branding can make or break a project overall, hence why it's not getting a lot of love probably; Vue/React on the other hand have way cooler names and easier to remember and type.

Heaps.io is nice, but it's really low-level and needs the Haxe language. Haxe is a lot like TS, but it's probably going to be alienating for a lot of potential developers.

Yeah, I recall at the time we weren't using a package manager (npm) nor Node.js, so the project wasn't compiled. Seeing Haxe needing compiling was a big drawback for me at the time. Years later someone turned the project inside out and migrated it to npm/Node.js and made a PR, without providing too much assistance/help/documentation, I almost rejected the thing as I wasn't familiar with the stuff at all, but knew we needed some optimizations, tasks and hence compiling sooner or later, so I started looking into it and finally went with merging the huge PR. I'm glad it made in, even if it confused a lot of contributors.

Godot is nice, but like Haxe, the language is a bit of a barrier for some developers. GScript is like Python, but different, unfortunately.

Indeed, very big drawbacks regarding Godot: the unique scripting language and rather clunky web exports (if even working).
While no longer an option for AB, but might still consider it for future projects, especially since doing 3d and having editors.

[andretchen0]

I'm going to test out Vue + Tres.

Testing out Vue + Tres. It's not bad so far.

Vue's learning curve might be slightly less steep than React's, if starting from zero. But React is hands down more popular, with loads more documentation, examples and users.

Tres is fine, but documentation is really sparse.

In passing, hovering/clicking on hexes works out of the box with Tres – well, with Three actually. That solves a long-standing bug in the current codebase.

[DreadKnight]

I'm going to test out Vue + Tres.

Testing out Vue + Tres. It's not bad so far.

Yey! Good to hear🥳

Vue's learning curve might be slightly less steep than React's, if starting from zero. But React is hands down more popular, with loads more documentation, examples and users.

Sounds good. React might be number one, but from my experience, some of the people that tried to reinvent the wheel after might have had some very good reasons, as they learned from the projects that were already popular but they were bothered with some bottlenecks that were hard to avoid without doing a complete rewrite (and sometimes even pissing off some people and alienating them), so they did just that by starting a new project and bringing other stuff to the table as well. Plus industry standards can be very annoying at times, as I'm focused more on the design aspect and graphics, in this field the default software was pretty much 3d Studio Max, which is still proprietary/closed source to this day, very expensive, not very stable and somewhat badly designed, meanwhile, I was using Blender 3d, it had its own set of issues, but a totally different approach to things as it got open sourced and free, cross-platform and quite stable in comparison, plus scaling into more fields, hence the name, Blender, combining as many aspects as possible, since it was designed this way from the ground up and whenever there were some design limitation, new major versions always managed to address some of those quite successfully at times. I was a somewhat early adopter, forced myself to use it as I embraced open source and Linux; now a lot of the studios and projects tend to use it by default. Nice to see how things changed, as I always considered Blender to be the 8th wonder of the world type of thing.

Tres is fine, but documentation is really sparse.

Ancient Beast is a long term project, so even if something doesn't have that great documentation for now, while not getting fixated on it, by adopting it and promoting it, there are chances for it to get better, provided it's suitable for the project and has a good base. When we migrated to Phaser, it pretty much lacked documentation since it was fresh out of the oven so to say; I didn't rushed the main coder at the time, but he managed without it quite well to my surprise. I think it took several more weeks or even months for documentation to get released after we migrated already, hmm...

In passing, hovering/clicking on hexes works out of the box with Tres – well, with Three actually. That solves a long-standing bug in the current codebase.

Oh, that would be awesome, as I often manage to get newly materialized units snapped to a different place after confirmation.

[andretchen0]

React might be number one, but from my experience, some of the people that tried to reinvent the wheel after might have had some very good reasons, as they learned from the projects that were already popular but they were bothered with some bottlenecks that were hard to avoid without doing a complete rewrite (and sometimes even pissing off some people and alienating them)

I've helped a fair number of new programmers get started with React. React went through a transition from the original class-based components to function-based components – both still exist in the API, but function-based components are favored by the community. Imho, function-based components really trip up newcomers. OTOH, there are lots of official and unofficial how-tos for doing common operations "the right way", so once you realize that you need to look things up, it's usually not a problem to find the missing information.

Vue is less popular and I haven't helped many people use it, but they still got confused by it, even if the API is arguably more straightforward than React's.

Not an argument one way or another. Just passing on what I've seen.

[talking about Tres] Ancient Beast is a long term project, so even if something doesn't have that great documentation for now, while not getting fixated on it, by adopting it and promoting it, there are chances for it to get better

I don't expect that Vue will disappear anytime soon, but Tres is really in the early stages. It's under active development, but the team is small so far. There's no telling if it'll survive. R3F takes up a lot of oxygen in the relatively small market of "I use a reactive library and need reactive 3D components". Tres uses some R3F source off the shelf and wraps it in the Vue API.

I guess if we want an absolutely safe bet, it'd be to use WebGL, or possibly just Three.js (without Vue+Tres/React+R3F). Or maybe something in between WebGL and Three.js, like twgl. That has the downside that many new developers find it really hard to approach though.

I was using Blender 3d

I'm a longtime Blender noob. If you haven't taken it, you might be interested in Bruno Simon's paid course on three.js. It shows how to get Blender content on the web using Three.

It's now got a section on using React + R3F apparently. I took it about a year ago and it helped me finally get my head around Three.js, but it didn't have the R3F section at the time.

[DreadKnight]

React might be number one, but from my experience, some of the people that tried to reinvent the wheel after might have had some very good reasons, as they learned from the projects that were already popular but they were bothered with some bottlenecks that were hard to avoid without doing a complete rewrite (and sometimes even pissing off some people and alienating them)

I've helped a fair number of new programmers get started with React. React went through a transition from the original class-based components to function-based components – both still exist in the API, but function-based components are favored by the community. Imho, function-based components really trip up newcomers. OTOH, there are lots of official and unofficial how-tos for doing common operations "the right way", so once you realize that you need to look things up, it's usually not a problem to find the missing information.

Yeah, figured React might be somewhat "two-faced" like that because of some transition.

Vue is less popular and I haven't helped many people use it, but they still got confused by it, even if the API is arguably more straightforward than React's.

Not an argument one way or another. Just passing on what I've seen.

Like I was saying, Vue had examples before it in order to figure out some important do's and don'ts, which can make things way cleaner overall.

[talking about Tres] Ancient Beast is a long term project, so even if something doesn't have that great documentation for now, while not getting fixated on it, by adopting it and promoting it, there are chances for it to get better

I don't expect that Vue will disappear anytime soon, but Tres is really in the early stages. It's under active development, but the team is small so far. There's no telling if it'll survive. R3F takes up a lot of oxygen in the relatively small market of "I use a reactive library and need reactive 3D components". Tres uses some R3F source off the shelf and wraps it in the Vue API.

Understood. Well, I like the "Tres" branding and website and I also think that Vue could become way more popular given time.

I guess if we want an absolutely safe bet, it'd be to use WebGL, or possibly just Three.js (without Vue+Tres/React+R3F). Or maybe something in between WebGL and Three.js, like twgl. That has the downside that many new developers find it really hard to approach though.

I'm not opposed to just using Three.js, but first I have to wrap my head around the needs of this project (AB) when it comes to stuff that's needed down the road and what actually useful stuff do frameworks like React and Vue actually bring to the table in order to facilitate any needs to fulfill the specs at hand, as well as upcoming ones and the overall vision (bigger picture), so I need to somewhat predict how well will some of the things scale or adapt because trends will change along with technologies.

I was using Blender 3d

I'm a longtime Blender noob. If you haven't taken it, you might be interested in Bruno Simon's paid course on three.js. It shows how to get Blender content on the web using Three.

I've looked at some three.js tutorials before; I'm a crappy coder and probably won't end up implementing that sort of stuff myself anytime soon at least, but the tuts where good to view at very least so that I could get a better idea of how the process works and what's under the hood; I usually do that sort of things with all the domains that are involved in game development so that I can have a more realistic expectation of things by being able to understand technical limitations plus it also helps out knowing the vocabulary, that way I can talk and coordinate with others specialized in those fields.

It's now got a section on using React + R3F apparently. I took it about a year ago and it helped me finally get my head around Three.js, but it didn't have the R3F section at the time.

Good to hear. After we'll manage to have online multiplayer in good shape at some point, development focus will shift towards a planned add-on game mode for AB that will be more "MMO" and season based. It will involve economy, town building (units will have their own dwelling structures) and even sieges. Someone just followed me on ArtStation and he's a Blender user with quite a few works posted, many in the direction of those structures and dwellings that will be needed, so I might poke him soon about this. Timing helps because I was constantly thinking about having the towns 3d or at very least the dwellings and structures themselves instead of just doing them the very old fashioned way with pre-rendered 2d sprites, since this way we can implement some animations way nicer if needed and also offer some eye candy if allowing rotations or some limited camera movement.

[DreadKnight]

@andretchen0 Would R3F also fix our hex grid problem?

What's your take on Angular.io and its three.js support?
It's in between regarding popularity and I could take the logo (hex + "A" letter that can be from "Ancient" as well) as a sign 🐻

[andretchen0]

I think any reactive library — Angular, React, etc. — that lets you get a reference to an underlying JS object would be compatible with Three.js. That probably includes all of the big name libraries.

But afterwards, there are other considerations like documentation, community, etc. I don't know anything about the Angular community. I might be looking in the wrong spot, but I don't find an Angular/Three.js library that looks like it has enough support to base a project on.

That said, a fix for the Ancient Beast hex problem is in Three.js itself — out of the box, arbitrary geometry is clickable/hoverable.

Fwiw, it's surely fixable in the current version of AB. Clicks are handled with Phaser, but I don't know enough about Phaser CE to fix it. Barring that, you could write your own "picking" code in pure JS, but that'd be yet another system to add to the mix.

[DreadKnight]

I think any reactive library — Angular, React, etc. — that lets you get a reference to an underlying JS object would be compatible with Three.js. That probably includes all of the big name libraries.

But afterwards, there are other considerations like documentation, community, etc. I don't know anything about the Angular community. I might be looking in the wrong spot, but I don't find an Angular/Three.js library that looks like it has enough support to base a project on.

Did some research earlier and the GitHub repo looked pretty good, but couldn't find a Three.js project, just articles of compatibility.

That said, a fix for the Ancient Beast hex problem is in Three.js itself — out of the box, arbitrary geometry is clickable/hoverable.

Fwiw, it's surely fixable in the current version of AB. Clicks are handled with Phaser, but I don't know enough about Phaser CE to fix it. Barring that, you could write your own "picking" code in pure JS, but that'd be yet another system to add to the mix.

Phaser CE has decent documentation nowadays. Just did a bit of searching and a Polygon hitArea might do the job I think:
https://photonstorm.github.io/phaser-ce/Phaser.Button.html#hitArea

[andretchen0]

Did some research earlier and the GitHub repo looked pretty good

Yeah, Angular is well-supported and will likely live a long time, but it doesn't have any community efforts behind Three.js. That's a deal-breaker for me anyway, since Vue and React both already work with Three.js declaratively with existing npm modules.

[andretchen0]

Just did a bit of searching and a Polygon hitArea might do the job I think:
https://photonstorm.github.io/phaser-ce/Phaser.Button.html#hitArea

I'll check it out.

I've been busying myself with Vue and Three. The declarative/composable approach can be pretty nice in the right circumstances. For comparison, here's the template code for the clickable/hoverable playfield – no bugs:

    <template v-for="{ hex, point } of store.gridTransforms">
        <Hexagon 
        @pointer-enter="() => store.onPointerEnter(hex)" 
        @pointer-leave="() => store.onPointerLeave(hex)"
        @click="() => onClick(hex)" :position="[point.x, point.y, 0]" />
    </template>

It's admittedly easy to fix a bug if you don't also have to take the surrounding system into account. But it's pretty nice to work with, I think.

[DreadKnight]

Just did a bit of searching and a Polygon hitArea might do the job I think:
https://photonstorm.github.io/phaser-ce/Phaser.Button.html#hitArea

I'll check it out.

Alright #2253 (comment)

I've been busying myself with Vue and Three. The declarative/composable approach can be pretty nice in the right circumstances. For comparison, here's the template code for the clickable/hoverable playfield – no bugs:

    <template v-for="{ hex, point } of store.gridTransforms">
        <Hexagon 
        @pointer-enter="() => store.onPointerEnter(hex)" 
        @pointer-leave="() => store.onPointerLeave(hex)"
        @click="() => onClick(hex)" :position="[point.x, point.y, 0]" />
    </template>

It's admittedly easy to fix a bug if you don't also have to take the surrounding system into account. But it's pretty nice to work with, I think.

Neat, but as I said in the linked comment above, probably just nicer overall to upgrade the rectangles to hexagons in Phaser.

[andretchen0]

Neat, but as I said in the linked comment above, probably just nicer overall to upgrade the rectangles to hexagons in Phaser.

I don't have any expectation one way or another that you'd swap the whole codebase for a refactored one written in Vue/Three.js, but I'm enjoying giving it a shot.

[DreadKnight]

Cool. Even if we go that Vue/Three.js route, I'm still trying to wrap my head around why would the hex input get changed.

Anyway, regarding Angular and Three.js, seems they play along nicely:

https://medium.com/geekculture/hello-cube-your-first-three-js-scene-in-angular-176c44b9c6c0

And found this repo as well, though it's not poked at very often, but it's fresh enough anyway:
https://github.com/angular-threejs/angular-three

[andretchen0]

Anyway, regarding Angular and Three.js, seems they play along nicely:

Yeah, it's not that they aren't compatible. It's that there's not a component library for Angular that's got traction, afaik. That's what R3F and Tres are.

In order to compose/modify a Three.js scene with Angular (or without any framework at all), you have to write imperative JS. That looks a lot like what we're currently doing with Phaser and it's tough to get right – and continue to get right. Here's a bit of code from the article:

this.scene = new Three.Scene();
this.scene.background = new THREE.Color(0x000000);
this.scene.add(this.cube);
// Camera
let aspectRatio = this.getAspectRatio();
this.camera = new THREE.PerspectiveCamera(
  this.fieldOfView,
  aspectRatio,
  this.nearClippingPlane,
  this.farClippingPlane
);
this.camera.position.z = this.cameraZ;

If you have a component library like R3F or Tres and a data store, that looks like this:

<setup>
import {useStore} from '../stores/store';
import {TheCube} from './TheCube';
const store = useStore();
// NOTE: assumes the store has a camera.
</setup>

<template>
  <TresCanvas clear-color="#000000" window-size>
    <TresPerspectiveCamera v-bind="store.camera" />
    <TheCube />
  </TresCanvas>
</template>

That's a pretty neat trick. Want to remove the cube? Just remove <TheCube />. Want 2 cubes? Just another <TheCube /> to the template.

But what's really neat here is that the camera comes from the store. Because the store camera is reactive and bound to the <TresPerspectiveCamera /> any changes made to the camera in the store will be reflected in the view automatically.

But there's more. The store holds the business rules for how its data is mutated. So, if there's a button push in the view, the view just calls a method on the store. The store decides how to update its own data and that update is automatically propagated through the view.

So, we cut down on this kind of code mixing, where data, business rules, and presentation are bound together:

    this.btnSkipTurn = new Button(
      {
        $button: $j('#skip.button'),
        hasShortcut: true,
        click: () => {
          if (!this.dashopen) {
            if (game.turnThrottle) {
              return;
            }

            game.gamelog.add({
              action: 'skip',
            });

            // Prevents upgrade animation from carrying on into opponent's turn and disabling their button
            clearTimeout(this.animationUpgradeTimeOutID);

            game.skipTurn();
            this.lastViewedCreature = '';
            this.queryUnit = '';
          }
        },
      },
      game,
    );

... and we make it harder for future contributors to write code like that in the first place.

[DreadKnight]

Understood. Seen the tag <> type of coding before and I thought that's pretty neat. So that's the data store stuff.

Let's say we go with Vue/Tres combo. At some point we'll want 3d stuff as well, like version of the game and some sort of city building / sieging. That would mean porting to latest major Phaser version first. Hex grid and other interactions would be handled by Vue/Tres and it should synergize well enough with Phaser for the other game stuff?

[andretchen0]

Seen the tag <> type of coding before and I thought that's pretty neat. So that's the data store stuff.

It's the component stuff – that's how you put things on screen.

The store stuff is written in regular JS. Pinia is a popular store for Vue. It's got a demo if you want to take a look.

That would mean porting to latest major Phaser version first.

If you wanted, I think you could use Vue (or some other framework) to load Phaser when necessary or Three when necessary.

But to me anyway, Phaser doesn't offer a lot of tools for this particular game that aren't available in a lower level rendering library like Pixi (which Phaser uses under the hood) or Three. Currently in Ancient Beast, Phaser is mostly just used for rendering, but e.g., to my knowledge, we're not using any of Phaser's physics systems.

And for rendering libraries, if you need some 3D, you might as well use a 3D library for everything.

[DreadKnight]

Seen the tag <> type of coding before and I thought that's pretty neat. So that's the data store stuff.

It's the component stuff – that's how you put things on screen.

Yeah, components ftw! I was keen on google-web-components/Polymer back in the day, as I really liked the concept/evolution.

The store stuff is written in regular JS. Pinia is a popular store for Vue. It's got a demo if you want to take a look.

Watched the explanation video, pretty cool. This should be useful with state management issue for match saves without replay I guess, as well as the game's expansions that will even have economy. Some people will want some single player with adventure map at some point.

That would mean porting to latest major Phaser version first.

If you wanted, I think you could use Vue (or some other framework) to load Phaser when necessary or Three when necessary.

But to me anyway, Phaser doesn't offer a lot of tools for this particular game that aren't available in a lower level rendering library like Pixi (which Phaser uses under the hood) or Three. Currently in Ancient Beast, Phaser is mostly just used for rendering, but e.g., to my knowledge, we're not using any of Phaser's physics systems.

Eventually will want to make use of physics system, particles, as well as other cool stuff Phaser has to offer (#1005).
We focused more on the MVP side plus kept things lightweight for now, focusing on the gameplay aspect; whistles and bells to be added later (eye candy).

And for rendering libraries, if you need some 3D, you might as well use a 3D library for everything.

It's good that new versions of Phaser focus on that stuff as well. Anyway, I'm not too keen on letting it handle UI stuff too, so we'll have Vue/Tres for that sort of thing, while fully ditching jQuery. Probably better picking Vue/Tres over Angular, because the hexagonal logo with "A" in it might rather create some confusion then be a sign for me, as it can rather seem like some initial crappy mock-up logo for AB if I think about it. So yeah, we can proceed with Vue/Tres/Pinia 👍🏻 #1587 out of Brainstorm

[DreadKnight]

Also, marketing wise, using a lesser popular project can increase the odds of people finding this project (to check out as example initially or willing to contribute to get some experience), as GitHub has a "Used by" feature -> https://github.com/vuejs/core/network/dependents - there's a good chance that AB might be top 10 dependents right away.

[DreadKnight]

From the latest Phaser news letter:

Francisco completed our brand new Phaser + Vue 3 Template. He's also the one responsible for publishing the 11 bundler templates we've released over the past few weeks. The Vue template was more involved than a typical bundler one, as it required creating examples of how to communicate in both directions between Phaser and Vue, so you can create your game UI using Vue components if you so wish. This template is soon to be followed with a TypeScript variant and then, of course, a React-based one.