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 money. Show all posts
Showing posts with label money. 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/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.
2010/06/10
Game Idea Giveaway - City Basher
Last year, I wrote up this game idea giveaway for Emanuele Feronato to post on his popular Flash game development blog. But after waiting for many months without a reply from him, I decided to post it here so I can finally share it with all of you!
Be warned, this giveaway is epically long. My longest yet.
...continued from The Game Idea Giveaway Thread
Request by triqui:
The idea: City Basher
In short, City Basher is a physics-based multiplayer artillery game combined with a trading card game (like Magic: The Gathering). It's a competitive game where you try to knock over your opponent's buildings, and it is designed to work very well with microtransactions.
This game is founded on the wide appeal of vanquishing strangers over the Internet and the primal joy of toppling carefully built towers of blocks, without the bother of having to actually build them in the first place. For that reason, the game is primarily a quick deathmatch experience, like most online multiplayer games aimed at bloodthirsty teenage males. Though there is also the option for team play and casual matches between friends.
Like other multiplayer artillery games, most notably Worms, each play session is short, measured in minutes, and involves only a handful of players. But as a game supported by microtransactions, players maintain a persistent identity across play sessions, retaining their avatar, items, resources, and statistics. This is the approach taken by Gunbound, a multiplayer artillery game that was one of the earliest successful microtransaction-based games to establish itself with Western audiences. Gunbound made its money by selling avatar decorations. City Basher will do that, and more. Much more. [cue dramatic music]
Each play session takes place in a 2D arena, seen from the side. The arena is full of buildings, structures of physically-modeled blocks, some solidly stacked, some precarious. At first, the arena is a neutral territory, dominated by a huge monolith in the center. Players take their places in the arena, each one piloting a vehicle with a mounted cannon or two. The game begins, and players open fire on the buildings to convert them to their own color. When one player topples an enemy building, a new building rises up in its place, owned by the player who placed the final shot and color-coded accordingly. The session ends when the neutral monolith in the center is toppled, and players are awarded their final scores.
The play format is very flexible. The game is not zero-sum. Players play for points, not simply to defeat their opponents. If you destroy one of my buildings, you are rewarded and I am penalized, but your success does not depend on my failure. It merely happens to coincide with it. Players are never eliminated from the game, though they are free to leave at any time - their buildings are simply replaced by neutral ones. And most arenas would support a varying number of players depending on how many people are available. If there are slots open, new players can join an existing game. This is very important for a casual multiplayer game like City Basher.
Since this is a game supported by microtransactions, we want to make everything into an item that can be bought and used up. Not that players would necessarily have to pay real money for everything in the game, but it's nice to have that option. What this does is set up the expectation that things can be bought. If players get used to paying for items with virtual currency earned in the game, they'll be more open to paying real money for the really valuable items they might want later on. In City Basher, these items consist of vehicles, weapons, buildings, arenas, avatar decorations, and general enhancements.
Gameplay
An important part of most any game is the movement, how a player gets around in the world. In City Basher, vehicles encapsulate this piece of the gameplay. Every player starts with a basic vehicle that is like a slow-moving tank. But other vehicles could be bought. They might move faster, they might be smaller or larger or shaped differently, and some might even fly or hover or jump. However, movement isn't the focus of this game, so it should be kept fairly simple. As a result, each vehicle is controlled in more or less the same way - that is, with the arrow keys or with the mouse, following the mouse cursor. Also for simplicity and to minimize the effect of lag, vehicles would not be able to collide with other vehicles or knock over buildings. Instead, they would pass through other vehicles harmlessly and treat building blocks as immovable terrain.
The real fun of the game starts with the weapons. This is the part that puts the artillery in artillery games. As is typical in the genre, the basic weapon is a slow-firing cannon, which the player must aim by setting the angle and power of the shot with the mouse or keyboard. There are a lot of ways to set up the specific controls for this action, so I won't go into too much detail here. The easiest way I can imagine is just to click the mouse to set up an attack, move the cursor to set the angle and power, and click again to fire. This way, you could fire off a quick shot by double-clicking. Since attacking is a focus of the game, different weapons could even have different methods of control, as long as they support both the keyboard and the mouse.
For a game like this, there would be dozens, if not hundreds, of different weapons to buy. Some might be variations on the basic cannonball, maybe with extremely high mass for extra power on stable buildings, or a small but extremely bouncy ball that can ricochet off multiple blocks and quickly take out more delicate structures. Some weapons might shoot several balls at a time, or an explosive shell, or several balls chained together. Others might be a different kind of weapon altogether, like a rocket launcher or a block-melting death ray. There are a ton of possibilties here - just look at a game like Worms for example. Each weapon would have a certain reload rate, a waiting period of anything from a half a second to several minutes before they can fire again. This would help to give the game a more strategic, turn-based flavor, without the turns. For this reason, there could also be weapons that are weak but useful because of their rapid firing rate. Another part of the strategy would be in selecting your arsenal, since you can only bring a limited number of different weapons into each game.
The other focus of the game is on buildings. Weapons are what you use, and buildings are what you use them on. So naturally, you'd be paying a lot of attention to them. Just like there are different types of weapons, there are also different types of buildings, each one a particular configuration of blocks of various size, shapes, and masses. Some have special side effects too, that are active while the building is in play. For example, one building might increase the mass of all your other buildings while it is in play, making them harder to knock over. There could even be a building that increases the strength of gravity over the entire arena, or doubles your score from every hit. It's a lot like the way that different cards have rule-changing effects in games like Magic: The Gathering or Pokemon.
The similarities don't end there. City Basher handles buildings just like cards in a trading card game. You don't build buildings, you collect them. Each player has a bunch of building cards in their collection. Each of these cards represents a particular building type, though a player might own several copies of the same card. When you join a game, you choose a set of cards from your collection that will be available to you during the match, in the form of a deck of cards. Like any trading card game, there is a limit to the number of cards that you can include in a single deck, and a limit to the number of duplicates you can use of the same building card. This means that you have to put some thought into which ones you choose. Some players might even spend more time just designing their decks than they do in playing the actual game!
When you choose which deck you want to use for a play session, this determines the type of buildings you can get in the game. Whenever you are due to have one of your own buildings pop up in the arena - say, when you topple an opponent's building - a random card is taken from your deck, and placed in the arena as a new building. When that building is toppled, the corresponding card is returned to your deck. That means that if you have three copies of the Citadel of Awesomeness card in your deck, you can have up to three Citadel of Awesomeness buildings in play at any time. And if you have no more cards in your deck when you destroy an enemy building, that building is replaced by a neutral one instead. The most powerful buildings are designated as Legendary buildings, and can only sprout up in special Legendary building slots, of which there might only be one or two in any given arena. Legendary building cards are ignored when drawing for normal building slots. This helps keep the game balanced.
Finally, there are the arenas, where the games take place. These are not items owned by individual players, but the effect is similar, since players may have to spend points or money to access certain arenas. At its core, an arena is a 2D map of indestructible terrain with a bunch of building slots scattered around - areas on the ground where a building may sit. One of these areas is reserved for the monolith, the giant neutral building that ends that game when it is toppled. The arena defines what this monolith looks like, as well as the deck of possible neutral buildings that may pop up. Each arena also specifies how many players are allowed at a time and where they appear at the start of the game. Lastly, each arena defines its own physical properties like gravity, air resistance, and wind, as well as the background graphics and sounds that make up the feel of the place.
Monetization
In a typical microtransaction-based game, there are two types of virtual currency involved in the in-game economy. One is earned through playing the game, like experience points. The other is bought for real money, which is how the developers make a profit. City Basher is no exception. Players can exchange their real money for a virtual currency we'll call Coins, and they can also earn another virtual currency, Points, through gameplay. The names used here are just for convenience, by the way - in the actual game you'd probably want something a bit more glamorous.
Players can earn Points in a number of ways. The most common way to earn Points is to knock down an opponent's building. You don't have to knock it down completely to get points - you only have to reduce its height with your shot. Each type of building is worth a certain number of Points to topple, and you get a fraction of that for every fraction of the building's original height that you knock over. However, you only get to replace it with a building of your own if you deliver the final blow, one that topples the building completely. The advantage to having lots of your own buildings in the arena is that at the end of the game, when the monolith falls, you receive Points for each of your buildings according to their remaining height and Point value.
This results in a system where new players can join in the middle of an existing game without having any unfair advantages or disadvantages relative to the other players. It also encourages players to stick around for the whole session in order to earn bonus points at the end for their remaining buildings. At the same time, no one is bothered if they leave, since their buildings are replaced by neutral ones which yield Points just as readily as player buildings. And it works just as well for team games, since players on the same team simply share a single color, and don't earn any Points from toppling their teammates' buildings. On the whole, it is a scoring system designed to reward good players, without punishing the players who aren't as skilled. This keeps the game accessible to casual audiences. And that means more money for you.
So, let's talk a little more about money. Specifically, let's talk about what players spend it on, and why. First of all, let me emphasize that the game itself is free to play. Players are not spending money just to play the game, they are spending it to buy virtual items inside the game. This is what it means to have a game based on microtransactions. Second, it is important to understand why players would want to buy these imaginary items at all. Players will spend money not so much as an exchange but as an investment. It's not about exchanging value. Why would a player give you real money for nothing? It's about investment. A player gets some significant value through playing the game for free, and then they think that they could enjoy even greater value in the long run if they invest a little bit of their own money right now. They should feel like they're getting a great deal every time they spend money in your game. If you can keep this one principle in mind, all the rest of your monetization decisions should follow naturally.
Here's how it works in City Basher. All items are bought with either Points, Coins, or some combination of both. Some items are permanent, some get used up, and some last for a limited amount of time. Building cards and avatar decorations are permanent, as in a typical microtransaction-based game. But weapons and vehicles get used up - weapons are sold in the form of ammo, and vehicles can be used for a limited number of play sessions before they must be refueled. Only the starting weapon and vehicle last forever. This is like the rental approach to monetization. Lastly, membership cards to access special arenas and unlock special game enhancements are effective for a limited number of days before they expire, much like a subscription. Each of these items represents a different approach to microtransactions, in the hopes of appealing to as many different buying habits as possible and maximizing the revenue of the game.
Outside of the artillery game itself, there would be a sort of store interface where players could browse and shop for items. Building cards would be bought in random packs, from different editions, much like in an actual trading card game. Some editions could be bought only with Points, but the sets containing the more powerful cards must be bought with Coins. The idea is that players who really get into collecting cards are going to be the type to spend real money on the game. Avatar decorations are bought individually, mostly for Coins, though there might be some basic clothes and such that could be bought with Points instead.
Weapons are bought in bulk - that is, packs of ammunition - and for the most part can be bought with Points. For reasons of fairness, you want to be careful about charging real money for items that provide significant in-game advantages - like weapons - though it could be appropriate to charge Coins for some particularly strange or specialized types of weapons. Vehicles are similar, but since they have less of an effect on the fairness of the game, it is more appropriate to charge Coins for some of the vehicles, especially if their advantage is purely cosmetic or a matter of personal preference in the movement controls. Vehicles themselves do not get damaged or expire, but they do have a limited amount of fuel. Every time you enter a play session, you use up one unit of fuel in your chosen vehicle. The more powerful or expensive a vehicle, the more it costs to refuel it, though fuel should cost only Points since it is a recurring expense.
Arena access must be bought with Coins. Players buy membership cards, each of which provides access to several exclusive arenas for a certain amount of time. It might also be possible to include an arena editor that can be accessed in a similar way. This could be a nice place to incorporate player-created content, if you are so inclined. Other game enhancements can be bought individually with Coins, also for a limited amount of time. These may include advantages such as a larger maximum deck size, or extra weapon slots in each game. Most importantly, these enhancements would be the type of features that very dedicated players would appreciate and pay for, but that the average player would not find useful. This makes it acceptable to charge real money for such enhancements.
Permanent items - that is, building cards and avatar decorations as well as Coins and Points - can be traded freely between players. Temporary items like weapons and vehicles, however, may not. This is partly for simplicity, and partly because you want to use weapons and vehicles as a currency sink, a place where Coins and Points are removed from the game economy. And this role is undermined if players can just buy weapons from each other. In a real-world economy, this is not as important, but in a game where you can bring currency into circulation just by knocking over a few buildings, it's essential to drain that currency out of the system just as fast as it comes in, to avoid inflation. Since weapons and vehicles get used up over time, players must continually buy new ones, removing currency from circulation at a more or less constant rate. To keep the system running smoothly, you must continually balance item prices with the amount of Points that players can earn from each building type. Keep those Points flowing in and out at the same rate. No one said this would be easy!
Implementation
To actually make City Basher, you'd need a good rigid-body physics engine, like motor2 or Glaze, or even Box2D. This could also be a great project for use with the PushButton Engine, since it has built-in Box2D support and an optional networking component for making multiplayer games.
However, making any multiplayer game on this scale is always going to be a massive undertaking. Make sure that you know what you are doing before you start. If you've never made a physics-based game before, start by making a single-player prototype of the basic building-destroying gameplay. Then, if you're new to network programming, make a simple match-based multiplayer version of the game, without the special items or persistent avatars.
If you can do that, and make it fun, then you can think about taking the next step and making it massive. When you do succeed in making a massively multiplayer game, don't add in all the special items all at once. Start with the basic free game, and add items gradually, careful not to upset the balance of the game. Incremental development is the way to go.
Good luck.
References
Required reading for anyone who wants to make a game like this:
Since Emanuele Feronato never showed up to receive his idea, City Basher is open to anyone to use for free! Even you. ;)
Let me know if you decide to try making it. I'd be glad to help however I can. Post a comment!
Be warned, this giveaway is epically long. My longest yet.
...continued from The Game Idea Giveaway Thread
Request by triqui:
- what sort of game idea you're looking for
intriguing but difficult-to-implement ideas will do
- what your goals are in making this game
I would like to make a post about gameplay ideas
The idea: City Basher
In short, City Basher is a physics-based multiplayer artillery game combined with a trading card game (like Magic: The Gathering). It's a competitive game where you try to knock over your opponent's buildings, and it is designed to work very well with microtransactions.
This game is founded on the wide appeal of vanquishing strangers over the Internet and the primal joy of toppling carefully built towers of blocks, without the bother of having to actually build them in the first place. For that reason, the game is primarily a quick deathmatch experience, like most online multiplayer games aimed at bloodthirsty teenage males. Though there is also the option for team play and casual matches between friends.
Like other multiplayer artillery games, most notably Worms, each play session is short, measured in minutes, and involves only a handful of players. But as a game supported by microtransactions, players maintain a persistent identity across play sessions, retaining their avatar, items, resources, and statistics. This is the approach taken by Gunbound, a multiplayer artillery game that was one of the earliest successful microtransaction-based games to establish itself with Western audiences. Gunbound made its money by selling avatar decorations. City Basher will do that, and more. Much more. [cue dramatic music]
Each play session takes place in a 2D arena, seen from the side. The arena is full of buildings, structures of physically-modeled blocks, some solidly stacked, some precarious. At first, the arena is a neutral territory, dominated by a huge monolith in the center. Players take their places in the arena, each one piloting a vehicle with a mounted cannon or two. The game begins, and players open fire on the buildings to convert them to their own color. When one player topples an enemy building, a new building rises up in its place, owned by the player who placed the final shot and color-coded accordingly. The session ends when the neutral monolith in the center is toppled, and players are awarded their final scores.
The play format is very flexible. The game is not zero-sum. Players play for points, not simply to defeat their opponents. If you destroy one of my buildings, you are rewarded and I am penalized, but your success does not depend on my failure. It merely happens to coincide with it. Players are never eliminated from the game, though they are free to leave at any time - their buildings are simply replaced by neutral ones. And most arenas would support a varying number of players depending on how many people are available. If there are slots open, new players can join an existing game. This is very important for a casual multiplayer game like City Basher.
Since this is a game supported by microtransactions, we want to make everything into an item that can be bought and used up. Not that players would necessarily have to pay real money for everything in the game, but it's nice to have that option. What this does is set up the expectation that things can be bought. If players get used to paying for items with virtual currency earned in the game, they'll be more open to paying real money for the really valuable items they might want later on. In City Basher, these items consist of vehicles, weapons, buildings, arenas, avatar decorations, and general enhancements.
Gameplay
An important part of most any game is the movement, how a player gets around in the world. In City Basher, vehicles encapsulate this piece of the gameplay. Every player starts with a basic vehicle that is like a slow-moving tank. But other vehicles could be bought. They might move faster, they might be smaller or larger or shaped differently, and some might even fly or hover or jump. However, movement isn't the focus of this game, so it should be kept fairly simple. As a result, each vehicle is controlled in more or less the same way - that is, with the arrow keys or with the mouse, following the mouse cursor. Also for simplicity and to minimize the effect of lag, vehicles would not be able to collide with other vehicles or knock over buildings. Instead, they would pass through other vehicles harmlessly and treat building blocks as immovable terrain.
The real fun of the game starts with the weapons. This is the part that puts the artillery in artillery games. As is typical in the genre, the basic weapon is a slow-firing cannon, which the player must aim by setting the angle and power of the shot with the mouse or keyboard. There are a lot of ways to set up the specific controls for this action, so I won't go into too much detail here. The easiest way I can imagine is just to click the mouse to set up an attack, move the cursor to set the angle and power, and click again to fire. This way, you could fire off a quick shot by double-clicking. Since attacking is a focus of the game, different weapons could even have different methods of control, as long as they support both the keyboard and the mouse.
For a game like this, there would be dozens, if not hundreds, of different weapons to buy. Some might be variations on the basic cannonball, maybe with extremely high mass for extra power on stable buildings, or a small but extremely bouncy ball that can ricochet off multiple blocks and quickly take out more delicate structures. Some weapons might shoot several balls at a time, or an explosive shell, or several balls chained together. Others might be a different kind of weapon altogether, like a rocket launcher or a block-melting death ray. There are a ton of possibilties here - just look at a game like Worms for example. Each weapon would have a certain reload rate, a waiting period of anything from a half a second to several minutes before they can fire again. This would help to give the game a more strategic, turn-based flavor, without the turns. For this reason, there could also be weapons that are weak but useful because of their rapid firing rate. Another part of the strategy would be in selecting your arsenal, since you can only bring a limited number of different weapons into each game.
The other focus of the game is on buildings. Weapons are what you use, and buildings are what you use them on. So naturally, you'd be paying a lot of attention to them. Just like there are different types of weapons, there are also different types of buildings, each one a particular configuration of blocks of various size, shapes, and masses. Some have special side effects too, that are active while the building is in play. For example, one building might increase the mass of all your other buildings while it is in play, making them harder to knock over. There could even be a building that increases the strength of gravity over the entire arena, or doubles your score from every hit. It's a lot like the way that different cards have rule-changing effects in games like Magic: The Gathering or Pokemon.
The similarities don't end there. City Basher handles buildings just like cards in a trading card game. You don't build buildings, you collect them. Each player has a bunch of building cards in their collection. Each of these cards represents a particular building type, though a player might own several copies of the same card. When you join a game, you choose a set of cards from your collection that will be available to you during the match, in the form of a deck of cards. Like any trading card game, there is a limit to the number of cards that you can include in a single deck, and a limit to the number of duplicates you can use of the same building card. This means that you have to put some thought into which ones you choose. Some players might even spend more time just designing their decks than they do in playing the actual game!
When you choose which deck you want to use for a play session, this determines the type of buildings you can get in the game. Whenever you are due to have one of your own buildings pop up in the arena - say, when you topple an opponent's building - a random card is taken from your deck, and placed in the arena as a new building. When that building is toppled, the corresponding card is returned to your deck. That means that if you have three copies of the Citadel of Awesomeness card in your deck, you can have up to three Citadel of Awesomeness buildings in play at any time. And if you have no more cards in your deck when you destroy an enemy building, that building is replaced by a neutral one instead. The most powerful buildings are designated as Legendary buildings, and can only sprout up in special Legendary building slots, of which there might only be one or two in any given arena. Legendary building cards are ignored when drawing for normal building slots. This helps keep the game balanced.
Finally, there are the arenas, where the games take place. These are not items owned by individual players, but the effect is similar, since players may have to spend points or money to access certain arenas. At its core, an arena is a 2D map of indestructible terrain with a bunch of building slots scattered around - areas on the ground where a building may sit. One of these areas is reserved for the monolith, the giant neutral building that ends that game when it is toppled. The arena defines what this monolith looks like, as well as the deck of possible neutral buildings that may pop up. Each arena also specifies how many players are allowed at a time and where they appear at the start of the game. Lastly, each arena defines its own physical properties like gravity, air resistance, and wind, as well as the background graphics and sounds that make up the feel of the place.
Monetization
In a typical microtransaction-based game, there are two types of virtual currency involved in the in-game economy. One is earned through playing the game, like experience points. The other is bought for real money, which is how the developers make a profit. City Basher is no exception. Players can exchange their real money for a virtual currency we'll call Coins, and they can also earn another virtual currency, Points, through gameplay. The names used here are just for convenience, by the way - in the actual game you'd probably want something a bit more glamorous.
Players can earn Points in a number of ways. The most common way to earn Points is to knock down an opponent's building. You don't have to knock it down completely to get points - you only have to reduce its height with your shot. Each type of building is worth a certain number of Points to topple, and you get a fraction of that for every fraction of the building's original height that you knock over. However, you only get to replace it with a building of your own if you deliver the final blow, one that topples the building completely. The advantage to having lots of your own buildings in the arena is that at the end of the game, when the monolith falls, you receive Points for each of your buildings according to their remaining height and Point value.
This results in a system where new players can join in the middle of an existing game without having any unfair advantages or disadvantages relative to the other players. It also encourages players to stick around for the whole session in order to earn bonus points at the end for their remaining buildings. At the same time, no one is bothered if they leave, since their buildings are replaced by neutral ones which yield Points just as readily as player buildings. And it works just as well for team games, since players on the same team simply share a single color, and don't earn any Points from toppling their teammates' buildings. On the whole, it is a scoring system designed to reward good players, without punishing the players who aren't as skilled. This keeps the game accessible to casual audiences. And that means more money for you.
So, let's talk a little more about money. Specifically, let's talk about what players spend it on, and why. First of all, let me emphasize that the game itself is free to play. Players are not spending money just to play the game, they are spending it to buy virtual items inside the game. This is what it means to have a game based on microtransactions. Second, it is important to understand why players would want to buy these imaginary items at all. Players will spend money not so much as an exchange but as an investment. It's not about exchanging value. Why would a player give you real money for nothing? It's about investment. A player gets some significant value through playing the game for free, and then they think that they could enjoy even greater value in the long run if they invest a little bit of their own money right now. They should feel like they're getting a great deal every time they spend money in your game. If you can keep this one principle in mind, all the rest of your monetization decisions should follow naturally.
Here's how it works in City Basher. All items are bought with either Points, Coins, or some combination of both. Some items are permanent, some get used up, and some last for a limited amount of time. Building cards and avatar decorations are permanent, as in a typical microtransaction-based game. But weapons and vehicles get used up - weapons are sold in the form of ammo, and vehicles can be used for a limited number of play sessions before they must be refueled. Only the starting weapon and vehicle last forever. This is like the rental approach to monetization. Lastly, membership cards to access special arenas and unlock special game enhancements are effective for a limited number of days before they expire, much like a subscription. Each of these items represents a different approach to microtransactions, in the hopes of appealing to as many different buying habits as possible and maximizing the revenue of the game.
Outside of the artillery game itself, there would be a sort of store interface where players could browse and shop for items. Building cards would be bought in random packs, from different editions, much like in an actual trading card game. Some editions could be bought only with Points, but the sets containing the more powerful cards must be bought with Coins. The idea is that players who really get into collecting cards are going to be the type to spend real money on the game. Avatar decorations are bought individually, mostly for Coins, though there might be some basic clothes and such that could be bought with Points instead.
Weapons are bought in bulk - that is, packs of ammunition - and for the most part can be bought with Points. For reasons of fairness, you want to be careful about charging real money for items that provide significant in-game advantages - like weapons - though it could be appropriate to charge Coins for some particularly strange or specialized types of weapons. Vehicles are similar, but since they have less of an effect on the fairness of the game, it is more appropriate to charge Coins for some of the vehicles, especially if their advantage is purely cosmetic or a matter of personal preference in the movement controls. Vehicles themselves do not get damaged or expire, but they do have a limited amount of fuel. Every time you enter a play session, you use up one unit of fuel in your chosen vehicle. The more powerful or expensive a vehicle, the more it costs to refuel it, though fuel should cost only Points since it is a recurring expense.
Arena access must be bought with Coins. Players buy membership cards, each of which provides access to several exclusive arenas for a certain amount of time. It might also be possible to include an arena editor that can be accessed in a similar way. This could be a nice place to incorporate player-created content, if you are so inclined. Other game enhancements can be bought individually with Coins, also for a limited amount of time. These may include advantages such as a larger maximum deck size, or extra weapon slots in each game. Most importantly, these enhancements would be the type of features that very dedicated players would appreciate and pay for, but that the average player would not find useful. This makes it acceptable to charge real money for such enhancements.
Permanent items - that is, building cards and avatar decorations as well as Coins and Points - can be traded freely between players. Temporary items like weapons and vehicles, however, may not. This is partly for simplicity, and partly because you want to use weapons and vehicles as a currency sink, a place where Coins and Points are removed from the game economy. And this role is undermined if players can just buy weapons from each other. In a real-world economy, this is not as important, but in a game where you can bring currency into circulation just by knocking over a few buildings, it's essential to drain that currency out of the system just as fast as it comes in, to avoid inflation. Since weapons and vehicles get used up over time, players must continually buy new ones, removing currency from circulation at a more or less constant rate. To keep the system running smoothly, you must continually balance item prices with the amount of Points that players can earn from each building type. Keep those Points flowing in and out at the same rate. No one said this would be easy!
Implementation
To actually make City Basher, you'd need a good rigid-body physics engine, like motor2 or Glaze, or even Box2D. This could also be a great project for use with the PushButton Engine, since it has built-in Box2D support and an optional networking component for making multiplayer games.
However, making any multiplayer game on this scale is always going to be a massive undertaking. Make sure that you know what you are doing before you start. If you've never made a physics-based game before, start by making a single-player prototype of the basic building-destroying gameplay. Then, if you're new to network programming, make a simple match-based multiplayer version of the game, without the special items or persistent avatars.
If you can do that, and make it fun, then you can think about taking the next step and making it massive. When you do succeed in making a massively multiplayer game, don't add in all the special items all at once. Start with the basic free game, and add items gradually, careful not to upset the balance of the game. Incremental development is the way to go.
Good luck.
References
Required reading for anyone who wants to make a game like this:
- Testosterone and Competitive Play
- Space Crack: Financial Mechanics
- Flash Love Letter (2009) Part 1
- Flash Love Letter (2009) Part 2
- Designing for Virtual Item Sales
- Ten Ways to Monetize Your Flash Game
Since Emanuele Feronato never showed up to receive his idea, City Basher is open to anyone to use for free! Even you. ;)
Let me know if you decide to try making it. I'd be glad to help however I can. Post a comment!
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)
