Film Leaders FTW!

I love leaders. I've made a number of them in After Effects and add them to all my projects whenever I can. They're both useful and awesome. You can cram a ton of information in them, like producer, aspect ratio, title, director, actors names, legal stuff. It's like the fine print. The circle around the numbers also helps make sure the aspect ratio is correct, and the tone should be a perfect 1kHz tone on the 2 (this one is .88kHz) to help make sure frame rate and audio sync are correct.

I don't care much for standardizing leaders, especially with the way video is in today's world. If there is to be any standardization, it should be on what information should be contained within a leader. I think that 4 seconds of assurance that the film is being displayed properly is good, and that it's always good to hide some secret proof that it's your movie.

Is HTML5 the end of Adobe Flash?

There has been a lot of talk about HTML5 being the end of Adobe Flash and Microsoft Silverlight.

What do I have to say about it? I think that Adobe Flash is here to stay. Silverlight might have to go, though...

Why? Well, Flash is easier to develop with. HTML5 might be more dynamic, but it's still controlled with things like JavaScript. As a developer, I can say that I prefer working with Flash over other alternatives, like this newfangled HTML5 stuff. Personally, I've never tried to work with HTML5, but it looks like it's a bit of a mess.

The best part about Flash? When you're done with a project, it gets exported into one simple little .swf file. (There are exceptions to this rule, but any developer who ends up with more than a single file probably knows what they're doing.) Distributing HTML5 applications will be harder to do. I'm thinking of websites like Newgrounds or Armor Games. They work because .swf files are embeddable. Embedding HTML is hard to do without server-side scripting.

And all this complaining about open specifications. Who cares? Adobe's making money doing something they're good at, and I respect that. Besides, Adobe makes professional software. Let's say that word again: pro·fes·sion·al. That means that their software is intended for use by professionals. Obviously, this doesn't usually end up being the case, but it explains the huge price tag. Straight from the horse's mouth, the entire production of Avatar was accompanied by Adobe software (but they still used Media Composer for editing which proves its ubiquitousness.) Besides, kids don't have much use for software like Illustrator or InDesign, anyway.

All in all, Flash and HTML5 both have their pros and cons. For websites like lala and YouTube, HTML5 might be the better choice. But for gaming and animation (which is a huge function of Flash), Adobe's still the way to go.

But Silverlight really needs to go away. Microsoft's wasting its time filling a niche which Adobe has taken care of already.

Functions are not the devil

Hypothetical: your initialization function is a huge mess. It's probably 200 lines all by itself.

What do you do? Break it up into functions. Functions are not the devil.

That's right, you can make all of your messy initialization functions into clean little bits of comprehensible code with this amazing programming feature called Functions!!!

Turn your initialization function into something like this:

function Init()
{
  g.log.Add (1, "Initializing level "+g.level+"...");
   
  // making the level
  level = lm.LevelFor(g.level);
  PopulateLevel (g);
   
  // the player
  InitPlayer (g);
   
  // display initialization
  InitRadar (g);
  InitDisplay (g);
   
  // stamping the level stats
  StampStats (g);
}

With the magic of the almighty Function!!!

In all seriousness, the programming world has functions for a reason. I'm not trying to criticize the lack of functions in code. I'm simply trying to help people realize that having a thousand short little functions is a lot better than having twenty monolithic functions.

But you had better have some sort of function naming scheme in mind or things can get very hairy very fast.

Comments... really?

Why in the heck do people feel the need to write a novel about their code in the comments? I understand comments are good programming practice. I use comments all the time to make notes to myself about things in the code which may not be apparent at first, such as the purpose of a variable, or why a line of code is commented.

But I see this kind of thing in code and it annoys me:

// increment the 'counter' variable
counter++;

If you don't know what counter++ does, you should not be programming, and therefore should not be reading those comments.

So stop it with the novels, already. Chances are most programming projects can boast a bazillion lines of code because most of them are comments:

/**
 * incrementCounter
 *
 * this function is very important to the program
 * flow. without this function, the program would
 * not be able to operate correctly
 *
 * usually, this function is called by mainLoop
 * once every frame, but exceptions are made. this
 * function should never be used anywhere outside
 * of mainLoop, or the program flow could potentially
 * be thrown out of whack
 *
 * this function is a simple wrapper for the
 * 'counter++' operation and nothing more. however,
 * it will stick around because you never can know
 * when you need this function to do something
 * else
 **/
void incrementCounter (game_t *game)
{
  // increment the 'counter' variable of the supplied
  // game argument
  (game->counter)++;
}

Seriously, dude, couldn't you have done something a little less superfluous? Like this:

/**
 * incrementCounter
 * do NOT call this outside of
 * mainLoop, or risk screwing up
 * program flow
 **/
void incrementCounter (game_t *game)
{
  (game->counter)++;
}

Programmers are not morons, so stop treating them as such. We understand that functions are created to logically group special operations which may need to be repeatedly called or organized properly.

Of course, I'm making these examples up. I'm too lazy to try and find a real example, but this kind of thing is everywhere in Java.

What do I want you to walk away with? This is what I want you to get out of this post: comments are not for novels.

xkcd... really?

