Which language to learn for web game dev?

There are a number of different options these days when making casual games. Here is my take on the order of usefulness today:

1. Flash/Flex
2. HTML5
3. Java
4. Unity
5. Silverlight
   
6. etc..

Depending on your goals, any one of the above could be put to use. So why did I put in in that order?

The majority of casual games right now are being developed in Flash. If you look at sites like Games.com, Mochi, Mindjolt, and so on...you'll see that 90% (or more) of the content is Flash. Does this mean that Flash is better than the others? Nope. It just means that it's the most common use-case for developing casual games right now.

The question really is how long that's going to be. HTML5 is hot on Flash's heels, and it's really shaping up to be a powerful ally to casual game developers. I just don't think it's ready to usurp Flash's position just yet. The progress is substantial, though, so give it a year or two and it'll be a formidable contender. Adobe knows this too. They have been working on Flash->HTML5 conversion systems, and I wouldn't be surprised if they created a Flash-like IDE for the HTML5 (focusing primarily on the canvas support). As John Nack put it in his article regarding the conversion tool, "Adobe lives or dies by its ability to help customers solve real problems." This does seem the case and I would argue that Adobe's doing a pretty decent job of it. If they did create a full HTML5-IDE (ala Flash), I'd buy it.

Java is a great language for developing games. It's been around forever and has had a lot of push. I'm not a Java game developer, but I've tinkered lightly in the past and I had to do a few projects in college (non-game) using the language. The power afforded by the Java gives the developer a lot of options. The issue I see is that when Oracle took over the company they seemed to have put games off to the side. This doesn't mean that Java no longer offers gaming as a possibility. Far from it. It just means that the company-backing to grow that area of the language is no longer in the forefront...unless something has changed that I'm unaware of.

Unity is a nifty language with a robust graphics engine. It's powerful, 3D, supports builds on various platforms and distribution channels, etc. I've dabbled only lightly in it and I can say it is a very nifty world. Issue: the documentation is less than awesome. There are a lot of things that you just have to figure out. Now, if you're the tinkering type, this may be cool to you; if you're part of a team that is taking Unity and extending it to fit your particular game, then it's a very smart path to go. But if you're a hobbyist or a developer working on time-constrained projects, the learning curve may just be too great until they get their docs in order.

Silverlight is interesting, but I wonder how far it's going to go. With Microsoft behind it, one would imagine it has decent longevity. I wonder why they'd bother pushing money in its direction when HTML5 seems to be heading swiftly toward front-runner position. Personally, I've not developed in Silverlight, so I can't talk to its particular strengths. Still, as time permits, I will create a least a little something so I can see how it all comes together. I just don't see it as an area to spend too much of my time since Flash already has the lead and since I'm guess that HTML5 will soon take the #1 spot.

There are others out there that are available to learn as well, but I think the ones listed are the primary contenders at the moment. Of course I may have completely spaced on one of the other big players. If so, smack me. I'm not proud. :)

The bottom line is that any of the above languages (and more) have their advantages and disadvantages, but if you're looking to pick one or two to learn at this point, I feel that picking the more relevant one makes the most sense. This isn't a case of me saying (or thinking) that Flash/ActionScript is the best and everything else is crap. I don't believe that at all. Actually, there are parts of AS3 that drive me nuts. The point is that I see little value in spending my time deeply learning Unity and Silverlight for web-game development at this time, unless, again, there is a particular need (or job-opening) that requires that expertise.

Playing devil's advocate: There are a load of Flash and Java devs out there already. Companies that are invested in Silverlight, WildTangent, ActiveX, Unity, Torque, etc. are on the lookout for developers that know those technologies.

It's a catch-22. You either focus your time on being a know-it-all about one or two technologies, or you play the jack-of-all-trades card and just be decent in various technologies. I've always gone the second route. The way I see it is that I'm a developer regardless of the language I use. If I am tasked with developing an application in Java, I'll focus my efforts on learning it for that purpose. Same with Silverlight, etc. So I purposefully do not try to be an expert at any single language. To do so, for me, is limiting. ...but that's really a different discussion.

Mochi ZIP integration issue resolved

It took a couple of weeks working back and forth with the tech folks at Mochi, but we finally uncovered an interesting ooopsie.

