Archive for the ‘Project Management’ Category
My First GDC
Friday, March 19th, 2010
I returned home from the Game Developers Conference (GDC) nearly a week ago, but I feel like it has taken me this long to be able to recover from the late nights, the jetlag, the cold I caught, and put things into perspective. I thought I’d share a summary of my experience there, for those who are thinking of maybe going next year.
Executive Summary: SO AWESOME!!!
GDC is held every year in San Francisco. I’ve been in the games industry for over 6 years now, but this was my first time at the conference, so I wasn’t really sure what to expect. I managed to get an All Access Pass to the conference, so I was there for the summits and tutorials, as well as the main conference.
Let me back up a little and talk about my reasoning for going, as that will help you understand why the conference was so valuable to me. At the beginning of the year I started thinking about what conferences I wanted to attend. 360iDev was a must-attend for me, so I booked that first. However, I was torn between attending WWDC (Apple’s big annual conference) or GDC. I attended WWDC last year and it was great. But this year I felt like what I really needed was general game design inspiration, and less Apple-specific technical inspiration. With that in mind, I chose GDC. My goal for the conference was to focus mainly on game design sessions and take in a few technical and business sessions.
So, I arrived in San Francisco Monday, March 8th, the day before the Summits started. I managed to meet up with a bunch of iPhone devs I know from Toronto, other conferences, or Twitter. We had a few beers and tried to adjust to west coast time. It was a good way to ease myself into the week.
Tuesday and Wednesday were the Summit & Tutorial days at GDC. There were two summits I was interested in: the iPhone Summit, and the Independent Games Summit (IGS). I think I spent about 60% of my time at the IGS and about 40% at the iPhone Summit. I saw some great technical iPhone talks by Noel Llopis from SnappyTouch and Phil Hassey from Galcon. I also saw some great IGS talks that ranged in topic from managing an independent game studio’s creative process, to how to better design indie games. I saw a session by Ron Carmel from 2D Boy, several awesome sessions by the people at thatgamecompany (Flower is one of my favourite games), and a terrific session by Randy Smith from Tiger Style (among so many others!). By the end of the Summits, my head was already spinning with inspiration. The IGS design talks in particular were extremely motivating for me. Getting a chance to meet and hear amazing indie game designers/developers talk about their processes was fantastic. It started me thinking about a lot of things as they relate to my own processes. More on that later…
A tiny segment of the massive GDC Expo
The IGF Awards
Thursday through Saturday were the main conference, expo, and Independent Games Festival Awards. I sat in session after amazing session listening to industry leaders in game design, technical development, and business talk about their processes. I saw Peter Molyneux talk, Sid Meier talk, and even Will Wright talk. I saw a moving and inspirational talk by Brenda Brathwaite on her exploration into board games with serious themes. I saw a head-ache inducing (in a good way!) talk on PixelJunk Shooter’s real-time fluid dynamics system that made me really miss doing PS3 SPU programming. I saw an in-depth and honest look a the successes and problems encountered by Naughty Dog’s attempts to create an active cinematic experience for Uncharted 2. I was blown away by the quality of the content, and I was left reeling by how the talks started forcing me to think about the direction I want to take with my own games.
There were huge crowds in the halls between sessions!
But of course, the sessions are only part of GDC. The other part comes from meetings and parties. I was able to set up a few meetings with iPhone press to show them my new game. That was really great to be able to demo the game in person. I think it was extremely valuable. Then each night there were countless parties happening. Each party was a great chance to meet people in person who I’ve only communicated with on twitter or via email. It was a chance to discuss iPhone development with other people going through the same thing as me. It was a chance to discuss game design in general with other game designers and developers. It was a chance to have fun with people who share in the same daily challenges that I do.
Will Wright giving his presentation!
For me, I got out of GDC exactly what I wanted: design inspiration, new friends, new business connections and a wealth of knowledge. But perhaps most importantly, GDC helped me to put me back on track with where I want to take my games. When I decided to go indie in 2008, it was because I wanted to make the games that I was compelled to make. What I’ve noticed is that I’ve been making more and more design decisions lately based on what I think will sell well. This isn’t how I want to make games. I want to make the games that I have to make, not that I think I should make because I think it might make some money, even though the idea doesn’t excite me. Granted, I would love to be able to make the games that I feel compelled to make and have them also become a financial success. And obviously I can’t ignore the fact that I’m running a business. But GDC helped to remind me of what I want my priorities to be, and that, to me, is the most important part of having gone.
Owen
Postmortem: Monkeys in Space
Wednesday, January 6th, 2010
I never wrote up a formal postmortem for Dapple and I wish I had. Now that Monkeys in Space has been out for over a month and I’ve released one major update, I thought it was about time to sumarize what went right and what went wrong on my second game.
Because I really enjoy reading Game Developer Magazine, I thought I’d follow their template for a postmortem and list 5 things that went right followed by 5 things that went wrong on the project.
What Went Right
1. Prototyping, Iteration, and Early Feedback. One of the processes I put into place when I started Streaming Colour Studios is the extensive use of prototyping and rapid iteration. When you build a large console game, you need to plan out everything a lot more because there are 100 people working on the game. When it’s just you, you can afford to play around with ideas a lot more.
Monkeys in Space actually started out as a completely different game. The first prototype I built involved controlling space ships with black holes. One of the things I learned with Dapple is that the sooner you get feedback the better. So this time I sent that first prototype out to a few trusted friends to get their opinions on it. The feedback that I got was that the controls weren’t intuitive enough and the game wasn’t really fun to play, just frustrating. This was fantastic feedback to get so early in the process and I was able to start trying new ideas and iterating on the design.
Eventually I got to the point where the game was fun, but the space ship theme wasn’t working for me anymore. I had had an idea for a bonus level that involved picking up monkeys floating in space with your ship, but after discussing this with a few friends over coffee (one of them ended up writing the music for the game) I decided that the game might be more fun to play if the monkeys were the focus of the game. Once this decision was made, it opened up new avenues for art direction, marketing, names, and even merchandise.
Once I had the monkeys in the game, I opened the game up to much more public play testing. People were playing the game and providing regular feedback at a much earlier stage of the development than with Dapple. This proved to be invaluable for fine tuning the design and polishing the game.
2. Gameplay. Monkeys in Space fits into the “line drawing”/”chaos management” genre of games, but it needed something to set it apart and help it to stand out. I had also learned, through my experiences with Dapple, that I needed a gameplay mechanic that was easy to understand, but offered depth to the experienced player. Monkeys in Space offers familiar gameplay goals to players familiar with the genre (get the monkeys to the bases), but adds a twist that adds depth to the game (linking monkeys together). The chaining mechanic was added about mid way through the prototyping process, but the feedback from play testers was unanimously positive. I’m very happy with how the game ended up playing out. The chaining adds a risk/reward factor to the game that has been mentioned in a lot of reviews.
3. The Name. I mentioned above that the game was originally about space ships. Well, it was a search for a name for the game that ultimately led to the game being about monkeys instead. I was brainstorming game names with some friends when I mentioned I had been thinking about adding a space monkey level to the game. Immediately we all started thinking about fun names for a game involving space monkeys. My favourite at the time was “Space Monkey Rescue”, but I ultimately abandoned it because of trademark concerns. I contacted my friend Stacy, who is a writer, and asked her for help. I sent her some of my favourites, including just “Monkeys in Space”. I told her I was looking for a 50’s or 60’s sci-fi b-movie feel for the title and she came up with “Monkeys in Space: Escape to Banana Base Alpha”, which I absolutely loved. I think the name is perfect for the game in that it captures that silly retro feel I wanted, and it says “yes this is a game set in space, but it’s not a serious sci-fi game; it’s fun and it has monkeys!”
4. Artwork. With Dapple I had decided to hire a professional artist to do the game’s artwork. While the artist did an amazing job and I was extremely happy with her work, hiring an artist is also expensive. With Monkeys in Space I decided to take a different risk and do the artwork myself. Now, I took some art classes in university, I’ve done a little life drawing since then, and I once had a job where I was using Photoshop for eight hours a day, but I’m not a professional artist, so this was kind of a risky move. However, in the end, I was quite pleased with the art in the game. I think the monkeys especially turned out quite well. No doubt a professional artist could probably have bumped the artwork up a notch (or two), but I’m happy with the results. On top of that, it was also really fun. It was great to get back into drawing regularly again and I think it’s something I’ll be considering for future games, if it’s a possibility.
5. Reviews and Apple Feature. Monkeys in Space has received some great reviews from the iPhone gaming press/critics (you can read them on the Press page). Every good review helps to build buzz around a game, but one of the biggest reviews the game got was from TouchArcade.com. Their Monkeys in Space review was on their front page for two days and during that time I saw a sales spike close to what I was to see being featured by Apple. Then a week after the Touch Arcade review ran, the game was featured on the App Store in the Games -> What’s Hot section. This happened just before Christmas, which couldn’t have been better timing. It wasn’t a front page of the App Store feature, but it was enough to push me into the Top 100 Kids Games in the U.S. store. This gave the game some momentum through the holiday boost.
I’ve decided that while I don’t want to share sales specifics about the game (like the infamous Dapple “Numbers” post), I will share the shape of the graph of sales since the game’s launch:
What Went Wrong
1. Release Date. I mentioned this earlier this week, but my release date turned out to be a big mistake. I submitted the game to apple in mid-November and wasn’t sure when to expect it to be approved. I got the email from Apple saying the app was ready for sale at about 7:30pm on Wed, Nov 25th. I was so excited that I switched the app into the “for sale” state (by setting the release date to the 25th) and started preparing the email I’d send out to the press in the morning. On Thursday morning I sent out my press release along with screenshots and video, etc, to iPhone sites. At that point I started getting back “out of office” replies and suddenly released it was Thanksgiving in the U.S. See, we Canadians celebrate Thanksgiving in October, so the date completely slipped my mind.
At first I didn’t think it would be a big problem. But then I started reading the review sites that were staffed for the holidays and most of them were just running stories about the hundreds of games that were going on sale for Black Friday in the U.S. Not only that, but it turns out a lot of people apparently take a long weekend from Thursday-Sunday, so it meant I didn’t hear from anyone until well into the next week.
However, I can’t really complain as the game eventually did get picked up by review sites, but the roll out was more gradual than I had hoped. The delay meant that my marketing lost some momentum right at the start, which isn’t ideal. In the future I will be paying closer attention to U.S. holidays when I set my release dates.
2. Delays. When I did the first concept sketches for the game that was to become Monkeys in Space, the original plan was to build the game in 2 months or less. From start to finish, the game ended up taking almost exactly 3 months. One extra month isn’t terrible, but that’s a 50% overshoot of the original plan. Now I have excuses: my wife and I moved cities, which ate up a few weeks with packing, moving, and unpacking, etc. But I think the biggest reason the game took longer than I thought it would was because I decided to do the artwork. Because I was doing the art and the programming, it meant that the two couldn’t happen concurrently. When you work with an external artist, they can be drawing while you’re coding, but I didn’t have that ability this time. The artwork took longer than I thought it would, which pushed my timeline out. Ultimately, it was worth the extra time to make sure the art was good enough to meet my expectations for the quality of the game, but it did delay its release.
3. Marketing Push. I learned some important lessons with the launch of Dapple. One of the most important was the need to have your marketing push happen all at once. You want everyone to be talking about your game at the same time. I’ve already mentioned the problems the release date caused with this, but I suspect there were some other missed marketing opportunities around advertising that I didn’t explore. I haven’t had a lot of luck with advertising driving sales. However, I think if done properly, there may be ways to leverage advertising effectively, even for $0.99 games…I just haven’t figured it out yet.
4. Not Enough Levels in v1.0. During development I had to make a call about how many levels to include in the initial version of the game. I looked at the great games in the genre (e.g. Harbor Master, Flight Control, etc) and looked at how many levels each had shipped with, and decided to ship three levels. I also chose to limit myself to three levels at first because the game was already taking longer than I had expected. However, what I discovered is that people expect new games to contain as many levels as the other games do now, not how many they contained when they shipped. Some of the reviews of Monkeys in Space have mentioned that they would have liked to have seen more levels in the game. Since then I have released a fourth level as part of a free update and I hope to release more. Regardless, what I failed to realise is that the free update system for iPhone apps creates a different set of expectations in people’s minds. They don’t care that game X shipped with one level; what matters is that it has five now. This was an important lesson in competitive analysis for me.
5. Public Recruiting of Testers. I almost listed this in the “What Went Right” section as well, and it just barely squeaks into the “What Went Wrong” list. Very early in the process (much earlier than I’d ever considered before) I started asking people to play test the game and provide feedback. I put out a call on Twitter, on this blog, and in iPhone gaming forums, looking for people who wanted to play the game and provide some honest feedback about what did and didn’t work. The reason this should also be in the “What Went Right” is that I got some terrific people playing the game and providing me with insightful and helpful feedback. However, I also had a lot of people sign up, get the builds, and I’d never hear from them again. I think there is a small group of people who say they’ll beta test a game just to get a free game. The good news is that I’ve met enough great people that I now have a decent list of preferred testers I’ll ask first next time.
Conclusion
All in all, I’m extremely proud of Monkeys in Space. I think that I learned a lot from some of the mistakes I made with my first game, but I still made a few new mistakes. I suppose that’s all part of the process of becoming a better game designer, developer, and business person. What I like most about Monkeys in Space is seeing new players pick it up and to watch how easily they get involved with the game. I also love watching people laugh when the monkeys scream and wave their arms frantically. People seem to have fun with the game, and that makes me happy. To me, that alone makes the game successful.
Owen
I’m Still Here…Making Progress
Wednesday, October 21st, 2009
It’s been a little quiet here on the blog and video blog lately. I apologize for not being more communicative. I’m hoping to get a new video blog posted in the next couple of days. The gameplay for the game has been nailed down and I’m really close to having the in-game art locked. Once I finish up a HUD for the game I’ll post some screenshots and even some in-game video! Woo!
However, before that can happen I’ve been taking care of some less exciting stuff. The last couple of days I’ve been working on a save system for the game. It turns out saving the state of a game that has a physics engine and is interacted with in real-time is a lot more complicated than for a turn-based puzzle game. Who knew? I kid. But seriously, what I hadn’t anticipated was having to build a whole new save game framework to handle it nicely.
At this point I’m getting a little concerned with the fact that there are only 10 days left in October. If I’m going to submit by the end of the month, I’ve got a lot of work to do. If I really buckle down I still might make it, barring any horrible problems [knocks on wood]. Otherwise I might end up pushing a week in November. Here’s hoping the next two weeks go well!
The good news is that my play testers seem to be really enjoying the game! There are a couple that keep battling for the high score in the leaderboards. It’s exciting to see! A week ago I thought I was Mr. BigShot with the high score in the game for the first level. Now I’m 5th. I love it when that happens. It means the people playing the game are discovering strategies that I hadn’t anticipated.
It should be an exciting next couple of weeks!
Owen
How to Make Dapple in 6 Months
Tuesday, April 14th, 2009
When I posted my “Numbers Post” back in March, one of the most common questions I got asked was “how did it take 6 months to make Dapple?” I found this question interesting. I’ll admit that at first I found it frustrating, and I thought “how could it not have taken 6 months?” But then I started thinking about it more and more. It occurs to me that if you’ve never built a game from start to finish, you might now know what goes into making a game.
With that in mind, I thought I’d take some time today and go over a few things about Dapple. If you haven’t read my 360iDev presentation on the creation of Dapple, you might want to do that. I consider it a companion to this article, but this will go into more depth.
Effort:
The first thing I want to do is look at some numbers, because I think it’s good to put Dapple into context. The question of “how could you spend 6 months making Dapple” is interesting to me because I come from a AAA console game background. Before I moved back to Toronto and founded Streaming Colour, I worked on a team of over 100 people who all worked on a single game for 3 years. Dapple had one person (me) working on it full time for 6 months, and 3 content creators working on it, say, half-time for one month each (call it 1.5 months total). When you put it like that, it’s hard to really put that into perspective…so let’s do it this way instead.
AAA Console Title (Xbox 360 or PS3):
- 100 people (this is actually fairly conservative; some teams are up to 200 people now)
- 3 years (this is pretty standard, unless you’re EA putting out a franchise every year)
- 220 working days a year (this doesn’t include overtime, which means this will be much lower than actual effort involved)
- 6 hours of work per day (again, not including overtime)
- Total person-hours: 396,000
Dapple (iPhone):
- 1 person
- 7.5 months (this includes the contractors’ time)
- We’ll call it 160 working days
- 6 hours of work per day (again, not including overtime)
- Total person-hours: 960
Let’s call it 1,000 hours for Dapple, then. In actuality, I worked quite a bit of overtime, especially on the last 1/3 of the project. But still, for that amount of effort, I think Dapple is quite impressive. Maybe I’m biased.
Lines of Code
My friend Jay posted on his blog recently about the growth of code size between Wolfenstein 3D and Quake 3. It’s a fascinating read. It also got me thinking about Dapple’s code size. With Wolfenstein 3D being released for iPhone as open source recently, I thought I’d compare the two. I used a tool called cloc to run a line of code comparison of Wolf 3D and Dapple:
- Wolf 3D = ~28,000 lines of code
- Dapple = ~21,000 lines of code
This means that Dapple is about 3/4 the size of Wolfenstein 3D, which I actually found quite shocking. The big difference here is that Wolf 3D’s code is mostly for the game. When I broke it down further, I discovered that over 6,000 lines of code for Dapple is for the front end and user interface. If you look at Wolf 3D, they only have a few very simple menus in the game. Dapple has dozens of screens.
I’m not sure if there are any conclusions to be had here, other than to say that it does take time to write 21K lines of bug-free code.
Timeline
Finally, this will only be of interest to only the most hard-core of the hard-core, but I took an hour or two and I went through all of my change logs during development of Dapple. What I’ve done here is give a week by week summary of what I did to create Dapple. Keep in mind that most stuff relating to the business (e.g. finding and hiring contractors, dealing with international sales contracts, etc) didn’t have any mention in my change logs, so I haven’t mentioned them here. This mostly just relates to the coding tasks involved in creating Dapple. So, without further ado, here’s how you make Dapple in 6 months:
Pre-Production
Week 1:
– Downloaded, installed and learned Playfirst’s Playground SDK (2D game engine) for Mac.
Week 2:
– First pass at prototyping original game concept.
– Game isn’t fun.
Week 3:
– Created animation system.
– Changed some gameplay mechanics to make the game more fun.
– Added some simple animations.
– Game still isn’t fun.
Week 4:
– Branched prototype and started working on new gameplay mechanic, based around same idea: mixing paint colours.
– Gameplay now based around making matches (more similar to final product)
– Game is more fun, but is too complex – new players are easily confused.
– Experimented with simple SFX and background music
– Experimented with some simple HUD elements (displaying score, for example)
Week 5:
– Ported prototype to Windows.
– First draft of game design document.
– Started designing front-end UI flow (menu screens).
Week 6:
– More gameplay mechanic changes to simplify the gameplay.
– Game is now quite fun (very similar to final game mechanic).
– Added logic to detect end-of-game condition.
– Changes to underlying board data structures to make things more flexible.
– Added hint animation.
– Added in the concept of brown paint.
– Game no longer fun with current first-pass implementation.
Week 7:
– Balanced the way brown paint works.
– Added in concept of brown paint spreading.
– Game is quite fun again (and is now almost the same as final game, in terms of mechanics)
– Decided to port to iPhone, just to see if I could.
– Prototype ported to iPhone successfully (but no UI, no ability to restart a game after it ends, etc).
– Game uses CocoaTouch and UIKit for now.
Week 8 – 10:
– Working on company website and logo design.
– Other misc business stuff.
Week 11:
– Added special items to the game (water drop + diamond).
– Game much more fun, much better balance.
– Gameplay tuning.
– Fixed major bug in the search algorithms when looking for potential matches for the hint arrow.
– Hint tuning.
– Branched from prototype branch into the main trunk.
Production
Week 12:
– Now working on the game I will eventually ship – no longer prototyping.
– Deleting all the junk code from the prototype.
– Refactoring reusable code.
– Rewriting all the classes that were deleted.
Week 13:
– More refactoring and rewriting.
– Code base is much cleaning and extensible.
– Set up developer profiles, etc, and got project running on device hardware (instead of just simulator).
– Fixed some major bugs in the game logic and UI.
– Created Front End wireframes document to provide to artist.
Week 14:
– Converting game to OpenGL.
– Got the game back up to previous state, but with rendering layer swapped out and now using OpenGL instead of CocoaTouch and UIKit. Game now completely OpenGL-based.
– Adding temporary Title Screen on launch.
– Implemented game mode loading system.
– Did some event handling to disable rendering/update while device locked and handling long update times after unlocking.
– Fixed some bugs.
– Upped number of levels that game has difficulty controls for.
– Set up ad hoc distribution builds.
– Fixed some memory release bugs.
Week 15:
– Fixed bugs in touch handling.
– Implemented audio system shutdown during device lock (was causing battery drain).
– Implemented end-of-game handling to bring up simple high scores list.
– Difficulty tuning.
– Implemented paint “falling” animation and tuned.
– Implemented support for animated textures.
– Implemented paint “match” animation with temporary texture.
Week 16:
– Changed hint logic to pick random hint instead of closest to top-left.
– Adjusting scoring system to take into account special items.
– Implemented “scoring” animation.
– Fixed some bugs related to scaling/translation in animation system.
– Animation tuning.
– Fixed a bug with alpha blending for textures that had alpha in them.
– Fixed some memory leaks.
– Started adding first art assets that arrived from artist.
– Score tuning.
– Implemented score multiplier system for combos.
– Implemented “multiplier” animation.
– Refactored rendering code to separate rendering of individual HUD elements more.
– Implemented progress bar functionality.
– Implemented bitmap font rendering system just for number values in-game.
– Started implementing a Front End framework system.
– Implemented system to load/unload front end screens (i.e. menus)
– Implemented temp main menu to test FE flow system.
Week 17:
– Implemented more of the FE framework system.
– Hooked up the Pause button to load an empty pause menu.
– Added new artwork to the game.
– Implemented tinting for the bitmap font system.
– Implemented UI Widget framework to hook into the FE framework.
– Implemented “Menu” widget.
– Implemented first pass at “Main Menu” using new Menu widget.
– Implemented “Chooser” widget.
– Implemented first pass at “New Game” screen using the Chooser.
– Implemented “Slider” widget.
– Implemented “Checkbox” widget.
– Implemented first pass at “Options” popup.
– Connected widgets in Options popup to control user settings.
– Implemented first pass at “Pause Menu”.
– Implemented first pass at “How to Play” popup.
– Implemented first pass at “Credits” screen.
– Scoring tuning.
– Implemented a user data storage class.
– Connected user data to NSUserDefaults to save out user data settings.
Week 18:
– Added first SFX assets from sound designer.
– Added first music assets from composer.
– Implemented first pass at colourblind support.
– Added high scores to saved data.
– Animation tuning.
– Difficulty tuning.
– Added SFX to animations (e.g. “squish” effect when paint falls).
– Fixed a bunch of bugs and memory leaks in SoundEngine.
– Fixed some bugs around touching the screen during animations.
– Replaced all art in the game that contained text with new art with a new font (font licensing issues).
– Added new match animation.
Week 19:
– Implemented first pass at a “Generic Popup” class.
– Implemented “Quit Confirm” popup using new Generic Popup.
– Implemented system to save the user’s game in progress.
– Art tuning.
– Implemented first pass at “High Scores” popup.
– Hooked High Scores popup into the end-of-game flow.
– Implemented the “Level Up”, “Good”, “Great”, and “Amazing” animations.
– Big bug fix to do with alpha blending to do with premultiplied textures.
– Bug fixes.
– Implemented the Mixing Guide.
– Added new colourblind mode artwork.
Week 20:
– Implemented first pass at “New High Score” popup.
– Hooked New High Score popup into end-of-game flow.
– Added new SFX assets.
– Implemented all of the “How to Play” sub-popups.
– Tuned colourblind mode settings.
– Tuned all the FE positioning values to make sure everything lined up properly.
– Difficulty tuning.
– Started adding real credits to credits screen.
– Added final art assets.
Week 21:
– Christmas holiday
Week 22:
– Created game video captures and created first trailer video.
– Wrote announcement press release.
– Started gathering contact information for PR.
Week 23:
– Added new music assets.
– Added final SFX and music assets.
– Implemented system that allows user to either listen to the game’s music, or listen to their own iPod music. Game auto-detects whether user is playing their own music or not.
– Refactored audio SFX system to allow for easier playing of SFX.
– Hooked up SFX to all FE screens and widgets.
– Added “Tips” popups when user first starts the game.
– Implemented “Reset Tips” system that allows user to reset the tips state to see them all again.
– Updated and tuned the multiplier animation.
– Refactored and removed some dead code.
– Adjusting game initialization settings.
– Adjusted the Generic Popup code to make sure things looked better.
Week 24:
– Implemented first pass at “Timed” game mode.
– Implemented changes to store separate high scores for Classic and Timed modes.
– Added descriptions to Game Modes screen.
– Update High Scores screen to display separate lists for Classic and Timed modes.
– Added new “Game Mode” How to Play popups.
– Added Game Mode tips to start of game.
– Added confirmation popup to Continue button that displays info about game in progress.
– Fixed a bunch of memory leaks (mostly textures that were alloc’ed without being released).
– Implemented “3, 2, 1, Go!” animation for Timed mode.
Week 25:
– Implemented “Game Over” animation.
– Implemented audio warnings for Timed mode.
– Implemented first pass at “Two Player” game mode.
– Refactored most major classes to support a “player” parameter.
– Fixed major bug in the end-of-game detection code.
– Updated all rendering code for Two Player mode to rotate to face the current player.
– Updated all animations for Two Player mode to animate correctly for the current player.
– Update board logic so that tiles can fall in two directions.
– Implemented “Player X Wins” popup for 2P end-of-game flow.
– Optimized board rendering to get rid of some dumb, slow code.
– Fixed bugs.
– Updated FE framework so that FE screens get rotated based on the current player.
– Changed “New Game” confirmation popup to display info about game in progress.
– Animation tuning.
– Difficulty tuning.
– Added new “Board Layout” How to Play popup for 2P mode.
– Implemented “Player X Go!” animation for 2P mode.
– Hid current brush colour while input is disabled.
Post-Production
Week 26:
– Fixed a bunch of audio bugs.
– Fixed a bunch of UI bugs.
– Gameplay tuning.
– Implemented loading screens.
– Modified the sliders so that they are easier to use (bigger touch area).
– Implemented “System Layer” popup support.
– Implemented error popup if corrupt save data is detected for any reason.
– Hooked up save points to a lot more places in the game.
– Tuning score animations to render better when they’re close to edge of the screen.
– Created final icon and iTunes artwork.
– Fixed a bunch of memory leaks.
– Modified some UI widget functionality allowing for more intuitive use of Chooser widget.
– Changed the way the in-game double-tap works to make it easier to play.
Week 27:
– Updated Credits screen to support 2 pages of credits.
– Added Special Thanks credits.
– Fixed a few memory leaks.
– Major rework to SoundEngine.
– Fixed a couple of really obscure SoundEngine crashes that happened extremely rarely.
– Fixed a bunch of memory leaks in SoundEngine on engine shutdown.
– Created a “Final” build target that disables logging and asserts.
– Submitted to App Store!
Owen
360iDev: 3.5 Days of Awesomeness
Friday, March 6th, 2009
I apologise for the length of this post, but I wanted to get it all out in one post, so as not to forget anything…
I thought I’d take some time and talk in detail about 360|iDev. Overall, let me say this: the conference was fantastic. There were about 200 developers there and there were at least 3 talks running concurrently over 3 days with 5 sessions per day! That’s a lot of great content!
I think the easiest way to do this is a day-by-day breakdown, so here we go!
Day 0 – Sunday, March 1st, 2009
I arrived in San Jose on Sunday afternoon and checked into the hotel. I walked straight over to the eBay Town Hall Conference Center where the conference was being held. Sunday had some “pre-conference” hands-on presentations going on, for those who were able to attend.
Joe Pezzillo from Metafy was giving a great hands-on talk on creating 3 “Hello World” apps in 3 different ways. I arrived about half-way through the session so I just sat at the back and listened. What a great session! Dapple hardly uses any UIKit stuff, so I barely touched Interface Builder when I was working on it. Joe’s session showed me some amazingly powerful stuff you can do in Interface Builder with writing hardly any code! He also showed us some really cool stuff to do with memory management that I didn’t know about before. I was very impressed and knew the conference was going to be great right then.
After Joe’s presentation I ran into Keith Shepherd from Imangi Studios and Noel Llopis from Snappy Touch. We all talk on Twitter and it was really cool to meet these guys in person. Noel and Keith are both awesome and the three of us spent a lot of the conference together, as we had interest in a lot of the same sessions.
Sunday night has a Speaker’s Dinner where us speakers all got to meet each other. Then they opened the party up to everyone and we had drinks and played Rock Band and started meeting other people. I also got to meet Jeff Scott from 148Apps.com, who is a great guy. It was a great way to start the conference. Unfortunately, I was kind of jet lagged, so I wasn’t able to stay up very late that night and went to bed fairly early.
Day 1 – Monday, March 2nd, 2009
I got up really early Monday morning and went for a run with Noel before the conference started. It was great to run in the warm weather and not have to wear a hat or mitts. I kind of hurt my knee, though, so that was the only day I was able to run while I was there.
The first session of the day was two keynotes: one from the lead researcher at eBay (whose name I forget…sorry) and another from Mike Lee. Mike’s presentation, in particular, spoke to me as he discussed the need for the iPhone development community to work together and act as a community.
Next up with Julio Barros’s talk called “iPhone and Android?” He talked mostly about the differences in the way apps are created and distributed. It was a neat talk with a lot of questions and discussions that resulted. It’s clear that a lot of iPhone devs are considering Android as an alternate platform and wanted to know more about it.
There was a break for a delicious lunch, where I got to meet a bunch more people, like: Peter and Mike from ByteClub, Chuck Smith, Collin Donnell, Mark Johnson, and Julian Dolce from Fuel Industries (who are based in Ottawa, Ontario). And after lunch I gave my talk. I was lucky enough to be able to give a presentation on the creation of Dapple, the processes I used, and the lessons I learned. The room was nearly full for my talk and a lot of nice people said that they enjoyed the talk a lot.
Right after my talk I went to see a talk on the Unity Engine. The guy who was supposed to do the talk couldn’t be there so 4 students from a local game design school who are working at eBay gave a talk on Unity instead. They had been building a game in Unity and spoke very well about Unity and their processes.
The final talk of the day that I saw was by Scott Michaels, from a Canadian company based in Vancouver called Atimi. This was the presentation that people talked about for the rest of the show. He gave an in-depth and knowledgeable talk on marketing as it relates to iPhone apps. It was full of useful information and recommendations and I was blown away by it. It really showed me how little I understand about marketing. I started thinking about hiring a freelance marketing consultant at that point.
After that there was dinner, talking to lots of people, beer, and more Rock Band. By the end of the first day I was already convinced that the conference was worth more than the price of admission.
Day 2 – Tues, March 3rd, 2009
Up early again, but this time I met up with an old friend of mine I hadn’t seen in about 15 or 16 years. He lives in San Francisco now and I was nice enough to drive out to San Jose and meet me for breakfast. It was cool to get a chance to meet up with him after all these years. However, as a consequence I missed the first slot of speakers that day.
I arrived in time for the second slot and sat in on Tim Burks’s “Deep Geek Diving into the iPhone OS and Frameworks” session. This was a fascinating talk about how to dig into the underlying core APIs and see what’s available. There’s all kinds of cool stuff that Apple doesn’t allow developers access to, and this was just a look at what’s there that we can’t use yet. It was kind of a tease actually…look at all this cool stuff that’s available! But you can’t ship an app on the App Store if you touch this stuff… Still, a great session.
Lunch time again, more tasty treats. More chatting.
After lunch I attended Noel Llopis’s (Snappy Touch) talk on “Becoming Indie: A Professional Game Developer’s Change to the iPhone”. It was a great talk and I learned a whole bunch of information about iPhone hardware. I wish Noel’s talk could have been twice as long as there was a lot of stuff he talked about that I would have loved to have seen more on. Noel is also a huge proponent of unit testing and talked quite a bit about it in his presentation. It’s definitely something I need to do more of.
Next up with Peter Bakhyryev’s (ByteClub) presentation on “Making Multiplayer iPhone Games: Theory and Practice”. Peter had a great talk, mostly concentration on all the things you need to take into consideration when you’re designing a multiplayer game. This talk sparked dozens of ideas for new games or multiplayer extensions to Dapple in my head. I spent quite a bit of time talking with Peter and Mike at the conference and they’re both great guys. They’re doing some really cool stuff around releasing a multiplayer gaming framework.
The last talk of the day was Jonathan Saggau’s (TouchEngine) presentation on “Connecting iPhone to Google’s App Engine”. I made a bit of a mistake here and assumed this would be much higher-level than it was. The started his talk assuming that everyone knew what “The Cloud” and how Google’s App Engine worked, and so most of the presentation was kind of over my head. It wasn’t until later that I realised the talk was a 300-level talk, meaning it was an advanced topic. Oops. I’m sure it would have been cool if I’d already known how to use App Engine.
Dinner, more beer, more networking. Met some more people. Back at the hotel I ended up in the lobby with a bunch of people talking about iPhone stuff. It turns out I was talking to one of the guys who first jailbroke the iPhone, as well as the guy who wrote Cydia (saurik). They were really interesting to talk to because they have a very different perspective on things.
Day 3 – Wed, March 4th, 2009
Another early day…got up to make it to the keynote presentations. This time by Eric Litman from Medialets and a guy (whose name I forget, sorry) from AdMob. They both talked about analytics software and advertising in apps. They were neat talks. The AdMob guy talked a lot about monetizing apps by ad-enabling them, which I have no interest in, but he also talked about how I could run ads in other apps. That’s something I might look into at some point.
Next up was Sean Christmann’s presentation on “Powerful Visuals with Quartz 2D”. I didn’t know much about Quartz 2D, so this was a really neat presentation for me. I learned a lot about how it works and now I want an excuse to play around with them.
Final lunch break.
After lunch I went to Danton Chin’s “Managing and Optimizing Memory Usage”. I had hoped that this talk would be a little more in-depth, but a lot of it covered the same kind of stuff I’d written up in my Leaks Tutorial. I think it would have been a great presentation if I didn’t already know how to use Instruments to track down memory leaks. However, I did learn some things about using the Static Analysis to find mem problems at compile time.
Next I popped into a talk being given by Jeff LaMarche and another guy whose name I forget (sorry) on Open GL and the iPhone accelerometer. The accelerometer stuff was quite neat, but the OpenGL discussion kind of got side-tracked by people asking a lot of questions about how it works. OpenGL is difficult to learn in an hour. It was still a good presentation, though.
Finally, the last presentation of the show I went to was Dom Sagolla‘s “Why a Dollar?” presentation. His was about why his company only releases $0.99 apps and about the process he uses to create these apps. It was interesting to hear his point of view and to see how he does it.
With that, the conference was over! There were a bunch of us who weren’t flying out until the next day so we headed out to a Mexican restaurant for drinks and food. The conference organizers, Tom Ortega and John Wilker, were there too, so it was cool to get to hang out with them a bit. I also spent some time talking with one of the guys, Azeem Ansar, from PinchMedia, which was cool, as well as Mark Thomas, who had flown all the way from the UK for the conference.
After that, I went back to my hotel, exhausted from all the excitement and brain activity. I was up bright and early yesterday morning (4:30am) to get on a plane back to Ontario (via Chicago of course). Today has been kind of a wash. I’m having trouble concentrating as my brain tries to sort through all the amazing things I’ve learned this week and all the things I want to do in the future!
If you weren’t able to make it to 360|iDev this time, I highly recommend it. They’re talking about doing another one in 6 months, but possibly further East. When tickets go on sale, get in early!
Owen