November Archives

One major thing most developers do – myself included – is to fail to target the right platform. And by that I don’t mean the whole android or iPhone or windows debate, I mean those all-important system specs. Do you focus on your end user’s system specs to start? Or is it better to tweak later? You have a shiny new super powerful computer that you do all your coding, your graphic design, your entire game on this amazing machine, and it performs beautifully. But then you realize it must run on ‘normal’ systems. All those amazing glows and animations, are they going to look good, much less perform decently on a lower end device? That’s the big question! I know I am guilty of doing the same thing and I have a bad habit of developing almost the entire game to completion before I upload it to my target device to test, and then it bombs. Ok, so most of the time it doesn’t bomb, but I have to go back and make numerous performance tweaks and adjustments to get it to run acceptably. Same thing with the latest project, Scratch’n Score. It’s a pretty simple 2D game though using some 3D dice that use physics to roll. It runs great on my system and in the editor with everything on screen at around 6-800 fps. Amazing! Then you remember the device you develop for is a much lower end device, think entry to barely mid-level android devices, and bam, now you’re struggling to hit 60fps during some of the ‘cool’ stuff. I just did exactly that. In fact, I spent hours on one animation, slicing and aligning the images, designing the animation, all to play when the player scratches and loses all their points that round. Does it look great? Yep! Does it play on the device? Well, barely. By the time the device catches up, the whole animation is over halfway done and then bam, it’s gone… Not to mention, now that I see it playing on the device, I really don’t like how it looks. But that’s a developer’s dilemma. It takes time to save and compile everything and deploy it to the device in question to test, depending on the project it can take anywhere from 3 minutes to an hour. Is it worth it to do this on a regular basis or is it better to develop and then tweak it later after testing. That’s up to you and how valuable your time is. On the bright side, deciding out of the blue to test it on the device today (mostly because I wanted to show off a bit), I realized I don’t like that animation anymore and thought of a much better solution, AND saved myself some time since I was thinking about doing some other animations the same way. Overall, testing it on the device probably saved me several hours of designing more animations like that that I would have ultimately tossed out anyways. Well, since the wife is out of state for the weekend, I am going to take advantage of her absense get back to some coding! This project is wrapping up nicely and I can see the light at the end of the tunnel. The gameplay is essentially done, it’s all the polish and animations that I need to work on now, along with a couple game variations just to add some spice and keep replayability up there! Then all the boring stuff, settings menus, etc.. Ugh.. 

Amid all the distractions last night, not the least of which was standing in line for several hours to vote, I did manage to get some coding time in and made significant progress on Scratch’n Score, eliminating the issues with the old codebase. It took a couple days to truly get over it and delete the old code completely and rewrite it. I know I’m stubborn, but I backed up the two files thinking to use them as a reference, but the problem came when I kept going to them, trying to just copy and paste to fix it, rather than doing what I had intended, a rewrite. Once I was able to get my brain to cooperate, and after several heated internal arguments with myself, I convinced all those nagging thoughts that a rewrite, from scratch, was the better way to attack this. And the result? A lovely dice rolling simulator, that lets you roll until you scratch, or until you score your points and pass the dice to the next player. I amended the score calculating code to keep track of which dice in a roll were contributing to the score to eliminate players trying to cheat… For example, you roll and 5 of your dice are scoring, but that last one wasn’t. Well, you could cheat the system by just selecting all 6 and then boom, next roll it would think you scored with all 6 and let you reroll 6, instead of one. Not anymore. As a matter of fact, I think it’s going to be a default ‘house rule’ that if you try to include a non-scoring die in your take, it will be an instant scratch.. The rewrite also allowed me to handle some other things that would have been harder with the old code like having wild dice where if you’re lucky you could change one of the die values to anything you want, among other variations. In the long run, this was worth it, but painful. I hate doing a complete rewrite as I feel like I have just wasted all that time, but it was worth it. Hopefully this weekend I’ll get back to the code and finish up the gameplay portion. Time will tell!