There are three ways (that I'm aware of) to build a game for Mochi distribution:

1 - Use a single SWF file that contains all your components, images, sounds, etc.
....This one works pretty well for the most part. Very few moving parts so not a lot to worry about.

2 - Use a single SWF that loads external resources from a site you host.
....Works well as long as you have a reliable server with the proper crossdomain.xml file setup and all that, but is subject to dropouts of your assets and potentially slower loading times. If you have a decent CDN it's better.

3 - Use a .ZIP file that contains your SWF plus all the externally loaded assets.
....Neat idea and has its merits, but it's not idea. Firstly, you can't use sub-directories (as of this writing anyway). Not a huge deal, but I like to try and keep my assets categorized so it bugs me a little bit. Secondly, you have to watch how you load these assets because Mochi's launchpad pages (the pages where they launch the games on) fail on external loads of the .ZIP'd content in some instances. Third, even if you use try{}...catch{} blocks on items that aren't available, using the catch to resort to different methodology for getting your assets/data, the game will fail to launch.

The point of this post is to discuss what I did to get the .ZIP file local loading issue resolved in the hopes that it'll help someone else.

The key component came from the Mochi techs that said I needed to have any loaders based off of the loaderURL. This snags the URL of the initiating SWF file, thus providing a fully qualified URL instead of relative. Here is a bit of sample code for what I mean:

var loader:Loader;
var resourceURL:String;
var request:URLRequest;

loader = new Loader();
resourceURL = loader.contentLoaderInfo.loaderURL;
resourceURL = resourceURL.substring(0,resourceURL.lastIndexOf("/") + 1);

resourceURL = resourceURL + "tempflashfile.swf";
request = new URLRequest(resourceURL);
loader.contentLoaderInfo.addEventListener(Event.COMPLETE, loaderCompleteHandler, false, 0, true);
loader.contentLoaderInfo.addEventListener(IOErrorEvent.IO_ERROR, loaderErrorHandler, false, 0, true);
loader.load(request);

The key point is to make sure that instead of having just "tempflashfile.swf" as the resource URL we end up with like "http://www.yourdomain.com/tempflashfile.swf". In the case of a Mochi distribution point, this "yourdomain" would be whatever domain the game gets loaded from, of course.

The next trick comes from making sure you either a) do this on ALL externally loaded items or b) you don't put in any try{}...catch{} blocks for stuff you know isn't going to be there. In other words, if you have code that checks for an external asset and defaults to an internal asset if the external one is not found...don't do that. Any non-found external asset seems to knock your game to a halt, even if you use the above methodology (at least it did for me!). Instead, for your Mochi build, just rely on the internal asset and avoid the external check completely.

If you're loading .XML files or somesuch, you will likely just be using the URLLoader and not the Loader. That's fine, but the URLLoader doesn't have a corresponding contentLoaderInfo.loaderURL data point, so you may scratch your head a bit. Just use a dummy Loader to get that full domain and stack it globally so you have it when building your resource URL.

private var gLoader:Loader;
private var gResourceURL:String;

gLoader = new Loader();
gResourceURL = gLoader.contentLoaderInfo.loaderURL;
gResourceURL = gResourceURL.substring(0,gResourceURL.lastIndexOf("/") + 1);

Now you can just preface any of your URL's with the gResourceLoader (gResourceLoader + "tempflashfile.swf") and you should be fine. Creating a class out of this is a snap and will save you a bit of headache and cut down on globals too.

HTML5 is nifty

I've been coding primarily in AS3 for a few years now, but I was tasked to do some research into HTML5.

While I'm still in the exploration stage, it's pretty nifty. I can see adopting this technology heavily once all browsers are on board. I'd love to be elitist about it and just say be damned to IE, but that's not my call. I know thee are workarounds for the IE shortcomings, but I kinda have to wait for actual support for the things I do.

Either way it's a very interesting technology that I'll be giving mindshare to so that I'm ready for the full shift when all browsers get with the program.

Algorithms are fun

I've been working on a persnickety (yes, I actually just used that word) little algorithmic issue for a new game I'm working on. The game is kind like Phlinx and Bubble Town, so there is a little projectile that flies up toward the board and, upon matching three or more, causes the pieces to explode and disappear.

That matching bit was fun in and of itself, but I got that one sorted out. The challenge now is the line-of-sight check for spotting where the projectile is allowed to land.

The problem is a little tougher because the board is staggered (Row 0 starts at pixel 45 and Row 1 starts at pixel 90...for example), so you can't just simply check on an array basis. You use the array, of course, but you have to kind of treat it a bit differently.

For example, consider:

[ ][ ][O][ ]
[ ][ ][X][ ]

      [P]

Since the row offsets match, we can immediately see that the projectile (P) can not get to the open position (O) because there is a piece (X) in the way.

But, if we stagger the board:

  [ ][ ][O][ ]
[ ][ ][X][ ]

      [P]

...and if we imagine an line drawn from P to O, then the piece CAN hit that spot.

But how far can it go?

  [ ][ ][ ][O]
[ ][ ][ ][O]
  [ ][ ][O][ ]
[ ][ ][X][ ]

      [P]

...looking at this board, an imagining that line draw up, the projectile can find its way all the way to the top of the board here.

Those are just a couple of the issues associated with this. Either way, it's a fun challenge (so far), but I'm certainly finding myself brooding more than coding at times. :)

Flash Debugging

So as I (and seemingly tons of other Flash devs) continue to struggle with memory and CPU issues, I searched for ways to help pinpoint issues. I found two items that I'm planning to try out today to help:

