Since this project has a low-res pixel-art style, it is very important that everything is presented as point-filtered textures with no anti-aliasing, or it defeats the intended look. I noticed that my Windows builds had a very “soft” look to them, while my builds on OS X were perfectly crisp with no blurriness.
I have a quad that covers the entire visible area with a pass-through shader on it that is used for occasional visual effects. With no effects active, it simply passes the pixels behind it onwards. This is achieved using Shader Forge’s “Scene Color” nodes. After discussing this with Shader Forge’s developer Joachim Holmér, he suggested that the issue may be a different pixel boundary in DirectX vs OpenGL. Sure enough, this was the case and I was able to account for this by using a custom “Code” node in combination with Unity’s pre-processor shaderlab macros:
It’s a simple edit, but you can see that a pixel offset is first calculated. This is 0 (none) for OpenGL and 0.5 for DirectX. This value is then used to offset the screen’s UVs by an amount calculated using that offset and the screen dimensions. I’m sure there are other ways to solve this, but this is working for me and hopefully the information is helpful regardless.
My good friend and Y.A. published author Maurene recently organized a “work retreat.” This was basically a short weekend getaway for a bunch of friends from different disciplines – writers, illustrators, storyboard artists, concept artists, and game development – to gather and bounce ideas off each other. Rather than a quick meeting, hosting this in a private home far from the city was a perfect opportunity to hyper-focus in a relaxed informal environment.
I just wanted to list a few takeaways I had from this:
An external deadline can be a good thing Having the weekend scheduled in advance was a good milestone deadline that was forced upon me. I wanted the project to be in as polished a state as possible for its stage in development since a bunch of people would be playing it over the weekend. This turned out to be an excellent motivator – I noticeably increased my amount of production in the weeks leading up to this.
Note everything The amount of data you can get from real play tests with “real” people is invaluable, to say the least. You are in a bubble during development, and as soon as you begin working on a project, you lose all objectivity. No matter what you think about your own game, real play tests will give you the cold hard truth about everything from fun factor to unnecessary fat to bugs you may have missed. The most important thing is to note everything – no matter how insignificant it may seem. The way in which players feel or react (not just what they say) is a great gauge.
Allow time to respond If you have the luxury, give yourself time to iterate on your build with the same group of testers. It’s definitely important to test with a wide range of people, but if you can respond to some of the feedback quickly and have them play again, you can more easily determine if some ideas are on the right track or not. As this was a weekend retreat, it allowed for me to organize play tests in the morning, work on updates during the day, and test some of the changes again at night.
Eat pizza We were each tasked with covering a meal. I’m so glad I chose make-your-own pizzas.
Break up your routine Based in Los Angeles, we chose to drive out to Ojai and the change of scenery was a breath of fresh air (literally). I usually spend half my week working at home on development, music and audio, and the other half at our shared office space focusing purely on coding and art tasks. Although I love both environments, a break in routine is super healthy, inspiring, and energizing.
Always, always, always: have fun! You’re in the business of making fun, and you can draw from your real-world experiences.
The ultimate stealth battle adventure where everyone’s invisible.