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 programming. Show all posts
Showing posts with label programming. 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!
2012/02/14
The Love Letter released!
But under the surface, my game development life has been roiling with barely constrained productivity and awesomeness! :D
In December, I participated in my first official game jam, the 72-hour jam for Ludum Dare 22. It was awesome. I teamed up with the artist, fledgling game designer, Flixel programmer, and all-around amazingly creative guy knivel, and I had the most intensely fun, productive weekend of programming and game development I'd had all year. No exaggeration.
The theme was ALONE, and after I suggested a game where you try to get away from all these people who keep bothering you, knivel basically came up with the entire concept of The Love Letter right then and there.
Oh, did I say "The Love Letter"? That's the game we made. Of course, we didn't have time to add a tutorial, or make it so you could actually win the game, but even then people seemed to like it, and told us to finish it, and voted us to first place in the "Theme" category of the game jam! Yay! :D
You can read more about our adventures here, in my Ludum Dare blog posts.
But anyway, that brings me to the point of this post, which is to kindly inform you that WE FINISHED THE LOVE LETTER AND IT'S VALENTINE'S DAY AND YOU SHOULD PLAY THE GAME NOW IT'S REALLY COOL!!!!!!!! :DDDD
This project has marked a turning point for me in many ways. For one thing, the game has done much better in playtesting than any of my previous games. People like it, and it's easy to understand and get into. Kind of like Pillars in that way, except an actual game instead of just a little prototype. Of course, we still haven't had a full public release yet, but even so far it has had a very promising reception. (By the way, have you played it yet? You should.)
But more importantly, I discovered that I can enjoy being the programmer on a game, working with a designer, and that this can be just as much fun or even more so than simply trying to be the designer myself. What I realized is that when I fully trust the designer - knivel, in this case - to the extent that I feel like he would make the same design decisions that I would make except faster and better, and when we occasionally disagree it is an opportunity for us both to expand our own perspectives and make a better game together then we could on our own. It's hard to be the programmer and the designer at the same time. It takes time to mentally switch between roles. When I work alongside a designer whose creativity and design sense I really admire and trust, it frees me to focus on the groundwork of programming while he scopes out the game design possibility space from above.
It also really helps to work with an artist and designer who also knows programming and can hack in features without my help if necessary! :) Just like I can fix pixel art mistakes if I see them. After my experiences making games with knivel, I don't think I would choose to work with a code-illiterate designer unless I had a really good reason to. It's so nice to be able to explain to a designer what I'm doing, what problems I'm running into, or what awesome thing I just figured out, and have that designer actually understand me. It's all about that connection, like we are just parts of one unit, the team. Without that common understanding, it's easy for friction to come up in our interactions.
So there, I'm getting more picky. ;) But in a good way. :) I'm learning what works for me.
The Love Letter was also the first project where I got really into working on it, fitting it into every crack in my schedule I could find after the game jam ended and we started fixing up the game for the release I now have the pleasure of announcing. I'd bring my laptop on the bus and work on it there. I'd work on it while eating dinner. I'd keep working on it and stay up late. I was so into it, I didn't want to stop. And I couldn't wait to get back to it. :)
Finally! :p A year ago I remember being similarly obsessed with reading Harry Potter and the Methods of Rationality, and thinking to myself, "If I wanted to make games as much as I want to read the next chapter of Harry Potter and the Methods of Rationality, I'd be making a lot more games." And now I've gotten to that point. I know what it feels like. I can tap into this with my future projects too. Which is great to think about.
But I also need to get some sleep, if I want to stay motivated, not to mention... alive? So I think I'll wrap this up.
I also participated in the Global Game Jam for the first time this year, and made another little game with knivel and the same composer (and this time you can actually get to the end). It's not quite ready for prime time yet - we're planning to give it the same sort of treatment as The Love Letter, but I'll be sure to let you know when it's done. :) Now that we're finished (or are we?) with The Love Letter, I'll probably be getting back to this game pretty soon. After I get some sleep, of course. ;)
Oh, and also, I wrote about my first ever game jam, back in October, on the Fugazo blog. It was not nearly as successful as my latest adventures, but it was educational. Hehe. :)
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/10/13
Teaching Flixel
A few weeks ago, I started teaching some kids how to make games with Flixel and other free tools. I'm offering my time up as a volunteer, at a progressive school I came across through this inspiring blog. Here is an email I just wrote to my students:
Hi class,
I'm really tired right now. I should be sleeping. But I'm writing these instructions to you now because of something that is more urgent to me than sleep. River sent me an email asking me again to explain how to finish the animation and change where the bullet shoots from. He apparently wanted to figure this out enough that he bothered to remind me about it. He didn't have to do that. I don't have to do anything for you guys. But he wanted to. And because he wanted to, I will do whatever it takes to help him get there, even though I'm really busy, even though I'm tired. Because this is the whole reason that I decided to try teaching a class at PSCS. I came here on the chance that I might be able to help someone get somewhere they really want to go but can't get to by themselves. I'm not an expert in most things, but this opportunity to share what I can with people who want it is very motivating for me.
And I've been waiting for this. And now I see the beginnings of it.
I'm not attached to you wanting to learn game programming, or game design, or whatever. You love playing games, and I think there is a chance that you may come to love creating games as well, once you get more of a taste of it. It is an acquired taste. It might not be your thing. Which is fine with me. I don't really care personally either way. But if it is, and if there is a chance that it might be, I will do whatever I can to catch that spark in you, and help you kindle it into a steady flame, if you so choose. Just let me know.
Yeah. So, those instructions...
You added some code in the beginning of update() that said this:
var moved:Boolean = false;
Then you added code to each if-statement for the arrow keys, to changed moved to true, if you press an arrow key during the update.
moved = true;
So you have a virtual bucket, sitting in your computer's memory, which you call moved, in which you can put either true or false. But it doesn't do anything by itself. It just sits there.
However, it is useful. Because you can look at it. If it has true inside it, you know that an arrow key was pressed, because you put true in it whenever an arrow key is pressed. Right? If it has false inside it, you know that no arrow key was pressed.
Say you wanted to do something only if an arrow key was pressed, and another thing if no arrow key was pressed. Like play a walk animation, or play an idle animation. If you wanted to do that, then it might be helpful to look into this moved bucket, and see what's inside.
You could say...
If moved has true inside of it, then play the walk animation.
Otherwise (if it is false), play the idle animation.
And you could translate that into actual AS3 code, like this:
if (moved)
{
_box.play("walk");
}
else
{
_box.play("idle");
}
And you would put that code in update(), after all the arrow keys and such have been checked.
Some notes:
if (moved) is the same as if (moved == true) - because what you put between the parentheses in an if-statement is checked to see if it is equal to true. If it is equal to true, the code in the curly braces is run. Otherwise, it runs the code for else.
Why does if (FlxG.keys.LEFT) work to see if the left arrow key is pressed? Because FlxG.keys.LEFT is a virtual bucket that holds true if the left arrow key is pressed and false otherwise. Get it?
Also, there is no way to just stop an animation. You must have another animation to replace it. For example, you could create an animation, with _box.addAnimation(), that is called "idle" and that has only one frame in its list of frames. Then when you play that animation, the _box would stay on that one frame forever, unless you play a different animation later on.
You might also wonder whether telling the _box to play an animation, telling it again and again every frame, might make it start over from the beginning every frame and not get anywhere. There is a way to do that. But fortunately, Flixel will not restart the animation if it's already playing. So this works.
There you have it - the instructions for how to make an animation only play while moving. It will take a bit of work, a bit of thought, a bit of failure and frustration and trial-and-error in order to get it to work in your particular program. But this is the price we pay.
I do not demand success from you. But I do demand that you try, or I cannot help you. And I suggest that you try more than once, even if you fail at first. You have unlimited lives, when it comes to programming. Remember that.
Next.
Making bullets shoot from somewhere other than the top left corner of the box sprite.
This is easier.
Find the code where you first create the bullet. It looks something like this:
var bullet:FlxSprite = new FlxSprite(_box.x, _box.y);
Remember? That creates a new FlxSprite, and gives it the name bullet, and puts it at a certain spot on the screen. That certain spot on the screen happens to be the upper left corner of the _box sprite.
If the box sprite has its corner at the coordinates (5, 10) and it is 50 pixels wide and 50 pixels high, then where is its center?
I'll tell you the answer. Its center is at the coordinates (5 + 50 / 2, 10 + 50 / 2), which is the same as (5 + 25, 10 + 25), which is (30, 35).
To put it more generally, the box's center is at (_box.x + 25, _box.y + 25). Just add an offset of (25, 25) and you get the center. Right?
What if you wanted to put the bullet at the center of the box?
var bullet:FlxSprite = new FlxSprite(_box.x + 25, _box.y + 25);
Would that work? I suggest you try it out and see.
What if you want it to appear somewhere other than the center? Well, try using some other numbers, instead of 25.
Once you get that working (which I'm sure you will), try making an animation for the bullet. Can you do it?
Show me on Monday.
If you have any questions, let me know before the weekend.
Good luck.
Hi class,
I'm really tired right now. I should be sleeping. But I'm writing these instructions to you now because of something that is more urgent to me than sleep. River sent me an email asking me again to explain how to finish the animation and change where the bullet shoots from. He apparently wanted to figure this out enough that he bothered to remind me about it. He didn't have to do that. I don't have to do anything for you guys. But he wanted to. And because he wanted to, I will do whatever it takes to help him get there, even though I'm really busy, even though I'm tired. Because this is the whole reason that I decided to try teaching a class at PSCS. I came here on the chance that I might be able to help someone get somewhere they really want to go but can't get to by themselves. I'm not an expert in most things, but this opportunity to share what I can with people who want it is very motivating for me.
And I've been waiting for this. And now I see the beginnings of it.
I'm not attached to you wanting to learn game programming, or game design, or whatever. You love playing games, and I think there is a chance that you may come to love creating games as well, once you get more of a taste of it. It is an acquired taste. It might not be your thing. Which is fine with me. I don't really care personally either way. But if it is, and if there is a chance that it might be, I will do whatever I can to catch that spark in you, and help you kindle it into a steady flame, if you so choose. Just let me know.
Yeah. So, those instructions...
You added some code in the beginning of update() that said this:
var moved:Boolean = false;
Then you added code to each if-statement for the arrow keys, to changed moved to true, if you press an arrow key during the update.
moved = true;
So you have a virtual bucket, sitting in your computer's memory, which you call moved, in which you can put either true or false. But it doesn't do anything by itself. It just sits there.
However, it is useful. Because you can look at it. If it has true inside it, you know that an arrow key was pressed, because you put true in it whenever an arrow key is pressed. Right? If it has false inside it, you know that no arrow key was pressed.
Say you wanted to do something only if an arrow key was pressed, and another thing if no arrow key was pressed. Like play a walk animation, or play an idle animation. If you wanted to do that, then it might be helpful to look into this moved bucket, and see what's inside.
You could say...
If moved has true inside of it, then play the walk animation.
Otherwise (if it is false), play the idle animation.
And you could translate that into actual AS3 code, like this:
if (moved)
{
_box.play("walk");
}
else
{
_box.play("idle");
}
And you would put that code in update(), after all the arrow keys and such have been checked.
Some notes:
if (moved) is the same as if (moved == true) - because what you put between the parentheses in an if-statement is checked to see if it is equal to true. If it is equal to true, the code in the curly braces is run. Otherwise, it runs the code for else.
Why does if (FlxG.keys.LEFT) work to see if the left arrow key is pressed? Because FlxG.keys.LEFT is a virtual bucket that holds true if the left arrow key is pressed and false otherwise. Get it?
Also, there is no way to just stop an animation. You must have another animation to replace it. For example, you could create an animation, with _box.addAnimation(), that is called "idle" and that has only one frame in its list of frames. Then when you play that animation, the _box would stay on that one frame forever, unless you play a different animation later on.
You might also wonder whether telling the _box to play an animation, telling it again and again every frame, might make it start over from the beginning every frame and not get anywhere. There is a way to do that. But fortunately, Flixel will not restart the animation if it's already playing. So this works.
There you have it - the instructions for how to make an animation only play while moving. It will take a bit of work, a bit of thought, a bit of failure and frustration and trial-and-error in order to get it to work in your particular program. But this is the price we pay.
I do not demand success from you. But I do demand that you try, or I cannot help you. And I suggest that you try more than once, even if you fail at first. You have unlimited lives, when it comes to programming. Remember that.
Next.
Making bullets shoot from somewhere other than the top left corner of the box sprite.
This is easier.
Find the code where you first create the bullet. It looks something like this:
var bullet:FlxSprite = new FlxSprite(_box.x, _box.y);
Remember? That creates a new FlxSprite, and gives it the name bullet, and puts it at a certain spot on the screen. That certain spot on the screen happens to be the upper left corner of the _box sprite.
If the box sprite has its corner at the coordinates (5, 10) and it is 50 pixels wide and 50 pixels high, then where is its center?
I'll tell you the answer. Its center is at the coordinates (5 + 50 / 2, 10 + 50 / 2), which is the same as (5 + 25, 10 + 25), which is (30, 35).
To put it more generally, the box's center is at (_box.x + 25, _box.y + 25). Just add an offset of (25, 25) and you get the center. Right?
What if you wanted to put the bullet at the center of the box?
var bullet:FlxSprite = new FlxSprite(_box.x + 25, _box.y + 25);
Would that work? I suggest you try it out and see.
What if you want it to appear somewhere other than the center? Well, try using some other numbers, instead of 25.
Once you get that working (which I'm sure you will), try making an animation for the bullet. Can you do it?
Show me on Monday.
If you have any questions, let me know before the weekend.
Good luck.
2010/09/19
How Artists Want to Make Games
On the notgames forum, Michaël Samyn posted this thread:
Programming in code is counter-productive for people with art-sided brains. The solution to this problem exists: graphical programming. But the people who need to implement this solution happen to be its worst enemies. Because to engineers, code-based programming beats everything.
Until somebody somewhere starts believing artists when they say they want to program in a visual language, or starts realizing that giving access to artists is the best way for a creative technology to continue evolving, I find myself settling with inferior designs. Because I cannot express myself adequately in code, I need to change my ideas, I need to talk about simpler things in a simple way.
It's like someone is forcing me to write poetry in French. French is a great language. And people who are familiar with it can write beautiful poetry. But I speak Dutch. My Dutch poems are subtle and sublime. In French, however, all I can write are nursery rhymes.
So I've been thinking about this a lot over the last several days. Actually I've been obsessively thinking about it non-stop and reading everything I can on related topics online.
I tend to do that for a different thing every week. This week, it's been this.
So there are a few pieces I've been focusing on, that seem most crucial to the success of a programming or game development tool for artists. There are probably others, but I thought I'd share what I've been thinking about so far.
One is readability through R-mode perception.
First of all, a disclaimer: When I say "R-mode" versus "L-mode", as in "Right brain" or "Relational" or "Rtistic" versus "Left brain" or "Logical" or "Linear", I don't mean to suggest that the brain is really divided into strict differences between its physical right and left halves. That is an outdated belief. But I find the terminology to be a useful shorthand.
Thinking on Michael's comments about visual flowcharts being easier for him to read than linguistic code, and looking back on my own experience, I think there really is something significant about how the code is presented and perceived, even when the underlying logic is the same.
When I am reading code (or a book!) I am usually using what I call "L-mode" perception - going through in a linear, linguistic way, and building up my mental model one step, one line of code at a time, following the logic that is expressed symbolically, in sequences like that.
However, sometimes my mind is in an "R-mode" of all-at-once, spatial perception like you'd use for looking at a painting or trying to find a certain LEGO piece in a big box of pieces. When I am in that state of mind, and I look at code (or to a lesser extent, written language) I see all the words at once and perceive the spatial relationships between them, and the underlying logic of the code is utterly incomprehensible to me. Obviously not the "right" way to read code.
But maybe it could be.
Ha, that would be a good tagline. "The right way to code." :P
The thing about R-mode perception is that it's a lot easier to be creative when you're in it. The other thing about R-mode perception is that artists are usually a lot more skilled at functioning in R-mode than they are in L-mode.
Therefore, if you had a tool that let you do programming while in R-mode rather than L-mode, it might be slightly easier to do creative things with it. At the least, there would be less inefficiency caused by switching between R-mode and L-mode whenever you think about what you want to change and then have to dive into the code to actually change it.
However, this may not even be possible.
All the visual programming editors I've seen, all the examples that have been posted here, require an uncomfortable mix of L-mode and R-mode perception in order to use. What I tend to see is a bunch of visually identical boxes connected by lines, and differentiated by text.
What you see in R-mode is the set of relationships between the boxes. But you can't tell what each of the boxes does. To do that, you must read the text and think symbolically, in L-mode. Really, very little information is conveyed through spatial relationships, through R-mode. Most of it is still sequential and symbolic.
For that reason, I find that pure written code, all L-mode, is much easier for me to deal with, since I don't need to switch around multiple times a second just to figure out what everything means. However, I suspect that there may be a way to create a pure R-mode method of programming too. But I'm not confident that it's actually possible. Just intrigued enough to try.
There are some programmers who hate the idea of visual programming, and say that it's a waste of time to use spatial relationships to convey the meaning of code. If you are one of those people and you use syntax coloring or indentation, you are a hypocrite.
So there's one aspect. Make sure your tool is R-mode accessible, if you want artists to be able to use it.
The second thing is building with functional pieces in real (or almost real) time.
Artists tend to appreciate tools where "what you see is what you get" - you're manipulating the end result, so you can immediately see the results of your actions. The process becomes more like sculpting.
Programmers tend to discount such tools as nice but unnecessary. They are used to typing in code for an hour, hitting a button, and waiting a minute for everything to compile and show up on the screen.
These are two fundamentally different mindsets, as different as a slideshow and an animation.
When you operate in the slow, "slideshow" approach, development and creativity tends to happen in an architected, "top-down" way. You have a plan, which is in your head, and then you put in a bunch of time and hard work to mold reality into the shape of that plan.
There is a fundamental shift that occurs as you decrease the time between action and result. It's as real as the shift that occurs when you hit 24 frames per second - from slideshow to animation. To your brain, it's alive, it's moving.
When you operate in the immediate, "animation" way, development tends to operate in a more exploratory, "bottom-up" process. You don't have to have an entire plan in your head. You see the results of your actions immediately, and if they are surprising or unexpected, you can adjust your plan. You can try random things and follow them if they prove to be interesting.
In the area of game design, innovation is much more likely to come out of an exploratory process than an architected one. As Jonathan Blow said earlier. It's hard to do things that haven't been done before if you have to plan it all out in your head first.
So we want a tool that allows us to sculpt the end result, with immediate feedback.
Part of this is that everything you can make should work. It may not work in the way you desire or expect, but it should still do something.
If you are painting with pixels in an art program, no matter how you put those pixels down on the screen, it will always be a functional, viewable image. It might not be pretty, but you can still see it. You are never going to run into a error message that says, "Invalid pixels at position 55, 46. Image cannot be displayed."
But if you are writing the code for a program, this sort of thing happens all the time. Most of the things you can type won't work at all. They won't turn into a program, even a broken one. There are right ways to write code, and wrong ways to write it.
I would say that this also makes a big difference. Perhaps the biggest difference is that writing code has a much higher barrier to entry, more learning how to do things at all before you can start learning how to do them well. But it also makes experimentation so much more difficult. You can't throw a bunch of random stuff together just to see what happens. Because what happens is nothing. It just won't do anything at all.
So if you can build only with pieces that work, and immediately see what changes, this would make truly artistic interactive art much easier to create.
The last thing is expressing general logic through specific examples.
This is probably the most impossible and most revolutionary but least important of the three. If you just had a tool that you'd use in R-mode, that let you shape the end results with immediate feedback, that could be awesome, and probably enough to make a huge difference.
But at the same time I am intrigued by this further vision I have of providing specific examples, which the system will extrapolate to create possible general rules for creating those examples, which you will then provide feedback on and refine in order to guide the system's hypotheses toward the end you have in mind.
Because I don't see how to actually avoid symbols when describing logic, or how to directly manipulate end results in a general way. Because games are systems, and the end results happen when you take the rules that you have set up and run them through their paces.
So maybe this is the only way to achieve those first two goals in their entirety.
What am I talking about?
You know how you draw diagrams and mockups for different things that happen in different situations in a game? Like this. It's a pretty common way to organize your thoughts when you're designing. The thing about those is they're all organized around specific examples, not general rules. So you might draw a diagram with a guy hitting a wall, showing how he bounces off or breaks through it or whatever. It's not completely specific, as you might have an abstract line standing in for any kind of wall, and a stick figure representing any kind of guy, but at the same time it's very concrete. And you can add general connotations by writing in little notes, to explain the rules behind the example more clearly.
The reason that we don't just stop there is that our game development tools require everything to be spelled out exactly - they cannot extrapolate from these examples, because there is so much ambiguity. It could mean this or it could mean that.
However, we run into a similar problem when trying to communicate our ideas to other people who are helping us make them into a reality. Especially if we are designers and we are telling programmers what to do. How do we solve this problem with other people?
Part of this is by clarifying with more examples when an area is unclear. Kind of starting at the highest level and breaking it down into more specific situations when necessary. Another part is through conversation, asking "It sounds like you're describing this... Is that right?" and responding "Yes, exactly!" or "No, I was thinking something more like this..."
Both of these could be accomplished with a special computer program instead of a human programmer. Maybe not as well, especially in terms of accuracy of translation, but in some ways better - particularly, in the time between your description of a design and seeing something on the screen. And this increase in speed could make up for the lack of accuracy, since you can adjust and correct much more quickly. And as a result, make use of exploratory design instead of architecture.
Break dynamics down into stories instead of rules. A playthrough of the entire game could be an example story, and you could create example stories of successively smaller and smaller pieces of the game until you have specified it completely. Or completely enough.
The tool generates possible rules that could create the situations you specify, and presents several for you to try out. Most likely none of them work the way you want. Pick the one that's closest, and let it generate more possibilities based on that. It's an evolutionary search. Like Biomorphs.
And stories don't always have to be specific stories about specific instances. They can be more or less abstract and universal. Like Raven, with a capital "R", who is both the character Raven and all ravens and all tricksters at once. Or the princess in the tower, or the wise old man, or the dragon in the cave. Or the stick figure on the crosswalk sign who represents all pedestrians who could ever walk this way. There is a continuum between the specific and the symbol.
I am particularly inspired by the concept of the Dreamtime. The translation of this name is misleading, as it does not refer to a time in history. It is like a parallel slice of the world running alongside and underneath the specific, physical world, where the gods and heroes walk, creating and personifying the dynamics and processes that underlie everything we see in reality.
I want a tool where I can not only shape the world as a level designer, but also shift into the Dreamtime and shape the dynamics of that world as concretely I would shape the placement of coins and mushrooms.
When this happens, we will get our interactive art.
2009/10/08
Where to Start with AS3, FlashDevelop and Flixel
the free tools of the trade...
I've been working with Flash for a few years now. But I didn't switch over to programming with ActionScript 3.0 until earlier this summer. And I have to say, I've found AS3 to be so much easier to work with than AS2. I'm glad I switched.
Here's where to start if you want to make Flash games with AS3. If you do it this way, it's all free, and you don't need any prior experience with programming, or Flash.
If you forget everything else I'm about to tell you, just remember these two words:
- FlashDevelop
(it turns code into programs)
- Flixel
(it helps you make game code)
So, where do you start?
Step 1: FlashDevelop
so shiny...Start with the Making Games in ActionScript 3 using FlashDevelop tutorials! They'll tell you everything you need to download, how to install it and get it all set up, and walk you through all the basics of a typical Flash game.
Here they are:
- MGAS3FD 1: The Setup
- MGAS3FD 2: The Beginning
- MGAS3FD 3: Getting on with it
- MGAS3FD 4: More embedding
- MGAS3FD 5: Enter the frame
- MGAS3FD 6: Click it like it’s hot
This tutorial will assume some basic familiarity with object oriented programming, a graphical tool of your choice and general computer literacy.
If you have any questions, you are welcome to post them here - I'll do my best to help. :)
But first, I'd recommend having a look through the Understanding Classes in AS3 tutorials!
If you’re stuck in an ActionScript 2 rut, or you’re new to ActionScript 3 and it’s blowing your mind, this should help ease you in a bit better.
Here they are:
- Understanding Classes in AS3 Part 1
- Understanding Classes in AS3 Part 2
- Understanding Classes in AS3 Part 3
- Understanding Classes in AS3 Part 4
All right.
Have you gone through the Making Games in AS3 tutorials? Have you gotten FlashDevelop all set up, and maybe made a simple program or two?
If not, then go back and do it!
If yes, then you're ready to move on to the next step! :D
Step 2: Flixel
so pixelicious...Don't bother making games from scratch. Make them with Flixel.
flixel is a completely free collection of ActionScript 3 files that helps organize, automate, and optimize Flash games; an object-oriented framework that lets anyone create original and complex games with thousands of objects on screen in just a few hours.
Oh yes.It's the same game engine that was used to make Canabalt.
Start by downloading the latest version of Flixel, then follow these instructions to get a something showing up on the screen. If it works, download this example game and follow these quick instructions to run it:
If you can get the example game to work, you can move on to these two step-by-step tutorials on how to build a game from scratch using Flixel:
- Making a simple brick breaker game with Flash and Flixel
- Making a platform game with Actionscript and Flixel
Then you can try this more in-depth tutorial on how to make a spaceship shooting game from scratch using Flixel:
Follow along, and by the end of it you should have three little action games and the knowledge to start building your own games with Flixel!To help you in your journey, there is the Flixel documentation, the Flixel wiki, and the help forum where you can ask questions and find answers. Also, the Flash Game Dojo. And of course, Google is always helpful.
If you get tired of using Flixel, for some strange reason, and you want to build your own game engine, you can give this tutorial a try. For experts only!
Update:
Flixel has changed a lot since I first wrote this post, so I recommend you check out this more recent guide on How to Learn Flixel if you're just getting started now.
Lastly, here are a few tools that may come in handy.
Unless you're making games for blind people (which is awesome) you'll probably need some way to make graphics and animations for your games. I'd highly recommend using the free image editor Paint.NET for this purpose. It's great for pixel art, and easy to use despite having a lot of nice features in it.Similarly, you'll probably want to have sounds in your game. For general sound recording and editing, try the free sound editor Audacity. Again, it's easy to use and is capable enough for recording and modifying sounds. I use it mostly to clean up recordings or save sounds into different formats and file sizes.If you're not interested in recording your own sound effects, you can generate them, with the amazing free tool called sfxr. Just click a button to get a randomized game sound, or change the settings manually to get the sound you want. It's perfect for games.
The creator of sfxr has also released a free tool for making game music, called musagi. I haven't tried it yet but I hear it's pretty good.There are quite a lot of nice, free tools out there if you know where to look. Here's one list that you might find useful.
That's all I have for you! Now go make some awesome games with FlashDevelop and Flixel. And let me know how it goes. I'm here if you have any questions. :)
Good luck!
2009/08/25
The Story of the Mountain Climber
Over the past few weeks, I've realized that I enjoy working in the domain that I have become fluent in, but find it frustrating to untangle a new, unfamiliar system while simultaneously trying to build something with it. I like exploring permutations and connections, rather than untangling difficult puzzles. And I am able to focus much better and use my time more productively when I am doing something I like.
And all of this has helped me realize that I don't want to be a game programmer. I want to be a game designer.
I like to explain this in terms of the Explorer and the Achiever player type. I am an Explorer (or Seeker). Programming, or engineering in general, tends to be most rewarding for Achievers, not Explorers. Achievers feel a rush of pleasure and energy when they finally solve a difficult challenge. I, on the other hand, tend to feel relief rather than excitement. What I like is the part that comes afterward.
Here's a little story to help visualize the situation.
Imagine climbing a mountain. I'm part of a team of engineers, laboriously lugging a heavy load of code up the mountainside. It's hard going, and we have to keep our heads down, focus on keeping a solid footing, freeing our load from snags, climbing over or around the boulders in our way. All the while, we have to stay coordinated and make sure the whole team is making steady progress up the mountain. Our determination and caffeinated beverages keep us going.
But I tire of this more quickly than my companions, and often turn to look out, away from the rocks and mud and out to the valley below. Something about this valley excites me, in a way the challenges of the mountain never could. But I turn back, grudgingly, to my teammates who still depend on me to carry my share of the load.
Eventually, finally, we reach the summit. Cries of triumph can be heard from all around, and a jubilant energy fills the air. I, too, am excited - now, with all that hard work and preparation out of the way we can finally begin! I look out across the magnificent vista spreading before my eyes and the terrain comes alive with plans and possibilities. I see empires rise and fall, resources flow and networks grow.
Then, I turn back to see my fellow engineers putting the last load of code into place, heaped atop the mountain, waiting for the designers who will be arriving tomorrow morning. Time to head back down! We'd better be on our way if we want to reach the next mountain in time!
Wait a minute - we're leaving already? The fun part was just about to start. No - but the others have already started down the mountain, caffeinated beverages in hand. Can't wait to conquer the next challenge. I turn to follow, reluctantly, with one last wistful glance over the vista that had so captivated me earlier.
Just another day in the life of an engineer.
Achievers get a big rush of pleasure upon reaching the top of a mountain. The bigger and more difficult the mountain, the bigger the rush. Explorers, like myself, enjoy looking out from the top of a mountain onto the world below. Just drink it in. Getting to the top isn't pleasurable in itself, it just means that the fun can finally begin.
The more patterns, the more connections, the more fun. That's what being an Explorer is all about.
I guess that should give me an edge in the next Casual Gameplay Design Competition. The theme is EXPLORE! ;)
And all of this has helped me realize that I don't want to be a game programmer. I want to be a game designer.
I like to explain this in terms of the Explorer and the Achiever player type. I am an Explorer (or Seeker). Programming, or engineering in general, tends to be most rewarding for Achievers, not Explorers. Achievers feel a rush of pleasure and energy when they finally solve a difficult challenge. I, on the other hand, tend to feel relief rather than excitement. What I like is the part that comes afterward.
Here's a little story to help visualize the situation.
Imagine climbing a mountain. I'm part of a team of engineers, laboriously lugging a heavy load of code up the mountainside. It's hard going, and we have to keep our heads down, focus on keeping a solid footing, freeing our load from snags, climbing over or around the boulders in our way. All the while, we have to stay coordinated and make sure the whole team is making steady progress up the mountain. Our determination and caffeinated beverages keep us going.
But I tire of this more quickly than my companions, and often turn to look out, away from the rocks and mud and out to the valley below. Something about this valley excites me, in a way the challenges of the mountain never could. But I turn back, grudgingly, to my teammates who still depend on me to carry my share of the load.
Eventually, finally, we reach the summit. Cries of triumph can be heard from all around, and a jubilant energy fills the air. I, too, am excited - now, with all that hard work and preparation out of the way we can finally begin! I look out across the magnificent vista spreading before my eyes and the terrain comes alive with plans and possibilities. I see empires rise and fall, resources flow and networks grow.
Then, I turn back to see my fellow engineers putting the last load of code into place, heaped atop the mountain, waiting for the designers who will be arriving tomorrow morning. Time to head back down! We'd better be on our way if we want to reach the next mountain in time!
Wait a minute - we're leaving already? The fun part was just about to start. No - but the others have already started down the mountain, caffeinated beverages in hand. Can't wait to conquer the next challenge. I turn to follow, reluctantly, with one last wistful glance over the vista that had so captivated me earlier.
Just another day in the life of an engineer.
Achievers get a big rush of pleasure upon reaching the top of a mountain. The bigger and more difficult the mountain, the bigger the rush. Explorers, like myself, enjoy looking out from the top of a mountain onto the world below. Just drink it in. Getting to the top isn't pleasurable in itself, it just means that the fun can finally begin.
The more patterns, the more connections, the more fun. That's what being an Explorer is all about.
I guess that should give me an edge in the next Casual Gameplay Design Competition. The theme is EXPLORE! ;)
Subscribe to:
Posts (Atom)
