Monday 27 October 2014

I Got Very Distracted There

This last week I've been spending all the free time I could find coding something I've meant to make for a long time - a reimagining of the classic MMO Progress Quest. Progress Quest is the original idle game, predating Candy Box and Cookie Clicker by more than a decade. But Progress Quest was truly an idle game. There was no way to interact with it once you selected your name, race and class and rolled your stats.

The choices you made didn't matter except for an oversight that made it ideal to have your strength be as high as possible and all other stats be as low as possible. Your character fought monsters, completed quests, progressed through the story, and got new equipment, all without you clicking a thing.

For a long time I thought about making a Progress-Quest like game, and now in the age of idle games, the time has finally come. I've started making a lot of idle games in the past, this is probably the farthest I've gotten on one. I'm hitting the wall now in that I'm really not sure what the mid-game should look like, so this one might be headed for the heap soon too, but maybe not because what I've got so far is actually pretty neat. All that practice coding javascript has really paid off.

What I really want to brag about is an incredibly dumb thing that will, I'm fair sure, cause most of the population to say, "What does that mean?" or "Why does that matter?" and will cause the vast majority of people who understand what I'm talking about to say, "Yes, of course that's how you do it." But I felt good that I thought it up anyway.

Something that always bothered me about the code for Cookie Clicker was a section where it checks whether you've gotten certain achievements. Essentially, it looks like this:

if (count>100) award_achievement(1);
if (count>10000) award_achievement(2);
if (count>1000000) award_achievement(3);

And so on. Every time I look at that I just don't like how even after you've got achievement one, every time it goes through that code it checks if you should get it, then if you should it calls the function which checks if you already have it and then returns nothing. Now evaluating if statements shouldn't be taxing the processor cycles of a contemporary computer, but I just don't like the fact that its doing it. It's more about aesthetics than about the actual wasted effort.

The solution to this problem was way too obvious for it to have taken me so long to think of. Each talent in my game has a lock function. All of those functions are added to an object. When it comes time to check if talents should be unlocked, it runs through all the properties of the object and executes each function. If the function returns true then it both unlocks the talent and removes that function from the object so it is never checked again.

Depending on how javascript works this might be a straight-up worse solution than the put-it-all-in-a-list way. After all, I have no idea how hard it is for javascript to go through the properties of an object in a for-in loop.

But of course my way has another advantage. The check to see whether to unlock each talent is with that talent in the code, so if I want to change it I know where to look and I don't have to go to more than one place to cover different cases.

So I'm happy I did it. And I'm happy to report to you, my readers, that I definitely have some code written and there is really a possibility I will not leave it to rot.

No comments:

Post a Comment