SquigglyFrogStudios

Returning to code a year later…

Off To The Eval Group…

Scratch N Score Another game ‘rolled’ out to the eval group (pardon the pun). Since the process was never truly explained, and because it’s pretty self-explanatory, that’s where a game goes to live or die.. Does it feel like it has a home on the table? And is it good enough. My biggest fear is that that same eval team is going to come back one day and say, nah, we don’t think this fits. Normally that would be fine and dandy, except for the fact that I don’t publish anywhere else now. It’s just not worth it.  One of my big things with all the major stores is the tremendous amount of shovelware and reskins, hundreds of thousands of identical games with different names, and at least 60-70% of it is trash. Sure, there are some gems out there, but you have to shovel through bad to find the good. One of the things I love about the platform I develop for is generally, most of the games are higher quality stuff that feels like it belongs there. Ok, there’s a couple that probably shouldn’t have made it, but hey… 😉 So I do my damndest to make sure my stuff is at least a couple notches above average. They may not be perfect, but I do my best to polish the hell out of them and I try to avoid using and of the thousands of prebuilt templates out there. This weekend I finally finished up and pushed out Scratch N Score to the eval group. Yes, it’s a clone, but it’s also one that doesn’t exist in their ecosystem, plus it’s one requested by many owners of the device on different facebook groups I have seen, so I am pretty confident it will be a success! Well, fingers crossed! I even added multiple gameplay variations and a lot of options for choosing your playstyle to give it that extra little boost. So once the eval team tries it out, makes their holy determination, then we go to the beta team. Those guys… MONSTERS!!! They can find bugs where bugs don’t exist. It’s my firm belief that they have a backdoor to my pc and are secretly coding the bugs in so that I have to go fix em. Honestly, they have an amazing team over there, and a ton of dedicated testers who really put a game through its paces. Every now and then something slips through the cracks, but wow! So that’s the next step, we wait, we let the testers get their hands on it and then we sit back and wait for the reports to roll in. I’m sure a certain tester will find something, probably some obscure combination of button presses on screen that no normal player would even try, and another one will find my spelling and grammar errors… But that’s what makes it a great team. Those guys deserve a lot of credit, because while I consider myself a great programmer, I readily admit as a one man team doing it all, I miss a lot sometimes. Just like this game, I originally wrote the gameplay routines, the scoring and then after a couple weeks realized I had completely screwed it up and had to rewrite 90% of the game play code. It’s better now, but that’s a big hit.

Opânico Release! & Upcoming Projects…

Opânico Released! Woohooo! Another game released after a long and arduous beta process; but in the end it was worth it and the game is definitely better for it! In what spare time I have been able to scrape up, I managed to get the vast majority of Scratch’n Score gameplay done, so now it’s mostly minor cosmetics, adding the splash and polish that a good game needs, along with all the boring mundane stuff like the player select and instructions.. the list goes on and on. I have some ideas on enhancements to make on this one before release, including a couple additional game modes I have been contemplating. Coming Up Next… I still have a multitude of ideas and projects in the works, but I’m going to be focusing on five main titles in the upcoming months, roughly in this order… Unless I come up with a different better idea that strikes my fancy at that particular moment, in which case everything below is out the window. Short attention span and all… 😉 As for timelines? With my schedule, who knows.. But I am aiming to have the first out the door to the beta testers in the next 30 days. After that there, I’ll get back to working on Rogues ‘n Riches since it’s mostly complete and send that over. It’s not a fast paced game, so hopefully it will still be well received. The others haven’t even been started yet, so I have no idea on any kind of schedule. Scratch’n Score Roll the dice and race against your friends to reach the target score first. With each turn, match combos to rack up points and strategize your way to victory. Roll as much as you like as long as you don’t scratch out! Rogues ‘n Riches A strategy board game where you’re dealt a hand of cards, some may unlock doors while others may blind your opponent. Can you make it to the vault and escape to the exit before getting caught? * * This one is mostly done. I’m hesitant to include an AI in this since you can play single player. I just need to do a little more testing before sending it out.  Frustration Remember that game you played as a kid where you had to fit the shapes into the holes on the board before the time ran out and everything exploded? We’re doing it! This one will be great for adults and kids alike with varying difficulties! Can you beat it or is it just going to frustrate you some more? SLOA It’s 9pm, your sitting there watching the intergalactic news like you always do, the only difference is your child just told you they have a science project due tomorrow morning… Great.. Another middle of the night abduction to take care of… When will they learn to let you know ahead of time that they need another human to probe? Pathways A strategy game on a grid where your goal is to make it to the other side of the board. The only problem is your opponents and they walls they can place up at their whim as they try to block you! Be the first one to make it across and be declared the winner! Not sure if or how I am going to theme this yet, but I’m leaning towards sci-fi / tech.

To Build Or Not To Build

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.. 

Rewrite rewritten!

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!