Archive for the ‘Design’ Category
Why I Attend GDC
Tuesday, April 19th, 2011
Hello, my long neglected readers! I have been a terrible blogger as of late. I have been extremely busy with my current contract work, so I haven’t had a lot that I can talk about here on the ‘ol blog. The game I’m working on is nearing completion, at which point I’ll be returning to my own projects and I should have more to talk about.
The good news is that my turn rolled around for #iDevBlogADay and it has pushed me into writing this post. Hooray! This is precisely the purpose of iDBaD, but I digress…
I’m long overdue for a post-GDC blog entry. Last year was my first time attending the Game Developers Conference and I wrote up a post about how much I enjoyed it. This year was even more exiting for me, and I had intended to come home and write up a post about how great it was, and then life and work got in the way. However, it is time. Let’s talk GDC!
I will say this right now: GDC is expensive. It’s not a cheap conference. Most people attending are there because their large company is paying for them to be there, so cost isn’t really an issue. For us indies, plunking down $1400 for a full-access pass is like taking a swift blow to the stomach. Add the cost of a flight from Toronto, and 5 nights of staying in a hotel, and you’ve got quite a bill. So the question everyone wants to know is: is it worth it? I’ve heard some devs say “why should I go to GDC when I can get a new computer instead for the same price?” Is it worth it? My answer: an emphatic YES.
GDC has three parts to the show: the 2-day summits and tutorials, the 3-day main conference, and the 3-day expo that runs at the same time as the main conference. You can buy a pass for the summits, the main conference, or both. I like to do both. The reason is this: the summits have a big indie emphasis, so you get to meet a lot of amazing people and get inspired by the top indies in the world; the main conference has some amazingly inspirational talks from some of the top minds in the industry. I wouldn’t miss either. Together they form a near-perfect conference for me.
This year for the 2-day summits & tutorials I decided to gamble on taking part in the 2-day game design workshop. I was nervous about doing this because it meant I couldn’t attend any of the indie sessions. However, I think I made the right choice for me. The workshop was an intense 2-day crash course in game design, and it was absolutely invaluable. I learned an incredible amount about game design process, which is one of the areas of game development where I feel I have the most to learn. This workshop gave me a language to use to talk about game design; it let me interact with other designs and solve design problems together; and I came away with some invaluable tools for solving game design problems. If you’re attending GDC and considering the game design workshop, I can’t recommend it highly enough. After those first two days, I felt I had already gotten my money’s worth for the conference, but there were still 3 days of awesomeness remaining!
Last year at GDC, I didn’t really know what to expect from the main conference, so I went to a lot of different sessions in a lot of different fields: programming, art, game design, business, etc. This year I focused on design sessions and this really worked for me. I saw some mind-blowing talks on game design and design process from some of the game designers I most look up to. (Check out the GDC Vault and you can watch some of the classic game post-mortems for free.) By the end of the conference my mind was bursting with ideas, and my heart was filled with hope for games as a medium and inspiration for my own games.
That feeling right there, that’s why I go to GDC. Nowhere else have I ever felt so excited to be a game designer and developer. Nowhere else have I become so inspired to create new and innovative games. Nowhere else have I met so many amazing game developers who are all striving to make the best games the world has ever experienced. Nowhere else have I had so many amazing conversations with other developers and designers about games and their importance.
By the end of February, I was feeling pretty burnt out about making games. I hadn’t worked on my own projects in quite some time. I was starting to wonder why I do what I do. By the time I left GDC, I was alight with creativity, a renewal of excitement about having the best job in the world, and a hunger to create something new and important. GDC was a reminder that there are amazing people making incredible games all around the world; a reminder that there are people trying to make games that matter to themselves and to others; a reminder that making games is extremely difficult, but also profoundly rewarding. This is why I will choose GDC over a new computer, any day.
Owen
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
Creative Block
Sunday, October 3rd, 2010
After failing to meet my deadline for #iDevBlogADay on my second week, I was put to the end of the waiting list. Just over three months later and my turn is back up! I’ve taken the Sunday slot, which has a history of not lasting very long, so we’ll see how many weeks I can keep this up…
For my (triumphant?) return I’ve decided to not write a technical post. I was going through a list of technical things I could write about, but I just wasn’t feeling it. I decided I’d rather write about game design today, and perhaps more generally, about the creative process in general. Specifically, I’d like to talk about the problem of creative block.
What I’m talking about is getting stuck on a creative problem; being paralyzed by creative decisions. It happens to everyone. And if it hasn’t happened to you, then, well, I envy you. The block can happen in a number of ways: you have too many ideas and can’t decide which one to look at first; you have lots of ideas, but now they all seem terrible; you have no ideas at all; you have a few ideas, but they all seem equally interesting; and on and on.
For me, I run into these problems most commonly at the start of a new game. I’ve just wrapped up a previous game where I’ve spent the last month or two dealing with the tiniest minutia of polish and wrap-up and marketing. It’s been a while since I’ve had to do “big picture” thinking and come up with a new concept. It’s usually at this point that I’m also in my post-release “blues” period, coming back down to reality from a post-release high (perhaps I’ll devote next week’s post to this alone). I start going through my various notebooks and sketches looking at all the ideas I’ve written down and looking for those few that scream out for more exploration. It’s at this point where I’m most likely to become stuck.
“What if all the ideas I have written down are terrible?” “What if none of these are doable?” “What I spent several months building this game and no one buys it?” “What if…” “What if…” It’s easy to get sucked into a place where you can’t make a decision and spend all day reading twitter and other iDevBlogADay posts in an effort to avoid actually doing something. [wink]
Of course, this sort of paralysis can come at other points in the project too: you’ve got a working prototype but you’re uncertain how to take the next step into starting to turn it into a game; you can’t decide whether your game data structure would be better represented as a graph or as a b-tree; you can’t decide whether the game should feature zombies or pirates or both; you can’t decide whether your pause button should be green or red; and on and on. So off to twitter and your favourite RSS reader you go to avoid the problem.
Now I should probably state that I don’t have a solution. Oops, maybe I should have said that before you started reading this far. But honestly, if I did, I’d be on the motivational speaking circuit instead of making indie games. However, I have a few tricks that I try, and usually one or two of them will help me push through a rough spot and let me get on with it:
1) Make a Decision and Go
This is probably the hardest of the things I’m about to say, but this is probably one of the most useful. Flip a coin, write the options down on paper and draw one out of a hat, or just pick whatever seems most reasonable, then start working on it. Often after a few hours of working on anything it’ll get you out of your own head and the ideas will start flowing again in some kind of helpful way. The process of building something instead of thinking about it may also expose problems you hadn’t thought about, or even better, solutions you hadn’t thought about.
Got too many game ideas you like? Pick one, build an eight hour prototype, and see how it feels. If you don’t like it, try another one. Repeat as necessary. Don’t know if your pause button should be red or green? Try both and see how they feel in the game. Can’t decide on a data structure? Pick one and start coding. Five minutes in you may realize that the one you’ve chosen won’t support the API you need and you can start over. But at least you’ve moved on.
2) Use Tools
In 1975 Brian Eno and Peter Schmidt came up with a deck of cards to help get through creative block called The Oblique Strategies. The idea is that each card has a bit of text on it to help you think about a problem in a new way. When you’re stuck on something, you draw a card at random from the deck and it might say something like “Only one element of each kind.” The idea is to force your brain to think about the problem in a new way.
There are Oblique Strategies iOS apps available in the app store if you search for them. I’m not sure which ones have the actual rights to use the text and which are in violation of copyright, so I’m not linking to any of them.
3) Think About Something New
If I’m stuck on a game idea and I’m just not sure if I can make it work, sometimes it helps me to think about a different game for a few minutes. It’s a similar strategy to using the Oblique Strategies. Except in this case, I have a little script I go to that generates a random game idea. I’m making this script available on the site now. You can find it in the right-hand sidebar under the Pages header, called “Game Idea Generator“. Go play with it for a couple of minutes and come back…I’ll wait here.
Back? Good. Moving on.
4) Talk it Out
Still stuck? Talk it out with a friend. Even someone who knows nothing about what you’re trying to do. In fact, sometimes that helps. They might be able to offer suggestions you wouldn’t think about. Even just saying the problem aloud to yourself can sometimes help (though can also lead people to believe you may not be right in the head). Talk to a friend, your husband or wife, your cat or dog, or post a question on twitter or your blog and see what people say.
5) Take a Break; Do Something Inspiring
If all of the above don’t work, maybe it’s time to take a break. I like to try to find something to do that will inspire me in new ways: play a video game, watch a film, read a book, do some sketching, go to a life drawing class, listen to music, go to an art gallery, go for a walk in a forest, go for a bike ride, talk to someone you love, grab a coffee with a friend. The important thing is not to dwell on the fact that you’re stuck. Get your mind onto something else. Have fun. Be inspired in new ways and the block will become unstuck. Just remember: you do need to come back to the problem at some point. Don’t let taking a break become taking ten breaks.
Fin
Making games is hard work. We all know that. But we also know it’s the best job in the world. We make games because we love what we do. But we often don’t talk to each other about the hard parts, about the frustrations of getting creatively blocked, the financial challenges, and the emotional ups and downs. Maybe it’s time we started doing that a little bit more so we can help each other out.
Owen