1 - De MonsterDebugger -- an AIR app that allows you to realtime debug on many fronts.

2 - EventController Lib - a library that manages events to make sure you don't end up with lingering event managers in your code.

With any luck I'll have good news on these two items soon. Either way, I'll post up how things are turning now.

**UPDATE:

Wow. The two items listed above are AWESOME. I highly recommend this to anyone serious about developing Flash apps/games. The bug I've been hunting forever has been found and (hopefully) squashed. And, yes, it was my fault.

I fell into the trap of expecting Flash's garbage collector to be more intelligent the larger system gc's because it is smaller world. Unfortunately, it's not. So, just like C's new and delete, so it goes heavily with Flash. If you want more details, check out this great article by Tom at Gabob.

It was in the comments of that article that I found the EventController Lib and from that I found the Monster Debugger.

Even though I was removing the event listeners from everything, I wasn't nulling things properly. I *thought* I was, but with the Monster Debugger I was able to see a lot more than I was getting from the Flash debugger. What I saw with Monster was how I was missing quite a few of nulls, and a couple of deletes too. Oops.

Anyway, now CPU usage is now quite nice (when the GC decides to kick off) and memory is staying low too.

I will likely integrate the EventController Lib too since it seems to be really intelligent in how it works. First, though, I want to see how things go now that I'm nulling/deleting in (again, hopefully) all the right places.

With my luck I'm probably still not 100% solved on this issue, but it's GOT to be better!

** Update Part 2:

Integrated EventController Lib. Nice. It was simple to integrate and it gives a simple interface for controlling events. Plus it can be easily set to log information over to Monster Debugger, so that's sweet.

So far I'm liking these new toys!

One year anniversary

I can't believe it, but yesterday was the one year anniversary of when I stopped drinking sodas. After downing 4-6 sodas a day (on a slow day) I decide that it was time to stop.

So, I did. And...it sucked, but I ended up dropping lots of weight and my mood evened out. It took thirty days or so before I could stand being in a room with soda and not wanting to imbibe. Even now I long for an ice-cold can of Mt. Dew.

Point is that I stuck with it for a year. I'm glad I did it and I'm not going to go back to sodas, but...but...but damn do I want that Mt. Dew.

Ice Breakers: Penguin Pirates

Finally released Penguin Pirates on games.com. It's in beta right now, so I'm sure there are still a few bugs to contend with, but it's looking pretty good.

Check it out at http://www.games.com/game/ice-breakers-penguin-pirates/

Moved stuff around

In order to take the writing life more seriously, I've decided to go with the recommendations of a few industry folks I've talked to.

One of the bigger dealios for this is that I had to set up a separate blog specifically for my writing adventure. That blog will have nothing but stuff about writing. This blog will still go on for the other crap that I do, which seems to be dwindling slowly to a crawl. :-)

Anyway, by the time I'm done I'll have three total blogs going:

1 - This one, which is for games, coding, and general nerdery.

2 - The writing blog

3 - The music blog

Yeah, I know that's nutty, but separation of church and state seems to be needed these days.

"Book" to roots

I have been a developer since the early 80's and have coded on a VIC-20, C-64, C-128, TRS-80 (I, III, and IV), PC (DOS, 95, 98, XP, and now 7...skipped Vista), Mac (OS/X only), iPod Touch/iPhone (thoroughly hated coding on these), and now the Droid. I have used Assembler, BASIC, COBOL, Pascal, Prolog, C, C++, C#, Objective C, Java, JavaScript, PHP, PERL, HTML, ActionScript (3.0)...and likely more. I've also written numerous game development articles and had two books published on 2D game development as well.

Well, after all of this I had finally gotten to the point (about 5 years ago) where coding started losing the same level of excitement that it used to have. I still love coding games, but just plain coding, tinkering, and hacking is not all that thrilling anymore.

Fortunately, I picked up the book "Code", by Charles Petzold last week and I have suddenly realized the problem. I miss the days of the VIC-20, C-64, and all the other nerdy machines made! There is so much abstraction now that the tinkering and hacking just doesn't have that same draw. At least not for me. Mr. Petzold really brought me back to my roots with his excellent book.

I'm planning to order a NerdKit (http://www.nerdkits.com) later this week, and will eventually like snag a Tower System (http://www.towergeeks.org/page/the-tower-system) before I finally join up for the Game Institute class on creating your own video game console and game (http://www.gameinstitute.com/Video_Game_Console_Design.html).

I've never been much into electronics, so it will also be an exciting new jump into a technological area. Building stuff and the coding to it just sounds so cool that I must give myself a +2500 geek points immediately upon completion of my first project. Sadly this stuff is not cheap and in this economy there is a lot of penny-pinching going on. So it's going to take some time to get things going, but that's cool. There are loads of FREE sites out there and plenty of cheap used books to read at nights and on the weekends when there is time.

