Code Isn't Everything

I recently saw this Gamasutra blog post by Pascal Bestebroer, titled "My game's done. Now comes the stress, struggles, and adrenaline of a one-man team doing his own PR". And I thought... HOW RELEVANT!

For the longest time I was laser-focused on writing the code for my game. And I would occasionally blog about it. But I didn't give much thought to marketing the game after it was completed. Kudos to Mr. Bestebroer for starting his PR as early as the first week of development! This guy clearly has had more time in the trenches than I.

Marketing is perhaps more important than the coding of a successful game, at least by conventional definition of success. For me, I think just getting my game out on the Google Play store will be a success. But it's good to realize, as I'm learning, that you're not done once the game code is completed. And if you can get a head start on your PR efforts, the earlier the better.

Are You Willing to Pay???

Image By: SalFalko

How much is TOO MUCH for an Android game? How much is too little?

These questions plague me as a I prepare to release my upcoming game on the Android Market, hopefully within a month or so. I've spent nearly a year and a half, mostly after hours because I have a day job also, developing a rather simple ball-jumping-platform-puzzler... for lack of a better description, and I'm quite proud of it. Heck, it even has an on-device level editor you can use to create your own levels! But it's no Mario. In fact, it's more along the lines of something like Lunar Lander. Will people be willing to pay 99 cents for something I've poured countless hours into? And honestly, it feels a little devaluing (is that a word?) to charge a mere buck for something that's taken so much time, effort, and... sacrifice.

There's always a cost, or many costs, when you pursue something you truly enjoy. And I'm talking about more than just the cost of the man-hours invested in a project! In my case, I can't tell you how many family movie times, story times, or bedtime songs I've missed to "keep plugging away" at some urgent-seeming code. In retrospect, I doubt that any piece of code is ever that urgent.

Also perhaps ironically, I haven't played any games in a long time, which is a very sad fact for someone who used to love first-person shooters and who is also on a journey to become a GAME developer! The truth is, whenever I consider playing a new game, my thought process goes something like "Why should I play another game right now when I could be using this precious little time to work on MY game?"

And let's not forget the cost of lost sleep and late mornings. Feeling dead tired in the morning because you were up until 2 or 3am the night before is a major drain, repeated occurrences of which can (and in my case did) lead to major burnouts. At one point I had to take a couple months hiatus from my personal development to get some rest. That was a tough call for me, but was important to get some sanity back. In the end, taking some time off allowed me to get some distance and come back with fresh perspectives.

All this isn't to say I regret the time I've spent working on the game. Over time, I've established a discipline of only developing a couple nights a week, though they do still tend to be late nights requiring a major shot of caffeine when I wake up. But I think it's good to realize with any passion you pursue, unless you're lucky enough to already do it for a living, that there are many potential costs to consider.

So if you're about to pursue something awesome on your own time, the question remains...

Are you willing to pay?

Oh, and... keep your eyes open for a game called "JUMP!" landing on a market near you very soon :)

What's YOUR backup strategy?

Recently, I was working on my afore-mentioned forthcoming Android game. I currently use Subversion, coupled with TortoiseSVN, locally on my development laptop for change management. So if I get to a solid point where I'm happy with my changes, I can commit them to my local repository. Then if I later try something new and don't like my latest work I can just revert back to the last "golden" build.

But there is a certain danger in this development flow. As I mentioned, I'm using Subversion locally on my development laptop. And every now and then, I get a sneaking suspicion that my laptop is just waiting to die on me right before I commit a large chunk of code with the most amazing changes I've ever made! So what is a poor indie game developer to do?

In the past, collaborating with a team on a small PC game, my team used a commercial hosting plan. So our code was committed to a remote repository and that worked as our off-site backup. But for my small Android game, I didn't really want to pay for hosting OR use an open-source repository. So I've actually been using the much lower-tech method of zipping up my code folder and storing occasional backups on DropBox or my Google Drive. That gets the job done; I just worry I may not be doing that frequently enough, and like I said the laptop could choose to give up on any given day. One thing I've learned over the years is "Save early, Save often." and to not trust hardware, because it will let you down when you least expect it.

