upgrade to Phaser 3

[DreadKnight]

We should eventually upgrade to Phaser 3, while v4 is being heavily worked on, as v3 will get polished.

[andretchen0]

Can this be closed as of this decision?

[DreadKnight]

Can this be closed as of this decision?

@andretchen0 The 3d for gameplay later on should most likely be handled by Phaser v4 or later imo; we'll rely more and more on engine goodies given time. Three.js stuff from Tres can come in handy for UI stuff.

Since we're still far from 3d gameplay, Phaser v3 is a good step forward as it will allow us to load assets on demand, after gameplay has started, that way we can have way more playable units and eventually animated one using sprite sheets, which would make the game somewhat heady. There are some open issues for those things already, but need Phaser v3; postponed this issue though for next major milestone, targeting v0.6

[andretchen0]

Nothing against Phaser.

I don't mind dropping Vue/Tres/Three.js (or a similar combo) in favor of Phaser, but my vote would be not to blend them.

Phaser's a full game engine. Phaser 4 has 2D and 3D rendering built in. Adding Three.js on top means another API for functionality that Phaser 4 already offers.

---

Since we're still far from 3d gameplay, Phaser v3 is a good step forward as it will allow us to load assets on demand, after gameplay has started, that way we can have way more playable units and eventually animated one using sprite sheets,

I'd love to see sprite animations in AB. From where I sit, what's holding it back is that we don't have the frames for the animations.

I saw there was an issue somewhere about converting the game to a pixel art style. That might not be a bad idea – the style is relatively easy to animate and maybe some artists would contribute animations.

Plus, pixel art generally compresses really well, so loading all the sprites we're likely to have wouldn't be an issue.

[DreadKnight]

Nothing against Phaser.

I don't mind dropping Vue/Tres/Three.js (or a similar combo) in favor of Phaser, but my vote would be not to blend them.

Well, Phaser sucks at scalable UI overall, not to mention it works only within canvas, plus it's good to keep things modular; Vue would do for UI and Tres might come in handy sooner or later for various UI 3d effects perhaps, I have some ideas.
It would be a very huge drawback to make the stuff Phaser only or to go the other way around & drop Phaser altogether.

Phaser's a full game engine. Phaser 4 has 2D and 3D rendering built in. Adding Three.js on top means another API for functionality that Phaser 4 already offers.

Sometimes lots of libs have some sort of overlap in functionality, but they have very different API and overall scopes.

Since we're still far from 3d gameplay, Phaser v3 is a good step forward as it will allow us to load assets on demand, after gameplay has started, that way we can have way more playable units and eventually animated one using sprite sheets,

I'd love to see sprite animations in AB. From where I sit, what's holding it back is that we don't have the frames for the animations.

Yeah, it's quite hard to create nice looking 3d units and have them animated. I've considered going a 2d approach as well with https://rive.app, but it's closed source software, except the library for using the animations within games, apps etc.
Rive is really neat, simple to use compared to Blender and browser based, so things would get done way faster/easier.
Though there would be more animations and variations, they might look way more cartoonish and flat compared to 3d.

I saw there was an issue somewhere about converting the game to a pixel art style. That might not be a bad idea – the style is relatively easy to animate and maybe some artists would contribute animations.

Plus, pixel art generally compresses really well, so loading all the sprites we're likely to have wouldn't be an issue.

Once we'll eliminate some of the main bottlenecks of the project, like lack of online multiplayer and lack of bots, I'll be focusing way more on the artwork aspects, so the project will be pushed regarding animations and even pixel art mode.
The issue wasn't about going full pixel art, but to have an alternative visual mode at some point if project becomes hot.

[andretchen0]

Once we'll eliminate some of the main bottlenecks of the project, like lack of online multiplayer and lack of bots, I'll be focusing way more on the artwork aspects, so the project will be pushed regarding animations and even pixel art mode.
The issue wasn't about going full pixel art, but to have an alternative visual mode at some point if project becomes hot.

My vote would be animations sooner rather than later. Even simple animations and a few effects can really sell a game.

I like the cardboards that the game currently has, but no idea about animating them. They've got a lot of detail.

[DreadKnight]

Once we'll eliminate some of the main bottlenecks of the project, like lack of online multiplayer and lack of bots, I'll be focusing way more on the artwork aspects, so the project will be pushed regarding animations and even pixel art mode.
The issue wasn't about going full pixel art, but to have an alternative visual mode at some point if project becomes hot.

My vote would be animations sooner rather than later. Even simple animations and a few effects can really sell a game.

I like the cardboards that the game currently has, but no idea about animating them. They've got a lot of detail.

