So. December’s game did not materialize. Some of this was scheduling. Best laid plans and all that. Partially as well in that after I thought more about the design, I realized that I wasn’t all that excited to create that game. Then! Inspiration! I had an idea that was mostly in line with the original, but considerably better, and I could write it as a test to see if something like this would work well for a mobile programming project.
So, I crack open Unity, and set the project to 2D. Now I have Orthello Pro, but I wanted to take the new 2D stuff in Unity for a spin. I mean, how hard could it be, right? I also wanted to get a little fancy. Since this would be written for Android, and Android devices are pathological about having different screen resolutions, I wanted to program the game field to size itself to the screen at run time.
Algorithm was fairly simple, I wanted the play field divided width wise into 6 chunks, with 4 for the play area and 2 for the score/drop off point. So Screen.Width / 6 (using integer math here, so the decimal is dropped) gave me my chunk size. Play field would be Chunk * 4 in size, and the side bar would get any leftover pixels with Screen.Width – Chunk * 4. I wanted things in a checkerboard pattern, so I needed to know how many rows I could have, so Screen.Height / Chunk gave me that. (Screen.Height – Rows * Chunk) / 2 would give me the offset I need to deal with spare pixels.
Now I know that 1 pixel != 1 unit in Unity. What I did in the past was take a point in screen space and use a Camera.main.ScreentoWorldPoint to figure out how much to scale something. So if I needed a cube to act as a background for a 640×480 screen, then I’d toss (640,480,0) into the Camera call and use 2x the returned value to scale the cube. Easy-peasy. Of course I’ve found out during this ordeal that’s the hard way of doing it, but I’ll get to that later. Now sprites should be just as easy. Right? No. Sprites? They’re bat-**** crazy.
My first attempt at drawing objects in a checker pattern failed horribly and strangely, which is what tipped me off that I had a fundamental flaw in my understanding of things. So I decided to do some verification to make sure I was understanding Unity sprites correctly. I took a 64×64 pixel png, tossed it into Unity using the sprite import setting, and tossed it into a scene. Should be 64 pixels, right? Wrong, it was 31 pixels. Or maybe 39×39 if the screen is 800×600. Needless to say, trying to scale a 64 pixel image by 10 doesn’t take up 100% of the width. Why Unity, why?
So hence the title, when game engines strike. The idea that I would place a sprite in a 2D game, and not want that sprite to be pixel perfect on display, is baffling. I have spent days trying to figure out how Unity internally is handling things to no avail. I have learned quite a bit so all is not lost, though I’ll save the parts learned for another blog post. I know it is possible to get pixel-perfect because Orthello has a flag you can check to make it work, so all that’s left is just figuring out how to do that myself.
Comments are closed.