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. :)
rsr_galaxys3

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

With the newly updated MGE, this brings a level of coding creativity that I haven’t had since I was working with Visual Basic and created something called the “DXGame Engine”. The “DXGame Engine” at the time was one of the few high level 2d frame works available.  Thanks to DirectX hardware support, performance was very smooth, even in a “basic” like language as Visual Basic. I did end up releasing several games using this frame work, “Retroblast” was probably the most popular.

I made the move to a language called “BlitzMax” which was cool because I could deploy on PC & Mac. Over the course of a year I improved upon DXG and MGE was born. I released a game called “Christmas Clix” for the PC/Mac using this framework. MGE was easily ported over to C and allowed us to port over Christmas Clix for the Wii very quickly. I also was hired to be part of a team what worked on a multi game app for the Wii which also used MGE. I had planned on doing SEVERAL pc games using MGE, but at that time Flash games were growing and I really loved the idea of coding small’ish games that could be played in the browser so I took a look at Flash using FlashDevelop as my IDE of choice.

One thing I quickly realized was that at the time, to really maximize what Flash could do, you had to get low level and dirty. It was common a few years back to see a Flash game running very slowly, with very few objects on screen. There was a faster way of doing things, and luckily I was already familiar with the “blitting” process coming from my work  on the Atari ST. After a few simple ideas, I started working on a proof of concept demo. The demo was basically an “anything goes” type with little to no structure. One thing lead to another, optimized code, etc, etc, and something called “Retroshoot” was born. It wasn’t even supposed to be a game really. lol.. In any event it did turn some heads in the Flash industry, and it was my first game ever sponsored. Looking back, it was also the least amount of money I made from what’s called a “primary” sponsorship. Luckily the game went on to sell a ton of site lock sales. I think the smartest thing I did was put a site lock on Newgrounds. Every sponsor who wanted the game couldn’t take it from Newgrounds so they had to contact me directly. ;)

So I’ve been using Flash for almost 5 years now and up till recently I’ve been using the old school “copypixel” blitting method for everything. And to maximize performance you need to “pre render” your sprite images as much as possible. And that is…well…..was…  a pain. But the results were pretty cool. Games like RetroShoot, BalliesShoot, GemClix all make good use of that low level pixel pushing engine. Ofcourse now days, you could get similar results just using normal display objects, pc’s are fast enough not to worry about it.

So…with the updated MGE and Stage3D I’m back to what I call “pixel freedom”. Creating my fun little games has never been easier or more fun! It’s brought back a level of excitement that I haven’t had for a long time! Ofcourse this does come at a price. I’ve been informed that Stage3D games can’t go viral, don’t get sponsored, etc. No prob, because I’ll just self sponsor the games anyway. And at this point in my life, as I wind down my game development career, I might as well just have some fun and code whatever the hell I want to. :)

And in the process, if one of my games has entertained you for even just a few minutes…I’ve done my job. ;)