But I guess I’m excited because it’s raining. In my game, I mean.
I keep saying it’s all about the small details but I genuinely think it’s half the battle. Being able to add little touches without impacting too severely on the performance is one of the ways that Unity never fails to amaze me. When I set out programming this game, I assumed that my lazy techniques would soon punish the game’s performance. I’m not by training an Object Orientated programmer, so it’s taking time for me to come around to not writing things in a very linear fashion. I’m also writing this game for tablets and (I hope) mobile phones, which means I haven’t got huge resources to play with. Each time I add a feature, I think the frame rate will be impacted hugely.
Last night I added rain. Unity barely flinched.
[Sidenote: the way I added rain was to create a long sprite, fading towards the upper end, a slight tear on the other. I then display about 20 or 30 of them (random intervals and timings on each) inside the camera bounds (don’t waste precious CPU cycles drawing rain you can’t see), and then I move them down as I very quickly stretch them. I also apply a gradual fade by adjusting the alpha values. Add a random angle of slant and with the right timing, they look just like rain. I keep reusing the same GameObjects to save time, repositioning/re-angling/retiming the line of rain as soon as it has faded from view. I also animated a few drops of rain splashing on the ground which I also randomly display. ]
The effect isn’t bad, as I hope you can see from this deliberately empty and uninspiring shot of my game. And, yes, it’s mainly in black and white but it does have splashes of colour. The lack of objects on the screen accounts for the framerate nearly hitting 70fps, as you can see in the top left corner. I added that frame rate display to show me the average performance and the numbers are surprising. On the PC, the framerate is effectively about 450 frames a second (though, of course, my screen doesn’t update that quickly). It means that the code could update the screen over four hundred times per second if called upon. In reality, 30 frames a second is what most games run at. Some of the newer games run at 60 frames a second, which is something of a gold standard for 3D games, and accounts for much of the current bickering between XBone and PS4 owners.
My game is 2D so it’s not quite so impressive to be hitting around 60fps on my tablet but that’s (apparently) it what it’s doing. It drops a little on my phone to somewhere in the 40-50fps but that hopefully means that I’m in a sweet spot given that my phone is neither the most recent nor the powerful. The more people can play this game, the more my efforts are worth it.
Today it’s about fixing more bugs, adding more content which I drew last night, playing and replaying each level to see if it feels right. I’m thinking about ripping out all the music since I also need to start to reduce the final size of the final app. It’s compiling into a 45mb package, which is just under the Play Store’s limit of 50mb (I believe you can go much higher but it involves breaking the app into different resource files, which is something I don’t want to do). 45mb seems far too big for this game, even if it is packed with hand draw graphics which don’t lend themselves to tight compression. The main problem seems to be five or six very large graphic files, which I’ll need to reduce in quality. Hopefully there’ll be no obvious visual impact on the game.
Hmm… I push on.
No comments:
Post a Comment