Finally back to doing some coding and I can’t think of a better way to celebrate this than by coding up a quick little GemClix variation. GemClix Blast has the same familiar play as the original GemClix but this time you only get 60 seconds and or 60 moves, which ever comes first! Surprisingly the game came out quite fun. Give it a play and by all means please pass it around to game sites you visit. :)

Not much happened lately code wise other than alot of internal optimizations, clean up, etc. Boring but it has to be done as things progress. One thing I like about my code, it’s very readable. My code isn’t filled with the latest buzzwords, or overly complex variable names, functions, etc. I learned a long time ago that it’s best to always break down any code into small logic blocks as often as possible. This makes it much easier to come back later and actually understand it.

My initial goal for coding RetroShoot Rush was to put around 2 weeks total development time into it, which I’m pretty much at that mark right now. Actually, if the game was released today I’d be happy with the outcome. It’s  really not supposed to be more than a proof of concept for my new framework. I’m at the stage now where I could stop right now or stay in the retro zone and just keep throwing things at it. I think I’m going to give it another 1-2 weeks and see where it leads me. The code base makes it easy to add new levels so perhaps I’ll release it and add new levels every week or so after the game is released. ;)

In this video I’m messing around with a bug boss. It’s funny, I forgot the boss could actually spin around and aim at the player even if the player was behind the boss. Might keep that in, but I doubt it would be used since the player will always be aiming forward.

Had pretty much an entire session wasted by trying to locate a bug that would disable the background from being rendered. Everything else was being rendered accurately. So…frustrating and time consuming.  So like any good debugging session you start by turning everything off and then start turning one thing back on at a time to see when the error shows itself. First you start with the high level code, then slowly work your way down to the abyss. At this point you’re experiencing complete bliss as a coder. ;)

Later that day….it all boiled down to simply not initializing a variable to zero. Wonderful.

Well…at least the entire day wasn’t a loss, I did manage to work on adding code to the wave handler so it supports boss / armada launching. This makes the background scrolling slow down all dramatic like as the boss and or armada approaches. Hopefully this will be utilized several times in the game. ;)

By now it should be obvious that RSR will be a horizontally oriented game. I like the wide screen look and it also allows some level creativity I’ve never explored before in a Retroshoot game. Plus on phones, it really just feels natural to hold the device horizontal, put your thumbs on the screen to control the game.

In this video I’m just exploring a level idea. I actually think this is going to work and will probably end up in the game. Plus now I have an idea to use the same media and create a level where you’re navigating through cavern walls, etc. Oh the joy of coding a game that isn’t really a game. No story, no structure, etc. Anything goes. :) lol…

I’m the kind of person that likes to get the obvious out of the way first so the past couple of days were spent working on making the framework behave nicely on mobile. This means dealing with device suspend/resume, locked, context lost, etc, etc.

As usual with mobile, no two devices behave exactly the same, so at some point you just have to be happy with the fact that a decent amount of users will be able to run your app. At this point we’ve passed q&a for just about all of the most popular phones and tablets, which is great news and means I can get back to just coding game related goodies. All those “house chores” are done. :)


RSR = RetroShoot Rush. Clever eh? lol..

So today’s coding session was primarily discovery that the “virtual stick” movement code I was so proud of yesterday is not going to work for this game…at all. So I spent all day coding various ways to move the player around the screen, creating apk’s and testing it out on my Galaxy S3. This cycle of madness went on for about 8 hours until I’m finally at a point where I’m content and can move on. I ended up creating a fairly intuitive way to allow the user to drag their thumb or finger, etc, and have the player ship react accordingly without the dreaded “fat finger in my way” syndrome.  lol…

Right now the game has 3 control modes coded:

1) Finger movement.
2) VStick.
3) Flappy (yes…flappy).

I’m guessing the finger movement will be the one that makes it in the final version, even though flappy control does work for this game, but I’ll probably save that for another app.

Code wise, RSR is probably 75% of the core game finished. The slow part is going to be attempting to tweak the game for somewhat balanced progression as you play through the game.  Also while mobile devices are powerful ,they’re still no where close to desktop performance so I have to be careful about spoiling myself on my desktop kit. My target fps is 60fps, the game uses time based movement so everything runs the same regardless of frame rate. On Kindle Fire (1st generation) I’m getting between 30-50fps even with a ton of things zipping around. On my Galaxy S3 the frame rate stays between 45-60fps. So I’m very happy with overall performance. If I had to compare Stage3D to my old GPU accelerated raster engine, I’d say performance wise on mobile they’re fairly similar, but the ease of doing things from a programmer’s perspective using Stage3D is the key difference. wow…

I had someone email me and ask if there is even a market for RSR on mobile. I answered back.. “probably not”. lol… But it does make a fun way to tweak MGE, fine tune all the code, create new routines for the MGE kernal, etc, which will be utilized in other apps with a larger potential demographic. ;)

And finally, here’s a lovely screen shot of RSR running on my Galaxy S3. :)

Not that I expect anyone to rejoice with me, but I developed something from scratch today that worked the first time and that’s always nice. :) Yah, most other developers have been doing this for some time, but I tend to come late to the party. lol..

I’ve always used “sprite sheets” for some time. This is basically a collection of smaller images which fit nicely onto 1 larger image. At some point “sprite sheet” became “texture atlas”. I just love how the latest generation of coders love their buzz words. ;)  As everyone knows by now, I don’t like being dependent on anyone else’s code so I tend to loathe using 3rd party frameworks, so when ever possible I like to write my own version so it’s tucked away nicely in my own custom framework.

I’ve never embedded an xml file into an AS3 project. There…I said it. I’ve always hard coded my data structures or used tools to create inline code, etc, etc. Same thing with my sprite data. This worked ok in the past, but we’re playing catch up here, it’s 2014 after all!

I won’t bore you the details, but it turns out it was very easy to do all this. So now I just use a fancy program called “Texture Packer” to put all my little sprites onto 1 larger sprite sheet. Embed the resulting texture and xml file into my app and let MGEAtlas do the rest.

On a sad note, this means I won’t be using a fancy web tool my son Michael Munsie wrote for me anymore which would parse data from an older texture packing tool and create inline code I could just copy into my app. Thanks for the routine Mike, it did save me alot of time and headache. ;)

Now that my new framework has been tested and verified to run on web and mobile, it’s time to have some fun. As usual, this means working on various demos, routines, etc, etc. Occasionally this evolves into something resembling a game and in this case I’ve decided to let this evolve into RetroShoot Rush. :)

RetroShoot Rush is a throwback to the first RetroShoot game as it’s going to be basically a hogwash of levels throw together. The “rush” means it’s going to have short levels, lots of particle eye candy (would I have it any other way?) and a variety of things to keep anyone with A.D.D. entertained. lol..

Pics and perhaps a playable sneak peek soon. ;)