DB2 - User Interface Design
Throughout most of the development of Detective Butler 2 so far, I've been concerned with function over form. That is, I started working on the game by prototyping its gameplay. Early in development, the visuals don't really matter so much, because eventually they'll be replaced or improved. As a game reaches its final development stages, graphical improvements become more common.
So, with all that said -- it's about time we start looking into graphical improvements, right? That includes ways of cleaning up the user interface. In today's blog post I'll be explaining what I've done during this past month to improve our graphics, user interface, and even bring down our filesize to less than a third of what it used to be!
As you probably know by now, Detective Butler 2 utilizes 3D models for its backgrounds. But rather than rendering them into a flat plane, we keep them in 3D and simply change the camera angle. One obvious downside is that if you want realistic-looking models, you'll need lots of polygons per model, which hurts game performance. It's always a trade-off between performance and quality. But there's a neat trick I learned about recently called texture mapping.
Now, at this point in time I'm still not much of an expert on texture mapping, but the idea works like this: rather than increasing the polygon count of your models to simulate light and shadows, your textures are processed by certain programs that can calculate where the lights and shadows should go (I have been using CrazyBump). Thus, the information about light, shadow, smoothness, sharpness, etc. can be stored inside the texture material rather than generated by the game at runtime. This process is called mapping the texture, and there are several different types of maps: bump maps, specular maps, occlusion maps, normal maps, and so on. Basically, if a game has awesome graphics, it probably uses texture mapping to some degree.
You can see the difference. Compare to a screenshot of DB2 before and after texture mapping:
The New User Interface
You have probably seen the textbox menu in several screenshots by now, but I haven't previously explained what each button actually does. Prior to upgrading the graphical user interface, each feature was slightly disconnected from each other, both functionally and visually. But I've created a way to link them all together: through the Deduction Device!
The Deduction Device (tentative name, but I like the alliteration) is a smartphone-like device that allows Detective Butler to more easily solve mysteries. What exactly does it do? Everything a mystery fanatic would want!
The Map feature shows a satellite view of the surrounding area, pointing out any nearby locations and people of interest.
The Evidence feature shows a list of all evidence that has been collected so far, including its name, description, and 3D picture.
The History feature shows a comprehensive log of all conversations with all people of interest, organized by topic.
The Settings feature allows Butler to adjust the settings on his device, including graphics quality, screen resolution, and toggle any filters.
All of these features are designed to make the mystery-solving process a lot more intuitive and also a lot more fun! All the information you need will be at your fingertips - you just need to use your brain to piece it all together!
Here's a work-in-progress screenshot of the Deduction Device, with some placeholder data inside:
File Size Reduction
Last but not least, despite improving the graphics and user interface, we've somehow managed to decrease the game's file size! How does that happen?!
In order to understand, we once again have to go over how I'm implementing the sprites. The characters each have a body, a head, and a face, each individual sprites. These parts are layered on top of each other in-game. As such, I had been storing them in files the same way I had been storing the sprites in the first game, like so:
This way, when layered on top of each other, the head and face would always be in the correct position. However, I didn't realize this was unnecessarily bloating the file size of the project. Because the height of each face file is 1024, despite the fact that each face is only about 200x200 pixels in area, the texture is treated as a 1024x1024 texture. This results in a lot of wasted space. By simply cropping the faces and heads, I was able to reduce a 2 MB file down to a 20 KB file. That's 1/100th of its previous size!
Keep in mind, I had to code a way to align the heads and faces with each body, but it only took about two hours to make. At the start of the scene, the game reads from a text file where I manually wrote down the coordinates required to move each head and face into the correct place for each character. It's a little bit of manual labor, but it's well worth the reduction in file size. The game's build went from 1.5 GB to 400 MB! I'll continue looking for additional optimizations, including compressing the audio files and using the lowest-poly 3D models I can find (or make). I don't want people to be discouraged from trying the game due to an unnecessarily large file size, and it's even better if I can improve the graphics while I'm at it!
By the way, keep your eyes peeled for another announcement near the end of the month. If all goes well, our monthly game will be ready to play!