I hate xkcd, but not because of its humor (which I don't mind.) I hate xkcd because of its fandom, mostly the high school fanboys.

I hate the fanboys. They're always where you expect them: in YouTube comment threads, on Newgrounds, etc. And what's more, they smugly quote xkcd, acting like they're engineers or something for knowing what a furry is. Their logic goes something like this: "Randy's an engineer. Randy knows what a furry is. I know what a furry is. I must be an engineer."

So to clarify:





And while I'm hating on xkcd, I'd just like to say I hate extreme fans of pretty much everything. The other day I was looking around on the net for LCARS stuff (I love the way LCARS looks) and I stumbled across a little thread of some sort. Naturally, it was full of Trekkies. Part of the exchange went something like this:

A Fan: Better set the fazers to stun!
Fan who Knows Stuff: Actually, it's phasers.
Trekkie (not Trekker): haha, pwned!

Yeah, nothing's more important than knowing the correct spelling of "phasers." Fans can be so retarded sometimes!

Okay, I'm done now :)

</soapbox>

AS3 Dynamic Construction

This is a little ActionScript 3.0 programming gem I discovered ON MY OWN without Google's help...

Check out the following code:

class Animal
{
    function Animal()
    {
        trace ("Animal has been created");
    }
}

class Dog extends Animal
{
    function Dog()
    {
        trace ("Dog has been created. Woof!");
    }
}

var notADogType:Animal = new Dog(); // outputs "Dog has been created. Woof!"
var doggie:Dog = new (Object(notADogType).constructor)() // outputs "Dog has been created. Woof!"

That's all fine and dandy, but give this a whirl:

var puppy:Animal = new Dog(); // outputs "Dog has been created. Woof"
var noType:* = puppy;

var newDog:Dog = new (Object(noType).constructor)() // outputs "Dog has been created. Woof!"

This is really useful to put in a superclass of something to return a new one of that type. Take this for example:

class Thing
{
    function newOne():Thing
    {
        return new (Object(this).constructor)();
    }

    function overrideMe()
    {
        trace ("I'm just a thing");
    }
}

class Car
{
    override function overrideMe()
    {
        trace ("I'm a car. Vroooom!");
    }
}

var volvo:Thing = new Car();
volvo.overrideMe(); // outputs "I'm a car. Vroooom!"

var justAThing:Thing = volvo.newOne();
justAThing.overrideMe(); // outputs "I'm a car. Vroooom!"

This proved to be very helpful in my latest game.

Note: there are inaccuracies in the code, such as: you can't put the code in a frame and expect it to work. Also, when a subclass is constructed, its superclass's constructor is called as well. But the general concept still works.

Basically, regardless of the type of someInstance, Object(someInstance).constructor points to the class used to construct someInstance. You can use that exactly like it's a normal class, but don't forget to put parentheses around Object(someInstance).constructor. Wanna typecast? (Object(someInstance).constructor)(otherObject). Create a new one new (Object(someInstance).constructor)().

I can't believe this isn't documented very well...

Night of '10 Jan 2 - Driving and School

Last night I had this dream...

It started out with me deciding I was going to drive to somewhere north of Phoenix. I think it was Flagstaff. So I got in my car and began driving. Dream driving for me was never really good. I always seem to go 150 miles per hour, and swerve in and out of traffic, even the oncoming traffic.

But I decided it was time to stop. I don't remember why. I think there might have been something wrong with my car. Anyway, I ran into someone named "Buffy the Vampire Slayer." I've only read about the show briefly on tvtropes, so I have no idea if Buffy is the main character, or what she looks like. But she was there.

Anyway, Flagstaff was off the list...

Then there was this weird dream transition, where it's foggy and you're not sure what happened, but there was some huge shift in continuity.

But suddenly, I was at school, the first day of the second semester. And my physics class was canceled. I'm all for physics, but I have a lot of friends in that class, and only that class. So I was distraught, naturally. We were going to go to Six Flags this semester, too!

Why was the class canceled? The teacher was fired. Actually, all of the teachers were fired. The superintendent didn't really like the way the teachers were teaching. So, she called together all of the students to a big assembly, and taught us herself, schoolhouse style. Most of it was stuff I already knew, so me and my friends ditched.

Then I woke up.

How I Code

Most of my coding is games made in Adobe Flash CS3. When I code a game in Flash, I code in 3 different phases, named—get this—phases 1, 2, and 3.

Phase 1 is getting the game to a playable state. I just need SOMETHING to build off of. This is like that first little chunk of a rubberband ball. That chunk is always the hardest. You can't just put the project down in the middle of phase 1. If I do that and try to come back to it later, I forget where I was. Running the program is no help because, well, there's no program to run. Phase 1 is the longest and hardest. This is where all the core code comes from.

I was never a fan of todo lists. I usually have them, but they're very, very, very vague, and usually on paper. I've never gotten through phase 1 without some sort of todo list, so I'm warming up to them now. Because phase 1 is the writing of all the core code, it only makes sense that todo lists would be advisable.

After I've finished phase 1, i.e. have a playable something, I begin phase 2. Phase 2 is probably the easiest one. Now that the first chunk of working code is written, I can toy with it, add stuff to it, take stuff from it, and still have playable code to test out. This is the most creative phase. Features are being added, removed, and tweaked constantly. Art is not a concern here. Art is usually no more than graphic primitives (yay Polystar tool!) which I OCCASIONALLY fill with gradients.

Once I have a game that I am happy with, I put the finishing touches on it with phase 3. Phase 3 is menus, a preloader, and—most importantly—art. This is where the game is polished off for publication.

Of course, the products of these phases are not mutually exclusive. The core code gets changed a lot during phase 2, and quite possibly even phase 3 (it's been known to happen). Phase 2 code changes a lot during phase 3, too.

That's how I code. It took me 7 years to figure that out :(