Archive for the ‘Misc’ Category
Indie Challenges
Sunday, November 14th, 2010
Several weeks ago I wrote up a post called “I’m Indie, and I’m Proud” about the things I love about being an indie game developer. The post was full of all the positive things I love about indie life. A few people pointed out that I wasn’t representing the whole picture, so I thought I’d write up a companion post about some of the biggest challenges I have encountered being indie. This is not meant to dissuade anyone from becoming indie, but merely to show both sides of the issue. Going indie is still one of the best decisions I’ve made.
Note: This article refers to being “indie” in the sense of running your own business. If you’re working a salaried position at a small indie studio, much of this won’t apply.
1. Lack of Stable Income
Let’s get this out of the way right off the bat, because it’s the biggie. As an indie developer, you will most likely not have a steady income. Your income will fluctuate greatly from day to day. Until you launch that first game, your income will be $0. Even after you launch that first game, your income may very well still be close to $0. You need to be ready for that.
Game Developer Magazine does an annual survey of game developer salaries around the world (but mostly centred in the US). This past year they did the first indie salary survey [1]. The survey found that the average annual income for a solo indie developer (i.e. a dev working by his or herself) is about $11,000 USD. The average increases to about $20,000 if the developer works as part of a team of two or more people. This is why so many indie developers do contract work on the side. Making your own game is a risk, but being paid to develop someone else’s game is less risky.
But there’s an upside: if you’re one of the few lucky ones to release a really killer game that takes off and becomes a hit, the potential to make a lot of money is there. Just don’t rely on it as your plan for sustaining the business.
What does this mean? It’s going to be an adjustment. If you’re used to working a job with a regular salary, working for yourself will take some time to get used to. You’ll start thinking about your time differently, and also start thinking about money differently. Instead of thinking “This DVD is only $20, I’ll take it!” You’ll start thinking “Wow, $20…that’s like selling 29 copies of my game at $0.99…that’s like…three days of sales.”
2. Work/Life Balance
In my other post I talked about the freedom we have as indie developers to work the hours we want to work. However, the flip side of that is that the line between home life and work life can easily become blurred. If you’re working for a larger indie studio you may have office space and this isn’t as much of a problem. But if you’re working from home, it’s easy to “just work one more hour” after dinner, or “just write a few more emails before bed”. Next thing you know it’s 2:00 AM and you’re introducing three bugs every 15 minutes into your rendering system. When your work computer is in your home, it can be difficult to force yourself to stop working, or sometimes to start working.
I’m a guy who likes his routine (boy is that changing now that I have a one-month-old baby). My routine helps me to work during “working hours” and not work when I want to spend time with my family. Even though I work from home, (before the baby) I got up every day at 7:30, showered, ate breakfast, got dressed, and “went to work”. It helps me to delineate the difference between being at home, and being at work. A friend of mine told me about his friend who used to walk around the block and return home to force himself to think about being “at work” differently. Where I still struggle the most is at the end of the day. 5:30 or 6:00 rolls around and I need to start cooking dinner, but it’s easy to “just write a couple more lines of code” and get lost in it.
However, it can be done. You can find a really nice balance between work and life outside of work. It’s just going to take more discipline than if you worked for someone else.
3. Oh So Much Paperwork
All you want to do is make great games, but if you’re reading this, you’re probably pretty serious about it. You’re running a business. Running a business comes with a lot of work that isn’t much fun: filling out international tax treaty forms, doing your monthly bookkeeping (did I say monthly? er…yearly?), filing your taxes, dealing with copyright or trademark infringement, figuring out how to make money, etc, etc. But it all needs to be done. Your brain will want to say to you “hey man, you could be logging your business receipts in your accounting software right now…but wouldn’t you much rather be implementing that new animation system you’ve been dying to try??” Sometimes you need to tell that little voice to shut up and take care of the business.
4. Feeling Like a Failure
Ok, this is starting to get kind of personal…and I really hope I’m not the only one who feels this sometimes. 
As much as you’ll have days where you absolutely LOVE being indie and making your own games, you will probably have days where it just sucks. You’ll get your daily sales report (if you’re selling on the App Store) and have a day where you made $1.43 the previous day and you’ll start to wonder what you’re doing with your life. You’ll hit a roadblock with your game and wonder if you’ll ever be able to solve it. You’ll get to an alpha build with your game and realize all the fun work is done and now you just have to hunker down and finish the boring parts of making a game. You’ll have a day where all your ideas feel like they’re the worst idea you’ve ever had.
I’m here to tell you: that’s ok. But this is why it’s so important that you LOVE making games. Because not all parts of the process are fun. Some parts suck. Some parts will make you want to quit. But if you really love it, if you can’t think of anything else you’d rather be doing with your life, then you’ll push through the bad days and you’ll get back to loving it again.
But…It’s Worth It
So yes, there are parts of being an indie developer that aren’t all sunshine, lollipops, and rainbows (you really should click that link). But you know what? I still love it! Because for all the annoyances and hard days, they all pale in comparison to the fact that I get to make the games I want to make every day!
Owen
[1] Brandon Sheffield and Jeffrey Fleming. “9th Annual Game Developer Salary Survey“. Game Developer Magazine. April 2010: 12.
Game Dev: Getting Started
Sunday, November 7th, 2010
A friend of mine sent me a message on Twitter the other day asking if I had any tips for someone looking to get started in game development. I mentioned this was quite a large question, so I asked him to narrow the scope of his question. He came back with “between idea and prototype.” That seemed like a good subject for a blog post!
So, you’ve got some programming under your belt. Maybe you’ve been building web site back ends, or accounting software, and you’d like to try your hand at games. Where do you start? If you’ve got an idea, how on earth do you approach the process of turning that idea into a prototype?
1. Consider Scope
I’m putting this right up front, because it’s the biggest and one of the most common traps a new developer can fall into: your idea is just too big. It’s very easy to bite off more than you can chew with a game idea. If you’ve never made a game before, don’t try to build a huge RPG in a massive world for your first game; you will almost certainly not finish it. What about something like tic-tac-toe instead? Or your favorite card game? Or a match-3 game (my first game, Dapple, was chosen because it had a very defined scope, and it still took nearly 6 months to make).
To put things into perspective: a triple-A Xbox 360 or PS3 game will have a team of 100-200 people working for 1-3 years on it. If you’re one person expecting to work on a game for six months, you need to make sure you’re working with an idea you can finish. You can’t build Halo by yourself. That’s ok. Pick a game idea you know you can finish; it will be challenging enough.
Also don’t forget that there are lots of parts to making a game that aren’t immediately obvious that you’ll need to build: menus, save systems, high score boards, platform specific requirements, etc, etc, etc. If you think your game is going to take you three months to make, bank on it taking six. So if you only have three months of savings to live off, maybe pick a game idea you think you can complete in a month and a half.
2. Learn About Games
This is a tough one, are you ready? You need to learn more about games. This means, yes, even playing other games for research. It’s a tough job, but someone’s got to do it. Take a look at other games in the genre that you’re targeting. Look at what they do well, and more importantly, what they don’t. What bugs you about the way they implemented things? What stands out as being done well? Are their menus clunky? Do the animations add that extra punch to really augment the gameplay? Does the music help draw you in? Take notes. Remember that you’re playing to learn, not just to have fun.
If you’re coming at this from a background other than game design, you may also need to do some reading. There are lots of great books written on the subject, and more being written every day, as the industry grows. See what expert game designers can teach you about designing games by reading their books.
One of my favourites, which is also a very quick read, is Raph Koster’s “A Theory of Fun for Game Design“. It’s great book to get you started thinking about designing games and what makes games fun. Another book I haven’t read yet, but have heard a lot of great things about, is Jesse Schell’s “The Art of Game Design: A Book of Lenses“. There are many other great ones, I’m sure. The important thing to remember is that making games is a constant learning experience, so get learning!
If you’re already a game developer reading this, what about you? What are you favourite books? What developer forums do you read? What blogs are the most useful?
3. Choose a Prototyping Technology
So you’ve got your idea and you’ve got some ideas about how to make it work as a game. Now you need to choose your technology for implementing a prototype. I gave a talk in April at the amazing 360iDev conference (their fall conference starts today in Austin) on rapid prototyping. One of the things I talked about is that when you’re prototyping, use whatever technology you are most comfortable with. This doesn’t have to be the same technology you’re going to implement the game with. If you’re targeting releasing an iOS game, but you’ve never touched Objective-C, but you’re a Flash wizard, prototype in Flash. If you’re an expert in javascript, prototype in javascript. If you’re not overly comfortable in any technology, prototype with pen and paper! Do whatever you need to do to get a working version of the game as quickly as possible. All the planning in the world won’t tell you whether or not the game is fun. Playing it will tell you that instantly.
If you’re doing iOS development, cocos2D is a fantastic platform with which to do 2D game prototyping. Flash is a great prototyping tool. If you’ve used Unity, I’m told it’s also great for prototyping. If you’ve got your own engine you’ve been building, use that, just be careful not to spend your prototyping time implementing engine features.
4. The 2-Minute Guide to Game Architecture
Ok, so what I’ve talked about is all well and good, but if you’ve never looked at game code before, you may be wondering how on earth a game works. This is obviously a HUGE topic, one that’s covered in immense detail in many books. However, I will attempt to give the extremely high level overview of how a game works. Ahem…wish me luck.
The Game Loop
At the heart of your game is a loop. This loop executes as long as the game is running. In fact, in many games, it’s a while (1) loop. In iOS development, you’ll be working with an event-driven timer instead. However it’s structured, the important thing is that you’ve got a chunk of code that’s going to execute over and over again. This chunk of code makes up one frame of execution. Most games aim for either 30 or 60 fps (frames per second). This means that your game loop needs to execute in less than 1/30 or 1/60 of a second.
At its most basic, your game loop is going to do two things every frame: update and then render.
The Update
This is where your per frame game logic resides. The update will do things like: pump the physics system (if there is one), update all the active animations, handle collision detection, etc. Basically, it updates the state of the game world in 1/30 or 1/60 second intervals. It says, 1/60 second has passed since the last time I was called, what needs to update? Oh, this character animation needs to be updated, these sprite positions needs to change, these two objects collided, etc. At the end of the update function, your game is in a new state and is ready for rendering.
The Render
Now that the world’s state has been updated, it’s time to render everything to the screen. This means going through all the renderable objects in the world and drawing them. If you’re using a graphics engine, then renderable objects (like sprites) may automatically get a draw() call made on them. If you’re using OpenGL or DirectX directly, then this is where you’ll be making calls into the graphics libraries to do the drawing yourself.
Building a rendering engine that runs quickly is an absolutely massive topic. You’ll need to pick up a book or two (and brush up on your 2D and 3D linear algebra, as well as low-level graphics hardware achitecture) if you’re going to roll your own.
Events
But let’s remember, games are interactive media. This means that at some point you need to handle user interaction with the game. This is often event-driven, in that it’s handled outside your main game loop. You’ll get calls into your code saying “this button was pressed” or “the user touched the screen here”. Some more traditional game loops would have input polling before the update was done. Many modern game frameworks (or platform APIs) rely much more heavily on event-driven code. Much more of your game logic will happen in your event handlers.
At any rate, these events are where you’re going to change game state based on what the user is doing. In a board game, the user might click a button to roll the dice, so your button click event handler is where you’ll trigger a dice roll. In a first-person shooter, you’ll be handling analog stick position updates to update the camera orientation and player’s position in the world.
You may also need to respond to system events, like an iPhone going to sleep, or the user alt-tabbing out of your full-screen game.
The Other Stuff
Those are the basics, but there is so much more that goes into a game: audio systems, user interface systems, front end menus, HUDs (heads up displays), physics systems, animation systems, game logic systems, font rendering systems, save game systems, leaderboard systems, achievement systems, and localization systems (to name but a few). But remember, not every game needs all of these things. That’s why it’s important to remember #1 and limit the scope of your first game.
The hardest thing about creating your first game is finishing it.
It will take dedication to work through the bugs and the tedious parts of building a game (yes, there are tedious parts), but in the end, it’s worth it. You’ll have a game that you made ready for the world to play and enjoy. So what are you waiting for? Start learning. Go make a game!
Owen
I’m Indie, and I’m Proud
Sunday, October 10th, 2010
I had been struggling to come up with a topic for this week’s #iDevBlogADay post and @frederictessier suggested I write about a day in the life of an indie, and that sparked a post I keep meaning to write.
I want to talk today about why I’m indie. As many of you know, I come from a games industry background. I worked two years at Electronic Arts, and almost three years at Propaganda Games (a Disney studio) in Vancouver. I worked on PSP, Xbox 360, PS3, and PC games as a lead user interface programmer and senior gameplay programmer. I loved my jobs in the industry. I loved the people I worked with, and I loved the games I got to work on. And yes, I enjoyed the regular, decent pay cheque. So in the summer of 2008, when my wife and I decided to move back to Ontario to be closer to our families, I had a decision to make: I could find an industry job in Ontario, or I could follow my dream of being an indie developer and start making my own games. Obviously, I chose the latter. But why?
To me, the most alluring aspect of indie life is the idea of taking an idea and making a game out of it. Not a game designed by a team of designers, level designers, artists, programmers, audio designers, audio programmers, animators, etc, etc, but a game designed and created by me, the way I see it in my mind. The opportunity to tell my own stories, to share my own thoughts and emotions with players. The chance to express myself in game form. I view game creation primarily as a craft or artistic expression, not just as a business. Being indie offers me the opportunity to explore concepts that I wouldn’t otherwise have the chance to explore.
My time in the console industry, while I wouldn’t trade it for the world, also involved some heavy amounts of long hours and weekend work. I did more than my fair share of crunch. My wife and I are starting a family and I didn’t want to be working 80 hours a week while my child grew up without me there. Working for myself allows me to set my own hours. It allows me the flexibility to work when I want and not work when I want. If I want to work 80 hours a week, that’s fine. But if I don’t want to work 80 hours a week, then I don’t work 80 hours a week. If I want to work in the evenings and spend the mornings with my family, then I can do it. I can work however I want! As self-employed indie developers, we get to choose our own hours. We get to choose our own work-life balance. This is not something we should take for granted.
Finally, I love being an indie games developer for the same reason I like cooking: I get to understand every step from start to finish. If I want a physics system in my game, I need to learn how it works. If I want sound effects in my game, I need to teach myself how to create them. If I want graphics in my game, I need to draw them. I love programming, that’s my professional background, but I enjoy all the parts that go into making a game. I love being able to learn about it all. Being an indie developer means that I’m constantly learning about a whole variety of new things, from math, to movie editing, to 19th century artistic movements, to 8-bit square wave music generation. What could be more awesome than that?
Yes, there are hard parts about being indie. I’m not pretending otherwise. It’s incredibly hard at times. I miss the social aspects of working in an office. I miss having a regular pay cheque. And yes, sometimes I even miss having someone else telling me what to do, instead of having to make every decision myself. But you know? I still love it. Because if I want to make a game about mixing paint colours, monkeys in space, or about terraforming, I can, damn it. I’m Owen Goss. I’m indie, and I’m proud.
[Update (2010-11-14): I just posted a companion piece to this entitled "Indie Challenges", that looks at the other side of being indie.]
Owen
P.S. Happy Thanksgiving to my fellow Canadians!
FITC Mobile 2010
Tuesday, September 7th, 2010
Can you believe it’s September already? Where did the summer go? Here in Southern Ontario we didn’t even get a transition; it was 33C one day, then two days later it was 12C. Anyway, I digress. With fall comes back to school (for those still in school), and the start of a new season of conferences!
I’m going to be speaking at FITC Mobile in Toronto, running Sept 16-18, 2010. I’m giving a talk on memory leaks in iOS on Friday the 17th, from 12:00-1:00pm. Specifically, I’ll be talking about memory management, what a memory leak is, some common ways they’re introduced in iOS programming, and show you how to use the tools to track them down and fix them. If you’re an iOS programmer and you’re coming to FITC Mobile, I hope you’ll check out my talk. Bring your coding hat, though; I’m going to be showing code, and actually demonstrating stuff in Xcode.
I hope to see you there!
Owen