Categories
Game Development Personal Development

Learning from Game Development

Over a decade ago, while I was still in college, I went to my first indie game developer meetup. It was in a suburb of Chicago at a Starbucks, and it involved mainly people who participated in Dexterity Software’s game development forums, which are now the Indie Gamer forums. My first meeting’s minutes are still online: Indie Game Dev Meeting Summary December 2004

It was kind of a mastermind group. We showed off what we were making. Or rather, they did. I never had anything to demonstrate. I played their games and gave feedback, and we talked shop and set goals for the next month’s meeting.

Some people traveled from downstate to make it out to these meetings, which alternated between that Schaumburg Starbucks and the Dave & Buster’s in downtown Chicago.

I remember while packing up to leave one meeting I asked everyone, “How do I get better at programming?” At the time, I felt like I wasn’t making a lot of forward progress and it was mostly due to my lack of experience and knowledge.

I remember getting a few looks, there was a pause, and then someone said to nods of agreement, “Just…do it.”

It didn’t feel like very helpful advice, but I chalked it up to the idea that no one actually knows how they get good at something. When you are good at it, you don’t remember how you got there because your goalposts are always moving, and if you aren’t good at it, you don’t know how to change that fact.

Unless you ask, of course, and “just do it” actually is fantastic advice.

I learned C++ in college, but it was Visual C++ 6.0, and it wasn’t consistent with the C++ Standard, and I think I was taught wrong. I remember reading code online and not understanding why people were needlessly using “advanced data structures” such as vectors and sets. I taught myself BASIC on the Apple II c+, but programming in C++ was not fun or enjoyable.

But then I found some advice in the GameDev.net forums to read Accelerated C++: Practical Programming by Example. I bought the book, forced myself to read it from the beginning and do the exercises, and wouldn’t you know it, it turned out that C++ wasn’t so bad. What were considered advanced topics in college were introduced in the first few chapters.

I was still struggling to be productive with programming. I was challenged to find tools and libraries to make my job easier, and it is how I learned about a sprite engine, which I blogged about extensively.

I learned how to use libSDL. I succeeded at my first game jam when I attempted to work on Game in a Day, which was hosted by people at Garage Games. Kinda. I made something playable. It just wasn’t what I wanted to make originally.

And I learned a ton participating, including the first time I had an overwhelming sense of fear that I had no idea what I was doing and should stop, even though I had no rational reason for listening to this fear. I pressed on somehow, but I was shocked at how that experience challenged me. I didn’t expect it.

I had that almost tangible anxiety a second time, probably during my first Ludum Dare compo, but it was less powerful and I recognized it and pushed through it, and I haven’t felt it since.

I started finishing games. I built confidence in my abilities. When I read my old blog entries, I read about someone who struggled with focus and time management, someone who felt like he wasn’t putting in enough effort to learn and work on games.

But over the years, chipping away at ignorance made a difference. Today I’m seen as not only an expert in C++ but also in software development in general. I still find myself surprised by C++ today, though. For instance, sometime in the last couple of months I learned that I could forward declare more often than I thought I could.

A decade ago I couldn’t code my way out of a wet paper bag. Today, I could rearchitect a complete game halfway through its development without so much as a flinch.

Most of my experience and knowledge of software development came about due to my persistence with working on my own game projects. I did research on best practices. I sought answers to the problems I ran into. I wrote code outside of class and outside of my day jobs.

I just did it.

And while I might not have felt I was making a lot of progress on any given day, over a decade of such days resulted in a ton of growth.

It could be argued that a more focused effort with a lot more time dedicated to it would have been better, that I could have gotten to the same point years earlier.

But the advice would still be the same. You want to learn how to be a better programmer, artist, game developer, mathematician, engineer, or designer?

Just do what they do, and push through the “I suck” phase until you get the hang of it, push through the fear where you feel like you might choke and give up. Just do it, and even if you don’t figure it out today, tomorrow you’ll know how.

2 replies on “Learning from Game Development”

“Just do what they do, and push through the “I suck” phase until you get the hang of it.”

I usually tell people who are getting into programming that their first 100,000 lines of code are going to suck. Period. It doesn’t matter how smart they are, or what language they’re using, or anything else like that. You first 100,000 lines are going to suck. If you have a really good mentor and training program, and you listen to them, then maybe, maybe you can get that down to 80,000 lines of suck before you get good.

The solution, just like everything else, is to suck at it for a while and keep doing it anyway. It takes a long time to rewire your brain to handle programming (or anything else). Give it as much constructive exposure as possible to get past the suck phase.

I think this kind of advice is what was missing. Everyone feels like they need to be experts right away, and the reality is that there is going to be a period of time in which you don’t like what you create until you improve your ability to create it.

Comments are closed.