The big news with Startup Freak is that I am now working with an amazing artist to help with the game art. I found Rob Hayes on Indie Gamer Forums and his professionalism and quality of work have been superb. You can see some of his work over on his portfolio site:
It’s still a little early to show any screenshots, but the whole thing is really helping with motivation on this project.
As expected, a lot of my focus on the coding side in the past week or two has been around supporting the art. Here are some issues I have been working on:
Pixel Perfect Art
For better or worse, I decided to make the game pixel perfect, meaning a pixel in a texture is represented by exactly one pixel on the screen in the game. I’m not using pixel art in the game so perhaps this is not as necessary, however my experiments showed that I still got the best, cleanest, crispest results when I go for pixel perfectness.
I won’t go into the specifics of how this is implemented in Unity, as there are plenty of articles and videos dealing with that, like this one. In short you need to:
- Disable any texture settings that may affect the raw texture pixels, such as any compression, mip-mapping, bilinear/trilinear filtering, etc.
- Use an orthographic camera
- Set the camera orthographic size based on the current screen resolution (see article above)
One downside of this method is that based on your resolution/aspect ratio you’ll see more or less of the level. This means you can’t be 100% sure what your game will look like in every resolution. I have based most of my calculations on office tile sizes. For all resolutions up to a 1536p (height) I use 64×64 tiles. For any resolution above this the level starts to get too small, so I switch over to 128×128 tiles. I might also consider smaller tiles (32×32) for lower resolutions.
Loading The Right Texture
The original arts are generally created at the highest required resolution for the game, and then scaled down as needed. For example as I mentioned above, for high resolutions we would load 128×128 tiles (original art), and a 64×64 version at lower resolutions. That means we need to load a completely different set of textures at lower resolution. Note that Unity will automatically scale the larger texture, and may look OK with bilinear filtering on, however it will never look as good as if we load a dedicated, scaled-down texture created with dedicated software.
I really want to be able to do this at runtime when the player changes the resolution, and not have to restart the game. This poses quite a few challenges and I have not yet solved all of these, but a couple of online resources have come in handy.
This video describes how you might swap out all the textures in the current scene based on the resolutions, using
I implemented an extended version of this whereby I look at all textures of all materials in the current scene (not just sprites), including shaders that have multiple textures. I also handle situations whereby the textures are not all in the same folder. There is a big shortcoming in Unity (as far I’m concerned) where you can’t access metadata about shaders and textures at runtime, such as name of texture properties or texture paths. However since this data can be accessed in editor code, I simply capture and save them in a JSON file which can be used in-game. These parts of the Unity API were helpful for this:
- AssetDatabase: Lets you iterate through all assets like shaders and textures and get their paths and details.
- ShaderUtil: Allows you to inspect a shader and get information like the texture property names.
- PostProcessSceneAttribute: I use this as a trigger in the Unity editor to automatically run the script for storing asset paths and details. It beats having a menu item which I may or may not remember to run explicitly.