So, at this point, we’re all familiar with the way this game looks.

We’ve got our little guy, a camera fixed behind him, he can move up, down, left, and right. He can jump and stuff too. Neat!
The Octopath Problem
One of the things I’ve been thinking about a lot lately is what I wanted my areas to look like. I have plans and ideas for this world, and I needed to do some thinking about how it would come together. While I was thinking about this, I started thinking a lot about Octopath Traveler. That lead to watching a lot of documentary about Octopath Traveler.
One thing they pointed out in their own developer documentation was that, because of their fixed camera, they spent a lot of time building terraced designs.



You can immediately see what they mean – and the more I looked, the more obvious it became. Every single area in the entire game is designed in almost the exact same way:
The further you move toward the camera, the lower in elevation the landscape gets. The further you move away from the camera, the higher in elevation the landscape gets. Take a look at all three screenshots above. Note that everything in the background is higher than everything in the foreground. For areas that have more space closer to the camera, you can see stairs and ramps going downward to lower elevations.
The reasons for this are obvious in hindsight: the fixed camera means there would be too many things blocking the camera. By creating this terraced design, where things further “north” in a map are higher elevation than things further “south” in a map, you can place foliage, buildings, decorations, etc, without worrying about any of them blocking the camera.
Octopath traveler does have a system of culling out models that block the camera, but it’s mainly used for things like trees. I think they (perhaps correctly) thought it would be too jarring to have buildings suddenly appearing and disappearing. It also carried some technical flaws with it, because the insides of buildings actually exist and are rendered – but at half scale. If a building disappeared from view, they’d also have to make the interior disappear too, otherwise the “trick” of interiors rendering at half-scale would be exposed. Suddenly that becomes a lot more expensive to do on a frame-by-frame basis.
Don’t Tell Me What I Can’t Do
I, because I am a stubborn ass, did not like the idea that I would be constrained in this way. It’s true that I could probably come up with some way of getting around this limitation, but the truth is that I didn’t even want to think about it.
I had actually been thinking about eliminating the fixed camera for some time now, independently of all this. The realization that a fixed camera angle constrained my level design was only the coffin nail.
The truth is that one of the real drivers behind this decision was that I wanted gameplay to look more interesting or varied. I didn’t want all players to be forced to look at an area from the same perspective. It’s actually a huge complaint of mine when it comes to ARPGs like Diablo, or Path of Exile. The isometric camera angle makes me feel constrained. Camera angles are a weird form of expression. Choosing the lens through which you view the game seems important.
The more I thought about that, the more I realized I was probably going to need to make a change.
So I did.
Ta da!
Challenges
This presented some challenges. The sprites looked wrong. Previously they were billboarded – meaning they always turned to face the camera. This prevented the character sprites from feeling like flat pieces of paper in a full 3D world. That aesthetic might work for Paper Mario, where they’re supposed to literally be paper, but it wouldn’t work for this.
So you’ll notice in that video that characters actually update the position they’re facing as the camera spins.


This actually ended up being quite simple in the end. The hardest part was updating the code for all of the characters in the game to actually rotate when they moved. Previously, there was no reason to have any rotation because the sprites were billboarded, so rotation wouldn’t have done anything anyway. But now, the sprites need a rotation despite being billboarded.
I mentioned in yesterday’s post that I was experimenting with a new movement system for the enemies. This planned change was actually the catalyst for that little experiment.
Anyway, so now the sprite compares its rotation with the rotation of the camera and then does some math to figure out which direction it should play its animation in. This system should be robust enough that it will continue to work when we have running animations, jumping animations, talking animations, emotes, etc.
But Also…
I had to do it for other players too!
WARNING, I DO THAT MMO THING WHERE I JUMP IN CIRCLES HERE, SO IF YOU GET DIZZY AND BARF, DON’T SAY I DIDN’T WARN YOU.
Ultimately the new movement system is imperfect. It’s a little too jittery and desperately needs to be smoothed out. However, as you can see, the rotation of the other player characters relative to your own is now respected, and the facing direction updates in real time as the players rotate around.
It’s weird, because I both at once feel like this is both an incredibly meaningful and incredibly meaningless change. It feels like both an incredibly small and incredibly large fundamental change. For me, it’s made a lot of difference as to how the game feels.
Okay, I’ve Put It Off Long Enough
Combat comes next.