Followers

Monday, December 1, 2008

Keeping it Real, man....

Hello again everyone. Well, now that I have had some sleep, not to mention a little break during Thanksgiving, I thought I'd talk about what has been going on since the Great Crunch.

The last project that I worked on was a sequel to an existing franchise. As much as possible, I'd like to be open and honest in this blog to give everyone an idea about what it is like working in the game industry, so I'd like to talk about the ups and down we had developing this sequel.

Being a sequel, this new game had many features in common with its predecessor. We were able to use a lot of the same code, and even some of the same assets (e.g. art, effects, user interface screens). In fact, one reviewer suggested that too much of the content was simply copied from the previous game. Although everyone is entitled to his or her opinion, I can tell you that nothing is further from the truth.

Feature Re-Use

When you have a game that has a large following, it is expected that the sequel will have some continuity. Therefore, you don't want to make the sequel entirely different from the original. With this sequel, we decided to keep the basic mechanics of how you shoot and match balls in place because this is what players have grown to love. On the other hand, we also added some radical new features including a progression map, a deep story, and voice-overs, which had never been done. Although this might sound like "fluff", it took a great deal of work and a great deal of programming to pull it off. Even then, we weren't sure if players would like the new direction we had taken things. Although we have received comments from both those who did and did not like the new features, overall the response has been positive. Should we do another sequel, the challenge would be to once again provide a little bit of the new with a little bit of the old in a way that satisfies veteran players and entices new players.

Code Re-Use

Sure, a lot of the code was re-used from the previous game. But that is more a testament to good design than anything. In many cases there is no reason to re-invent the wheel when you are doing a sequel. However, it is very rare, indeed, that code can be simply recycled and used without modifications. I would estimate that 70% of the existing code had to be modified, and another 50% of code was added completely from scratch to incorporate new features.

For example, we wanted a new mode where two chains of balls could approach each other face to face. We also wanted a computerized AI opponent in this level. Neither of these ideas had ever been incorporated into the previous games. Creating the ability to have a computerized opponent meant writing completely new code as well as modifying almost every piece of existing code to allow for this new possibility. In the end, we only used the AI in a single mode, but the code will now allow an AI to be added to any level.

To allow for two opposing trains, the entire class (a class is a group of related code) that handled train movement had to be completely re-written. This re-write impacted all levels, even if they didn't use opposing trains, because all levels share the same core code for managing the balls, collisions, matches, etc. During the re-write, new bugs where introduced that impacted every level of the game (not just the new levels). For a while the balls would spin off wildly and go the opposite direction off the screen! Not only did the bugs have to get fixed, but all of the interactions had to work exactly as players would expect them to work. I spent many long nights perfecting that particular piece of code.

Asset Re-Use

At first glance, it might appear that portions of this game are re-used directly from the previous version. If you look closer, you will discover that this is rarely the case. For example, all of the balls were re-designed. All of the background art is completely original. The only thing I can think of off the top of my head that was not re-designed is the actual shooter. We had plans to change this but simply ran out of time. Some effects (such as coins falling) were also re-used, but most effects were revamped as well.

Although putting out a sequel can be slightly easier than creating a game from scratch, it isn't as easy as some people may think. We spent just as much time developing the sequel as we did creating its predecessor, if not more.

Well, that's it for this post. I'll try to post more often now that I have time. In this blog I have mostly focused on things that went right with the game. Next time I'll talk more about what went wrong!

