refactor: use offsetCoordsToPx, simplify sprite coordinates

[andretchen0]

This will probably require a fair amount of testing as it touches most of what gets put on screen in Phaser.

This commit streamlines grid space -> pixel space.

Otherwise:

• undoes the uneven scale applied to hexGrid, meant to show perspective. Instead scales the grid images.
• allows Creature sprites to be flipped left/right without needing to reposition them.
• deprecates Hex.displayPos. It's not needed. A grid position can be converted to the pixel position using Const.offsetCoordsToPx(). No need to have a handle on a Hex.
• adds the following to Creature:

+       get topPx() {
+               return this.footPx - this.sprite.texture.height;
+       }
+
+       get footPx() {
+               return this.grp.y + this.sprite.y;
+       }
+
+       get centerPx() {
+               return this.grp.x;
+       }
+
+       get leftPx() {
+               return this.grp.x - this.sprite.texture.width * 0.5;
+       }
+
+       get rightPx() {
+               return this.grp.x + this.sprite.texture.width * 0.5;
+       }

This makes it simpler to put things on screen next to creatures at various positions. Used for projectiles in this commit.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
ancientbeast	✅ Ready (Inspect)	Visit Preview	Jul 20, 2023 2:22pm

[ghost]

👇 Click on the image for a new way to code review

Legend

[andretchen0]

Opened an issue: #2442

[DreadKnight]

@andretchen0 Not too keen at all about the idea of squishing hexagon sprites like that, it makes them kinda useless for reuse in a future 3d renderer of the game. Thinking far ahead in some ways but it's where the game is heading given time.
It also makes creating and editing hexagons very hard, UI ones especially; I need to think carefully about this stuff tbh.

Also, you rather corrupted those cardboards: they are now lower quality and their baked in shadows got removed.
Though we could always add the shadows procedurally, but someone else might be tempted again to bake them in...

[DreadKnight]

Dark Priests cardboards are now jaggy and lacking shadows.

[DreadKnight]

Abolished cardboard not showing up at new location after using Bonfire Spring, but snaps into new places after moving.

[DreadKnight]

Grid coordinate system (shift key or hovering round marker) are placed badly, not centered.

[DreadKnight]

Whole hexagon grid is moved around a bit. Not sure atm what to make of it, if better or worse overall.

[DreadKnight]

Uncle Fungus cardboard is placed badly, too high in X value, unlike in beta.AncientBeast.com

[andretchen0]

Thanks for testing. Will address these or otherwise respond.

[andretchen0]

@andretchen0 Not too keen at all about the idea of squishing hexagon sprites like that, it makes them kinda useless for reuse in a future 3d renderer of the game.

It's your call.

Fwiw, the images are tracked by Git, so nothing is lost, as long as someone remembers they're there.

From my perspective, I'd be concerned about keeping my hands on copies of the original hi-dpi, hi-color-depth artwork for the monsters and environments. But the UI stuff, particularly the hex stuff, I wouldn't get overly attached to. If you switch to 3d, you'll probably either need different assets – the current hex images are small and will look blurry if there's a zoom in on the action – and there's a pretty good chance you'd just define hex geometry and then use a shader for the glowing, etc. effects.

But that said, I can definitely pull out the old hexes and squish them in-game.

Thinking far ahead in some ways but it's where the game is heading given time. It also makes creating and editing hexagons very hard, UI ones especially; I need to think carefully about this stuff tbh.

Sure thing. Your call.

Also, you rather corrupted those cardboards: they are now lower quality and their baked in shadows got removed.

Ah, my bad. Thanks for pointing that out. I have my programmer eyes on. ;)

Though we could always add the shadows procedurally, but someone else might be tempted again to bake them in...

With the current designs, you can't easily add them procedurally, at least not like they look with the baked in shadows. (I should say I don't know how to do this in Phaser, but with a shader ...) With a shader, in a nutshell, you'd make a copy of the monster image. Where the original is 100% opaque, make the new image replacing opaque pixels with transparent black, and skew that image. But if you skew it, it's going to look wonky, unless the feet line up on the same Y.

So, that would probably be fine for a sprite like "Dark Priest". It wouldn't work for "Uncle Fungus".

You could do oval-shaped old school video game shadows.

[andretchen0]

Grid coordinate system (shift key or hovering round marker) are placed badly, not centered.

I think I understand what you're looking for here. I've squished the type and nudged the grid position to line up with beta.ancientbeast.com. See the commit: graphics: nudge grid.