So what's YOUR backup strategy? Leave a comment to let me know! But excuse me... I need to go, uh... make another backup... :)

Indie Startups - How Do You Collaborate?

Working with others is hard. But being able to work remotely and have all your files merged together nicely is really cool. I'm talking about source-control/versioning software, a tool that lets you maintain history of the changes to your files, as well as allowing everyone on the team to merge their changes to the project seamlessly. There are a couple different versioning tools out there, but the one I'm most familiar with and enjoy using is Subversion.

Since my team has decided we might consider selling our Tower Defense game at some point, we finally decided to remove its open source label and get smarter about how we secure our project. So I decided to set up my laptop as a Subversion (SVN) server; I know I should really use a spare server but I don't have one lying around. So I installed SVN server, got the repository and permissions set up, configured my router to forward the SVN port to a static internal IP address, and... VOILA! I had a working SVN repository accessible via the internet.

Unfortunately my upload speed, which measured .96Mbps on speedtest.net, was providing an abysmal 120kBps download rate for my team members trying to update their working copy of the project -- and let's not even mention the 2+ hours spent on the initial checkout! By comparison, downloads from our open source provider were roughly 1500kBps. I was a little perplexed as to WHY my 1 meg-per-second upload rate was so slow until I saw this forum post, specifically the comment by JC316. Megabits are eight times smaller than Megabytes, and when I did the math I realized that 120kBps (120,000 * 8 = 960,000 bits) is the same as .96Mbps (.96 * 1,000,000).

The reality is that my upload speed is just too slow. We don't have an office to work out of yet and I don't want to shell out $100+ per month for internet service just for a better upload rate. We're considering other closed-source SVN hosting services for now, but I have to wonder...

As an indie startup with team members working remotely over the internet, how do YOU collaborate?

Three Lessons Learned

So I think I mentioned in my last post (two months ago?) that some buddies and I were working on a tower defense game that we hoped to demo at an upcoming conference in September. As you may have noticed, September has almost come and gone but I haven't posted any stellar updates detailing the success of our demo at said conference.

Part of this is due to an unavoidable stall in development progress, which brings me to my first lesson learned. When I realized the ever-increasing scope of the game I would soon be writing, I should have pulled in more developers. As it is, I am currently the only programmer among a group of two 3D artists, two concept artists, and one musician. Although there is a certain amount of pride in being able to take full ownership of the (increasingly large) code base, there is also much to be said for having a fellow to bounce ideas off of and having someone to share the load when you're not available.

Another thing that's bitten us in the development of our game is not understanding core requirements in the beginning. We think we have a great idea for a game and started prototyping the basics right away. For a simple tower defense game, you have enemies moving from one end of the screen to the other, and that's what we created initially as a 2D game. Once we had this basic prototype, we realized that it was pretty darn difficult to make projectiles with faux-depth in a 2D isometric view look right. So we had to make the leap to the third dimension, which involved converting our 2D sprites into 3D rigged/animated/textured models. We started creating 3D animated models right away before adding concept artists to the team; so the models had to be recreated. But once we had our concepts, we needed to make specific decisions regarding Art Style - the overall game appearance - and this required new models yet again. As a programmer I occasionally overlook these finer details; I mean, if all the characters on screen are moving to their correct destinations... it looks good! But the second lesson I've learned is that Art Style is something that should be seriously considered early on in a game's development.

Performance is also a major consideration for our game. Although we want to have the best-looking game we can build, we also want it to be playable for as many people as possible, so limiting it to the highest-end graphics cards didn't seem right. And given the fact that I was developing the game on a laptop with only 32MB of dedicated video memory at the time, I had a big problem creating a game I wouldn't be able to play! So we took a step back and realized that our 3000-polygon models probably weren't going to cut the mustard. But even with reduced-poly models, we wanted to do some fun stuff in our game like using outlines on our toon-lit models, particle effects, etc. And some of these special effects are expensive operations that quickly drop frame rate and can cause the game to lag. So as our designer likes to say it, the final lesson for today is to "prototype everything." Although he doesn't really mean to prototype everything. What should really be prototyped is all of the core systems of a game that could be rendered/executing together at the busiest point of the game's interaction: music, sound effects, lighting, particle effects, blur effects, and so on. And provide a way to instantly, with the push of a button, drop a hundred or more models on the screen to simulate the game at its most computationally-intensive point to see how it will perform in the worst-case scenario. Doing this type of prototyping early on can help identify where you need to save polygons or cut features that could prevent your intended audience from playing your game.