Animations are optional for gameplay, MVP stuff should be focus. Will have new specs/issues for multiplayer soon.
Well, regarding animating current units, Rive allows importing textures and moving things around in various ways, but would be best to work with 2d artists to make things chopped and modular, along with alternatives, that would be get made into a sprite sheet and used to recreate the character and then make animations; not sure how easy it would be to add new sprites to the sheet though without breaking any of the existing progress... there's an animation studio that emailed be twice last month about a partnership, will see about setting up a meeting soon and see if we can get something going on.

[andretchen0]

Animations are optional for gameplay, MVP stuff should be focus.

I see where you're coming from. But I'd love some animations. They really sell a game.

not sure how easy it would be to add new sprites to the sheet though without breaking any of the existing progress

It depends on the system probably. If you're doing sprite animation, you end up having to redefine the animation if you want to add an extra frame in the middle, but it's not horribly difficult. But otherwise, adding a new sprite usually just means recompiling the atlas/texture, which is probably automated.

That example that I linked to above has a really great setup for sprite animations. It uses dnlibs for Haxe.

For a given animation, you name your individual images:

hero_shoot_up0.png
hero_shoot_up1.png
hero_shoot_up2.png
hero_shoot_up3.png

Those get packed into an atlas/texture with all the other images. When the animation system pulls them out, it automatically groups same prefixes into animations. So you can tell it to play hero_shoot_up out of the box without any configuration. But then it also allows you to define the frame order with delays and frame ranges in a string:

defineAnimation('hero_shoot_up', '0(10), 1-3, 1-3, 1-3, 0(-1)');

So, iirc, that would hold on frame 0 for 10 ticks, then play frames 1-3 three times, then hold indefinitely on frame 0. Defining things that way is really handy and makes iterations pretty fast.

[DreadKnight]

Animations are optional for gameplay, MVP stuff should be focus.

I see where you're coming from. But I'd love some animations. They really sell a game.

They do, would love animations as well, but everything at the right time I guess. After multiplayer and bots we'll scale and I can poke at blender artists communities and even offer bounties (XatteR ideally) in order to motivate people even more.

not sure how easy it would be to add new sprites to the sheet though without breaking any of the existing progress

It depends on the system probably. If you're doing sprite animation, you end up having to redefine the animation if you want to add an extra frame in the middle, but it's not horribly difficult. But otherwise, adding a new sprite usually just means recompiling the atlas/texture, which is probably automated.

That example that I linked to above has a really great setup for sprite animations. It uses dnlibs for Haxe.

For a given animation, you name your individual images:

hero_shoot_up0.png hero_shoot_up1.png hero_shoot_up2.png hero_shoot_up3.png

Those get packed into an atlas/texture with all the other images. When the animation system pulls them out, it automatically groups same prefixes into animations. So you can tell it to play hero_shoot_up out of the box without any configuration. But then it also allows you to define the frame order with delays and frame ranges in a string:

defineAnimation('hero_shoot_up', '0(10), 1-3, 1-3, 1-3, 0(-1)');

So, iirc, that would hold on frame 0 for 10 ticks, then play frames 1-3 three times, then hold indefinitely on frame 0. Defining things that way is really handy and makes iterations pretty fast.

Yeah, this is the sprite based animation that was initially planned, though with Rive things are different, you get some assets that compose the characters and you have skeleton based and mesh based animations going on, so basically you can make way more stuff with the character once things are nicely set-up, but I don't have too much experience with it, guessing you would have to sort of work in atlas style to begin with, avoiding moving things around overall, or issues.

[andretchen0]

Yeah, this is the sprite based animation that was initially planned, though with Rive things are different, you get some assets that compose the characters and you have skeleton based and mesh based animations going on, so basically you can make way more stuff with the character once things are nicely set-up, but I don't have too much experience with it, guessing you would have to sort of work in atlas style to begin with, avoiding moving things around overall, or issues.

It's interesting. Paid, closed source sounds like it'll shut out a lot of potential contributors, though.

Wesnoth has gotten pretty far with in-game pixel art animations and "cutscene" static drawings.

[DreadKnight]

Yeah, this is the sprite based animation that was initially planned, though with Rive things are different, you get some assets that compose the characters and you have skeleton based and mesh based animations going on, so basically you can make way more stuff with the character once things are nicely set-up, but I don't have too much experience with it, guessing you would have to sort of work in atlas style to begin with, avoiding moving things around overall, or issues.

It's interesting. Paid, closed source sounds like it'll shut out a lot of potential contributors, though.

Well, it's free, but only 3 files, meh. Most artists don't care that much about open source though, sadly.
But yeah, should probably just focus on the original Blender 3d path, even if harder, but it will pay off.

Wesnoth has gotten pretty far with in-game pixel art animations and "cutscene" static drawings.

It sure did; I've seen some cute pixel fan art done for Ancient Beast before, so we'll see how things go.