[andretchen0]

Abolished cardboard not showing up at new location after using Bonfire Spring, but snaps into new places after moving.

Fixed in commit fix: teleport animation

[DreadKnight]

@andretchen0 Not too keen at all about the idea of squishing hexagon sprites like that, it makes them kinda useless for reuse in a future 3d renderer of the game.

It's your call.

Fwiw, the images are tracked by Git, so nothing is lost, as long as someone remembers they're there.

From my perspective, I'd be concerned about keeping my hands on copies of the original hi-dpi, hi-color-depth artwork for the monsters and environments. But the UI stuff, particularly the hex stuff, I wouldn't get overly attached to. If you switch to 3d, you'll probably either need different assets – the current hex images are small and will look blurry if there's a zoom in on the action – and there's a pretty good chance you'd just define hex geometry and then use a shader for the glowing, etc. effects.

Yeah, I always keep copies and such. There's even a Mega repo linked ion the website footer with artwork and sources.
Was thinking about that regarding 3d, anyway, even the 2d game will eventually go for a 4k version and have higher res versions, so going the 3d route for units and prerendering sprites will be more future proof, as higher res spritesheets can be re-rendered. I recall initially wanted to just use svg sources for those UI hexagons, but Phaser not able to deal with those. Just did some research, good news is that Phaser 3 will be able to handle svg files apparently, so I'll see about opening new issues to make use for that for hexagons and some other UI parts.

But that said, I can definitely pull out the old hexes and squish them in-game.

Yeah, would be better to do things like that, just like textures in 3d games basically.
Some sprites or traps are meant to be raised from the ground, like Impaler's Poisonous vines, which you squished flat.
Will make new comment around for it; might need new issue to have trap class or so to handle "vertical traps" like that.

Thinking far ahead in some ways but it's where the game is heading given time. It also makes creating and editing hexagons very hard, UI ones especially; I need to think carefully about this stuff tbh.

Sure thing. Your call.

At some point in the future, people will be able to play AB in cafeterias or in the park with only glasses, looking around, seeing a huge screen in front of them. So yeah, if able to simplify things, reuse, do properly and make it look good, proceed!

Also, you rather corrupted those cardboards: they are now lower quality and their baked in shadows got removed.

Ah, my bad. Thanks for pointing that out. I have my programmer eyes on. ;)

I was thinking that as well :)) All good, that's why it's a team effort, different expertise and points of view.

Though we could always add the shadows procedurally, but someone else might be tempted again to bake them in...

With the current designs, you can't easily add them procedurally, at least not like they look with the baked in shadows. (I should say I don't know how to do this in Phaser, but with a shader ...) With a shader, in a nutshell, you'd make a copy of the monster image. Where the original is 100% opaque, make the new image replacing opaque pixels with transparent black, and skew that image. But if you skew it, it's going to look wonky, unless the feet line up on the same Y.

Yeah, aware the process regarding the shadow graphics. Had to do all of those manually, then skew as I've seen fit.

So, that would probably be fine for a sprite like "Dark Priest". It wouldn't work for "Uncle Fungus".

That's true, Uncle Fungus was problematic indeed, just like it is atm, hence I had to make new comment before.

You could do oval-shaped old school video game shadows.

That might fly well with some of the other future graphical modes, like pixel art.

[andretchen0]

Ok. I'm rolling back the changes to the pngs. Will push again soon.

I'll keep pushing to this branch so you can comment.

But there's no sense clogging up history with a bunch of changes that get rolled back in the same refactor merge. Let me know if/when this is ready to merge and I'll open a fresh PR.

[andretchen0]

I think this is where we are:

• Unsquish hexes
• Revert cardboards
• Fix Abolished teleport animation
• Nudge grid overlay back to original position
• Uncle Fungus too high?

About the Uncle Fungus, you said

Uncle Fungus cardboard is placed badly, too high in X value, unlike in beta.AncientBeast.com

Do you mean vertically, by chance?

For background:

There are sprite offsets defined in units.json, like so:

		"display": {
			"width": 108,
			"height": 200,
			"offset-x": 0,
			"offset-y": -164
		},

For me, this is a real stumbling block. The other information in units.json is stuff like, "What is this creature type's max health? Can it be materialized?" Business rule stuff.

In contrast display is display details about one particular sprite for the creature in one particular version of the game IO.

Once there are animations, or we switch to 3d, that information is useless. For me, it just doesn't belong here.