I loved tinkering with the old Commodore's and TI's back in the day and I'm already excited about the potentialities of these little kits. But (those of you who know me) this is not a take-over-the-world situation for me. I'm going to treat this as nothing but a hobby. No deadlines, no next-biggest-thing projects...just nerdy learning and geeky fun. That's it.

It's like a technological breath of fresh air to go back to a point where abstraction is minimal. Many of these kits offer C as the connection point, and I'll likely utilize that on tougher projects, but wherever possible I'm using Assembler (or ML, if at all possible!). I can already imagine spending hours and hours fiddling with a project whereby I toil and toil using Assembler and various schematics to satisfy a project that simply makes an LED blink once. Yes, it's essentially pointless, but damn if it ain't cool!

So, if you're looking to get that old-skool interest again, check out Petzold's book. It's an interesting read and it may serve re-spark your nerdiness too.

My Grandparents

My grandmother passed away this morning. She and my grandfather (Pap-pap, as we called him) were awesome people, and I just wanted to take a few moments to thank them for all the memories.

Grandma was a strong woman who told it like it was; she never pulled any punches. She was funny, kind, caring, somewhat irreverent, and a bit sarcastic. She was awesome.

Pap-pap was always on the go. He was in better shape at 80 than I was at 30. He was funny, mischievous, and always joking around. He kept us on our toes!

I remember growing up and faking a number of illnesses so that I could a) get out of going to school, and b) get to go to my grandparent's for the day. Every time I went there I was treated to the best southern iced tea money could buy (homemade, of course), grilled cheese sandwiches that were simply amazing, and a guaranteed trip to the toy store. Looking back, I know that she and Pap-pap knew that I was faking being sick most of the time, but they didn't say anything. I know they knew when I was really fine, though, because I'd end up doing yard work with pap-pap. This mostly consisted of Pap-pap chasing me around the yard with hedge clippers saying that I looked to need a shave. :)

I also remember how grandma and pap-pap's house was the hub for me and all my friends as I got in my teen years. We would ride our BMX bikes all over the place, but I would always call Grandma and ask if it was okay to stop in for lunch. My friends would ask me constantly, "Are we going to Grandma and Pap-pap's?" They called them that too, which my grandparents seemed to quite enjoy.

Pap-pap would take to looking over the bikes to see if they needed a tune up or not. He did this, of course, with his hedge clippers. At first the fellas would be looking to me with a "what the heck is he doing???" stare of horror, but soon they understood he was just joking around, especially when he would say things like, "Looks like these tires need work. I'll go get my hammer." Grandma would call him an "old fool" (to which he would giggle, as it seemed that if he could get a rise out of her it made his day) and wave all of us in for a round of grilled cheese sandwiches and iced tea. Ah, those were the days.

A lot of people tell me that I should have been a comedian or an actor. I think I get a lot of that from my grandparents. Their interactions were hilarious at times. Grandma would play the role of Dean Martin while Pap-pap played the role of Jerry Lewis. Occasionally, they'd even go as far as Laurel and Hardy. While I have no designs on being a comedian or an actor, I hope my writing reflects the comedic view my grandparents ingrained in me. Most assuredly they will both find themselves as lovable characters in my world as I can think of no better dedication to two people who so highly impacted my life.

Grandma and Pap-pap, thanks for being lighthearted, fun-loving, caring, entertaining, and the best grandparents a kid could ask for. I love you both!

Origins of BlitzCoder

I received a request from one of my long time friends, Malcolm "Chiefy" Brown, to write up a piece regarding a site that I ran a number of years ago. The site was called BlitzCoder and it was all about Blitz Basic development. Chiefy happened to send me a bunch of questions to help get things started. I'm going to go ahead and answer his questions here. If there are more questions from anyone, just post a comment and I'll do my best to answer. This will make it more interactive than just an article. :D

Chiefy's Questions

1 - What sparked you to start the site?

I was looking at the current blitzbasic.com site and was finding very little information on how to code up stuff using Blitz. I basically studied the demo stuff and the commands list and did up a few simple things and then decided to write a full game in one day. I created Rocktoids, which was a cheesy little Asteroids clone. People asked how I did it and I thought I'd write up some tutorials on that. But where to put them? That's when I decided to open up BlitzCoder.

2 - Did you do it on your own?

I did all the development stuff on my own, yes, but I had big support at the time from Paul "Snarty" Snart. He was the biggest cheerleader, giving tons of ideas and support as I plodded through the development cycle.

I never expected it to be more than some tutorials, but then a forum got added and I had to start picking up PERL in order to build things into it. Snarty was managing the community along with me and he was telling everyone to come check it out. We started growing and people started asking for more and more...and more...and more. hehe

3 - How did you get all the parts to work together? e.g. people could LOAD their projects ONTO the site, did you know all the www coding to do that or was it part of some website package?

