Happy Monday!
I'm still knee-deep in tutorialization and performance, but I thought today it would be fun to talk about how MoteMancer fell into using both 2D and 3D pipelines simultaneously, and the opportunities it ended up providing. There are definitely both upsides and downsides, and I'm not sure I'd do it the same way again, but I also definitely remember how I got here, so let's go on a journey.
Obviously 2D
I knew from the beginning that MoteMancer would present as a 2D game. One of my favorite parts of the automation genre is the local logistics puzzle itself, and realizing that every space has an opportunity cost. MoteMancer definitely focuses on that gameplay more than anything.
3D factory games have great spectacle, but can get hard to read very quickly, especially once you layer several stacked lines over each other. Certainly that has its own advantages too, but being on a Hex Grid is already complicated enough to wrap your head around, so 2D it is.
This means theoretically everything can be a single image, or sprite sheet, and originally I thought that was going to be a huge performance boon. The jury's actually still out on that, because while not rendering 3D objects certainly saves a lot up front, Many of Unity's engine optimizations have been targeted at 3D specifically (looking at you DOTS), and I was not aware of that from the outset.
Still though, 2D provided a great framework to start from and aligned with my design goals so that's where it started.
The Player Character
The first major hurdle came from having a player character that needed a variety of animations. Typically you can solve this with sprite sheet sequences, but given how many angles and animations I had, the sheer amount of texture space needed to give the character everything needed was not going to work. Not for lack of trying mind you, I did build the full 2d sprite pipeline before realizing it just wasn't going to be the path.
I even did this cool lighting trick you can do where you film the character with pure Red Green and Blue lights, so you can change lighting after the fact. Let's say your staff light is Red, but you want to cast a shadow spell, you can take the Red information and change that color to whatever you want (say purple) after the fact and fake real time lighting changes even on a 2d sprite image.
Anyway, suffice to say I did not pursue that path, and opted for a full real-time 3D character. The main issue now was - the game was already rendering and sorting in 2D, so I needed a way to marry the two into a cohesive result. Thankfully unity provides the ability to make a separate render camera from your main camera to achieve just that.
The actual character is sitting on a tilted plane far in the distance with a camera pointed at them as if from game view. Plus a special camera that captures the cast shadow only. Did you ever notice while playing that the character's shadow will rotate around them as the day passes? That effect is achieved with yet another camera capturing the cast shadow as a fake light rotates around throughout the day cycle.
Perf and Opportunities
It turns out rendering a character with a unique camera or two is not cheap, it's actually one of the more expensive persistent taxes MoteMancer pays for. And it has to be done because a 3D character won't sort properly with the other 2D objects in the scene without the camera trick.
The nice thing is, there are a bunch of optimizations that can be made, and one of the big ones is making sure the character uses a single mesh for everything. This would normally be an issue for materials, but we can leverage something pretty awesome here that will also set ourselves up for future success.
In the image above, we can map a swatch to a given portion of the character, and even better, expose the colors themselves so they can be edited in real time. Yes this means the door is open for character customization! Exactly where this lands in the game flow is a little up in the air, it'll likely either be an early research unlock, or a pre-game selection probably.
Terrain Chunks
The character alone is not enough to push the hybrid rendering setup over the edge though, the real lever was terrain rendering. MoteMancer originally used tilemaps for everything, and while the game could have found success there probably, having an infinitely large world of tiles is also much more expensive than low-resolution meshes, at least for the constraints MoteMancer has.
Each vertex here samples the noise texture to create coast lines and RGB masks that drive the terrain texture. I wrote pretty extensively about this in a past devlog, but suffice to say, this approach helped give MoteMancer its soft painterly terrain look while massively improving performance along the way.
Wrapping Up
No plan survives contact with reality, and knowing what I know now, I could see a world where MoteMancer leaned much more heavily into 3D assets as a whole just for the sake of the DOTS and ECS Unity pipeline, but that also would have come with plenty of other tradeoffs. Despite having a clear vision for the game, much of MoteMancer's journey has been a sculptural process of letting the game reveal its own idiosyncrasies and leaning into them rather than fighting them.
On the other side of the dev space, the revamped tutorial is moving along steadily, and I'm more and more convinced that the Alchemists Journal feature is worth making. Achievements are also coming soon on the horizon. The future is bright :)
Back to the lab 🌿
~CyanAvatar