Object Oriented Code Is Not Smaller In Size

I have a new version of Island Interloper up.  Dunno if it is an upgrade or downgrade from the last time I uploaded it.

It has still not reached feature parity with the previous attempt, but one can buy and sell commodities at different islands.

Really there are only three minor features to add back before parity is achieved.

One is the ability to “take note” of prices at various islands.

Two is the save and load feature, which really isn’t much of a feature at all, as it just dumps a string to a textarea.

Third is the feature that actually consumes resources as the sailing voyage goes on.  It is a key feature that adds the element of anxiety over limited resources.  It gets you asking if you have enough food to make it to the next island. It is very “Oregon Trail”-esque.

(Maybe I should add the ability to fish….)


If you want evidence that OO code is larger than equivalent non-OO code (and the previous version was not completely non-OO, it was part-OO), you need look no farther than the code for Island Interloper.

Previous version (not counting third party code used unmodified as libraries): 37.0 K

Current version(again not counting third party, and haven’t achieved feature parity yet): 46.1 K

No, it isn’t a huge difference, but it is over 20% bigger at this point.

Of course, my software size is measured in K, not M or G.  In JavaScript, code size is the same as software size.

Why more code?

Because the code is better organized.


Imagine this:

Your game has a number of different things to deal with that make up the game state.  In Island Interloper, these things to deal with are primarily the avatar and the islands, at least at the moment.

In the old code, the avatar was part of the game object, and was accessed using some code like:


One of the properties was called “heading”, which stored an angle in which the avatar’s ship was going.

It was stored in:


As you can see, this is not entirely OO, but not entirely not either.  There is no encapsulation.  It is simply a raw global variable for all to see.

In the new code, there is still a game object passed just about everywhere, and within it there is an avatar object, but now the avatar is an object of a class called AvatarObject.

And while “heading” is still a variable within the AvatarObject, there are also two accessor functions: getHeading and setHeading.

And of course, the avatar property of the game is accessed through a function called getAvatar, so to get the heading of the avatar, we go from:




Which is already longer, and so that is where the extra size comes from.


There is a company called InnoGames.  They are German. If you have been on Facebook, they had a massive advertising campaign for their game Grepolis.

I tried out Grepolis, and their other strategy game Tribal Wars.

I didn’t much care for either of them.


I also tried out their OTHER other game, The West.

It turns out to be an ideal fusion of “Errand Boy”, “Sporadic Play”, “Base Building”, and so on that I’ve found.

Takes about 5 minutes twice a day to play.  I queue up about 6 hours worth of activities for my character to do, and it calmly ticks down the timer for the character to do them.

Unlike many of the other strategic browser based MMOs I’ve played (lots of Storm8 games), the games purpose is not (as yet) easily thwarted by something like investing in passive income sources. Instead, there seems to be a pretty progressive series of errand boy missions, plus adding in contributing to building the town one belongs to.

And it accepts mailinator.com email addresses.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s