Simple Easing

I found a really nice system for easing values over time. I haven't come up with a name for it, though. There's only one catch: in its current state, it only works over fixed time intervals. But there's probably a really simple fix for that.

In a normal code scenario (I'm going to use C) you declare a variable like this:

int variable;

Now, to use this now special "easing" system of variable change, you simply add two more variables to your declaration. The declaration now looks like this:

int variable;
int variableWant;
const int VARIABLE_SPEED = 3;

The first one is the original variable, which I'll call the "actual" value. The second one is the "want" variable, and the third is the "speed" variable. The "want" value is the one you will be changing, while the "actual" value is the one you'll be reading. "Want" is kinda like the "set" variable, while "actual" is the "get" variable. You can use any naming scheme for these variables, but those are the ones I use.

To make this work, you add the following code (which corresponds to the naming scheme above) to a regular-interval function:

variable = (variable * (VARIABLE_SPEED - 1) + variableWant) / VARIABLE_SPEED;

This may look complicated at first, but it's actually really simple. It calculates a new "actual" value based on the "actual" and "want" values by averaging them with specific weight on "actual." If you remember anything about averaging (which you should) you should remember that the last step is to divide by the number of added terms. Well, if you look above, there are (VARIABLE_SPEED - 1) "actual" terms, while there is 1 "want" term. This means that the total number of terms is (VARIABLE_SPEED - 1) + 1, or simply VARIABLE_SPEED, which is what we divide by.

The last variable which hasn't gotten enough attention is VARIABLE_SPEED. This variable's function is simple: it determines the rate at which the ease takes place. If this value is 1, the ease will happen instantly. If the value is 3, the ease will happen rather slow. For a value of 100, you'll be waiting a while.

The only issue with this method of variable change over time is that, theoretically, for values of VARIABLE_SPEED greater than 1, the "actual" value never actually becomes the "want" value. Adding this functionality simply means adding an if statement that sets the "actual" to the "want" for differences less than some constant.

C struct Inheritance

Inheritance is generally thought of as belonging to object oriented programming languages like C++ and Python, but it can actually work with procedural languages like C.

In C, there is a data type called the struct, which is basically a collection of various types.

A struct typedef like this:

typedef struct 
{
    int val1;
    char *name;
} super_t;

can be "sub-structed" by another struct typedef like this:

typedef struct
{
    super_t sup; // this HAS to go at the beginning of the struct
    char otherval;
} sub_t;

With the types set up like this, if a pointer to a variable of type sub_t is casted to a pointer to super_t, then the attributes of super_t can be accessed like normal.

The only problem is that a sub_t instance needs to get the values of its superclass through the sup variable.

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.

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

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 :(