The only thing on the site that I didn't code was the UBB bulletin board system, but even that I spent countless hours modifying. All of it was PERL with flat files for storage. Looking back, it was simply horrible coding practice. Regardless, I learned a heck of a lot.

4 - The absence of advertising made it a really clean slick place - did you ever consider having advertising?

Not at first, no. I personally hated the whole ads thing, but in the third year I was paying a fair share of my own money to keep the site running because it had gotten quite popular. So then I started looking for ways to make some money on it to at least break even.

That's when I started writing the Blitz book. It was a very rewarding project to work on, but man was it HARD. Anyone who says that it's easy to write a book has never written a book. :)

After it was published it was a double-edged sword. On the one side, it was making enough to help me break even on the site costs; on the other side, it made the site more popular and filled my email with tons of requests and questions about game coding and development, etc. I was slammed.

Fortunately, Charles "Specis" McCrimmon was fully supporting the site at that point…to the point of basically administrating the entire thing. If it hadn't been for him, I'd have lost my mind.

5 - In the early days there must have been just a few members there, how did word spread? How did people know it was out there?

Mostly Snarty was responsible for starting the influx of people. Then I think my tutorials started pulling more and more folks in. Then I went to a couple of BlitzCoder conferences in the UK (and a number throughout the US) and that added even more people. Finally, the environment that was set up was one that fostered help and didn't allow snapping at people simply for asking questions.

The goal was to be helpful, not elitist. I've always felt that just because I'm better at something than someone else doesn't mean I haven't traveled the road that they're currently on. Also, I'm smart enough to know that there are MANY people out there better at that same thing than I am…and it's quite likely that this person I'm helping today it going to end up surpassing my skills in the long run. Plus, frankly, I just can't stand people that act elitist. They're clearly hiding some type of inferiority or they wouldn't be that way. I think this attitude spread from me to the moderators and to the rest of the people on the site.

People weren't afraid to ask questions. They weren't afraid to participate in discussions, even if they were still noobies. It was about coding prowess, it was about enjoying the geekiness of coding in a mostly obscure language.

When it's all said and done the community ultimately made the site as popular as it was...they deserve the credit.

6 - Did you have bandwidth warnings/ data moving up to maximum levels to contend with?

In the end, the site was being slammed with so much usage that the Webhost I was using contacted me and said I had 30 days to remove the site from their servers! LOL. I felt a mix of pride and panic. I didn't have the money to do anything with this so I was going to put up a message that I was taking the site down.

I happened to be talking to George Bray (then of Idigicon) about some book fixes that I needed to make before the next run and I told him that BlitzCoder was in trouble. He talked to Giles Hunter and they offered to take over the running of the site. From there I slowly moved away from Blitz stuff and into other languages, doing another book for Idigicon on Pure Basic.

Well, that's about it I guess. It was a fantastic experience and there are so many fond memories of all the people that I got to meet on that site. Most of the people I know only by their Aliases, which is kind of cool actually.

Blackbox coding

I'm in the middle of a big project for work that is very geeky and fun. I'm having a blast coding it up.

Essentially I have a bunch of APIs that I have to integrate a game into each time one comes in.

As anyone who codes knows, this is a tricky proposition because it takes time to understand someone else's code. Once you understand the code then you have to start working the API hooks into it. Then you do your testing and get others to help test. Finally, you ship that version of the product and then do the next integration point for the same game (hook in another API for a different launch portal). Currently we have three portals to launch out of, but there will be another 3-5 over the course of the year. This puts me in the position of each game taking like a month to do. With 15 games looming, anyone can see that's not gonna happen quickly.

So I thought about it and decided to write a blackbox interface for all this junk that I can turn over to the game developer and allow them to do the integration themselves.

It looks something like this:

So the blackbox is essentially an interface. It has a list of all the available functions that the developer can code to. The developer doesn't have to worry about the Platform specific code. I do.

• When the SWF is loaded, I set the distribution argument in the embed tags flashvars section, which tells the black box what platform to connect to.
  
• The developer builds once on a generic platform, hand the code+build to me.
  
• I create multiple .html files that have different distribution arguments, and then launch the game.
  
• The blackbox handles the routing to the appropriate platform and the platform communicates with the appropriate server.
  
• All the data that comes back into the game is identical regardless of the platform selection because the blackbox handles the translation.

I know that this isn't a novel idea at all, but it sure is freakin' fun to code! :D

Shoulder separation - Not recommended

I was playing ice hockey the other night and all was well. There were two minutes remaining in the game. We were winning 6 - 2. Then it happened.

I was heading into the boards to poke a puck around. It was just me and one of the fellows from the other team. Neither of us was going all that fast considering a deficit of 6 - 2 is not easily changed in 2 minutes. Sadly, our feet got tangled and I went shoulder-first in to the wall.

