Jeff Vogel, Spiderweb Softare (Avernum, Geneforge), shares more wisdom from his 10+ years of indie game development in View From the Bottom: Part 3. This time he discusses his experience with trying to innovate.
GBGames has a nice introduction to object oriented design for game development.
GB does a nice job of summarizing some basic concepts that can be incredibly powerful for simplifying your object model as well as future-proofing your design.
I’ve used these techniques extensively for application development in my day job as a C# developer. As GB mentions, it’s very easy and tempting to fall into the deep class design mode, but if you can resist and take the time to turn your classes sideways, your classes will grow in power and flexibility right before your eyes.
Thanks to GB’s reminder, I’ll now remember to use these techniques in my games.
For the past year or so I’ve been organically growing my RSS feed collection with a focus towards what other indie game developers have to say. My collection has grown to a pretty good size including game industry veterans and stalwarts to first-time designers and rookies.
There is a lot to read, and many to learn from. Here is a list my favorite writers from my current feed collection and why I regularly follow them (not in any particular order).
- A Shareware Life – Thomas Warfield, developer of “Pretty Good Solitaire” and “Pretty Good MahJongg” is one of those successful super hero indie developers. He’s been at it for a long time and has some very valuable insights on how others can succeed at the independent games business. If you like cats, you’ll enjoy his “Friday CatBlogging”.
- Phil Steinmeyer – Phil recently broke away from his old company, PopTop Software, after having success with games such as Railroad Tycoon and Tropico. He left for the freedom and the green fields of the indie game world. In May, 2005 he started his new company Crayon Games and recently released his first product, the casual game “Bonnie’s Bookstore”. I like Phil’s writing because he brings the experience of working for a successful game studio to the world of indie game development.
- GBGames – Gianfranco Berardi has a comfortable writing style and is not afraid to talk about his failures along with his successes. He’s new to business and the game industry, but he brings a ton of enthusiasm and a surprisingly mature point of view. He has frequent updates with very little of it off topic. GB provides great inspiration for me since he’s struggling through many of the same issues that I am as he tries to make his way into the game industry.
- GameProducer.NET – A recent addition to my feed collection, but has quickly become one of my favorites. Juuso Hietalahti of Polycount Productions shares some great insights into the job of a game producer. But the most interesting stuff comes from his Sales Stats articles from around the indie game industry where he reveals the sales numbers behind recently released games. GameProducer.NET is updated regularly and usually worth the time spent visiting.
- Joe Indie – David Michael, author of The Indie Game Developers Survival Guide and developer of Paintball NET, writes about the business side of indie game development. He has a pragmatic view of the indie game industry and shares some great advice.
- Casual Game Design – William Willing covers, you guessed it, casual game design. There’s some good stuff on William’s site covering all kinds of topics related to getting the best out of your game designs.
- Tales of the Rampant Coyote – Jay Barnson is another game industry veteran turned indie. His site has a good mix of industry commentary and shared wisdom from his experiences.
There are a bunch more that I subscribe to, but these are the ones that consistently have the best signal to noise ratio and that seem to provide information that directly speaks to me.
If you know of any other indie game developers out there that are sharing their experiences and wisdom, I’d love to hear about them.
What is the moral of this? The game industry is a highly competitive, scary place. It’s not hopeless, but it’s a tough road. And that’s a good place to start to describe the view from the bottom.
Also check out part two of Jeff’s series View From the Bottom #2:
Indie developers have a real purpose in this world. They make little niche products for markets too small for Activision. They make many new puzzle games for the casual audience. Or, at least, the same old puzzle game again and again. They rewrite Asteroids… because someone has to.
Looks like a series that is well worth following. Vogel has a long successful history in the indie game industry and probably knows what he’s talking about.
Psychochild responds to Vogel’s article with The Indie Problem…again:
So, let’s talk about the real problems with indie game development and why you don’t see innovation from them.
Let’s be honest here, there are some serious issues you have to deal with as an independent game developer. It would be wonderful if that old myth about “if you build it, they will come” were true. Unfortunately, that’s not the case.
I’ve been steadily plugging away at my list of bugs and enhancements for the upcoming release and finally tackled one area that I had been avoiding: improving the AI of some of the bugs.
Most of the bugs had a pretty random set of behaviors depending on how close to the edge of the screen they were moving. But other than keeping them from getting stuck in a corner or wandering off screen, their decision trees were pretty simple.
- “How long since the last time I turned?”
- “Which direction do I turn this time?”
The only bug that had any intelligence to speak of was the feared mosquito. Since the whole purpose of the mosquito’s life is to harass the player and steal valuable time off the ticking clock, it needed to chase the frog and buzz him. So the mosquito’s decision tree looked something like the following:
Unfortunately, I didn’t have time during the contest to really give any of the other bugs any convincing artificial intelligence. I made a crude attempt at making the Horsefly flee the Bullfrog if it ever came too close, but I was unable to get it to work without the fly trapping itself in the extreme corners of the screen.
With this upcoming release, more of the bugs finally have some “intelligence” to them. I revisited the Horsefly code and was able to rewrite the AI code to give the fly some simple evasion behavior, but it’s now smart enough not to get trapped. Well, okay not quite smart, but it falls back on its random behavior if it gets too close to the edge of the screen. This completely eliminates the trapped fly problem.
With this small success, I also attacked the bee’s AI. In this case, I didn’t want to add any intelligence, but to cause the bee to go into a frenzy when approached by the frog. My approach was to simply increase the bee’s movement speed when the frog came near. This gives the illusion that the bee is agitated by the frog’s presence.
Granted, these changes aren’t rocket science but they do break up the repetitious pattern of random movement at constant speeds.
With these changes “in the can”, I’m down to four items left on my list. Hopefully, I’ll have the time to get these coded and tested in the next week.
The only real hurdle left is finding a way to test the Universal Binary so that I can include that as part of the release.
Aside from needing an idea, there were a few hurdles to tackle. Not only was this my first game project in almost fifteen years, it was also to be my first Mac project, written in Objective-C and Cocoa. I was also aware that most games for the platform are written in OpenGL because of the sub-optimal performance of CoreGraphics and Quartz Extreme. Though I have been a professional software developer for twelve years, I felt that learning OpenGL in addition to Cocoa was too much to tackle in such a short time frame. So I had to make do with what Apple’s API would provide.
Budget was the next hurdle to tackle. Money was limited, I had to operate on a very small budget. I would either need to create all my own artwork and sound or acquire what I needed for free or very cheap. To help limit the amount of artwork I would need, the game would have to take place entirely in one location.
Once I decided upon the basic game idea, I put together a very rough prototype to get a feel of how the game would play and whether it was something I could finish inside the six week deadline. Armed with my prototype and a rough project plan, I dove in.
Here is what went right and what went wrong:
Apple’s Cocoa framework is amazing. It does have a steep learning curve, but once I got a feel for how things fit together work became a pleasure. CoreGraphics may be slow, but it has some great functionality built in. There were many times where I feared having to write a very complicated set of routines to get something done, but a quick search through documentation lead me to a class or method that did exactly what I needed. While I did have performance issues to work around, especially on older machines, I wouldn’t hesitate to use CoreGraphics for simple games that don’t have intense animation requirements.
I’ve written extensively about my experience working with my graphic designer. While I was very happy with the quality of work and the timeliness of delivery, the best part of working with someone else is the additional input an objective observer can provide. My designer provided many ideas and suggestions that had very real and positive impacts on the game’s design.
Bullfrog was originally going to have a simple black background. Jordan would have nothing of it. Before I knew it he’d sent me a very nice background image with some ideas on how to use it. Ultimately, the background changed a bit and ended up being a simple window dressing for the game; but, I ended up with some very cool ideas for the next version.
There were two significant disappointments on the sound front for Bullfrog. First and most significant was my decision to go cheap (read free) for all my sounds. When selecting the sounds, each one sounded adequate. When put together and repeated many times during game play they became annoying rather quickly. Even if they don’t annoy, the overall sound mix does not meet my standards. Next time, I pay for quality tracks. In hindsight, I would have been better off with no sound than bad sound.
The second issue was technical. While Cocoa’s sound support is adequate for playing simple audio, performance and functionality is the pits for game development. I would consistently see significant frame-rate drops when more than a couple of sounds were played concurrently and the API provides very limited access for controlling how the audio tracks are played. There is no support for fading or panning. Next time I’ll definitely look into alternatives for my audio needs.
Unfortunately, somewhere along the line I boxed myself into only being able to support the latest version of Mac OS X (Tiger). The game would execute just fine on 10.3.9 (Panther), but something with my handling of images caused graphics to disappear when animated. Since I don’t have a long history with Mac development, I have no frame of reference for what could have changed from 10.3.9 to 10.4 in the graphics handling. I suspect it was the png support changes I read about somewhere, but I didn’t have the time or the experience to hunt down the problem within the contest timeframe. Thankfully, the OMG Cup only required Tiger (10.4) so I settled for having to fix the problem after the contest. Since the game was targeting simple game play for casual and young players, I need to target older OS X versions since this audience is more likely to fall behind in operating system versions.
General Observations and Lessons Learned
Play testing is critical. I don’t mean testing for bugs, that goes with out saying. I mean testing game play. Is the game fun? Is it easy to learn? Do the controls work as designed? Is your game “user friendly”?
It was fascinating to watch someone play my game for the first time. Especially people who are not hard-core game players. One of the first things that jumped out was my choice of control keys. I had gone with the first-person-shooter standard of ADWS for left, right, forward, back. Bad choice. Simply choosing the more obvious arrow keys made a world of difference. Get as many people to play test your game as you can. Do this early. Do this often.
Everyone found the game more difficult to play than I do. What I thought would be challenging, others found frustrating. What I designed to be easy, was often just right. This probably varies between games, genres, and target audience to some extent, but I would bet that there is some of this for all games.
Polish is Important
Games that are not polished aren’t done. Developer graphics and sound won’t cut it. No matter how “fun” the game is, if the presentation isn’t professional and polished then the game will disappoint. Cutting corners will only serve to pull the overall feel or value down. See my experience on using free sounds above for reference.
Deadlines are Good
One of the things that excited me about working on my own development projects was the lack of artificial deadlines. I was looking forward to the ideal of only releasing my software when it was done. The reality was indecision and procrastination. Before the OMG Cup announcement, I spent months flailing about without choosing a game idea or creating a final design. I started and abandoned several prototypes and never committed to moving forward.
The OMG deadline motivated me and got me moving. It also kept me working through to completion. It forced me to decide on a game design even if it wasn’t my “ideal” or favorite idea. A finished game is better than a great idea that isn’t even started.
Bullfrog was an incredible experience. I gained confidence in both game development and Mac programming and I learned a lot about myself in the process. Six weeks seemed like a very short time to write a complete game, but I surprised myself with what I was able to accomplish starting from scratch.
The OMG Cup was a ton of fun to participate in and the people at iDevGames.com were an inspiration and invaluable support network. I look forward to trying again next year.
What’s involved in building a casual game these days?
There is a lot more to making a casual game than most people realize. I learned this first hand recently, as I participated in the 2005 OMG Cup these past two months. I always believed casual games were simple and quick to develop. Compared to the modern enourmous budget A-list first person shooter games, I guess they are — but for a one person development shop it’s still a lot of hard work.
I love when developers allow the outside world to see how their games were built. Sharing knowledge is what the internet is about. In this case, Phil not only shows us the artwork that made it into the game, but also the artwork that was rejected.
Phil also discloses his method for deciding on what theme his word game should use. It’s very interesting to see the numbers behind his survey and what themes people liked or not. I had not thought of surveying blog readers for their opinion on game design directions.
But, why not? Readers would probably be a ready and usually willing participant in the process. After all, readers are already participating by visiting your site. By allowing readers to join the design process, they get a small stake in the success of the game and may be more apt to purchase and spread the word.
GBGames has an interesting discussion going on about the importance of prototypes and design documents in game design, specifically casual games in direct reference to the Gamasutra article with James Gwetzman of Popcap Games.
It seems that Popcap has an “extremely prototype heavy” development process.
Some of GB’s reader comments focus on this importance of prototypes in game development and feel that all they need is a prototype in order to develop their games. While this approach may work for some, I would follow this approach with caution.
I agree that prototypes are of great value, but I am also a believer of design documents.
Not necessarily designs that specifiy how every little thing is going to be built, software development is much too fluid and organic for that.
I realize that Popcap is a casual game pupblisher; but in the case of a complex RPG, it simply can’t be built without a design document. Well, at least not a good RPG. There are too many story possiblities, event points, and interactions to just make up as you go along.
Outlining the overall story arch and connecting the important events, characters, and items that populate the game is pretty much a requirement or else you run a very high risk of forgetting something, building a non-sensical story, or even a game that can’t be won.
I think where people get caught up is thinking that a design document has to be a detailed technical design. When you are a single developer on a small project, chances are you don’t need to write everything down, because you aren’t communicating it to anyone else.
I can see the advantage of detailed technical designs in a MMOG where you really need to have detailed descriptions of the network layer and protocols, how game state will be persisted, and how game assets will be managed, maintained, and updated.
Additionally, the second you have a development team of more than one person you need some sort of design document. How else do you make sure everyone is on the same page and is developing code that will work with the rest of the system?
Writing a design document doesn’t mean that you can’t be agile or proceed in an iterative manner. It is just a tool to help ensure that you don’t forget things, a tool to help facilitate communication, and a tool to jog your memory when you return to the development of a project that you haven’t touched in months.
Yes prototypes are valuable and in some cases all you may need. But, design documents are equally important. They are both simply tools in a software developer’s tool set. It would be silly to dismiss one of the most useful tools available to you.