Till then. Keep gaming (and/or programming if that's ur thing).

Robert

Wednesday, October 29, 2008

It's been a while...

...since I wrote in my blog. That's because I just crawled out of the long, deep, dark black-hole called crunch.

Unfortunately, crunch is still a reality in the game industry. While many people decry crunch as a moral outrage, the truth is this:

Crunch Happens.

I'm not kidding when I say that I have spent the last 90 days working 12 to 16 hours a day, 7 days a week. Well, I did take a long weekend at the beginning of September. Anyway, I have been working A LOT and I'm proud to say the my first game as a lead programmer was launched on time and will be ready for you in store shelves before Christmas.

Whether you are in the game industry or just hear about the game industry, you hear a lot about the C word (no, not Christmas!)

Some romanticize it: late nights with pizza and other food items littering the desks. Sleeping in the couch. Days between showers. You get the idea. Loss of vision. Partial insanity.

Others scorn crunch. They decry the lack of overtime paid, the way it takes them away from their family. The pizza.

I don't complain about crunch (nor do I complain about people who complain about crunch). The truth is, I'm a natural cruncher. Before I came to the game industry, I worked 12 hour days all the time running my own business. The difference now is that I get to do something really fun and I'm relatively sure I'm actually going to get paid for it.

It is also true that my wife still lives in Colorado (she hasn't been able to move to Dallas, yet) and so I have no family here and nothing better to do.

I'm also a newbie to the game industry, so I think I would have been disappointed if my first game went out with no crunch time. I guess that makes me a romantic.

I applaud the efforts of those who work hard to try to raise the quality of life in the game industry. I understand that it is harder on those who do have spouses and children they'd like to see occasionally. But I don't think crunch will ever go away. Because crunch is everywhere. Whether you are in the game industry, an application programmer, or a student trying to finish school--at some point you just have to do whatever it takes to get the job done so you can succeed.

That's not just crunch.

That's life.

Robert

Tuesday, July 29, 2008

To Infinity and Beyond

Well, I've been crazy busy these last few weeks! I just spent about 2 week in iterator hell trying to rework some code and I can tell ya I'm not all that fond of the C++ implementation of iterators! It seems like no 2 iterators want to talk to each other.

If you've been reading my blog, then you just about know my life story by now! Thanks for taking the time. On a related not I also wrote an article for GameCareerGuide.com on how I broke into the gaming industry. Take a look at http://gamecareerguide.com/features/578/no_more_it_for_me_how_one_tech_.php. Don't know how long it will be there.

So, now that you know more about me that you ever cared to, how would you like to know about my son, Stephen. He is also a game programmer and know works for Other Ocean Interactive in Charlottetown, PEI, Canada. I won't go into too much detail (he'll be writing his own blog soon, I'm sure), but his tale is interesting as well.

About 5 years ago I remember Stephen coming to me and telling me he wanted to make a living off of video games. He had a magazine article that discussed the three main careers at the time (art, programming, and QA). I thought that was a great idea. As programmer, I knew he would be making a pretty good salary, and it was a perfect match for his love of gaming.

At the time he was still completing high school, so we begain checking into colleges. Previously, Stephen had checked out Full Sail Real World education in Florida because he was interested in their music program (Stephen is a drummer). Now, we started looking into their Game Development program.

Full Sail seemed like the dream school to attend for this field. They offered a Bachelor's degree in 2 years and were totally focused on game development. Of course, the cost is beyond beyond!

I would like to say, for potential students out there, that the jury is still out on degrees from game technical schools. In a way companies are still a little leary of such schools because it it unclear whether the education you receive is on par with a four-year college. Most of the research I have done indicates that a traditional Computer Science degree with some emphasis on game theory is still the baseline requirement.

The one thing schools like Full Sail do offer is that you come out of the program having written at lest a couple of projects. You also come out of a school like Full Sail with a "game career" work ethic, e.g. work until you drop or drop-out!

So we chose Full Sail because I wanted to go into debt for the rest of my life, er, I mean because I thought that it was the best fit for Stephen's goals. Also, I liked the fact that the program resulted in a B.S. Degree, not just a certificate. My advise would be to steer clear of programs that don't offer an actual Bachelor's program In just about every industry, tech school certifications are almost meaningless (but not totally...anything is better than nothing).

Anyway, just before he went to Full Sail, Stephen and I had a chance to go to E3 (what I refer to as "the real" E3). I was mesmerized. I'm not kidding when I say that E3 changed my life! I remember thinking, "I have got to get into this!" An here I am.

One more life lesson. Getting the degree isn't any guarantee of getting a job. Although some people get jobs right out of school, it is more common that it will take some time. It took until April before Stephen found the right match. After many interviews, tests, and "Thank you for your interest" letters, he finally got a job offer. In fact, it was 1 week after I had accepted my job offer. It was a happy day at the Madsen family! (I wonder if there are any other Father/Son game programmers out there?)

If you are trying to break in to the game industry as either a student or otherwise, it will take perseverance, hard work, and a tough skin, but my advice is to keep moving toward the goal!

Where to from here?

So, enough about me already! From here out I'm going to try to write about my experience as a game programmer rather than my experience getting here. Maybe I can share some useful tips and trick along the way. Feel free to come along for the ride. :)

Friday, July 11, 2008

Running The Gauntlet Part 3 - The Interview

I jokingly refer to my on-site interview the "six hours of torture." For six hours I stood at a whiteboard assailed by questions as small teams of programmers threw scenarios at me to solve. Some required actual coding (no IntelliSense on a whiteboard) and others required design. I was told at the beginning that the goal was to test the limits of my knowledge.

We started with the basics: C classes and object, copy constructors and related issues, pointers and dynamic memory. We covered 2D related game math: trigonometry and applications of vectors and matrices. Break. Next we covered inheritance, polymorphism, containers, STL. Lunch. State engines, lerping, timing, quantum physics, the nature of God and the Universe. 42. Break. Why are you here? End.

I believe two strategies are relevant to this type of interview. The first is to apply good problem solving. Even if I didn't know a specific technical demand, I at least tried to analyze the question and form an approach toward the solution. The second strategy is to know what you don't know and ask questions. If I reached a point where I simply didn't know what to do, I said so.

I'm not sure if MumboJumbo's approach is unique, but I definitely agree with it. At each point in the interview, I was told that my problem solving skills where more important than my technical knowledge. Every time I reached a hurdle that I couldn't cross, we worked through that hurdle together. My interview was a two-way process in which information flowed in both directions.

I am happy to report that I have been working at MumboJumbo for almost 3 months now and I am in programming heaven. Someone just asked me the other day if working in the game industry had lived up to my expectations and the answer was a resounding, "Yes!" I may be old, but I'm not too old to have that naïve kind of joy that I am finally doing what I always wanted to do (and getting paid for it!).

I hope my story inspires someone out there who, like me, wants to get into the game industry but feels it might be too late. The game industry is not just for twenty-something year olds just out of college. In fact, the industry is beginning to realize that there are important lessons that can be learned from traditional IT. As an IT professional, you have those skills.

The key to breaking into the game industry is twofold. First, prepare. Looking back, it took me five years of preparation (along with making a living) to come to a point where I was ready and marketable. Second, find the right company. Not every company will appreciate you or overlook your obvious lack of game-centric experience. But the right companies will. And you wouldn't want to work for anyone else.

In future episodes...

One thing I have learned about being a game programmer...I don't have a lot of time to blog! But I would like to continue writing about my experience and sharing tidbits of technical and other gaming wisdom along the way. Stay tuned.

Friday, June 13, 2008

Running the Gauntlet (Part 2)

After my phone interview, I was sent the feared programming test. These tests are designed to gauge your knowledge of the C++ language as it applies too games. I ahve seen several versions of programming tests sent by game companies. In my opinion, many of them are an unrealistic test of an entry level programmer's skills. That means that these tests are a major hurdle to overcome for recent graduates or anyone trying to break into the game industry.

I know this is just my own personal soapbox, but the reality of programming is that you do most of it with a reference or two at your side before you get up to speed. Even experts need to refer to reference materials to get it right. So a test that require advanced math and programming to be completed in a short amount of time without any reference material seem unrealistic to me. However, the reality is that you MUST be prepared to deal with these types of tests if you ever want to get to the next step.

Perhaps we'll cover some of these types of questions in future blogs and run through the solutions. Fortunately for me, the test I was given was more realistic. I can't share the specifics of the test, but I can give a general idea of what was required.

The first step was to create a basic "adventure" type game. The implementation was left totally up to me, but I could tell from the requirements that they were looking for a piece of code that demonstrated a wide range of standard C++ skills with some direct application to game programming. Some of the elements necessary to pass this test were:

  • Implementing a game loop
  • Creating classes
  • Class inheritance
  • Container classes
  • Virtual and pure virtual functions
  • Using polymorphism
  • Static variables and functions
  • Friend functions
  • Use of the standard template library (STL), especially vecotr
  • Use of iterators
  • Dynamic memory allocation and deallocation

The second requirement was to write a detailed design spec for a particular problem. Some of the skill required to pass this part of the test included:

  • Good writing skills
  • Good analytical skills
  • Solid problem solving skills
  • A basic understanding of state machines

The thing I most appreciated about my test is that it was a true test of my problem solving abilities, not a test of how well I had memorized particular routines or snippets of C code. I was allowed to solve the problems using any resources at my disposal without a time limit (other that the deadline to turn in the test which was quite reasonable).

I think the key to my success in passing this test was that I didn't put it off until the last minute. I started that day, and then worked on my solutions over the next two days, leaving time at the the end for review and polish.

I'll be the first to admit that I did not pass these tests with perfect accuracy. I later discovered I had made one or two glaring errors. However, the company I work for looks for good problem solving skills more than they look for perfect code, and my performance was sufficient to earn me the next level in the process: the face-to-face interview!

Robert

Monday, May 19, 2008

Running the Gauntlet

So I had just received my first phone interview from a game company. I was both excited and anxious. I had applied to this company precisely because their advertisement encouraged those who were trying to cross-over from general IT into game programming. I knew that I had no game-related experience, but that I had a wealth of experience both in programming and the areas that surrounded it: project management, training, system design. I also had excellent writing and communication skills. Would this be enough.

The phone interview began with a general discussion of my background. One of the biggest questions I knew I had to answer was the "Why". Why did I want to get into game development? Why was making this career change? Why was I moving from self-employment to employment?

I don't want to bore you (too much), but I had really thought out the answers to these questions. I realized that I already had a couple of factors working against me. First was my age. At 46 its hard to change careers. People either think that you are overqualified or entrenched in your ways. They may also feel that your skills are out of date. I couldn't change my age, so I worried about the issues I could control.

I had tried to deal with the latter by keeping up with the latest programming techniques and by self-studying the issues surrounding game development, game design, and the gaming industry in general. For example, I realized about 5 years ago that my C++ skills had atrophied since I was working mostly in Visual Basic for my clients. So I forced myself to start doing work in C++, even if I got paid little or nothing for the projects. I also read every book I could get my hands on related to game development, got on every mailing list and website, and attended a few game industry conferences. By the time I got my first interview, I felt confident that I had a good grasp for what was going to me demanded of me.

You might think that being overqualified was not an issue since I had no experience in game development. However, my interviewer was concerned about one major issue: with over 25 years experience, how did I see myself fitting into the company? In other words, would I be satisfied as an entry level programmer? Would my pride be damaged? Would I be able to accept the salary that they could offer? I already realized that I would have to be willing to enter the industry at an entry level, even if that meant taking a cut in salary. I had no expectations of special treatment because of my years of experience. I just wanted to program games. If you find yourself in a similar situation, you will have to work all of this out in your head before you go seeking a job. Fortunately, the salary I was offered was very competitive and I was glad to consider the entry level programming position.

Another concern was whether someone who had worked for himself for the prior 15 years could integrate back into a corporate environment involving teamwork and collaboration. For me, there wasn't that much difference between having to please a client or please an employer. Both situations required teamwork and collaboration. Furthermore, many of my projects for clients had involved working with a team of other people to accomplish the project. The key was to communicate that I did not feel like I had to be the boss. Anyone who has worked as a consultant realizes that they are not really the boss anyway--the client always rules.

Next were questions about my technical skills. The interviewer told me that he was more interested in my ability to get along with people and solve problems than my particular skill level in C++. Nevertheless, we did cover basic C++ issues including class inheritance, polymorphism, and pointers. Although I felt good about my answers, there were definitely some concepts that I had no formal knowledge of. For example, I didn't know what a singleton was.

Although this was my first interview, I knew that many companies put technical prowess above everything else. This company continued to communicate that teamwork and personality were more important as long as you had the capacity to learn the technical skills.

More than anything, I just focused on being straight with my interviewer. I didn't try to come off as someone that I wasn't. I wasn't an expert game programmer, but I was an expert application programmer. C++ wasn't my strongest language, but given daily use it could be. I also emphasized my other strengths in problem solving, planning, and communicating. But I think the most important issue was a willingness to be flexible, teachable, and easy to get along with.

I had felt very good about the interview. I was informed that a programming test was on its way. And that will be our next story: The Test.

Robert

Monday, May 12, 2008

The View From Here

Well, I am now officially starting my fourth week as a game programmer and I have finally taken time to start my developer blog! I think my story of how I got here is sufficiently interesting, so this is the topic of my first entry.

I have been programming since 1979. Yes, I'm that old. I got my start in computing in a mainframe shop and have been variously employed in computers ever since. I taught myself Basic on a PDP 11/34 computer back in the day and have since programmed in Cobol (ech!), Fortran, C, C+, C++, Visual Basic, Java, Python, and a few other variants of those. My core languages are Visual Basic and C++.

For the last 15 years I had been self-employed. As a consultant, I sold myself to whoever would pay for my coding pleasure. That meant I got to do a lot of database design, school projects, and other stuff that was real interesting. Really.

Although I enjoyed my 29 year tenure as an application programmer, the time comes when an old programmer looks back on his life and asks, "What have I really accomplished?" In fact, I asked this about 5 years ago and the answer was that I had helped a lot of people but still didn't do what I loved...what originally got me interested in programming in the first place...that's right: games.

Games in 1979 were great! We had advent, trek and my all-time favorite tripe (if anyone knows where to find tripe let me know). I realized that I could create my own worlds!

So, here I am in 2008 and I'm finally doing it. I studied game programming on my own for the last 5 years. Attending E3 in 2004 was a life-changing event for me...I just had to get into game programming. But could and old-dog learn new tricks? Even if he did, would anyone care? (If a programmer falls in a forest and no one is around....you get it...)

My big break came when I responded to an job opening from a mysterious company who said they would actually like to hire someone who wanted to cross-over from IT into game programming. I sent the resume and held my breath (well, I did eventually start breathing again), and then went on writing those other programs. Then one day I got a phone call...

Robert