The cool thing about my team is that we're all learning as we go, and sometimes part of that involves looking back and saying "You know, we could have..." So I hope this helps as you start your next project.

Making Games on the Side

As a hobbyist/indie game developer, I found the following Gamasutra article of particular interest. It describes some of the challenges and sacrifices required to be a successful game developer, whether your definition of "success" is actually breaking in to the industry or simply making games for the love of doing it. Hope you enjoy the article as much as I did.

Making Games On The Side: Development In The Real World

Happy (Belated) Birthday, GDJ!

It's hard for me to believe this blog is one year old this week. I started writing last March 14th, not quite sure where the journey would take me, and now it seems a whole year has passed so quickly. One thing is for sure, I have learned a LOT about the game industry through numerous news feeds I now read almost daily and from the extremely bright folks over at the Game Career Guide forums. I've dedicated a large amount of effort to learning how to write games, have gotten involved in my local IGDA chapter, and have met some really cool people in the process.

I created a very basic Pong Clone in 24 hours, worked in a team to create the puzzle game Befuddled at the Global Game Jam in a single weekend, and am currently working with some amazing artists to create an exciting tower defense game. This latest project is one of my biggest and best endeavors yet, so I'm very excited to see the end result within a couple months.

Global Game Jam 2010

I had the unique opportunity to participate in the Global Game Jam this past weekend, January 29-31. The GGJ is a 48-hour, world-wide game creation marathon. Creating a game is no easy task, let alone doing it in such a shortened timeframe. But we did create games, many of us in small groups across the world, and it was truly an amazing experience to be part of this global event!

The Triangle Game Developers division of the Global Game Jam started off at Icarus game studio in Cary, NC on Friday the 29th at 4:30pm. Unfortunately, due to snowy weather we were not able to remain at the studio location for the entire weekend as planned. We had just a few hours to get together, meet our peers, view the keynote speech, and then get started by discussing game ideas and forming teams. After a short period of discussing our game with our new team members, we left for the evening with everyone's contact information in hand, and that's when the real fun began.

This year's theme was Deception. We had to think up game ideas incorporating some means of deception and, as an additional requirement, had to include one of the following three items in the game: a pet, a set, or a net. The idea our group settled on was a type of Bejeweled clone where players secretly choose the gems they use to score points and can also sabotage each other! Our game is called Befuddled and can be downloaded here, along with other games from the Triangle Game Developers.

One thing I learned from this event is that it takes a LOT of work to complete a game. And a lot of communication. In fact, I think that's one of the things my group did particularly well. One of our team members set up an IRC channel so we could all communicate real-time, and we were mostly connected the entire 48 hours for making design decisions, asking questions, and just chatting in general. Another thing we did really well was picking a simple game idea. It started very basic, but we were able to add on to it, giving it new visual styles and gameplay features as we went along.

One problem we had throughout was, with a basic game, trying to add the right things to make it fun. We know it still needs more playtesting and iteration to figure out the missing "fun" factor. But the best and most exciting part of it all is having something we can call a complete working game. Of course nobody stayed up the full 48 hours, but some of sure did try, and we're all very proud of our successes on this project!

Be sure to check out Befuddled and a ton of other Global Game Jam games by visiting the Global Game Jam website. You can also search Twitter for #GGJ to see posts about GGJ games.

Current Project: Tower Defense Game

I've noticed the guys over at Vortix Games occasionally take a hiatus from posting on their blog when busy with a given project. I think this is certainly understandable when you're part of a small team and would like to point out they have done a terrific job on their blog - definitely one to check out for some game development insights. And so I begin this post by admitting I've been doing the same... but hey, it's not so bad because I'm not the only one, right?!