Now I've been checked full force before and everything was dandy, but a little harmless fall at like 5mph and CRUNCH. Yes, I heard an audible crunching sound. Oddly, it didn't hurt at all...for like three whole seconds. For those three seconds I was having thoughts like, "Well, a crunching sound can't be good" and "Maybe it's like when the chiropractor adjusts your spine?". Turns out that the first thought was the correct one. When the three seconds of interested-third-party thoughts concluded, the in-the-moment me returned to find a searingly horrific pain like few others I've felt over the years.

I sat on the bench for the remainder of the game carefully holding my arm in place. It was less than fun. After getting back to the locker room my teammates helped me get everything together, and one of them did a makeshift sling (impressive, actually), and then I called my wife since I was in no condition to drive.

We got to the Emergency Room and waited a while (something I'm sure will get better now that we have universal healthcare coming...) before they did x-rays and such. At first they couldn't find anything wrong. Then they tried a different angle. I believe I heard an "oh...hmmmm...that's not good." I asked what was up and was told the doctor would see me.

The doctor showed up sometime later. She told me I had a fractured clavicle and likely a torn AC joint. I asked what this meant for my hockey playing days. "You'll be out 6-8 months," she said. "Blehgang?!?" I replied, or something akin to that.

The following day I was able to get to a specialist (again, we're still not at that full-on universal healthcare stage here so getting an appointment is still possible). He went over my x-rays, did a few tests on my shoulder and said that the people at the ER jumped the gun a bit. He said that there is no fracture and that both my joints are intact. "You have a grade-one separation," he said. "Am I out 6-8 months, doc?" I asked, hopeful as ever. "No, probably 2-3 weeks."

At first I was elated, then I thought "2-3 weeks???" and said, "Blehgang?!?" again. It just seemed fitting. He explained that I needed to use the arm and that it's basically going to hurt like hell. He's right about that. It does. Fortunately, I have little happy pills to help with the pain. Unfortunately, I don't like taking meds so I'm avoiding them as much as possible.

So now I'm doing stretches and such in order to work myself back to being able to play again in the next 3 weeks.

I'm just glad I'm able to type fully again.

End of the line redone

I redid all of "End of the Line" over the weekend using the GS-10. It just sounds 100x better this way than using the VG-99. Everything is crisp and has no digital feel to it. Sustain is also a lot better. I don't know why that is, but it is!

This was liberating since I was able to pull back from using 10's on the high E. Why does that matter? Because 10's rip my fingers up. I used them because of the GK-3 pickup. Now that I have removed the GK-3 pickup from my main ax and put it instead on my secondary, my main ax is back to using 9's. They feel like butter.

I was so stoked about the new sound that I also went back and sang the song over again too. There was more punch to the vocals this time around, so that will help.

Now the song is off to Ron for adding in drums and percussion, and then for mixing.

...off to re-recording "Wielder of the Blade" this week.

AS3 memory management part II

I went through and did the plan from my previous AS3 memory management post and things are looking better. By just allocating things one time at the beginning of the game and pushing them to the display list once as well, I'm now at about 1/2 the amount of memory hogged by the time I reach level 20 of the game.

This should be sufficient to solve the problem of game slowdowns.

At this point I could pull all of the frames and such from the game, but I don't think I'm going to do that. If a person runs back and forth in the menu and such 100x, it'll likely bump up the memory usage a bit but not nearly as badly as the game frame is and it's frankly an edge-case anyway.

The bottom line is that if you're coding up a game or application that has a number of levels to it, and is full of tons of graphical elements and such, you'll probably want to:

• Do all of your allocation at the start of your game
• Use addChild(...) as you allocate and then just write a little function that "hides" your graphics by altering their x and y to be something like: -999,-999
• Show your graphics by setting the new x and y to wherever they should actually be
• Make sure you don't undercut the number of graphics you'll need when doing your initial allocation

Now before anyone gets all fired up about the use of globals here. You don't have to use globals. You can create a class that handles all this stuff and encapsulates things neatly. It'll add a little overhead doing this, but for purists it should work fine. For everyone else, globals are not as neat and tidy, no, but they do give that feeling of old-skool hack development. :)

AS3 memory management

...is a pain in the butt.

I've known for years that the AS3 GC (Garbage Collector) runs through and cleans junk up when it is ready to, but this is somewhat crazy.

Let's say you have a Sprite all set up called "Ship", and you blow it up on the screen and then want to remove the ship.

// remove the child from the display list...I'm using GameElements here
// could just as easily be the root
GameElements.removeChild(ship);

// and set the actual ship var to null
ship = null;

Now, the ship should be deleted and done, right? Wouldn't that be super? Turns out that you can no longer reference the ship, but Flash still has it sitting around in memory until it decides the time is right to remove it. This could take seconds or hours (or it may never remove it).

The problem gets worse if you use the Flash frames, apparently. (I'm kind of guessing on this one). If you use Flash frames, everything you have populated onto the frame is going to be allocated. So any images, text-fields, etc. Now, when you're done with that frame and move onto the next--assuming you have set everything on the previous frame to null--it should all disappear. Visually, it does, but just like the aforementioned "ship", all the elements are still in memory until the Flash GC nukes them.

So, now, imagine this:

Frame 1: Splash screen
Frame 2: Game Screen
Frame 3: Level Complete screen
Frame 4: Game Over Screen

The game starts and we show Frame 1 for a couple of seconds and then jump over to Frame 2. Frame 2 starts up your game with all its nifty little sprites and such. You play through the level and win (yay!). Now the game moves on to Frame 3 to show you how you did, and asks you if you're ready for the next level. Stop...

1 - Show Frame 1 (Splash)

2 - Show Frame 2 (Game)

3 - Remove elements from Frame 2

4 - Show Frame 3 (Level Complete)

5 - Remove elements from Frame 3

6 - Go back to item #2 in this list

See a problem here? All of the elements in Frame 2 are still sitting in memory (unless Flash's GC cleaned them up...highly unlikely), and then Frame 3's are as well. We could be 20 levels into a game and ALL of the prior data is still sitting in memory. UGH!

And this doesn't even touch the fact that if you have any event listeners tied to these items they'll keep firing until the GC deletes them. Even if you remove the even listener, the reference will stay there unless you set the useWeakReference to true.

When creating an event listener, instead of:

SayAgainButton.addEventListener(MouseEvent.CLICK,SayAgain);

Use:

SayAgainButton.addEventListener(MouseEvent.CLICK,SayAgain, false, 0, true);

Again, it'll still hang out until the GC picks it up, but at least it *will* pick it up eventually.

Until then, guess what happens? Yep, all the stuff you created from levels 1-19 will still be in memory firing until the GC snags it. Why? I honestly don't know. It seems rather silly to me.

Oh, one more thing to note: Even if you create a symbol that has a bunch of frames sitting inside of it, and you're using gotoAndStop(...) or next() to pulse through, etc., you'll see your memory go up. This is because it's not until you actual hit a particular frame that the frame is loaded. This is actually understandable and fine, but it is something to note as you're doing stuff so you don't pull you hair out.

So what is there to do?

Well, that's the $1M question. What I'm going to *try*, is the following:

1 - Remove the whole frame concept entirely.

2 - Create all my assets at the start of the project

3 - Instead of removing them from the child list and nulling them, I'm going to create a little (throw me off the screen) function that effectively does the same thing, but only retains ONE element in memory through the life of the game, no hundreds. I'll just stick the items at -999,-999 or something.

4 - I already reuse the majority of my elements in arrays, but it seems the child list is a part of the problem (at least from my testing). So I want to have a fixed set of addChild calls instead of numerous ones. Again, this is accomplished by creating the elements at the start of the game and reusing them throughout.

Will this solve the problem? That's the question I hope to answer tomorrow.

Coding

I had a little fun working up a Flash system that snagged and XML file and an .MP3 file, mushed about inside of them and churns out a little soundtrack with text running along at the same time.

Unfortunately, I have no way of getting the XML to be smart enough to load up everything on the .MP3's timing. This just means that I have to use a tool (I use Audacity) to find the start points of each each text portion and tell the XML file where those are.

The tricky bit is that Flash doesn't have a way to reset its start timer. Not a huge deal, but doing the pause and resume stuff gets a little wacky while trying to keep tabs on the location on the .MP3 and the story itself.

The trick is to make sure to have a timer offset that you set when the story actually starts. And you set your start time to zero. Now you can compare safely, like:


timeElapsed = (timeElapsed + (getTimer() - timeOffset)) / 1000;
if (timeElapsed > storyTime)
{
....
}


When you pause, make sure to set a time paused variable using the getTimer(), and also pause the .MP3 and get its current position.


soundPausePoint = storySoundChannel.position;
storySoundChannel.stop();
timePaused = getTimer();


Then when you're ready to resume, you'll have all the junk you need to set your timers and your .MP3 start point accordingly.


storySoundChannel = storySound.play(soundPausePoint);
timeOffset = getTimer() + (timeOffset - timePaused);


Nifty, no?

Re-recording with GS-10

Well, I re-recorded all the distorted guitars on Aeserian using the GS-10 instead of the VG-99. It sounds loads better in my opinion, so I'm glad I figured that out now instead of during the mixing phase. The sad news is that now I have to go through and re-record all the guitar bits for all the songs I've already done. Hopefully this won't take all that long. I have to redo the following tunes:

1. End of the Line
2. Mirnrith
3. Wall
4. Sings to You (Whisper)
5. The Wielder of the Blade
6. Sai

I still have to record the rest of the songs, so I'm glad I caught this now. At least I don't have to redo all of them!

It wouldn't be so bad if it was just the rhythm parts, but I'm not to just use a single guitar in my stuff. I think Wielder alone has like 15 different guitar bits throughout. On the plus side, I've been playing these songs for years so I know them like the back of my hand. With any luck, it'll go pretty quickly. We shall see!

Kreth'x

What's a Kreth'x, you ask? Why it is a sword, of course! It's a sentient sword at that. It is the sword used by the main character in "The Wielder of the Blade" book based in the land of Phylean. The main character's name, if you're wondering, is Rais'Alon.

Kreth'x is also the name of the "band" (consisting of myself and Ron Burgoyne, so it's more of a duo than a band, but "duo" just doesn't have that awe-inspiring umph that "band" does) that is creating the heavy metal album "The Wielder of the Blade", which, if you're still following along, is a concept album based upon the book.

The domain for Kreth'x is already reserved, but I've not done anything with it yet because I'm still awaiting some images. Hopefully we'll have something to show in the next few weeks on the actual site. I will, however, try to post a few images and such here as they become available.

Roland VG-99 vs. Boss GS-10

I have both the Roland VG-99 and the Boss GS-10 and both are pretty nifty, but I'm finding that I really need both to feel comfy recording.

The VG-99 is a crazy unit that has all sorts of bells and whistles, especially if you use the GK-3 pickup (which I do). With this system, I'm able to play all sorts of sounds and even control midi-devices and record into Sonar the midi notes I'm playing on the guitar. This works because the GK-3 pickup has per-string pickups instead of the standard guitar one pickup model. I can essentially make my standard 6-string electric sound like anything: a flute, a 12-string guitar, a mandolin, violins, drums, a bass, etc.

The latency is a bit problematic when trying to control midi-devices, but it's not awful for recording the midi notes. The trick here is to have the midi notes recording while you're listening to a normal sound from the VG-99. Then you can manually tweak the midi notes and assign them to the instrument of choice. So you record using a standard guitar sound, but when you have Sonar (or you recording system of choice) play back the midi, it can sound like anything your midi-device supports. This is great if you're not a keyboardist but still want those keyboard sounds. Plus, using this method you can alter the notes by hand for when your timing or note placement is off a bit.

So what's the problem with the VG-99? Sadly, there are a few.

1. The pickup installation messes with your guitar's action. This is particularly bad if you're using heavier gauge strings. There is the slightest (barely noticeable) delay from when the string is plucked to when the sound emerges. It's so slight that the only person that will notice is the person playing 100mph. Slower players may not notice it at all.

2. When you play fast stuff, it starts to sound a bit digital. It's as if there are little wav files there just playing over themselves. It gets choppy.

3. Anytime I hit the D note (or chord), the guitar loses the proper stereo sound and hits full center. It only happens on D when the guitar is distorted.

4. The distortions sound iffy. There's just no really kerboom to them, if you know what I mean.

And this is why I hang onto the Boss GS-10. The Boss distortions are awesome. I get all the aforementioned kerboom out of the GS-10 for distortion and speed junk, and since it has the built-in speakers I can also move it around with me wherever I roam.

So for midi and clean sounds, the VG-99 is a pretty nifty unit. For distortion, I prefer the GS-10 greatly.

You'll get to hear them both on the upcoming "The Wielder of the Blade" album.

Sonar 8.5

In preparation for getting back on track with "The Wielder of the Blade" album, I upgraded from Sonar 7 to 8.5. So far I rather like it.

They changed the default menus and layout a little bit in the new version. It works better for me now that I'm getting used to it.

One of the nicer things is that the audio engine is more responsive. It's smoother. I haven't had any audio dropouts since the upgrade and I was getting them at least once per recording session before. I'm in the process of saving up for a new machine, which will make this puppy really purr (or, is that kitty?). For now, though, it's performing quite well on my elderly clunker.

The new vocal strip is going to be quite helpful in making my singing sound good...erm, less bad. It has a lot of nifty little features and presets. I can see that there will be a bit of a learning curve on it, but it promises to be worthwhile.

I plan on getting after more of the recording facets this weekend, so I'm certain problems will turn up. But my initial reaction is that Sonar 8.5 has potential.

BlitzCoder / Blitz Basic

Old BlitzCoder Tutorials are up - I've recently received a bunch of requests for my old Blitz Basic tutorials (from the BlitzCoder era). Fortunately, Charles 'Specis' McCrimmon retains a copy of everything known to man. So he packaged it all up and sent them over. I got everything working today so anyone who's interested can check out the old tutorials and grab the old source code.

NOTE: I'm not supporting this stuff anymore, but if you're interested: BlitzCoder Tutorials

The Big Move

I decided to move Krylar's Kreations over to the blogging format because I was tired of looking at the static page of my website. My hope is that this way I'll be able to write stuff more often in order to keep the content fresh.

For now, though, I've still got some integration work to do. So...more later!