Engines and Limitations

So, I’m currently making a game. I’ve been using Unity as my engine of choice due to its documentation. The Unity Docs are very well-written and totally comprehensive. Unity also has a rather large corpus of official instructive videos. I rarely find myself needing to look beyond the official Unity resources when treading into unknown territory.

For my current game, I’ve spent a long time designing the holistic product. I’ve always believed in integrated design when it comes to making things. I have the entire game down in my head, from level design to aesthetic to music to even the title. It’s all there, and it all fits together. Now I just need to make it work.

However, I’ve run into a bit of a situation. The way Unity is made, I cannot make my aesthetic work.

Essentially, I’m trying to make a real-time paint splatter effect similar to the one used in Ink. (You can find a Codepen prototype here. Credits to Zack Bell’s original post.) This essentially requires drawing a level-sized texture in realtime, masking the texture with the visible portions of the level, and updating the texture every time a splatter is made. In theory, this should be very fast. Drawing pixels is already what happens on the bottom layer of the graphics pipeline. By skipping the rendering step and going straight to the draw step, this should be very fast. Right?

Unfortunately, Unity’s architecture prevents this. Most of the operations exposed to the Unity developer, including graphics drawing, occur on the CPU. In order to update a texture, you have to call Texture2D.Apply(). The Docs page indicates that this function doesn’t actually ‘apply’ pixel changes in the literal sense, rather, it uploads the CPU version of the texture to the GPU for rendering.

While not an expensive operation, this means that even the simple task of rendering a texture every frame becomes throttled by bandwidth, and it becomes nearly impossible to actually accomplish the aesthetic that I am aiming for on a large scale.

Considering that this project is currently in its infantile stages, this should not be a problem. However, I have December deadline to meet.

Moving forward, I have a couple of solutions.

I could rework my design of my current game to change the aesthetic. This would force me to give up a little bit of my creative vision, but would allow me to stay comfortable within an engine that I am familiar with.

I could shelf this current game entirely. In order to meet the deadline, I could make a different game in my current engine, and save my current idea for a later time. However, I run the risk of making a game that’s not very well thought-out.

I could stick with my current idea, and rewrite the entire thing in a different engine. Since we’re still in early stages, this wouldn’t take that long. However, I would also have to learn that engine quickly enough to make the deadline.

All of these solutions are pretty terrible, if you ask me. I’m going to have to mull this over and discuss this with other people before moving forward. In the meantime, there are a few discussion points.

First of all, how valuable is holistic design? One one hand, there is a lot of value to cohesion and polish in a final product, but on the other hand, this can cause development to lag when reaching for an MVP. What’s more important – upholding artistic integrity, or finishing?

Second of all, should you learn one engine really well, or know a lot of engines pretty well? In theory, I could still fix my problem in Unity with direct low-level OpenGL calls, but this would require a much more in-depth engine knowledge, which might be easier or harder than learning Game Maker. On the other hand, since Unity and Game Maker are very different engines, perhaps I should just learn them both, anyway. This applies to many other things – Jekyll vs Pico, React vs Meteor, etc. (Okay, those things aren’t directly comparable, but whatever.)

I’m going to have to work at this a little bit. Expect a return to this topic in the future.