I haven’t made a post in a long time. Don’t worry, I’m not dead. I’m just really focused on development for “Drew and the Floating Labyrinth,” my hand-drawn 3D puzzle platformer, the first true hand-drawn 3D game of its kind. So a lack of posts this month is a good thing.
I actually spent most of this month still working on “Drew” ‘s animation. I was hoping I was mostly done in May, but part of the game is that you slowly regain Drew’s color as you progress through the levels. I’m talking adding color to each PNG file one at a time, now giving me over 8,000 unique PNG textures (please stop laughing). It’s a shame it took so long, especially since I still haven’t animated a planned idle animation for her, and I still haven’t animated a second “guide” character planned. But I have done more than enough to at least focus on the levels, which I should really focus on this week, just to see if it’s still possible for me to finish this for an August release (I still think it’s possible, but I’m really cutting it close).
Drew at the beginning and end of “Drew and the Floating Labyrinth”
For now, I’ll take a brief moment to talk about how the sprites, saved in Unity 3D as many HD textures, are used, and how I might improve this for later games.
I already mentioned in a older post what a Twitter person suggested, which is to not use full-size textures for small parts like faces to improve RAM. My character is separated in multiple parts, you see, for greater variety and flexibility in animation, at expense of multiplying RAM. But changing the size looses consistency, ruining ease of use as an artist, and suddenly makes the system only work for a specific character, so that isn’t ideal.
Another thought that came up was making a new material type in Unity to use a second texture to color in a first texture. That’s essentially what I’ve done already, but saving every colored-in texture as it’s own PNG file in Photoshop, part of why it took me so long to color Drew in. It sounds like it would be simple to make: Unity allows you to write your own material types, and I would just be replacing every instance of white color with the corresponding pixel in the second texture. But I didn’t do it here since I didn’t separate body parts too much, each part would have multiple colors in it, further adding complexity. Now thinking about it, I could use color coding to get around this (white replaced with texture 2, red replaced with texture 3, etc.), even then this is better suited for a variety of color options for the same texture (which may come in very handy for other games I’m planning). I have no idea if this would be better for RAM, however, which is the greatest concern.
Another thought is to simply flip the texture around on half of the character, thus reducing RAM by (almost) half. Rather, not flipping the material, but the plane itself that the material is on, and utilizing the same material. At first I had trouble doing this, but realize this is probably because I wasn’t flipping the right shape, which I could do by simply matching it’s scale to that of the shape it is taking the texture from (if this doesn’t make sense, I apologize, I do plan to make video tutorials explaining the whole process in the coming months). Of course, this only works if the character is symmetrical, which Drew is (almost), except for the hair (even that could have been made symmetrical). So I could have used this in this game, but will instead simply reduce textures as necessary to make it playable for you. But I will almost certainly do this in future games when considering character design, to reduce RAM and reduce time I spend drawing.
Also, Indie MEGABOOTH should be telling us soon if this game will be shown at Gamescom or PAX Prime, at my expense, and I should soon be seeking other developments for the game regarding voice acting and music. But I need to finish those levels first. I’ll see you in a few more weeks…