At any rate, I would like to briefly mention the new game project I've been working on. A couple months ago I had the great pleasure of meeting a couple artists in my area, and we've since been working to design and build a Tower Defense game. For the uninitiated, gameplay consists primarily of setting up a series of defenses such as turrets or guns and then watching a flood of enemies attempt to navigate from their start position to a given destination. This is an entirely new game genre to me, but after having played a few games online (such as Whiteboard Tower Defense) and working on our current prototype, I'm excited to see how it will turn out. One thing is sure: with professional artwork it will definitely look better than my basic Pong clone!

This project has some interesting challenges. For example, it is entirely a 2D game; I've been learning 3D development for so long that it is a welcome switch of gears. It is also being developed for the XBox 360 using XNA Game Studio 3.0, which allows me to put my existing C# skills to use, just in a new way. I use C# every day for web development but this is my first experience with XNA. Even though the target platform is the XBox 360, I plan to make it playable on the PC as well.

I hope to reveal more about the game as our agile design/implementation/testing rounds progress. Keep an eye out for future posts, even if they're not terribly frequent. With any luck, the completed game will appear here for your enjoyment!

Game Deployment Woes (Just Make It Flash!)

In one of my previous posts I released a Pong clone game that, albeit not polished, was a fully working game and I was quite proud of it. Of course, as sometimes happens with the deployment of Windows-based games, I was dismayed when I learned nobody who actually took an interest (thanks to you faithful few!) was able to run the game :(

That's when the fun began. I asked one friend to make sure he had the DirectX runtime installed and even to reinstall it - no luck. I then learned the C++ runtime was required and had the same friend perform that install - no luck. I tried two different machines with the same installations - no luck. Finally I learned it was not just requirements on the target systems; it turns out I had included a debug version of a DirectX library in my project, which allowed the program to be created and executed, just not in a way that it would work!

You see, as a developer, I have all of the tools required to run any program I create. But other machines don't necessarily have these tools/environments. So I think I'll use the following plan for deploying my next game.

1. Create a game, coding and testing in DEBUG mode
2. Change the project from DEBUG to RELEASE mode
3. Replace DEBUG libraries with RELEASE libraries
4. Build the project in RELEASE mode
5. Create an installer project to install the game, the C++ runtime, and the DirectX runtime

1. Create a Flash game that can be played from a web page in any browser!

Now all I need to do is learn to program a game in Flash...

Pong Postmortem: Completing a Game in 24 Hours!

For the uninitiated (or techno-illiterate), a "postmortem" is a wrap-up discussion summarizing the good, bad, and ugly of a project following its development. What follows is a summary of the creation of my first completed game, a clone of the Atari classic Pong.

My Pong clone was created in 24 hours, though not in the type of all-nighter hack-a-thon you might expect or even a typical three work days. I have a full-time day job, so development is typically done late evenings, but fortunately I kept track of the amount of time spent on specific components. Note that I started with a working Direct3D application from Luna's book Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach. Here is the hours-to-effort breakdown:

• 10 Hours - I dedicated the first 10 hours to rendering the basics of the game: the board, two paddles, and the ball. This included creation of graphical "placeholders"; I'm not an artist but I realized I could come back and make the art fancy after everything worked. Getting the ball in motion and then allowing it to bounce off the walls and paddles (Collision Detection) was the second major focus. Finally, the simple mechanic of allowing the player to move a paddle up/down brought the game into a playable state.
  
  
• 4 Hours - The primary effort of the next stretch was to implement a basic computer opponent (Artificial Intelligence), and I started with a perfect opponent whose vertical position matched the ball's position at every moment. When adding different game modes, this perfect opponent became part of the game's Practice Mode. I added the ball's motion blur effect just to improve aesthetics and moved hard-coded values to an include file for easier maintenance and testing.
  
  
• 4 Hours - In this phase I worked on creating a computer opponent that moved more realistically but was also fallible; a perfect opponent gets boring to play against! I added different difficulty levels (easy/medium/hard), which works by choosing a random "reaction time delay" between when the player hits the ball and the computer opponent is allowed to hit the ball. Obviously, as difficulty increases, the computer's reaction time improves to make it a more formidable opponent.
  
  
• 4 Hours - At this point the game was playable with differing levels of difficulty but no clear way of selecting game settings. I created the menu system and added scoring to determine the winner.
  
  
• 2 Hours - The last step before I considered the game completed was to work on the art, which could clearly still use some work! :)