But what's more, at this point, it doesn't really need to be included in this version of the game. It's pretty common in games of this nature that there's simply a convention, e.g., the center of the image is going to be where the anchor is placed – artists can deal accordingly. If a creature's design isn't symmetrical, it's not a problem. Just pad the image on one side until the creature's midpoint is on the texture's midpoint. (Fwiw, this is what I was doing with the Priest sprite when the shadows disappeared – padding the left to move the priest's center to the right. I used GIMP, which was probably a mistake. Below, I've used Krita and things seem ok to me.)

For the y, maybe we say that a texture's y-anchor is its "ground plane" and we say that's e.g., 40 pixels above its bottom row of pixels. That gives artists a little space to play with for feet. Uncle Fungus currently has 36 px of "feet":

A priest has tiny feet, just 6 px:

The idea would be to give all creature textures, including the ones above, the same amount of feet space. Then we can treat them all the same on the y-axis in code.

That puts a bit more responsibility on the artists, but also lets them control where things end up, without needing to figure out some JSON file.

Thoughts about this?

---

If this is the last issue to be tackled for this PR and you find the other changes acceptable then I'd like to:

• close this PR
• submit a fresh PR with the existing changes to be merged
• start a new PR with display data removed from units.json and creature sprites padded according to the rules above

[DreadKnight]

I think this is where we are:

• Unsquish hexes
• Revert cardboards
• Fix Abolished teleport animation
• Nudge grid overlay back to original position
• Uncle Fungus too high?

I didn't do too much testing, wanted to see if we go with this PR first and if so, to have things listed fixed first.

About the Uncle Fungus, you said

Uncle Fungus cardboard is placed badly, too high in X value, unlike in beta.AncientBeast.com

Do you mean vertically, by chance?

Yeah, my bad, meant vertically; that would be y axis in Phaser.

For background:

There are sprite offsets defined in units.json, like so:

		"display": {
			"width": 108,
			"height": 200,
			"offset-x": 0,
			"offset-y": -164
		},

For me, this is a real stumbling block. The other information in units.json is stuff like, "What is this creature type's max health? Can it be materialized?" Business rule stuff.

In contrast display is display details about one particular sprite for the creature in one particular version of the game IO.

Once there are animations, or we switch to 3d, that information is useless. For me, it just doesn't belong here.

Yeah, sprite data shouldn't be in that file, but it was hard to deal with too many files before, so we want for it. Now it's time to push things around once again.

But what's more, at this point, it doesn't really need to be included in this version of the game. It's pretty common in games of this nature that there's simply a convention, e.g., the center of the image is going to be where the anchor is placed – artists can deal accordingly. If a creature's design isn't symmetrical, it's not a problem. Just pad the image on one side until the creature's midpoint is on the texture's midpoint. (Fwiw, this is what I was doing with the Priest sprite when the shadows disappeared – padding the left to move the priest's center to the right. I used GIMP, which was probably a mistake. Below, I've used Krita and things seem ok to me.)

I figured that you were trying to tweak the Dark Priest padding. It can be done just fine in Gimp, you need to enlarge the canvas.

For the y, maybe we say that a texture's y-anchor is its "ground plane" and we say that's e.g., 40 pixels above its bottom row of pixels. That gives artists a little space to play with for feet. Uncle Fungus currently has 36 px of "feet":

A priest has tiny feet, just 6 px:

That's the general idea, line between feet = ground.

The idea would be to give all creature textures, including the ones above, the same amount of feet space. Then we can treat them all the same on the y-axis in code.

That puts a bit more responsibility on the artists, but also lets them control where things end up, without needing to figure out some JSON file.

Thoughts about this?

This actually complicates things a lot, as it would sabotage the art if not following some template overall, hence why there was some anchor variable around used in the first place.
And while it might still seem like good progress eliminating the X pos variable of that anchor point by making the cardboard canvas symmetric, in the long run this is horrible as well, because it will make the sprite sheets unoptimized and way bigger in some cases, not to mention way harder to render properly. Might be best to just let anchor points do their thing instead of doing extra work of fiddling with canvas sizes and centering things visually instead of in practice.

If this is the last issue to be tackled for this PR and you find the other changes acceptable then I'd like to:

• close this PR
• submit a fresh PR with the existing changes to be merged
• start a new PR with display data removed from units.json and creature sprites padded according to the rules above

Please no more bothering with clean history, just focus on real history and progress, showing the work process that actually went on (well, some of it, as there's always more "behind closed doors"). I'll be making curated press releases.