A couple years ago, my cousin interviewed me for a school project, which I posted as Interview with a Game Programmer. Recently, a number of students have found my blog and asked to interview me for their own school projects! Here for Part 2 is the second interview, by Anthony Hammen.
Needless to say, the views expressed here are my own and do not necessarily reflect the views of Linden Research, Inc.
What hours do you typically work?
I usually get to work anywhere between 9am and 10:30am, and leave between 5pm and 7pm. This is pretty typical of my coworkers as well. I'm trying to get myself into a stricter 9am to 5pm schedule though!
Are your hours constant?
No, as you can tell from my previous answer, there's no real incentive to be at work at exactly the same time every day, though it might make for a more efficient routine if I did! As a programmer, it's hard to know when I'll be leaving work any given day, as I don't like to leave until I've gotten to a good stopping point so I don't forget what I was doing when I come back the next day! Though I have heard some people say that it's better to stop in the middle of a task, so you won't procrastinate on starting up the next one when you get going again. I guess it depends on how good you are at remembering!
Who do you report to?
The way my team is structured at Linden Lab, I report to both a manager and a product owner for the project I'm working on. The manager keeps track of the productivity of myself and the other developers on my team, estimates how long it will take to finish the project based on our previous progress, and helps negotiate when other teams want us to help them with stuff. The product owner comes up with the goals that we are actually working toward, basically taking the perspective of a customer and describing the product that we developers are supposed to actually build.
What education or training do you have?
I have a Bachelor's degree in Computer Science from the University of Washington (BS with College Honors). I also had a couple internships with software companies while I was in college, which taught me a lot. Even more so, the jobs I've had working full-time as a programmer after graduating have really developed my skills over the last few years. And of course, I've taught myself a ton of stuff from free resources online, like how to program in ActionScript for Flash games, or how to make ragdoll physics engines.
Are your tasks scheduled? Who handles that?
Our work is divided into two-week periods called "sprints". At the end of each sprint, we decide what we will take on for the next sprint, with the aim of planning out exactly the amount of work that we can finish completely in two weeks. Our manager and product owner oversee this planning process, but they don't directly break our work into tasks for us or tell us what we need to do when - that's our job, as developers. Since we are the ones who actually know how to do the work, we have to estimate how long things will take and commit to an appropriate amount.
What languages do you currently code in?
I've been mostly coding in C++ for the last few years, both at Linden Lab where I work now and at my last job at Fugazo. I've recently started coding in Python as well. For my side projects, I use ActionScript 3.0 for Flash.
What's your work environment like?
I work in a building that originally was a brewery, and now is an office building with three floors and lots of open space. It's pretty cool. Desks are clumped together, and spread out in clusters around an open office plan - no cubicles, though a few people work in separate offices. Most of the separate rooms are used for meetings though - there are lots of those scattered around. Of course, everyone has a computer or two on their desk. I use an exercise ball for a chair, though most people use normal office chairs. There's a fair amount of natural light, though there's a lot of fluorescent light too, unfortunately. I was able to get the lights above my desk turned off, at least, so they're not in my eyes while I work.
What is your actual job title?
I'm a Software Engineer at Linden Lab.
How do you progress in your current workplace?
My understanding is that if you're a Software Engineer, you can become a Senior Software Engineer if you become awesome and experienced. From there, you can continue along that track to be a Senior Architect, or switch over to a management role as a Dev Manager. There's not a huge ladder to climb, though. Most people will just be Software Engineers, which is totally fine. Of course, there are other tracks at the company in addition to the Software Engineer track, but I don't really know how those work.
What development processes are used at your company?
As you may have guessed from my description, we use Agile, or Scrum. This is actually a relatively new process at the company, as originally it was just a bunch of programmers working on whatever they felt like, more or less. Now we have dev managers and product owners and daily standup meetings and two-week sprints.
If you could change something about your job, what would it be?
I'd much rather be working on experimental new games (or "shared creative spaces" at Linden Lab) instead of just adding more stuff to the giant machine that is Second Life. I like working on smaller projects where I can build from the ground up, and I have lots of ideas for cool projects I'd like to try, so I'm really hoping I can switch over to that.
What do you like about your job? Dislike?
I like that I'm constantly learning new things and improving my skills. And I like the people that I work with, and the respect and autonomy I have in general. What I don't like is that I'm not working on what feels most meaningful to me right now, and that I struggle to find time and energy for my own projects outside of work.
What do others think about what you do?
I don't know, I guess I've never really asked! Well, sure, my parents are proud of me. ;) Generally, within the industry, programmers have a lot of respect - we make everything actually happen, and we deal with arcane, technical stuff that other people get confused just looking at, so they generally assume we must be really smart! Maybe people in the outside world think we're weird or nerdy or geeky, but I've never really had to deal with that kind of thing myself, so I don't know. I mean sure, every programmer understands the stereotype, and there's some truth in it, but I've always found that there's a strong undercurrent of respect. I mean, when you're in demand, as programmers generally are these days, people are going to think of you more highly!
Does this job leave you very much free time?
Generally speaking, no. The game industry is notorious for demanding long hours, especially if you're a programmer. The joke is that once you get into the game industry you no longer have time to play games. I've been lucky enough to avoid the worst of that, but even in my last job I spent at least half of each year in a moderate crunch (working long hours for an extended period of time) and then the rest of the year recovering from crunch, so I didn't have as much time or energy as I wanted to pursue other projects and activities outside of work. At Linden Lab things are a lot better, since it's not technically in the game industry - it's more of a typical software company. A lot of people at the company have kids and families, and simply won't tolerate the terrible work-life balance that is stereotypical of the game industry. I have to say, though - even when you are working reasonable hours, programming itself is one of the most mentally exhausting activities you can do, so it can be hard to have enough energy for your own projects after work!
What inspired you to become a video game programmer?
I've always liked making things. When I was a little kid, I was always drawing monsters, building with LEGO, and folding origami. In fourth grade I found out that it's possible to make computer games by this weird thing called "programming", and I loved the idea of making my own little worlds on the computer, so I decided to figure out how to do that! By the time I was in high school, I had been programming tons of games on my TI-83 Plus graphing calculator, and had dreams of creating my own game company.
What kinds of math do you use, and how did you learn it?
I don't often use math directly when I'm programming, but certainly in order to understand programming you have to be adept in a mathematical way of thinking. You have to be very familiar with how algebraic expressions work, and evaluating formulas made up of variables and functions operating on other variables and functions - it should be second nature to you. Or rather, it will become second nature as you get better at programming. So it's not that you have to be good at calculating stuff in your head - that's the computer's job - but you have to be very comfortable with understanding the formulas and expressions themselves.
However, as you get deeper into specific areas of programming, particularly game programming, you may need to use more advanced math. At the most basic level, when you are laying out buttons and text on the screen for the user interface of a game, you'll most likely be dealing with numbers for the sizes and positions of these objects, and doing lots of basic addition and subtraction to put them in the right spot relative to each other, or dividing the widths by two to get the center, for example. If this is not second nature to you, it will quickly become confusing. Or if you are making an action game where objects are moving around and colliding with other objects and shooting and all that, you'll be working with simple Newtonian physics and tweaking numbers relating to velocity, acceleration, friction, and so on, where you must be very familiar with derivatives - not in the sense of doing calculus, but in how things behave when they are connected by the mathematical relationship we call the "derivative". Or if you are dealing with things rotating, and converting angles into vectors and velocities and all that, you'll need to understand how to use basic trigonometric functions to switch between these formats. All of that stuff is pretty easy, not as hard as it sounds. But once you start getting into making your own physics engines you'll have to learn tricky geometric algorithms and maybe even do some vector calculus, which I still have some trouble with. And 3D graphics is a big mess of matrix algebra and quaternions and stuff that I've been able to avoid completely so far.
So really, I started learning programming on my own at the same time that I was learning the relevant mathematical concepts in school. I started reading about programming at the same time that I was just getting introduced to algebra in school. And not too long after I started learning trigonometry in school, I discovered that it was actually really helpful for making a turret rotate and shoot in a game! And when I was learning about physics in school, I started exploring physics in games. Unfortunately, game programming isn't really used as a way to teach math in schools, even though for me it was the best way for me to really understand it. I ended up learning this stuff mostly from online resources and tutorials. If you have a basic foundation in mathematical and algebraic thinking, learning the math you need from online resources is no harder than learning programming the same way. Doesn't make it easy, though! Just start small - only learn as much as you need to do the game you're working on now. As you make more complex games, you can learn more complex math.
And here is Part 1, if you missed it!
Showing posts with label advice. Show all posts
Showing posts with label advice. Show all posts
2013/06/15
Interview with a Software Engineer - Part 1
A couple years ago, my cousin interviewed me for a school project, which I posted as Interview with a Game Programmer. Recently, a number of students have found my blog and asked to interview me for their own school projects! Here for Part 1 is the first interview, by Yair Granados.
Needless to say, the views expressed here are my own and do not necessarily reflect the views of Linden Research, Inc.
Could you explain a little about what exactly Linden Lab does?
Linden Lab is the company that created Second Life, which is probably the most well-known online virtual world. Second Life launched in 2003 and started getting a lot of media attention around 2006, which was when I first heard about it. The unique thing about Second Life is that anyone can create things in the virtual world - clothes, buildings, artwork - and fully own the rights to their creation, including selling copies of their work in the Second Life marketplace. As a result many people are able to create or participate in a wide variety of virtual experiences that they would not be able to in more gameplay-focused virtual worlds like World of Warcraft, where your only option is to kill monsters and earn gold.
Today, Second Life continues to be the primary source of income for Linden Lab, so most of the company's resources are devoted to maintaining and improving Second Life. And that's what I'm working on - programming new features and fixing bugs in Second Life. But last year the company started branching out, with four new projects - Creatorverse, Patterns, Dio, and Versu - that all fall under the theme of "shared creative spaces" kind of like Second Life. The hope is that as Linden Lab can continue to have some people developing new projects like these, and eventually at least one of them will become big like Second Life has. This is definitely what I'm most excited about, as I really like the idea of building virtual spaces where you can use your creativity and share with other people.
How long have you been programming, and how did you get started?
I've been programming professionally (getting paid for it!) for about three years now, but I first started learning about thirteen years ago now. So it took ten years between my first attempts and when I started making a living from it! Of course, I was about twelve years old when I first started so things were pretty slow at first. I didn't know anyone who could teach me programming, so I started out trying to find books about programming at the library and at bookstores - but it was hard to find books for beginners back then! It wasn't until I got this educational software in fifth grade called "Learn to Program: BASIC" that I actually managed to try out some of the stuff I had been reading about. I remember working on a simple game like Frogger, where you are an ant trying to get to the top of the screen while avoiding slugs and snails that move back and forth, but I never completely finished it. Not too long after that, my parents signed me up for a summer course on Visual Basic at a community college right before I started middle school, and I ended up making my first finished game in Visual Basic as part of a science project that year, in sixth grade. After that I started reading about C++, and tried making an artificial life simulation in C++ for my seventh grade science project, but failed spectacularly as my lack of programming experience finally caught up with my ambitions.
Fortunately, around that time we started using graphing calculators in math class, and so I began learning to program the TI-83 Plus graphing calculator using the language TI-BASIC. This was great because I couldn't get too ambitious - I made tons of little experiments and games, and just ended up doing a lot of coding, instead of spending so much time reading about it! In eighth grade I released my first calculator game on ticalc.org, and also started learning z80 assembly language, which is used to make more sophisticated games on the TI-83 Plus. By that time, programming games on the calculator was my main hobby, and I continued to release more games and grow in my programming skill over the next few years in high school and even college. As I got busier, becoming a university student and taking real computer science classes, I stopped doing much calculator programming, but it wasn't long before I found a new platform for making games - Flash. I taught myself the ActionScript language for making Flash games, and made a number of games in Flash on the side while studying computer science for my university degree. By the time I'd graduated, I'd gotten pretty comfortable with Flash and had done a few internships (some paid, some not) making use of my Flash programming skills.
My career goal has always been to make a living by making my own games, and my parents were nice enough to give me a year to try the whole indie game development thing while living rent-free, so that's what I did. I learned to use the Flixel game engine for making Flash games, and started making little experiments, hoping to come across an idea that would be worth developing into a full game. Unfortunately, I found that my lack of experience was really holding me back, not just in terms of programming but in terms of how to be consistently productive and how to manage my energy and all that, and on top of all that, I realized that I was really lonely trying to spend all day coding in my room. So, when that year was up, I had finished one game, Flydrill, but it wasn't successful and I wasn't able to finish another one, so I realized that I had to get a job.
I was fortunate enough to get a job soon after at Fugazo, a casual game studio, as a C++ game programmer. Despite my initial reservations about becoming an employee and working on other people's games, it was exactly what I needed. I ended up staying there for over two years, learning much more there than I had in any two years of college, leveled up several times in my game programming skill and understanding of the business, and emerged as a very valuable member of the team and a desirable target for recruiters, which brought me to Linden Lab. And I kept making Flash games on the side, of course. My most popular game so far, The Love Letter, was released last year while I was at Fugazo, and I'm looking forward to releasing even more games this year while I'm at Linden Lab!
What exactly does a Software Engineer do?
Generally speaking, the term "software engineer" is pretty much interchangeable with "programmer" or "developer", but it tends to imply a more systematic approach to creating software than just hacking things out in a quick and dirty way. As far as what a software engineer actually does, that of course varies from company to company, and from project to project, but you can be pretty sure that if you're a software engineer you'll be spending most of your time writing code. Programming.
You'll probably also spend a fair amount of time thinking about how you'll program something before you actually do it, and investigating possible ways of doing things, and learning new technologies and tools and programming languages as needed, and debugging and revising old code, and talking with other software engineers on your team about all this. And depending on how big of a company you work at, you might have to spend some time in meetings, but hopefully not too much. ;)
In other words, there will be non-technical people (game designers, producers, product owners) telling you what they want you to make, and then your job is to get with the other software engineers on your team, figure out how to actually make what you're supposed to make, and then make it. You're the maker. You know how to make things happen. Other people tell you what to make, but they don't know how to make it, so it's your job to actually do that. It's not always easy, but that's why there are smart people like you to figure it out.
At first, this was kind of frustrating to me, because I like thinking of my own ideas for what to make instead of just making what other people tell me to. But one thing I discovered is that there is a creative aspect to building software that is entirely invisible to non-technical people, which means that as a software engineer, you can have a lot of creative freedom in designing the structure of the software itself, even if you don't get to decide what it does. Software engineering is largely about this invisible structure, and one of the nice things about having the job title "software engineer" is that you are more likely to have the opportunity to give this structure the attention it deserves, instead of having to do things in an ugly way just to get the job done, as you might find as a mere "programmer" or "developer". But of course it varies a lot from company to company, and project to project.
What skills or training does a student like me need to become a programmer? Especially a game programmer.
Well, as a programmer (or "software engineer") you really need to get good at programming, because that's what you'll be doing! If you are good at programming, it won't be too hard to find a job as a programmer. And if you're not good at programming, why would anyone want to hire you? Of course, when you're just starting out, you don't have to be perfect - there's something to be said for raw potential - but you still need to be good at programming. Kind of like if you want to be a professional athlete - if you want to be paid to play basketball, you better be really good at playing basketball. Except that there are a lot more jobs out there for programmers than for professional athletes!
The point is, you can't just decide to start learning programming when you want to get a job - you need to start programming now. It doesn't really matter what kind of programming - as long as you enjoy it, and can start getting good at it, there's probably going to be some demand for that skill. And even if it's something like TI-BASIC for the graphing calculator, which no one would pay you for, the skills you learn in one programming language can transfer very easily over to other languages and platforms. What really matters are the fundamental skills. So start learning one programming language, and then if you're not too into it just try a different one. There are a ton of languages out there, and a ton of different types of software you can make (or even types of games, for that matter) so keep trying until you find something you really like. And at some point you may want to branch out and you can try something new. The important thing is just to do it. This may take years - it certainly did for me - but so does any real skill, whether it's learning to play the saxophone or getting a black belt in Taekwondo.
Of course, there are easier ways to start and harder ways to start, and it can be tough to know where to look if you've never programmed before. So I can give you some suggestions. First of all, don't start with C++. I know there's some macho thing about C++ being a more "serious" programming language and that you're a noob if you don't know it, but seriously. Don't waste your time learning C++ if you can help it! Until you've had several years of experience with other languages you won't really "get" what C++ is all about even if you technically know everything about the language. That was certainly the case for me in seventh grade. Nowadays I code in C++ for my job, but I still use Flash for my side projects. I don't hate C++, but I would only use it when I absolutely have to. It's powerful, but it's heavy and cumbersome, and unless you're working on a huge project with a bunch of other experienced programmers it's like carrying around a big sledgehammer when you could be using a nice, ergonomically shaped hammer that fits in your pocket instead. No matter what you think, you don't need that extra power. Seriously. Just don't.
Okay, so if not C++, where should you start? Well, there are a lot of possibilities out there, but for general programming your best bet would be Python. Python is just an awesome language overall, whether you're completely new or have years of experience. I use Python just as much as C++ in my current job. But if you try Python and you're not too into it, you could try Processing instead. I don't think anyone would call Processing an "awesome" language, but it really lets you dive into graphics and input right away, so if you're drawn to programming because of games this may be an easier place to start. Then if you try Processing and it's still not game-focused enough for you, you could give Lua a try. In particular, you should try the free Love2D engine, which lets you make games with Lua. If you try all of these and you just can't seem to get the hang of typing in all this code, I'd suggest checking out Stencyl, which is a game-making tool where you can program by dragging code blocks around, which can be a little easier to learn at first. Then once you are comfortable with that you could try learning an actual programming language again.
The important thing to keep in mind is to just make stuff. Don't try to make your big, ambitious dream game - just mess with code and make stuff happen on the screen, and shape that into games. Make small games. Make lots of small games, and finish them. And release them online! As you do this, your abilities will scale up, and your experiments will start to become interesting games in their own right.
If you've made a few games and you're looking for your next challenge, I'd recommend learning ActionScript 3.0 and a free game engine like Flixel or FlashPunk to make Flash games if you want to get further into 2D, or check out the Unity engine with C# or JavaScript if you want to go 3D. That's basically where I'm at now, so don't feel like you have to go any further to be a "real" programmer! But if you have your heart set on C++ for some strange reason, make sure you're very comfortable with making games in Flash or Unity first. And if you want to make iPhone games, Objective-C is hardly better than C++ in my opinion, and you should check out the Corona game engine for iPhone, which uses Lua.
As a game programmer, you also need to be able to collaborate with people in other disciplines, like artists and game designers. Once you've made a number of games on your own and feel ready to tackle something bigger, I highly recommend you seek out other creators online and try to make a game with them. Most collaborations fizzle out or fall apart before finishing a game, so don't get discouraged if that happens, but learn from the experience and try again another time. If you're used to making entire games all by yourself, I'd say it's easiest to collaborate with a music composer, so try that first. Then you could try collaborating with an artist too. Then you can try collaborating with a game designer or level designer if you want. But I think the hardest would be collaborating with another programmer! Because you really have to coordinate when you are both working on the same code. So start simple, and don't be surprised if things don't work out at first.
Lastly, while I have emphasized the importance of actually coding a lot, there's also something to be said for the kind of theoretical knowledge you can gain from a computer science degree (or if you are very self-directed, from learning on your own from the many resources available online). But for the first few years, you're not going to be able to really appreciate most of it, so it's much more important just to start coding a lot, and learning from your own mistakes. Eventually, if you want to get hired as a programmer you'll probably need a computer science degree from a university to even be considered, but really, having a bunch of games that you've made yourself that you can show off is just as important. And if you're going to try to make your own way as an independent game developer, the university degree is only as good as what you make of it. So start by just making a lot of games, and then once you start to get curious you can delve into the theory of computer science and maybe even get a degree in it.
If it isn't too personal, what is the range of income you can make working as a programmer?
According to the Game Developer Salary Survey, the average annual income for game programmers who have been in the industry for three years or less is around $60,000 while the average for game programmers with more than six years of experience is around $100,000. I'd say the actual range would start around $40,000 and then potentially up to the low six figures if you've been in the industry a long time. Outside of the game industry, programmer salaries are actually a bit higher, as I understand it, but the same general range still applies.
What is good about your job, or what do you like about it? And what do you not like about it?
I think one of the best things about being a programmer is that I get to constantly exercise my brain and learn new things. That means that my work can often be frustrating and confusing, but even then I don't feel too bad about it because I know that eventually I'll get through it and I'll have gotten lots of programmer experience points to help me level up my skills!
As far as the actual programming goes, I have always enjoyed building things, whether that's LEGO sets or game engines, and when I understand what I'm doing well enough then programming becomes a very enjoyable process of building, and designing an elegant and aesthetically pleasing conceptual structure for whatever I'm building. I really enjoy that, and at its best programming can give me that feeling better than just about anything else. But programming isn't always like that - you're often running into snags, or encountering problems that you can't solve without delving into some new technology that you don't understand yet, and so you have to be prepared to spend a lot of time puzzling over some tricky problem, or trying to figure out why things aren't working the way you expect them to.
It's also nice that programming is a very meritocratic profession - if you write good code, you will have respect. Because it's about the code that you write, you don't have to dress a certain way or keep a strict schedule of working hours, and while I don't know how it is in every company, I've been lucky enough to work at companies with a very friendly, casual atmosphere.
The biggest problem I have with programming is that I have to sit in front of a computer all day in order to do it. I've learned to take breaks to keep my mental energy and productivity high throughout the day, but it's still a struggle. Because programming is such a mentally taxing activity, managing my energy has been a crucially important skill for being a consistently productive programmer. And that's another drawback - I like to work on my own games on the side, but oftentimes I'll be so worn out at the end of the day that I won't have the mental capacity in the evening to work on my own stuff. However, like any kind of exercise, you do get stronger over time, so I'm still able to get some stuff done. Just not as much as I'd like.
Is there anything else I should know about this job?
Probably. But words can only get you so far. You really just have to try it. And the most important thing to know is that you can just try it. You don't need anyone's permission; you don't need anyone's help. If you're going to be a programmer, you have to be willing to persevere in pursuit of your goals, to fail and fail and keep trying until you figure it out. Because that's what programming feels like, most of the time. Even when you've been at it for thirteen years, like me. ;)
And on to Part 2!
Needless to say, the views expressed here are my own and do not necessarily reflect the views of Linden Research, Inc.
Could you explain a little about what exactly Linden Lab does?
Linden Lab is the company that created Second Life, which is probably the most well-known online virtual world. Second Life launched in 2003 and started getting a lot of media attention around 2006, which was when I first heard about it. The unique thing about Second Life is that anyone can create things in the virtual world - clothes, buildings, artwork - and fully own the rights to their creation, including selling copies of their work in the Second Life marketplace. As a result many people are able to create or participate in a wide variety of virtual experiences that they would not be able to in more gameplay-focused virtual worlds like World of Warcraft, where your only option is to kill monsters and earn gold.
Today, Second Life continues to be the primary source of income for Linden Lab, so most of the company's resources are devoted to maintaining and improving Second Life. And that's what I'm working on - programming new features and fixing bugs in Second Life. But last year the company started branching out, with four new projects - Creatorverse, Patterns, Dio, and Versu - that all fall under the theme of "shared creative spaces" kind of like Second Life. The hope is that as Linden Lab can continue to have some people developing new projects like these, and eventually at least one of them will become big like Second Life has. This is definitely what I'm most excited about, as I really like the idea of building virtual spaces where you can use your creativity and share with other people.
How long have you been programming, and how did you get started?
I've been programming professionally (getting paid for it!) for about three years now, but I first started learning about thirteen years ago now. So it took ten years between my first attempts and when I started making a living from it! Of course, I was about twelve years old when I first started so things were pretty slow at first. I didn't know anyone who could teach me programming, so I started out trying to find books about programming at the library and at bookstores - but it was hard to find books for beginners back then! It wasn't until I got this educational software in fifth grade called "Learn to Program: BASIC" that I actually managed to try out some of the stuff I had been reading about. I remember working on a simple game like Frogger, where you are an ant trying to get to the top of the screen while avoiding slugs and snails that move back and forth, but I never completely finished it. Not too long after that, my parents signed me up for a summer course on Visual Basic at a community college right before I started middle school, and I ended up making my first finished game in Visual Basic as part of a science project that year, in sixth grade. After that I started reading about C++, and tried making an artificial life simulation in C++ for my seventh grade science project, but failed spectacularly as my lack of programming experience finally caught up with my ambitions.
Fortunately, around that time we started using graphing calculators in math class, and so I began learning to program the TI-83 Plus graphing calculator using the language TI-BASIC. This was great because I couldn't get too ambitious - I made tons of little experiments and games, and just ended up doing a lot of coding, instead of spending so much time reading about it! In eighth grade I released my first calculator game on ticalc.org, and also started learning z80 assembly language, which is used to make more sophisticated games on the TI-83 Plus. By that time, programming games on the calculator was my main hobby, and I continued to release more games and grow in my programming skill over the next few years in high school and even college. As I got busier, becoming a university student and taking real computer science classes, I stopped doing much calculator programming, but it wasn't long before I found a new platform for making games - Flash. I taught myself the ActionScript language for making Flash games, and made a number of games in Flash on the side while studying computer science for my university degree. By the time I'd graduated, I'd gotten pretty comfortable with Flash and had done a few internships (some paid, some not) making use of my Flash programming skills.
My career goal has always been to make a living by making my own games, and my parents were nice enough to give me a year to try the whole indie game development thing while living rent-free, so that's what I did. I learned to use the Flixel game engine for making Flash games, and started making little experiments, hoping to come across an idea that would be worth developing into a full game. Unfortunately, I found that my lack of experience was really holding me back, not just in terms of programming but in terms of how to be consistently productive and how to manage my energy and all that, and on top of all that, I realized that I was really lonely trying to spend all day coding in my room. So, when that year was up, I had finished one game, Flydrill, but it wasn't successful and I wasn't able to finish another one, so I realized that I had to get a job.
I was fortunate enough to get a job soon after at Fugazo, a casual game studio, as a C++ game programmer. Despite my initial reservations about becoming an employee and working on other people's games, it was exactly what I needed. I ended up staying there for over two years, learning much more there than I had in any two years of college, leveled up several times in my game programming skill and understanding of the business, and emerged as a very valuable member of the team and a desirable target for recruiters, which brought me to Linden Lab. And I kept making Flash games on the side, of course. My most popular game so far, The Love Letter, was released last year while I was at Fugazo, and I'm looking forward to releasing even more games this year while I'm at Linden Lab!
What exactly does a Software Engineer do?
Generally speaking, the term "software engineer" is pretty much interchangeable with "programmer" or "developer", but it tends to imply a more systematic approach to creating software than just hacking things out in a quick and dirty way. As far as what a software engineer actually does, that of course varies from company to company, and from project to project, but you can be pretty sure that if you're a software engineer you'll be spending most of your time writing code. Programming.
You'll probably also spend a fair amount of time thinking about how you'll program something before you actually do it, and investigating possible ways of doing things, and learning new technologies and tools and programming languages as needed, and debugging and revising old code, and talking with other software engineers on your team about all this. And depending on how big of a company you work at, you might have to spend some time in meetings, but hopefully not too much. ;)
In other words, there will be non-technical people (game designers, producers, product owners) telling you what they want you to make, and then your job is to get with the other software engineers on your team, figure out how to actually make what you're supposed to make, and then make it. You're the maker. You know how to make things happen. Other people tell you what to make, but they don't know how to make it, so it's your job to actually do that. It's not always easy, but that's why there are smart people like you to figure it out.
At first, this was kind of frustrating to me, because I like thinking of my own ideas for what to make instead of just making what other people tell me to. But one thing I discovered is that there is a creative aspect to building software that is entirely invisible to non-technical people, which means that as a software engineer, you can have a lot of creative freedom in designing the structure of the software itself, even if you don't get to decide what it does. Software engineering is largely about this invisible structure, and one of the nice things about having the job title "software engineer" is that you are more likely to have the opportunity to give this structure the attention it deserves, instead of having to do things in an ugly way just to get the job done, as you might find as a mere "programmer" or "developer". But of course it varies a lot from company to company, and project to project.
What skills or training does a student like me need to become a programmer? Especially a game programmer.
Well, as a programmer (or "software engineer") you really need to get good at programming, because that's what you'll be doing! If you are good at programming, it won't be too hard to find a job as a programmer. And if you're not good at programming, why would anyone want to hire you? Of course, when you're just starting out, you don't have to be perfect - there's something to be said for raw potential - but you still need to be good at programming. Kind of like if you want to be a professional athlete - if you want to be paid to play basketball, you better be really good at playing basketball. Except that there are a lot more jobs out there for programmers than for professional athletes!
The point is, you can't just decide to start learning programming when you want to get a job - you need to start programming now. It doesn't really matter what kind of programming - as long as you enjoy it, and can start getting good at it, there's probably going to be some demand for that skill. And even if it's something like TI-BASIC for the graphing calculator, which no one would pay you for, the skills you learn in one programming language can transfer very easily over to other languages and platforms. What really matters are the fundamental skills. So start learning one programming language, and then if you're not too into it just try a different one. There are a ton of languages out there, and a ton of different types of software you can make (or even types of games, for that matter) so keep trying until you find something you really like. And at some point you may want to branch out and you can try something new. The important thing is just to do it. This may take years - it certainly did for me - but so does any real skill, whether it's learning to play the saxophone or getting a black belt in Taekwondo.
Of course, there are easier ways to start and harder ways to start, and it can be tough to know where to look if you've never programmed before. So I can give you some suggestions. First of all, don't start with C++. I know there's some macho thing about C++ being a more "serious" programming language and that you're a noob if you don't know it, but seriously. Don't waste your time learning C++ if you can help it! Until you've had several years of experience with other languages you won't really "get" what C++ is all about even if you technically know everything about the language. That was certainly the case for me in seventh grade. Nowadays I code in C++ for my job, but I still use Flash for my side projects. I don't hate C++, but I would only use it when I absolutely have to. It's powerful, but it's heavy and cumbersome, and unless you're working on a huge project with a bunch of other experienced programmers it's like carrying around a big sledgehammer when you could be using a nice, ergonomically shaped hammer that fits in your pocket instead. No matter what you think, you don't need that extra power. Seriously. Just don't.
Okay, so if not C++, where should you start? Well, there are a lot of possibilities out there, but for general programming your best bet would be Python. Python is just an awesome language overall, whether you're completely new or have years of experience. I use Python just as much as C++ in my current job. But if you try Python and you're not too into it, you could try Processing instead. I don't think anyone would call Processing an "awesome" language, but it really lets you dive into graphics and input right away, so if you're drawn to programming because of games this may be an easier place to start. Then if you try Processing and it's still not game-focused enough for you, you could give Lua a try. In particular, you should try the free Love2D engine, which lets you make games with Lua. If you try all of these and you just can't seem to get the hang of typing in all this code, I'd suggest checking out Stencyl, which is a game-making tool where you can program by dragging code blocks around, which can be a little easier to learn at first. Then once you are comfortable with that you could try learning an actual programming language again.
The important thing to keep in mind is to just make stuff. Don't try to make your big, ambitious dream game - just mess with code and make stuff happen on the screen, and shape that into games. Make small games. Make lots of small games, and finish them. And release them online! As you do this, your abilities will scale up, and your experiments will start to become interesting games in their own right.
If you've made a few games and you're looking for your next challenge, I'd recommend learning ActionScript 3.0 and a free game engine like Flixel or FlashPunk to make Flash games if you want to get further into 2D, or check out the Unity engine with C# or JavaScript if you want to go 3D. That's basically where I'm at now, so don't feel like you have to go any further to be a "real" programmer! But if you have your heart set on C++ for some strange reason, make sure you're very comfortable with making games in Flash or Unity first. And if you want to make iPhone games, Objective-C is hardly better than C++ in my opinion, and you should check out the Corona game engine for iPhone, which uses Lua.
As a game programmer, you also need to be able to collaborate with people in other disciplines, like artists and game designers. Once you've made a number of games on your own and feel ready to tackle something bigger, I highly recommend you seek out other creators online and try to make a game with them. Most collaborations fizzle out or fall apart before finishing a game, so don't get discouraged if that happens, but learn from the experience and try again another time. If you're used to making entire games all by yourself, I'd say it's easiest to collaborate with a music composer, so try that first. Then you could try collaborating with an artist too. Then you can try collaborating with a game designer or level designer if you want. But I think the hardest would be collaborating with another programmer! Because you really have to coordinate when you are both working on the same code. So start simple, and don't be surprised if things don't work out at first.
Lastly, while I have emphasized the importance of actually coding a lot, there's also something to be said for the kind of theoretical knowledge you can gain from a computer science degree (or if you are very self-directed, from learning on your own from the many resources available online). But for the first few years, you're not going to be able to really appreciate most of it, so it's much more important just to start coding a lot, and learning from your own mistakes. Eventually, if you want to get hired as a programmer you'll probably need a computer science degree from a university to even be considered, but really, having a bunch of games that you've made yourself that you can show off is just as important. And if you're going to try to make your own way as an independent game developer, the university degree is only as good as what you make of it. So start by just making a lot of games, and then once you start to get curious you can delve into the theory of computer science and maybe even get a degree in it.
If it isn't too personal, what is the range of income you can make working as a programmer?
According to the Game Developer Salary Survey, the average annual income for game programmers who have been in the industry for three years or less is around $60,000 while the average for game programmers with more than six years of experience is around $100,000. I'd say the actual range would start around $40,000 and then potentially up to the low six figures if you've been in the industry a long time. Outside of the game industry, programmer salaries are actually a bit higher, as I understand it, but the same general range still applies.
What is good about your job, or what do you like about it? And what do you not like about it?
I think one of the best things about being a programmer is that I get to constantly exercise my brain and learn new things. That means that my work can often be frustrating and confusing, but even then I don't feel too bad about it because I know that eventually I'll get through it and I'll have gotten lots of programmer experience points to help me level up my skills!
As far as the actual programming goes, I have always enjoyed building things, whether that's LEGO sets or game engines, and when I understand what I'm doing well enough then programming becomes a very enjoyable process of building, and designing an elegant and aesthetically pleasing conceptual structure for whatever I'm building. I really enjoy that, and at its best programming can give me that feeling better than just about anything else. But programming isn't always like that - you're often running into snags, or encountering problems that you can't solve without delving into some new technology that you don't understand yet, and so you have to be prepared to spend a lot of time puzzling over some tricky problem, or trying to figure out why things aren't working the way you expect them to.
It's also nice that programming is a very meritocratic profession - if you write good code, you will have respect. Because it's about the code that you write, you don't have to dress a certain way or keep a strict schedule of working hours, and while I don't know how it is in every company, I've been lucky enough to work at companies with a very friendly, casual atmosphere.
The biggest problem I have with programming is that I have to sit in front of a computer all day in order to do it. I've learned to take breaks to keep my mental energy and productivity high throughout the day, but it's still a struggle. Because programming is such a mentally taxing activity, managing my energy has been a crucially important skill for being a consistently productive programmer. And that's another drawback - I like to work on my own games on the side, but oftentimes I'll be so worn out at the end of the day that I won't have the mental capacity in the evening to work on my own stuff. However, like any kind of exercise, you do get stronger over time, so I'm still able to get some stuff done. Just not as much as I'd like.
Is there anything else I should know about this job?
Probably. But words can only get you so far. You really just have to try it. And the most important thing to know is that you can just try it. You don't need anyone's permission; you don't need anyone's help. If you're going to be a programmer, you have to be willing to persevere in pursuit of your goals, to fail and fail and keep trying until you figure it out. Because that's what programming feels like, most of the time. Even when you've been at it for thirteen years, like me. ;)
And on to Part 2!
2011/11/24
The Hug Initiation Protocol
When I read Steve Pavlina's blog post Just Frakkin Hug Me, I was inspired. I like hugs! Why couldn't I just hug people more often instead of being all shy and inhibited?
Well, for one, I'm shy and inhibited. Also, hugs are unusual, at least among guys, and so people might read more into my actions than I really intend. But mostly, I just don't know how to go about it in the first place. How do you give someone a hug, especially if they're not used to it?
So naturally, I did some research, and put together this handy Hug Initiation Protocol that breaks the process down into clear, concrete steps. You might think that this is a bit much, but socially awkward nerds like me need all the help we can get. I'm sure I'm not alone in this. ;) You tell me.
Hug Initiation Protocol
1. Make eye contact with your intended hug recipient.
2. Stand still. Do not rush at your intended hug recipient.
3. Hold your arms out, in front or to the side, palms open and up, in an inviting gesture that clearly signals your intent to hug.
4. Keep a neutral or positive facial expression. Do not scowl at your intended hug recipient, unless you are a little kid who looks particularly cute and huggable while scowling.
5. If your intended hug recipient does not respond, you may either abort your hug attempt or verbally offer a hug in case your intended hug recipient did not recognize your intent to hug.
6. If your intended hug recipient responds by hugging you, then congratulations! You have successfully initiated a hug.
7. Attempt to sustain the hug for at least one full inhalation and exhalation of breath. A quick hug indicates that you are hugging out of a sense of obligation rather than a sincere desire to connect.
8. But if your hug recipient attempts to disengage, you must respond with immediate disengagement as well.
9. While hugging, do not rub or pat your hug recipient on the back. Patting is a sign of insecurity, and rubbing is just awkward. Don't do it.
10. That's it!
Yes, I know I'm silly. :p
Have fun putting it into practice. And I hope you have a happy Thanksgiving today! :)
2011/03/06
Interview with a Game Programmer
One of my cousins asked to interview me for a school project, since I'm a real game programmer now! I went all-out on these questions and thought I'd share them here, so if you know anyone who's considering a career in games or programming, feel free to send them over for a bit of behind-the-scenes with a recent college grad who has just broken into the game industry.
Needless to say, the views expressed here are my own and do not necessarily reflect the views of Fugazo, Inc.
What is your name and job title?
My name is Alex Cho Snyder and I work as a Game Programmer at the casual game development studio Fugazo, Inc.
How long have you had this job?
I started this job on August 9th, 2010, so I've been working at Fugazo for about six months.
Please explain what a typical day of work is like for you.
I have breakfast at home, pack a lunch, and take the bus downtown to the office. I usually get there around 9:30am, but time is pretty flexible there, so it's no problem if you get there a bit late. I go to my desk - all our desks are together in the same big open-studio-style room - turn on my computer and wait for it to start up so I can check my work email, download the latest images and files that my teammates have added to the project from the SVN repository, and start up Visual Studio, which is kind of like Microsoft Word for programming code. I also look through my work notebook to refresh my memory about what exactly I've been working on and what I was thinking about the day before.
I work on a team of about three or four other people, making Fugazo's next hidden-object adventure game. There are about two other such teams at Fugazo, each working on a different game. Each team has one designer, one programmer, and two or three artists. I'm a programmer. I like to think of it in comparison to building houses. The designer is the architect, who draws the plans for the house and manages the overall process. The artists are the ones who prepare the pieces of the house - boards, doors, roofs, siding, etc. And the programmer - me - is the contractor putting the pieces together and actually building a functional house. I like building things, so it works out. But I really don't like remodels, where I'm taking an old building that someone else made and have to tear out old parts of the building and fix it up and add new rooms and features. You never know if one wall or pillar is okay to take out or if the whole building will collapse when you do. That's the annoying part.
In more specific terms, my designer will come to me with a feature or puzzle or something that he wants me to add to the game, and describe exactly what he wants while I ask questions until I feel like I understand completely. I usually like to write out the details of the task in my notebook by hand, because it helps me wrap my brain around the problem. Then I'll either start writing ideas for possible solutions, or look through the existing code of the game to get a better understanding of how the solution will have to fit in. Then I start actually writing code, and testing it out. Most of my time is spent going back and forth between thinking about the problem, reading code, and writing code. If I get stuck I'll ask the designer for clarification, or talk to our lead programmer to ask how he would recommend solving the problem. Once I've got something actually working on screen, I'll show the designer and ask him for feedback. Either he'll suggest more things to change, or he'll give me the next feature he wants me to build.
At noon we have an hour for lunch, and I often walk down to a nearby alternative school to volunteer-teach game programming to some middle-school kids. After that I'm back to work, until around 5:30pm when everyone leaves and I take the bus home or to martial arts practice for exercise.
What have you enjoyed most about your occupation?
That is a hard question for me to answer. I love thinking of ideas for games, and hashing out designs with teammates, but as a programmer that is something I am rarely involved in directly. In my role as a programmer, my enjoyment comes from exercising my near-magical ability to create imaginary worlds that live inside a computer screen. When I have gained enough understanding and familiarity with my tools that this process is no longer a confusing struggle but a mildly stimulating problem to solve, I find this very enjoyable. This usually happens when I am asked to create a smaller puzzle within a larger adventure game, where I can visualize the end result I want and then figure out how to actually build it with computer code. When things are going smoothly, I can go from start to finish in this process within a day or two.
I like seeing the fruits of my labor up on the computer screen - the quicker and more immediate, the better. I like to take something that works, that I can see and play around with, and tweak it and adjust it until it's just right. It is very rewarding to me to see and appreciate and savor this thing I have created, and when I am deprived of that gratification for too long I can easily become frustrated. I'm quite stubborn, so I don't give up when things take a long time to sort out. That doesn't mean I have to like it, though! :p
Do you believe most of your fellow colleagues or workers enjoy their work? Why?
I think they do. But not necessarily in the way you might assume. Many people mistakenly conflate the fun of playing games with the hard work of making them. I like to compare the process of game development to cooking or baking. Most people love to eat pastries and cookies and donuts, just like most people enjoy playing games. But not everyone likes to bake those cookies, and not everyone likes to make games. If you want to become a baker, it certainly helps to like eating pastries. But it's not enough.
Some game companies are more like donut factories. They are not fun places to work. Fugazo, where I work, is more like a successful neighborhood bakery. The work isn't amazingly fun, but it's usually interesting, and the people are nice, and it's not a bad place to be all day. And at the end of a project, after a few months, you have a finished game that's pretty cool and you can feel proud of it and show your friends and family and all that. And you get to think about games all the time.
If you could change anything about your occupation what would it be?
If I could make games without ever having to sit at a desk and stare at a computer screen, I would. If I could run around in a virtual forest, climb inheritance trees and swing from conditional branches, build towers with blocks of code, and just use my physical body and my stereoscopic vision and my musical ears and my agile primate fingers, I would be so much happier. I love plants; I love being outside. I also love the ability to create virtual worlds that other people can experience, through computers. But every minute that I spend in front of a computer screen is a sacrifice that I make in exchange for this power to shape (virtual) reality.
More realistically, if I never had to renovate another programmer's poorly encapsulated user interface code, that would be awesome. Most frustrating part of my job right there. Also, if I had more teamwork throughout the day, I think I would enjoy that. I love collaboration, and I get just enough of it to avoid feeling unbearably lonely throughout the day, but I really get very little. There's something called pair programming where two people share a computer and take turns writing code and observing, and I've done that a few times in school and I think I'd very much like to do that again. However, it's obviously not as feasible in a small company like Fugazo where each game has only a single programmer to work on it.
Have you gone back for more educational training since you began the job?
Nope. For me, working at this job is all the educational training I need! It has been at least as educational as an equivalent time at school was, in the six months I've been at Fugazo. In computer programming, school can be essential to getting started, but once you're actually working, you should be learning a lot as you gain experience and your company starts branching out to new technologies and platforms. At the least, you can learn a lot from your own side projects as well.
What educational background do you have?
I graduated from the University of Washington with a Bachelor's degree in Computer Science. It took me a little less than five years at the UW to decide on my major, take all my required classes, and graduate. Throughout college, however, I had a summer internship or two working as a programmer and also made quite a few of my own games on the side, which is crucial if you're trying to get a job after graduating. Just a Computer Science degree doesn't cut it. You need to have experience working at a programming job, at least as an intern, and show that you have the passion, skill, and discipline to make your own games in your free time.
If you won the lottery and did not have to work, would you? Explain.
For a while, at least. ;) I decided to look for a job last summer so I could earn money, spend my days working on a team instead of by myself, and get experience learning from people who know what they're doing instead of fumbling around on my own. The lottery would only take care of one of those things. My life's work is to change the world through games. The most important thing I can do right now is to hone my skill at designing and programming games, and become fluent in all other aspects of the process as well. I will work at a company for as long as I need to until I'm ready to strike out on my own and form my own team, and I can't imagine finding a better place for that than Fugazo right now. A lot of game companies are not fun places to work. Fugazo is a notable exception.
What kind of strategies do you use when your job gets stressful?
Programming is often frustrating and can easily get stressful if you are not careful. I find it important to take breaks whenever I am really stuck or not thinking clearly, and I find that taking a walk right before lunch is very helpful in clearing my head. I also have started giving myself permission - with my boss's encouragement - to take short naps when I feel sleepy, especially in the afternoon. When it comes to jobs like programming that consist almost entirely of difficult problem-solving, it is often much more efficient to take a twenty-minute nap and come back refreshed than to fight back sleep deprivation for three hours without getting anything done. As with any sort of activity that involves sitting at a computer and staring at a screen all day, I've also found it very helpful to take a few minutes every so often to get up and move around, do some handstands, stretch, get my blood flowing, and help loosen whatever mental rut I might have gotten into while hunched over at my desk.
In your career field, is it difficult to balance work with home/family or personal life?
The game industry is one of the most notorious when it comes to poor work-life balance. This is a problem that is slowly improving, but it is definitely a real concern. Many companies, because of poor scheduling, can have months of forced "crunch time" at the end of a project, where people are working evenings, even weekends, continuously until the game is finished. Obviously, this is a very bad thing and it is arguably counter-productive in the long run, but many companies still do it. Even at Fugazo, where I work now, there may be a week or two of crunch at the end of a project, where I stay late in the evenings, but I've never worked weekends. Even then, no one is forcing me to stay late - I choose to keep working because I have a long list of things I want to get done, and I tend to be a perfectionist about these things. And I'll usually be the only one working late on most occasions, since no one is forced to crunch.
Outside of extreme circumstances like crunch time, I do often struggle to balance work and personal life. I wouldn't necessarily attribute this to the game industry itself. I think this has more to do with my inexperience (I've been working full-time for less than a year) and my tendency to cram way more things into my life than I could reasonably have time for. Though maybe the game industry tends to attract people like me anyway, so who knows!
What was it like when you went to high school? What kind of career planning did you have in high school?
I started high school about eight years ago. Back then, I wasn't thinking about jobs at all, but I knew that I wanted to do something with games. At the time I was doing a lot of programming on the graphing calculators we used in math class, making little games and releasing them online. I was also starting to read about using games for education and social change and became inspired to make that my life's work. As it turns out, those were the perfect things to be doing if I later wanted to start a career in game development!
What do you feel is most important when choosing a career?
There are a lot of ways to think about this question. One approach that I like is to think of something that you could see yourself getting really good at, if you spent the next ten or twenty years doing it for a living. That doesn't mean something you are already good at, necessarily, but something that you could see yourself learning to get really good at. I started learning to make games about ten years ago. The reason I choose to make games for a living now is not that I'm particularly good at it now, but I could see myself becoming really good at designing and making games over the next ten years. And that has less to do than the skills I currently have, and more to do with my passion and what I'm excited about and what I enjoy doing and learning and thinking about in my free time.
If you really love to do something, chances are that you could get really good at it - that if you kept doing it for a living over the next ten years, you wouldn't get bored and drop out - you'd keep learning and exploring and getting better and better as time goes on. I wouldn't suggest that you think about money right away. The jobs that tend to make a good amount of money are the jobs where you can keep getting better and better, where someone who is really good, with a lot of experience, can be worth ten or a hundred times what someone might be worth when they're just starting out. Like programming. Or game design. And you're going to have a hard time getting better and better unless you really love doing what you're trying to do. So try a bunch of things, find out what you love to do, and then ask yourself, "Which of these things could I really become good at, if I did this for a living for the next ten years?" Start there.
What advice do you have for me as I think about my future education and career plans?
Explore! Try lots of things, read about lots of things, ask lots of people about the things they do, and follow your curiosity when something attracts your interest. I was in fourth grade when I first learned that it was possible to make your own computer games. Before that, I guess I just assumed they spontaneously materialized in the store, fully formed, like action figures or LEGO sets. But once my eyes were opened to this possibility, I started reading every book I could find about how to make games, buying educational software, signing up for programming classes. At the time I had no idea what I was doing so my efforts were surprisingly ineffective, but I was persistent. I just wouldn't give up. And this interest gradually grew from a drip and a trickle here and there into a full-fledged flood of obsession that has significantly shaped my life and taken me to where I am right now.
But game development was not the only field that caught my interest. In high school, for example, I read tons of books on biology, philosophy, and how the mind works, just because I was so fascinated by these subjects. I thought I'd end up studying evolutionary biology or psychology or neuroscience in college, even though I ended up in computer science. And there's nothing wrong with that. In middle school I was big into music, and I started learning to make bamboo flutes in high school. Throughout the last several years I've been doing a lot of martial arts practice. And I'm still working as a programmer. But the key is to keep exploring. Be curious. There are so many things you could do with your life. Your life's work and passion may turn out to be something you've never even heard of yet. Before fourth grade, I'd certainly had no idea that I could make a living making games. If I hadn't been willing to explore, I would never have found this path.
And, if you want to get a job in the game industry, the best thing you can do right now is start making games. I made my first computer game in sixth grade. It wasn't a great game, but it was something, and I learned a lot in making it. And more importantly, after that I made another one. And another one. And another one. If you don't know how to make computer games, go and find out how. Look online, read books, take classes - whatever you can find. There are so many more resources out there now than there were ten years ago when I was starting out. Download a free tool like Game Maker to get started - you don't even need to learn programming. Or make board games, and test them out with your friends - no programming required. Just make games, and keep making games, and by the time you are actually trying to convince someone to hire you, you will be able say, "Look at this. I made this. And this, and this, and this."
If you want to make games, make games.
Needless to say, the views expressed here are my own and do not necessarily reflect the views of Fugazo, Inc.
What is your name and job title?
My name is Alex Cho Snyder and I work as a Game Programmer at the casual game development studio Fugazo, Inc.
How long have you had this job?
I started this job on August 9th, 2010, so I've been working at Fugazo for about six months.
Please explain what a typical day of work is like for you.
I have breakfast at home, pack a lunch, and take the bus downtown to the office. I usually get there around 9:30am, but time is pretty flexible there, so it's no problem if you get there a bit late. I go to my desk - all our desks are together in the same big open-studio-style room - turn on my computer and wait for it to start up so I can check my work email, download the latest images and files that my teammates have added to the project from the SVN repository, and start up Visual Studio, which is kind of like Microsoft Word for programming code. I also look through my work notebook to refresh my memory about what exactly I've been working on and what I was thinking about the day before.
I work on a team of about three or four other people, making Fugazo's next hidden-object adventure game. There are about two other such teams at Fugazo, each working on a different game. Each team has one designer, one programmer, and two or three artists. I'm a programmer. I like to think of it in comparison to building houses. The designer is the architect, who draws the plans for the house and manages the overall process. The artists are the ones who prepare the pieces of the house - boards, doors, roofs, siding, etc. And the programmer - me - is the contractor putting the pieces together and actually building a functional house. I like building things, so it works out. But I really don't like remodels, where I'm taking an old building that someone else made and have to tear out old parts of the building and fix it up and add new rooms and features. You never know if one wall or pillar is okay to take out or if the whole building will collapse when you do. That's the annoying part.
In more specific terms, my designer will come to me with a feature or puzzle or something that he wants me to add to the game, and describe exactly what he wants while I ask questions until I feel like I understand completely. I usually like to write out the details of the task in my notebook by hand, because it helps me wrap my brain around the problem. Then I'll either start writing ideas for possible solutions, or look through the existing code of the game to get a better understanding of how the solution will have to fit in. Then I start actually writing code, and testing it out. Most of my time is spent going back and forth between thinking about the problem, reading code, and writing code. If I get stuck I'll ask the designer for clarification, or talk to our lead programmer to ask how he would recommend solving the problem. Once I've got something actually working on screen, I'll show the designer and ask him for feedback. Either he'll suggest more things to change, or he'll give me the next feature he wants me to build.
At noon we have an hour for lunch, and I often walk down to a nearby alternative school to volunteer-teach game programming to some middle-school kids. After that I'm back to work, until around 5:30pm when everyone leaves and I take the bus home or to martial arts practice for exercise.
What have you enjoyed most about your occupation?
That is a hard question for me to answer. I love thinking of ideas for games, and hashing out designs with teammates, but as a programmer that is something I am rarely involved in directly. In my role as a programmer, my enjoyment comes from exercising my near-magical ability to create imaginary worlds that live inside a computer screen. When I have gained enough understanding and familiarity with my tools that this process is no longer a confusing struggle but a mildly stimulating problem to solve, I find this very enjoyable. This usually happens when I am asked to create a smaller puzzle within a larger adventure game, where I can visualize the end result I want and then figure out how to actually build it with computer code. When things are going smoothly, I can go from start to finish in this process within a day or two.
I like seeing the fruits of my labor up on the computer screen - the quicker and more immediate, the better. I like to take something that works, that I can see and play around with, and tweak it and adjust it until it's just right. It is very rewarding to me to see and appreciate and savor this thing I have created, and when I am deprived of that gratification for too long I can easily become frustrated. I'm quite stubborn, so I don't give up when things take a long time to sort out. That doesn't mean I have to like it, though! :p
Do you believe most of your fellow colleagues or workers enjoy their work? Why?
I think they do. But not necessarily in the way you might assume. Many people mistakenly conflate the fun of playing games with the hard work of making them. I like to compare the process of game development to cooking or baking. Most people love to eat pastries and cookies and donuts, just like most people enjoy playing games. But not everyone likes to bake those cookies, and not everyone likes to make games. If you want to become a baker, it certainly helps to like eating pastries. But it's not enough.
Some game companies are more like donut factories. They are not fun places to work. Fugazo, where I work, is more like a successful neighborhood bakery. The work isn't amazingly fun, but it's usually interesting, and the people are nice, and it's not a bad place to be all day. And at the end of a project, after a few months, you have a finished game that's pretty cool and you can feel proud of it and show your friends and family and all that. And you get to think about games all the time.
If you could change anything about your occupation what would it be?
If I could make games without ever having to sit at a desk and stare at a computer screen, I would. If I could run around in a virtual forest, climb inheritance trees and swing from conditional branches, build towers with blocks of code, and just use my physical body and my stereoscopic vision and my musical ears and my agile primate fingers, I would be so much happier. I love plants; I love being outside. I also love the ability to create virtual worlds that other people can experience, through computers. But every minute that I spend in front of a computer screen is a sacrifice that I make in exchange for this power to shape (virtual) reality.
More realistically, if I never had to renovate another programmer's poorly encapsulated user interface code, that would be awesome. Most frustrating part of my job right there. Also, if I had more teamwork throughout the day, I think I would enjoy that. I love collaboration, and I get just enough of it to avoid feeling unbearably lonely throughout the day, but I really get very little. There's something called pair programming where two people share a computer and take turns writing code and observing, and I've done that a few times in school and I think I'd very much like to do that again. However, it's obviously not as feasible in a small company like Fugazo where each game has only a single programmer to work on it.
Have you gone back for more educational training since you began the job?
Nope. For me, working at this job is all the educational training I need! It has been at least as educational as an equivalent time at school was, in the six months I've been at Fugazo. In computer programming, school can be essential to getting started, but once you're actually working, you should be learning a lot as you gain experience and your company starts branching out to new technologies and platforms. At the least, you can learn a lot from your own side projects as well.
What educational background do you have?
I graduated from the University of Washington with a Bachelor's degree in Computer Science. It took me a little less than five years at the UW to decide on my major, take all my required classes, and graduate. Throughout college, however, I had a summer internship or two working as a programmer and also made quite a few of my own games on the side, which is crucial if you're trying to get a job after graduating. Just a Computer Science degree doesn't cut it. You need to have experience working at a programming job, at least as an intern, and show that you have the passion, skill, and discipline to make your own games in your free time.
If you won the lottery and did not have to work, would you? Explain.
For a while, at least. ;) I decided to look for a job last summer so I could earn money, spend my days working on a team instead of by myself, and get experience learning from people who know what they're doing instead of fumbling around on my own. The lottery would only take care of one of those things. My life's work is to change the world through games. The most important thing I can do right now is to hone my skill at designing and programming games, and become fluent in all other aspects of the process as well. I will work at a company for as long as I need to until I'm ready to strike out on my own and form my own team, and I can't imagine finding a better place for that than Fugazo right now. A lot of game companies are not fun places to work. Fugazo is a notable exception.
What kind of strategies do you use when your job gets stressful?
Programming is often frustrating and can easily get stressful if you are not careful. I find it important to take breaks whenever I am really stuck or not thinking clearly, and I find that taking a walk right before lunch is very helpful in clearing my head. I also have started giving myself permission - with my boss's encouragement - to take short naps when I feel sleepy, especially in the afternoon. When it comes to jobs like programming that consist almost entirely of difficult problem-solving, it is often much more efficient to take a twenty-minute nap and come back refreshed than to fight back sleep deprivation for three hours without getting anything done. As with any sort of activity that involves sitting at a computer and staring at a screen all day, I've also found it very helpful to take a few minutes every so often to get up and move around, do some handstands, stretch, get my blood flowing, and help loosen whatever mental rut I might have gotten into while hunched over at my desk.
In your career field, is it difficult to balance work with home/family or personal life?
The game industry is one of the most notorious when it comes to poor work-life balance. This is a problem that is slowly improving, but it is definitely a real concern. Many companies, because of poor scheduling, can have months of forced "crunch time" at the end of a project, where people are working evenings, even weekends, continuously until the game is finished. Obviously, this is a very bad thing and it is arguably counter-productive in the long run, but many companies still do it. Even at Fugazo, where I work now, there may be a week or two of crunch at the end of a project, where I stay late in the evenings, but I've never worked weekends. Even then, no one is forcing me to stay late - I choose to keep working because I have a long list of things I want to get done, and I tend to be a perfectionist about these things. And I'll usually be the only one working late on most occasions, since no one is forced to crunch.
Outside of extreme circumstances like crunch time, I do often struggle to balance work and personal life. I wouldn't necessarily attribute this to the game industry itself. I think this has more to do with my inexperience (I've been working full-time for less than a year) and my tendency to cram way more things into my life than I could reasonably have time for. Though maybe the game industry tends to attract people like me anyway, so who knows!
What was it like when you went to high school? What kind of career planning did you have in high school?
I started high school about eight years ago. Back then, I wasn't thinking about jobs at all, but I knew that I wanted to do something with games. At the time I was doing a lot of programming on the graphing calculators we used in math class, making little games and releasing them online. I was also starting to read about using games for education and social change and became inspired to make that my life's work. As it turns out, those were the perfect things to be doing if I later wanted to start a career in game development!
What do you feel is most important when choosing a career?
There are a lot of ways to think about this question. One approach that I like is to think of something that you could see yourself getting really good at, if you spent the next ten or twenty years doing it for a living. That doesn't mean something you are already good at, necessarily, but something that you could see yourself learning to get really good at. I started learning to make games about ten years ago. The reason I choose to make games for a living now is not that I'm particularly good at it now, but I could see myself becoming really good at designing and making games over the next ten years. And that has less to do than the skills I currently have, and more to do with my passion and what I'm excited about and what I enjoy doing and learning and thinking about in my free time.
If you really love to do something, chances are that you could get really good at it - that if you kept doing it for a living over the next ten years, you wouldn't get bored and drop out - you'd keep learning and exploring and getting better and better as time goes on. I wouldn't suggest that you think about money right away. The jobs that tend to make a good amount of money are the jobs where you can keep getting better and better, where someone who is really good, with a lot of experience, can be worth ten or a hundred times what someone might be worth when they're just starting out. Like programming. Or game design. And you're going to have a hard time getting better and better unless you really love doing what you're trying to do. So try a bunch of things, find out what you love to do, and then ask yourself, "Which of these things could I really become good at, if I did this for a living for the next ten years?" Start there.
What advice do you have for me as I think about my future education and career plans?
Explore! Try lots of things, read about lots of things, ask lots of people about the things they do, and follow your curiosity when something attracts your interest. I was in fourth grade when I first learned that it was possible to make your own computer games. Before that, I guess I just assumed they spontaneously materialized in the store, fully formed, like action figures or LEGO sets. But once my eyes were opened to this possibility, I started reading every book I could find about how to make games, buying educational software, signing up for programming classes. At the time I had no idea what I was doing so my efforts were surprisingly ineffective, but I was persistent. I just wouldn't give up. And this interest gradually grew from a drip and a trickle here and there into a full-fledged flood of obsession that has significantly shaped my life and taken me to where I am right now.
But game development was not the only field that caught my interest. In high school, for example, I read tons of books on biology, philosophy, and how the mind works, just because I was so fascinated by these subjects. I thought I'd end up studying evolutionary biology or psychology or neuroscience in college, even though I ended up in computer science. And there's nothing wrong with that. In middle school I was big into music, and I started learning to make bamboo flutes in high school. Throughout the last several years I've been doing a lot of martial arts practice. And I'm still working as a programmer. But the key is to keep exploring. Be curious. There are so many things you could do with your life. Your life's work and passion may turn out to be something you've never even heard of yet. Before fourth grade, I'd certainly had no idea that I could make a living making games. If I hadn't been willing to explore, I would never have found this path.
And, if you want to get a job in the game industry, the best thing you can do right now is start making games. I made my first computer game in sixth grade. It wasn't a great game, but it was something, and I learned a lot in making it. And more importantly, after that I made another one. And another one. And another one. If you don't know how to make computer games, go and find out how. Look online, read books, take classes - whatever you can find. There are so many more resources out there now than there were ten years ago when I was starting out. Download a free tool like Game Maker to get started - you don't even need to learn programming. Or make board games, and test them out with your friends - no programming required. Just make games, and keep making games, and by the time you are actually trying to convince someone to hire you, you will be able say, "Look at this. I made this. And this, and this, and this."
If you want to make games, make games.
2009/11/08
Playtesting the Enemy
You've probably heard that it's a good idea to playtest your game. If you haven't heard, well, I'm telling you now. It's a good idea.But how about playtesting other people's games?
I was reading a book called Don't Make Me Think, a classic in web design and usability. At one point, the author suggested doing a usability test of a competitor's website before you start designing your own.
Why not apply it to game development?
If you're thinking of making a particular type of game, find an existing game that may have some relevant similarities, and do a playtest of it.
Find a random person, sit them down in front of the game, and observe. Watch for what they enjoy, what confuses them and where they get frustrated.
Then repeat with other random people and other games. Do it with both good games and poorly designed games. You will learn more by testing both than by only looking at one or the other. See where the bad games fail and what the good games do differently.
And then when you go to design your own game, you will know what mistakes to avoid.
2009/10/08
Where to Start with AS3, FlashDevelop and Flixel
the free tools of the trade...
I've been working with Flash for a few years now. But I didn't switch over to programming with ActionScript 3.0 until earlier this summer. And I have to say, I've found AS3 to be so much easier to work with than AS2. I'm glad I switched.
Here's where to start if you want to make Flash games with AS3. If you do it this way, it's all free, and you don't need any prior experience with programming, or Flash.
If you forget everything else I'm about to tell you, just remember these two words:
- FlashDevelop
(it turns code into programs)
- Flixel
(it helps you make game code)
So, where do you start?
Step 1: FlashDevelop
so shiny...Start with the Making Games in ActionScript 3 using FlashDevelop tutorials! They'll tell you everything you need to download, how to install it and get it all set up, and walk you through all the basics of a typical Flash game.
Here they are:
- MGAS3FD 1: The Setup
- MGAS3FD 2: The Beginning
- MGAS3FD 3: Getting on with it
- MGAS3FD 4: More embedding
- MGAS3FD 5: Enter the frame
- MGAS3FD 6: Click it like it’s hot
This tutorial will assume some basic familiarity with object oriented programming, a graphical tool of your choice and general computer literacy.
If you have any questions, you are welcome to post them here - I'll do my best to help. :)
But first, I'd recommend having a look through the Understanding Classes in AS3 tutorials!
If you’re stuck in an ActionScript 2 rut, or you’re new to ActionScript 3 and it’s blowing your mind, this should help ease you in a bit better.
Here they are:
- Understanding Classes in AS3 Part 1
- Understanding Classes in AS3 Part 2
- Understanding Classes in AS3 Part 3
- Understanding Classes in AS3 Part 4
All right.
Have you gone through the Making Games in AS3 tutorials? Have you gotten FlashDevelop all set up, and maybe made a simple program or two?
If not, then go back and do it!
If yes, then you're ready to move on to the next step! :D
Step 2: Flixel
so pixelicious...Don't bother making games from scratch. Make them with Flixel.
flixel is a completely free collection of ActionScript 3 files that helps organize, automate, and optimize Flash games; an object-oriented framework that lets anyone create original and complex games with thousands of objects on screen in just a few hours.
Oh yes.It's the same game engine that was used to make Canabalt.
Start by downloading the latest version of Flixel, then follow these instructions to get a something showing up on the screen. If it works, download this example game and follow these quick instructions to run it:
If you can get the example game to work, you can move on to these two step-by-step tutorials on how to build a game from scratch using Flixel:
- Making a simple brick breaker game with Flash and Flixel
- Making a platform game with Actionscript and Flixel
Then you can try this more in-depth tutorial on how to make a spaceship shooting game from scratch using Flixel:
Follow along, and by the end of it you should have three little action games and the knowledge to start building your own games with Flixel!To help you in your journey, there is the Flixel documentation, the Flixel wiki, and the help forum where you can ask questions and find answers. Also, the Flash Game Dojo. And of course, Google is always helpful.
If you get tired of using Flixel, for some strange reason, and you want to build your own game engine, you can give this tutorial a try. For experts only!
Update:
Flixel has changed a lot since I first wrote this post, so I recommend you check out this more recent guide on How to Learn Flixel if you're just getting started now.
Lastly, here are a few tools that may come in handy.
Unless you're making games for blind people (which is awesome) you'll probably need some way to make graphics and animations for your games. I'd highly recommend using the free image editor Paint.NET for this purpose. It's great for pixel art, and easy to use despite having a lot of nice features in it.Similarly, you'll probably want to have sounds in your game. For general sound recording and editing, try the free sound editor Audacity. Again, it's easy to use and is capable enough for recording and modifying sounds. I use it mostly to clean up recordings or save sounds into different formats and file sizes.If you're not interested in recording your own sound effects, you can generate them, with the amazing free tool called sfxr. Just click a button to get a randomized game sound, or change the settings manually to get the sound you want. It's perfect for games.
The creator of sfxr has also released a free tool for making game music, called musagi. I haven't tried it yet but I hear it's pretty good.There are quite a lot of nice, free tools out there if you know where to look. Here's one list that you might find useful.
That's all I have for you! Now go make some awesome games with FlashDevelop and Flixel. And let me know how it goes. I'm here if you have any questions. :)
Good luck!
2009/07/05
The Coming Revolution in Flash Games
This will be our manifesto. Daniel Cook of Lost Garden has just posted the first installment of his epic Flash Love Letter, an attempt to provide an answer for why Flash game development, despite its amazing potential, fails to produce awesome, world-changing games. And of course, a plan to get Flash games back on track.
"I think that you, Flash game developers, are some of the most talented and inspirational people working today in game development. Your passion for building games burns so incredibly brightly. Your ability to quickly make and distribute games is second to none. You hold immense potential to transform the future of games."
The first part is about making money with Flash games. A popular subject these days. When developers can't make a living making Flash games, there's going to be a lot fewer people making games, and a lot fewer good games out there. So, why don't Flash games make much money, and how can we change that?
"There is one obvious fact: the entire flash ecosystem is driven by low quality advertising. Piddling amounts of ad money flows into the developer's pocket through a variety of obfuscated middlemen."
Daniel Cook is definitely in favor of just asking players for money, instead of getting them to click on ads. It's easier than you'd think! And it pays a lot better than ads. You might even be able to make a living off of it.
"When game developers ask for money, they are usually pleasantly surprised. Their customers give them money; in some cases, substantial amounts."
"Many Flash developers insist on giving away everything for free. Stop devaluing your work and start creating a premium offer."
"We live in a capitalist society so people understand the concept of buying something. Don't ask for a donation. Don't ask players to 'give you what they feel like giving.' People will think you are a charity case and in my experience your revenues will drop by 90% or more. Give the offer a specific price, be it $10 or 200 gold in your favorite virtual currency."
So how do you actually get the money? On the subject of payment providers and portals, Daniel Cook has some advice, and some excellently developer-centric opinions...
"A payment provider should be a reliable commodity service, not a major business partner."
"The ideal payment service is one with low margins, low switching costs, no branding and APIs that let you cheaply and easily tie into generic, developer controlled login and storage services."
"The market is highly fragmented (30,000 portals!) and no portal owns more than 5% of the players. At this point in the market, developers have the ability to walk away from the greedy minority. Suggest reasonable terms where portal keep their existing ad revenue and you keep all in game revenue. If they balk, leave the bastards to rot."
Oh snap! Take that, portals! ;)
The most important takeaway from Part 1 is this:
"If you make a great game played for hours on end by millions of people, you deserve to be paid. Stop worrying about how people 'might' react. Ask a fair price for the value that you provide."
Can't wait for Part 2. :D
"I think that you, Flash game developers, are some of the most talented and inspirational people working today in game development. Your passion for building games burns so incredibly brightly. Your ability to quickly make and distribute games is second to none. You hold immense potential to transform the future of games."
The first part is about making money with Flash games. A popular subject these days. When developers can't make a living making Flash games, there's going to be a lot fewer people making games, and a lot fewer good games out there. So, why don't Flash games make much money, and how can we change that?
"There is one obvious fact: the entire flash ecosystem is driven by low quality advertising. Piddling amounts of ad money flows into the developer's pocket through a variety of obfuscated middlemen."
Daniel Cook is definitely in favor of just asking players for money, instead of getting them to click on ads. It's easier than you'd think! And it pays a lot better than ads. You might even be able to make a living off of it.
"When game developers ask for money, they are usually pleasantly surprised. Their customers give them money; in some cases, substantial amounts."
"Many Flash developers insist on giving away everything for free. Stop devaluing your work and start creating a premium offer."
"We live in a capitalist society so people understand the concept of buying something. Don't ask for a donation. Don't ask players to 'give you what they feel like giving.' People will think you are a charity case and in my experience your revenues will drop by 90% or more. Give the offer a specific price, be it $10 or 200 gold in your favorite virtual currency."
So how do you actually get the money? On the subject of payment providers and portals, Daniel Cook has some advice, and some excellently developer-centric opinions...
"A payment provider should be a reliable commodity service, not a major business partner."
"The ideal payment service is one with low margins, low switching costs, no branding and APIs that let you cheaply and easily tie into generic, developer controlled login and storage services."
"The market is highly fragmented (30,000 portals!) and no portal owns more than 5% of the players. At this point in the market, developers have the ability to walk away from the greedy minority. Suggest reasonable terms where portal keep their existing ad revenue and you keep all in game revenue. If they balk, leave the bastards to rot."
Oh snap! Take that, portals! ;)
The most important takeaway from Part 1 is this:
"If you make a great game played for hours on end by millions of people, you deserve to be paid. Stop worrying about how people 'might' react. Ask a fair price for the value that you provide."
Can't wait for Part 2. :D
2009/06/30
Ten Ways to Monetize Your Flash Game
I'd love to be able to make Flash games for a living. But the way things are right now, only the biggest success stories are able to sustain themselves on Flash alone. The rest of us must approach Flash game development as a hobby, on the side of school or work.Part of the problem is that while Flash games are amazingly popular, there are very limited opportunities to actually make money from them. The vast majority of Flash games make money through ads or sponsorships or both. Originally, sponsorship was the main way for developers to make money, through sites such as Armor Games. Then in-game advertising became widespread, with the emergence of easy-to-use services like MochiAds. But so far, few games have succeeded in taking the next step - taking money from the actual players.
Lately I've been doing a lot of research into how games can make money, particularly Flash games. I've come across some very intriguing new monetization models, including some that have been successful in other games but have not yet been widely applied to Flash. I'd like to share what I've found, and hopefully inspire you to try some of these new strategies in your own games.
Before we get started though, this guy has one piece of advice for you: decide on your monetization model before you make the game! When you know how you're going to make money, you can design your game from the ground up to support your decision. It's a lot harder to tweak an existing game. Just think of monetization as just another component of your design, along with interface, progression, gameplay, graphics, and so on.
As this guy says, again,
"New monetization models open up new design possibilities."
You should be excited. This is exciting. New ways to make money equals new stuff to design.
Let's get started.
1. Advertising model
This is the most common way to monetize a Flash game. You can put ads in the loading screen of your game with services such as MochiAds or CPMStar, or just stick the game in a web page and put Google AdSense around it. You get money based on how many times these ads are viewed, so the more people playing your game, the better.
With ads embedded in the loading screen, you'll get money whenever your game is viewed, no matter what site it's on. If you have your own web page ads, these will only give you money when people play the game on your site, though they usually pay more per view.
2. Sponsorship model
Another common way to make money is to have your game sponsored. This means that a game portal, such as Kongregate, will pay you to put their logo in your game along with a link to their site. This helps bring more visitors to the portal site, which means that they get to make more money from their own web page ads.
Sponsorships are a good way to get a lot of money upfront, but you can only sell one sponsorship per game, and often your sponsor will not let you put your own ads in the game. This arrangement is called an "exclusive" sponsorship, because you can only have one sponsor. But other options are gaining in popularity, such as the primary sponsorship, where you still have one primary sponsor, but you are also allowed to sell restricted licenses to other websites.
3. Licensing model
This brings us to the next monetization model, licensing. Here, a game portal will pay you to make a special version of your game with their logo in it, and maybe connect up with their high score system. They will then host this special version on their site, but you are free to use a different version when putting your game on other websites. It's site-locked and non-exclusive. That means that you can sell separate licenses to a bunch of different websites, and make money from each one.
Individual licenses bring in less money than a typical sponsorship, but they are much more flexible, and they add up. You can combine them with advertising, with primary sponsorships, or both. You can also combine them with hosting a version on your own website.
4. Portal model
How can game portals afford to spend so much money sponsoring and licensing games? They must make even more money somehow, and that somehow is through web page ads. Some say that the best way to make money is to make your own website and host your game there. Lock the game to your site so no one else can steal it, and put some AdSense around it. Then spread the word about your game and hope it becomes popular.
If you don't have enough games of your own to keep people on your site, you can easily add other games with the MochiAds Publisher service. There are a number of tutorials out there explaining how to build your own portal. Here's one of them. This may help too. You can then sponsor your own games, by putting your logo in them with a link to your site. It may take more work, but the payoff can be greater than simply getting a sponsorship with an existing portal.
5. Premium model
Now here's where things get interesting. The methods we've discussed are all very indirect - your money comes from advertisers or portals. But now let's talk about taking money directly from your players.
The premium model means that you make a free game, and then you sell some extra, premium content to players who want more. This approach is slowly catching on, from an early, well-documented experiment with Drunken Masters, to the more recent success of Fantastic Contraption, making over a hundred thousand dollars in premium content sales. If you can make a game that's as good as Fantastic Contraption, and it makes sense to charge for extra features like a level editor, then selling premium content directly to players can be much more lucrative than advertising or licensing alone.
Just keep in mind that there is a very delicate balance between how much of the game you make available for free, and how much you reserve for paying players. If you are charging money for an experience that people could get for free somewhere else, then you will not be successful. But if the premium content doesn't feel valuable and 'premium' enough, few people will choose to buy it. This article suggests that you make the most popular parts free, so more people will try it out and like it, and only charge for specialized, niche content that very dedicated players will want. Advertising will pay for the free players.
And don't be afraid to charge a lot. Make the extra content worth it. Drunken Masters charged $1.50 for its premium content. Fantastic Contraption charged $10. Which do you think made more money? The hard part is getting players to pay at all. The difference between paying a dollar and paying ten is very little, once you've got your credit card out. Make your game worth ten, and ask for as much as you can.
6. Subscription model
So you've gotten your players to pay for premium content. But they're only paying you once. Wouldn't you rather have them pay you again and again and again? That's what subscriptions are all about - recurring revenue. Make premium content and special features only available to players who pay every month.
But hardly any Flash games are meant to be played for more than a month. If you want to get into subscriptions and really make some money, you need a different kind of Flash game, one that players can invest in, with their time and money, and feel like they are accomplishing something worthwhile. By far the easiest way to create this sort of feeling is to build a community around the game. Social bonds connect a game to reality, and can make a mediocre experience much more compelling.
This doesn't necessarily mean multiplayer, but if you want community, there has to be some way for players to interact with each other, whether that is by sharing custom-made levels or racing in real time. And there must be some form of persistent, saved data from the game that players can build up over time. Achievements and high scores are simple examples of this. But for the subscription model, you will need something more significant, such as a virtual world, customizable characters, or an in-game economy. You provide this larger context where the gameplay means something, and you charge money every month for players to get in.
But how much do you charge? If you set the price too high, some players might just give up and play something else. If you set the price too low, you could be leaving a lot of money on the table. But there's an alternative! Make the basic game free, the same way you would when selling premium content, and then have several "stackable" levels of subscription that players can buy. Maybe if players buy the first level subscription, they get access to some special clubhouse but they also get twice as many coins from playing the game as a free player would. Then players who pay twice as much and buy the second level of subscription get four times as many coins, and so on. Let players spend as much or as little as they want!
7. Micropayment model
This philosophy reaches its extreme in the micropayment or microtransaction model, where the game is largely free to play, but players can also spend real money in the game to buy special items. The way it usually works is that there are at least two different currencies in the game world: one earned by playing the game, and one that players get by putting in real money. Some items can be bought solely with currency earned in the game, and some can only be bought by spending real money currency.
You must be very careful when designing for this monetization model, or else free players will feel cheated when their skill and effort is thwarted by someone who simply paid to get ahead. For this reason, micropayment games often sell only decorative items for real money, and require players to earn the items that give them an advantage over other players. This works if there is a strong social component to the game. But in a cooperative game, players like it when someone else pays for a powerful item, because it will help them out too! Take a look at this article if you want a more detailed discussion of the design considerations involved.
If you're going to make a micropayment-based game you're going to need some sort of payment system, so players can spend money in the game. Fortunately, there are a number of payment providers all ready to be plugged into your virtual economy. Gambit is one example. But if you're looking for something even easier to integrate, a bunch of new virtual currencies have popped up for Flash recently. If you don't mind sharing your currency with other games, one of these might be the right choice for you.
8. Rental model
This model is crazy. It's a variation on the micropayment model, but adapted for a highly skill-based competitive style of game, such as the first-person shooter Combat Arms. In the rental model, you earn points and use them to buy items, but as the name implies, these items only last for a limited amount of time before they expire and you have to buy another one. Because players always return to the same baseline of power as their items expire, these rental items can provide significant gameplay enhancements without making the game feel too unfair.
You could allow players to pay real money for these items directly, but to make the game feel more fair you can instead let players spend real money on enhancements that help them earn points faster. That way everyone still has to play and earn their way through the game, but players who pay won't have to work quite as hard. And of course this can be combined with a more typical micropayment approach, selling purely cosmetic items for real money.
The advantage of the rental model is that players will keep buying the same items over and over again, so you can produce a smaller set of items than you would if players were buying a different item everyday like they might in a typical micropayment game. It also makes it feasible to charge lower prices for a given item, since each player will buy it more than once. Overall, the rental model may prove to be the most appropriate for a multiplayer game too small to justify a subscription or a huge number of items to sell.
9. Ransom model
If integrating a real money currency system and creating a bunch of items for your game seems like too much work, you could always just hold your game for ransom. In this model, you set the amount of money that you want to get from the game, and then you don't release your game until you've received that amount in donations. Once you release the game, though, it's free for everyone. And if you want to be nice, you could refund everyone for their donation if your ransom isn't met. This is called a threshold pledge.
The nice thing about this is that you don't really have to do any extra work. Just start making a free game and get donations for it. There's a nice little site called Kickstarter that takes care of all the details for you. Of course, you have to have enough of a reputation that you can get a bunch of people to pay you to release your game in the first place. It probably won't make you rich, but if you can attract enough support it could be perfect for small projects.
10. Patronage model
Last but not least, we have the patronage model. Like the ransom model, it is based on donations. But here, people are encouraged to donate larger amounts in exchange for exclusive and personalized recognition. A recent example of this is the donation system Daniel Benmergui set up with the release of his artistic game Today I Die. If you donate a certain amount, you get your name in the credits of his next game. If you donate one hundred dollars, you'll get a poster of one of his games with the characters replaced by whoever you want. And the first person to donate a thousand dollars gets to choose the characters and a new ending for a custom version of the game. Judging by the donation page, the game has brought in at least two thousand dollars in donations so far.
The key here is to make the people who donate, the patrons, feel special. People will pay more because they've gotten something unique and personalized. This approach requires that you give a lot of attention to your fans, and that you can attract enough of them, first of all. If you want to be an artist, and you are prepared to cultivate one thousand true fans, patronage may be the best option for you.
Want to learn more about making money from Flash games? Have a look at some of these other articles on the subject. Let me know if you have anything to add!
Update:
The ultimate treatise on Flash game monetization has arrived, in the form of Daniel Cook's Flash Love Letters! Make sure to read both Part 1 and Part 2. Oh, and don't miss the music video, either! ;)
If you like those, check out Cash Cow Part 1 and Part 2, an excellent set of articles on how you might put the Flash Love Letters into practice.
Subscribe to:
Posts (Atom)