Final Thoughts:
I knew this project would be relatively simple because there are only four game objects to keep track of: two paddles, one ball, and one board. However, due to its simple nature, I was inclined to hack it together quickly and did not follow strict OOP (object-oriented programming) principles. The majority of the game code is in a single monolithic file. I also resorted to reusing an existing class designed to output simple statistics to display text-based menus. But worse, the same class used to show all menus and text became my game state manager since I needed to know which menus had been processed. I then extended it to display current score values and to show which player had won the game. Although I could have put a lot of time into doing it the right way, the purpose of this effort was to get something done. In future endeavors I plan to follow better OOP design.

The best part of this project is that I actually completed a working game! I am proud of the subtle but effective motion blur effect. The game doesn't have all the bells and whistles (seriously, no sounds or music yet) but it is playable, implements Collision Detection and Artificial Intelligence, and has a clearly defined winner at the end. Some may even consider it fun :)

Staying Motivated

I can't believe I started this blog more than six months ago. I remember thinking initially, after seeing many game development blogs trail off after just a couple months, that I would surely put out at least five posts every week. Ha! Let's just say I may have been a little ambitious. It's easy to push forward full steam when something is new, but the question of true dedication comes when the going isn't so easy.

I've seen forum posts regarding burnout on the game development dream and even noticed one of the blogs I followed (and had linked here) seems to have disappeared. So... how do you stay motivated when your enthusiasm wanes? I think part of it is remembering what you enjoyed about it (whether it is game development or another hobby) in the first place, and looking forward to what you will be able to do with practice. In my case I'm reading through a very dry, technical graphics book right now and sometimes it is flat-out boring; but I know that by reading it and working through the examples I will in time be a better game developer.

Quite honestly, I think everyone loses their enthusiasm at times. If you stay away from an activity too long it can be hard (though not impossible) to get back into it, and if you play with something too long it can start to feel like work. But the best approach is to just stick with it. Don't give up!

Check out Brenda Brathwaite's blog post for more inspirational thoughts on staying motivated. I'm proud to say that even though I'm not posting as frequently, I am still learning new graphics tricks (today was Direct3D meshes) and will not be disappearing any time soon!

Sine Language Lesson, Part 1

I've had this idea ruminating in my mind for some time now. Math is a big part of graphics development and I'm certainly no expert, but I wanted to show off some cool things that can be done with sine waves. This part introduces the concept and shows some fun demo programs you can play with; part two will delve into the inner workings of the demos, which have been adapted from Frank Luna's Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach.

