Perl is an extremely useful and flexible language. It’s almost like a programming Play-doh. At the same time it can be stable and used to hook programs together. In that sense it’s like glue. I’ve gotten to work in the language for the last 5-6 months and I have really come to appreciate it. So, I’ll go into specifics of why I like it and when it’s been useful.
This week I wasn’t able to get anything done at home because I was working a fair amount of overtime, so I figured why not write about it. Overtime is something that most of the game industry tries to avoid, and all too often can’t help. Every project I’ve been on has had some amount of it, be it a few nights or a few nights every month. Some projects at the studio have had an almost constant crunch, but I was fortunate enough to either come after them or not be chosen for them.
Learning algorithms for quickly finding primes and testing whether a number is prime will greatly enhance your ability to solve project Euler problems. Since it’s key to so many problems I’ll link to some resources I used, and try to paraphrase what I’ve learned, linking to each concept. The links are necessary since you’ll get a pretty incomplete picture from me, but it’s a place to start.
Continuing my kick on optimization I found a piece of code that was responsible for second long delays. It seemed simple at first. So I profiled and found one part of a loop was slow. Dug further and found the next was slow then the next, until I hit the bottom and found a binary search algorithm. It was implemented as a recursive call and so I thought I may gain by removing the recursion.
I had been reading recently about an optimization that I wanted to try, eliminating branches. This seemed counter-intuitive to me at first. Branching seemed like it would eliminate useless code and save time, but as it turns out it can actually be detrimental. The CPU preloads instructions, but when its going to branch it can’t know what to grab. So instead of stopping it makes a guess as to the result of the branch based on a branch history table and grabs those instructions. When this guess is wrong the CPU has to unload the instructions it had guessed it needed and grab the ones it actually needs. This slows things down. There are tools to detect this, including ones from Intel and assembly instructions to get CPU stats.
While looking through our code base’s actionscript interpreter for a bug, I realized there were several language features not in use, and optimizations I could make to my scripts. As I got side tracked from the bug and started looking more at the surrounding code, it started to all make sense. I was getting a better vibe for the paradigms and structure that the interpreter would flow best through. Better understanding what the language was all about.
I’ve started reading Code Complete and have realized that the part about using a top down approach and bottom up approach together to architect a system is perfectly right. I noticed this is how I finally managed to come up with a solution to a personal project problem.
In light of hard times in the industry and having to say goodbye to large groups I’m contemplating the fluidity in the game industry. Does it still exist? How reduced has it become? I remember hearing stories about people jumping around studios like they were looking for the perfect pair of shoes, now people are on edge. The firings have slowed in the news but companies are still tightening belts, still solidifying their core teams and products. The ones that will make them the money to become adventurous again. At the same time there are so many small companies that I read about. Sub five person teams turning out gold. Not sure if its fool’s gold or not as I don’t know if they make money.
So after looking at thoughts on Demon’s Souls I started thinking about difficulty in gaming. The majority of people who play it say it’s hard but still really good. The people who haven’t played it take that as a negative thing. The assumption has become that a game that is described as hard, is so because it’s frustrating and thus can’t be fun. That’s simply not the case with a well designed game. To see why we need to analyze what makes a game fun.
Message from 3 years in the future. This is being posted retroactively and pulled over from my old Blogger account. I thought it was still interesting, so enjoy.