Of course, I haven’t slacked off at all, I’ve just been busy. As far as game development goes, I’ve just about finished painting the landscape textures for “True King,” and made some discoveries along the way.
My previous two games, “Drew and the Floating Labyrinth” and “Unfinished – An Artist’s Lament,” both specifically focused on character animation as the visual focus. That’s a nice way of saying that I spent no time making the environment: “Drew” had white blocks surrounded by empty coloured skies, and “Unfinished” had empty white void representing paper and a lapse in creativity. If ever I thought myself an artist, I preferred character animation over environments, and purposely avoided spending too much time with those worlds.
But building worlds to explore is one of the great things of game development, and with “True King,” I wanted to make a real world this time. The fictional continent of “Renatus” (name may change later in development) is a medieval fantasy kingdom made of seven towns within its valley, watched over by a castle in the center. As much as possible, I wanted to convey this game as a living painting in 3D, something many games have tried to emulate. Like my previous games, I figured the best way to do this was to literally paint the world into existence with 2D art.
Well, this isn’t any different from what any other game does, as textures are important in portraying detail in 3D environments. Anyway, I started by modelling the continent in Blender3D as a grid of individual cells (10×12), each representing a small portion of landscape. I divided them this way to plan ahead. I know rendering a large world is not cheap on computer hardware, and I haven’t committed yet on a method to efficiently render far locations (this will take more research, but I may consider enabling/disabling planes by cell based on player location). Separation also allows me to use high-quality textures easily, instead of a single texture for a giant land (there is a texture size limit in Unity3D) or many smaller repeated textures that had no place in this world.
The 3D shapes are incredibly simple, and the texturing doubly-so. I limited myself to a handful of colours to paint grassy planes, sandy beaches, muddy dirt and grey stone. In some areas, it is a single flat color, with virtually no detail. I spent a lot of time experimenting with what the land would look like, and decided this style for a few reasons: to save me valuable time painting it, and to better mimic impressionistic colour rather than well-rendered detail.
Despite my intentions, painting over 100 environment textures still took me longer than I hoped, and I am fully aware that the world looks like it was painted by a five-year old. I may decide to add extra detail further in development. I also have a lot more to do, namely adding in trees and basic foliage, houses for towns, a better castle, and more 2D effects to mimic grass and other things in the environment. And the actual gameplay hasn’t gotten very far yet. But at least my character can now walk around the world, a large world that takes at least a full five minutes to walk from one corner to the other. That’s a satisfying feeling that helps assure me that I am making progress.
And I’ve learned a few things while doing this part of the art assets. For one, I made the 3D planes for the environment by free-hand, not realizing that when scaled to full-screen in the game world, any tiny differences in positions of vertices are very noticeable when connecting planes side by side. I should have moved these vertices based on exact positions from the start, or make a single large world plane and cut it up after. This poor judgement forces me to spend a few more hours going back and fixing these individual planes one at a time.
I also have an issue with shadows flickering on certain models. There seems to be no direct answer of what this is or how to solve it, but it sounds like this is from the gap in between normal values from the 3D model. To get around this, I found I can play with the “bias” value in the inspector of the directional light creating shadows in my world, and the fact that I scale my 3D models up to over 1,000x it’s size also causes this effect, and scaling down my world instead of scaling up also prevents this issue. These are not perfect fixes, but it is definitely something I need to play with before deciding the game looks ready.
More importantly, I discovered Unity3D introduced something called “Crunched” texture compression since version 5.3. Despite low detail, my landscapes take up most of the screen one at a time, and really need to be rendered at the highest-size possible (8192×8192 currently as Unity’s max option, or at least 4096×4096). At the highest size, a single plane takes about 40 MB in file size at Unity’s default compression technique. Multiply that by all the plane textures, and the land alone can be taking over 4 GB of RAM during gameplay, enough of a reason to have modular loading based on player position. But “Crunched” is a new compression, and if your build device supports it (iOS can’t use this, for example), you get huge compression savings. Because my textures are fairly simple, it goes from 40 MB to about 2 MB per texture, roughly 95% savings in hard drive space! And the only big issue is that it can take several minutes per texture to compress these in the editor, an acceptable sacrifice.
I haven’t tested enough yet to say this actually saves on RAM (documentation suggests this may only improve hard-drive space, and early tests suggests RAM is not helped at all by this compression), but it’s still an improvement in Unity3D that has huge importance in my style of work. If this does improve RAM, it could allow a ton of 2D character animation playable on almost any modern computer.
An extra tip: even though my textures are simple, the compression was terrible on some of them, inexplicably changing the colour completely for a handful of my planes. I got around this by forcing compression under “Advanced” to “RGBA Crunched DXT5” instead of “RGB Crunched DXT1.” This is meant for transparency textures and doubles the file size (for me, from 1MB to 2MB), but I found it was also must more reliable for compression quality. This too is also not always perfect, it would be nice to understand why this compression causes such noticeable issues at unusual times.
I’ll probably spend the next month or two finishing the world properly, then start with interact-able NPC’s and turn-based strategy gameplay. It doesn’t seem that far away, but considering this is basically the whole game and that I still haven’t gotten to it yet, I still fear for development time…