You may remember from your high school Trigonometry class (don't worry if not, it was a long time ago for me too!) those two periodic functions, sine (pronounced "sign") and cosine ("co-sign"). They're essentially the same function and you could map one to the other with a slight shift. Cosine has some unique applications of its own, such as determining light intensity based on viewing angle, but the demos below will focus primarily on sine waves.

Credit: Wikimedia Commons

Notice a few interesting properties from the graph above. One is that a sine wave repeats itself every 2π (π ≈ 3.14159) or 360 degrees along the X-axis. Another is that it oscillates between the Y values -1 and 1. We write the function y = sin(x) to indicate the Y value as a function of X; see from the graph above that Y = 0 when X is any multiple of π and Y is either 1 or -1 (the peaks and valleys) when X is an odd multiple of π/2.

Point Light Demo - Download Program!

This demo shows how sine waves can be used to animate a light source. Use the specified keys to combine waves, creating a variety of unique horizontal and vertical motion paths.

Before learning this elegant method, my approach to animating an object that sways back and forth, or moves repeatedly up and down along a pole, was to use code like this in my update loop:

    static bool moveUp = true;
    if (moveUp) 
    { if (shipPos.y < 100) shipPos.y += value; else moveUp = false; }
    else 
    { if (shipPos.y > -100) shipPos.y -= value; else moveUp = true; }

With sine waves, this code reduces simply to shipPos.y = 100 * sin(x)! Notice that I multiplied by 100 to get the desired range instead of the standard oscillation from -1 to 1.

Ocean Waves Demo - Download Program!

This demo illustrates the effects of adding sine waves and two different wave types, circular and directional. Use the specified keys to play with parameters and change the wave patterns.

As with the Point Light demo, you will need to have DirectX (from Windows Update) installed in order to run the program.

These are just a couple applications of the sine function. Because of its periodic repetition, it could have many potential uses; some fellow GCG forum members cited their implementations of a 3D carousel and a wavy spaceship flight path as additional examples.

I hope you enjoy the demo programs of this post, though I admit I still need to learn better methods of input handling. Part two will describe wave alterations, based on the Ocean Waves demo, in greater detail. Until then, feel free to let us know: What's the coolest thing you've done with sine/cosine waves?

Quick Random Update

So, Gamasutra is on Twitter too. You may recognize them, or at least you should if you have any business as a video game developer/designer. Gamasutra is one of the most popular game-oriented websites with full-featured articles and commentaries on the state of the industry, game reviews, yadda yadda yadda. So now you can check out not only the website, but also the Twitter feed. Oops, sorry if that last link didn't work; I suppose I should have linked it the proper way: @Gamasutra!

Enough hype, this post is mostly me checking in for a quick progress update. I blasted through reading about lighting, textures, blending, and stenciling in my Direct3D book and then found out the exercises required a fair deal of re-reading. Lesson learned, I have to work through chapter exercises before moving on to more difficult chapters! The same applies to the Game Design Concepts course I'm taking -- it's much easier to keep up with the readings than work through the exercises, some of which I have to skip. FYI, you can follow discussion for the course on Twitter too; just search for #GDCU!

The topic of my next post will be the power of sine waves. Yep, I'm talking about those tricky oscillating waves you learned about way back in high school. I've found some interesting applications and want to show off some of the cool stuff you can do with them. And now that I'm finally understanding the basics of HLSL (High Level Shader Language) shaders, the part that tripped me up big time in the last book I read, you can expect some posts on that stuff too.

Just curious, when was the last time you used something from high school you never thought you would need again? What's the trickiest math you've used in game development, and does calculus ever figure into the equation (pun... fully... intended!)?

The Problem with the Mythical Black Box

In programming, we occasionally make use of something known as a "black box." This Mythical Black Box is any library or chunk of code written by someone else that allows us to abstract a problem so we don't have to understand the details of solving it. For example, if we pass the values 3 and 4 to a "calculator black box", which might be a class library written by another developer, we would expect it to return the value 12 for multiplication. We don't care how it works internally, whether it computes 3+3+3+3 or 4+4+4; all we care is that it returns the correct value. A black box diagram for an encryption algorithm might look something like the following.

Password => { Encryption Black Box } => Encrypted Password

Jeff Atwood of Coding Horror has recently expressed seemingly contrasting views on this topic, both touting and refuting the benefits of abstraction. And for good reason, because it can be a good thing or a bad thing depending on whose library you choose. For one thing, you should never introduce code into your project if you aren't 100% certain it will fulfill its promise. Many developers (myself included) prefer the "roll your own" method for most tasks simply because you know you can trust your own code (not that it will be error-free, just that it won't be malicious). But sometimes it makes sense to use a well-tested library from another developer, such as the ever-popular JQuery library for Javascript development. In such cases I suggest ensuring you trust the developer (e.g. they're well known, such as Microsoft, and would be ridiculed if the library failed) or that you have full access to the source code. Many open source projects are reviewed by large numbers of people such that bugs are caught and fixed quickly.

Unfortunately, even if you take my suggestions your black box may someday fail. The whole reason I bring this up is that I faced this exact problem with my SkyCop demo. I developed it using the Common Files Framework presented in Engel's Beginning Direct3D Game Programming, 2nd Edition and provided in a specific version of the Microsoft DirectX SDK. When I ugraded to the most recent build of the SDK, my demo suddently stopped working and I started getting reports of others not being able to run it either. I ran into numerous problems trying to get it to work with the latest DirectX SDK and believe the Common Files Framework was removed altogether in the latest version. Having relied too heavily on that framework, I wasn't sure how to resolve the compilation errors and feared I would have to scrap the project altogether.

Fortunately, in his Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach, Frank Luna fully describes a working game framework instead of glossing over it and providing another black box. I was able to essentially rip out the core of my SkyCop demo, converting it to use the new framework, and am pleased to have an updated demo below that should work on any DirectX 9 (or newer) version, but let me know if you still have any trouble running it.

SkyCop v1.1 Demo Download

Black boxes can be a good thing when they're well-written by a trusted developer, but it's also a good idea to review the code (if possible) and at least have a basic understanding of how it works. In my case, as a learning newbie, I was happy to avoid the initial complexity and that later bit me from behind. One thing to keep in mind, though, is that black boxes come in many shapes and sizes. My black box was a game framework but the concept could also apply to a game engine, a single portion (Renderer, Physics, Sound, etc.) of a game engine, or some other game components I'm not even aware of yet.

Do you know what's going on under the hood of your game framework/engine? What black boxes are you relying on to develop your games?

June Monthly Checkup

Yep, another month has come and gone. Sadly I still don't have a finished game, but I do have some cool demos to show off in upcoming posts. I'm up to chapter thirteen (of twenty-two) in Luna's Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach and am learning a lot, but it takes a while to work through the chapter exercises. I'm also in the process of taking Ian Schreiber's free online game design course. My portfolio website is nearly completed; I just need to find a better host before posting the link here on GDJ.

So it's been yet another busy month of learning and experimenting, all while prepping for our big move to NC in August. After we get settled I plan to join the Triangle IGDA chapter so I can get serious about that whole networking thing.

Game Development Process

I read the article How a Game Gets Made in the free online edition of Game Career Guide magazine some time ago. It's quite a good read for anyone interested in the process, and I believe it's important for me as a programmer to understand what role I will someday fill as a game developer. What follows is a transcription of notes I took while reading to summarize the process; note that not all possible roles are covered and the steps are not listed in sequential order.

• Preproduction
  This is the phase where core game design decisions are made, game elements are prototyped, and the game story is developed. A basic prototype of the game is developed quickly and shown to the producer who either scraps the game or gives it the go-ahead to move into production.
  • Designers document objects, characters, levels, enemies, NPCs, etc. for the game
  • Artists work on character designs, level concept art, and storyboarding
  • Programmers work on tools, document technical specs, and perform risk assessment
  • Producer determines a production schedule and milestones


• Production
  This is the phase where the game is fully developed based on preproduction planning and detailed design documents. Some experimentation is allowed as long as it improves the game. The development team follows a "production methodology" to keep track of and divvy up remaining work.
  • Must determine dependencies early to complete child tasks sooner and keep teams independent (max efficiency)
  • Artists get a head start creating/texturing character models and world props (cars, buildings, crates, etc.)
  • Animators generate animations for character models
  • Programmers work on core functionality and data manipulation
  • Level designers create rough sketches of all levels in the game
  • System designer plugs in characters and tweaks animations and gameplay
  • Sound designers work on effects, getting voice actors for character dialog, and music tracks
  • Team meets periodically to review overall progress of the game
  • At 2/3 of production timeline additional staff is brought in for QA testing; most features are implemented so it's time to squash bugs


• Postproduction
  Postproduction is all about getting the game into the hands of consumers.
  • Final build of the game (the Gold Master Disc) is printed
  • Marketing publicizes the game to popular game websites, magazines, and as TV ads
  • Publisher handles game manual and box manufacturing, and has a distributor set up to deliver the game to retail stores
  • Developers may be tasked with creating donwloadable content (characters, costumes, levels, etc.) to update and extend the game

May Monthly Checkup

This has been a busy and difficult month with some unexpected events that nearly derailed my resolve to continue this journey. Nonetheless, I press onward, but with the realization that I may not be able to post as frequently or accomplish goals as quickly as hoped. So this is a pretty informal checkup this month and I've decided not to restate previously completed goals in favor of highlighting tasks that still need work.

The foremost goal in my mind is to complete a full game. I've started reading a new book that I plan to review once I've completed it, and the exercises of chapter five have me working on a 2D space shooter. Following completion of this mini-project I will start work on a PONG clone; the physics of a ball in motion (including collision detection) are quite interesting to me and may require further study.

I have been playing more games lately but don't own a fancy new console yet; picked up three older games for the original XBox (only cost $20 for the set) and want to get a Nintendo Wii at some point. Meanwhile, I have updated my old resume and started a portfolio site that is still a work in progress.

So that's about it for progress updates this month. I think my main takeaway from this month is that it's not how quickly you run the race... just that you eventually finish... and Rome wasn't built in a day. Finally, for some fun reading, check out The Escapist online magazine. They've got some cool game-related articles and a pretty cool RSS feed. Check out my devious guide for help with RSS.

April Monthly Checkup

Has it been another whole month?!? Where does the time go? Here's my current goals checklist on my journey towards becoming a Game Developer.

	Create a finished game. I did some good work on my SkyCop demo, finally getting a playable demo posted. I plan to design a smaller-scale (possibly 2D) game at some point but need to work on learning more fundamentals first.
	Use personal projects to test different rendering techniques and programming methods. Check! See the SkyCop reference above.
	Continue learning and be competent enough to explain design decisions. In addtion to keeping up on the latest feeds for major game sites and participating in a couple forums, I've purchased five new books! Admittedly three of them were recommended for Ian Schreiber's Game Design Concepts course. The one I'm probably most excited to dig into is Game Coding Complete, which I'm hoping will be a good reference for proper structure and best practices. Despite these positive steps, I can't mark this item completed just yet. I am still learning, after all.
	Start networking! I'm staying active in a couple forums and planning to participate in a local IGDA chapter. The only problem is the local Columbus chapter (which I would still be a couple hours away from) appears to not be meeting at this time, so I may have to wait to participate with the Triangle chapter after we move to NC later this year. Attending the SIEGE conference is still a possibility, or I might consider a visit back up this way to check out the GameX Games and Media Expo.
	Play more games! I haven't bought a shiny new game to play yet, but I have tried out some independent games on Armor Games. Crush the Castle, where you get to use a trebuchet to destroy castles, is actually a lot of fun! Nonetheless I think I need to get better versed in newer games to mark this item completed.
	Update the outdated resume. This is a new goal and a worthy one I think will help me focus even better on my target. Darius Kazemi has some great tips on writing a resume for a game company and I plan to update my resume soon.

"If you wanna be rich, you gotta do rich people stuff." - Dave Ramsey
"Wanna be a Game Developer? Do Game Developer stuff!" - Me

See any holes in my plan or have useful tips/pointers to help get me further along? Post a comment!

Monthy Checkup

It's been a whopping two weeks since I started this blog, but it's also the end of the month, which means it's checkup time! At the end of each month, I will review my incomplete goals and determine how I'm progressing toward becoming a Game Developer. You may recall some of the following from my Inspiration post and I've added a few new goals too.

	Create a finished game. I'm still in the process of learning Direct3D and playing with various techniques. SkyCop is a wide-open testbed for experimentation, but once I feel more confident in my skills I will design a smaller-scale game that I can actually finish. I've read numerous articles stressing the importance of showing potential employers you can create a finished product.
	Use personal projects to test different rendering techniques and programming methods. Check! See the SkyCop reference above.
	Continue learning and be competent enough to explain design decisions. I've exponentially ramped up my reading of game development blogs and articles on major sites like GameDev.net and Gamasutra. I want to get another book or two to learn technical/design concepts; I've heard Game Coding Complete is a good reference.
	Start networking! I've started participating in the Game Career Guide forum; they have a bunch of bright and friendly people willing to help newcomers to the scene, and I'm hoping I will be able to contribute positively to the community. I'm also learning about different game development conferences and considering a trip to GDC next year or possibly attending SIEGE this year.
	Play more games! I love playing video games, and remember the thrill of playing multiplayer Quake 2 and Unreal Tournament back in the day. It's hard to find the time these days, but in order to understand modern game concepts I really should buy a new game. That's my rationalization, anyway ;)

Dave Ramsey, creator of Financial Peace University and an awesome motivational speaker, says "If you wanna be rich, you gotta do rich people stuff." Likewise, if you wanna be a Game Developer, you gotta do Game Developer stuff! I found these testimonies of actual developers/designers working in the field to be quite interesting. They're a good reminder that there's more than one way to break into the games industry, and I know that I can do it!