iDevGames

By now it should be no big surprise that I decided to make a computer game in the image of this beloved classic. I began in February of 2002 and ended in late May of 2003. Solace is the first game I’ve written that I did not publish myself (using online payment services such as Kagi). Indeed, this was my first experience interacting with a publisher. The road from independent game hobbyist to published independent hobbyist is not one well-paved or readily apparent, so I’d like to take a moment to reflect on my experiences traveling it.
h3. Finding That Special Someone
(Main Menu Screen) I should start off by stating that I am writing from the perspective of an independent game developer whose sole experience is with one publisher, namely Freeverse Software. In reality I don’t know how all publishers think—only how I think they do. Around the time I finished the design document for Solace, a coworker of mine was contacted about a Cocoa development project by Jason Whong (formerly of Ambrosia Software and Green Dragon, now an employee at Freeverse). Apparently, they had met in the past on a Bulletin Board service run by my coworker. Since my coworker was uninterested in Cocoa development at the time, he suggested to Jason that I meet with him instead. Although I had never met Jason before, I did know of his exploits in the Mac game development community (particularly the whole bug eating episode), so I let him know about myself and the new title I was beginning work on. After a short Thai lunch and a hand off of the Solace design document to Jason, the rest was history.

The point of the story here is that if you have an “in” (i.e. you know someone already in the correct position to give you a hand along), then the road is much easier. However, simply knowing someone doesn’t guarantee getting published. Having a good public track record is crucial! Being able to approach a publisher with “This is what I’ve done already, this is what I’m doing next,” is important. The longer and more successful your virtual sum is, the greater the chance a small to medium size publisher will take you on. This is one reason why the uDevGames Contest is such an excellent venue for independent game developers. You get to create a game, on which the iDevGames community will readily provide feedback, allowing you to make that game even better. Then if you’re lucky you may win, allowing you to say something like “Winner of the Best Polish Category.” But even if you don’t, it is one more public example of your work that a publisher can use to get to know you. If you enter the next four uDevGames Contests, that’s four publicly released titles backing up your claim that your next title should be published.

When dealing with small publishing houses, you need to keep in mind that while their resources may be vast, they are also limited. By necessity, they must be very picky about who they decide to publish and who they need to turn away. Naturally then, you want to make your proposal to them seem as simple on their part as possible. When you think you’re ready to approach someone like Freeverse or Ambrosia, keep in mind these three magic words: “Return On Investment” (ROI). Then, instead of thinking about the return you will get on your investment, think about what the publisher’s will be. Simply stated, you have a much better chance at getting published if you can show them a product which is 95 percent done, noting that you have another three percent to complete and they’ll be responsible for only two percent. This way you take the majority of the investment upon yourself (which in my case was simply 17 months of my time), and they look at it from the approach of “Well, even if we don’t sell bushels of them, we’ll still make money.” Granted, if your game’s quality is below what they’d consider you probably won’t get published, but then again they’ll be more likely to give you advice so that when your game is up to snuff, they’ll be ready for you.

It will also pay off if you do some research into the various publishing houses before you approach them. In the end, what you will want is a publisher who fits well with you, as well as your game fitting well with the publisher. Although I was lucky enough to meet Jason in person, there are several other reasons why I felt comfortable publishing Solace with Freeverse. Firstly, I looked at their reputation in the Mac game community, which is one of making fun and whimsical games: a company who can make a simple game of Solitaire great by throwing in a series of jokes and a barrel of monkeys (literally). I admire this about them, that is, their willingness to stray from the norm and go off on a path all their own. In contrast, my games tend to be very utilitarian (some might say bland) in nature. I can create visually appealing titles with in-depth gameplay, but I’ve yet to make one in which the player busts out laughing! In the end I felt that some of the Freeverse “spirit” was what I really needed.

I also examined the genre of games Freeverse produces and the nature of the audience they cater to. Freeverse is known for their selection of card and board games, with the occasional RPG and shooter thrown in, and their core audience enjoy the roll of the dice and the turn of the card. Solace strove to be a board game in your computer, so it would fit nicely into their current selection of games.
h3. What Went Right
h4. (Game Map Screen) Building upon past experience
Solace is sixth game that I’ve created and released publicly, and is the third game to reuse the same core engine code. This means that I was able to get Solace up and running in a relatively short amount of time. It also meant that I had a strong base which was relatively bug free to build upon, allowing me to spend most of my time actually creating Solace and not working on how to develop a fullscreen OpenGL display. Taking the time to create a solid foundation that is modular enough to carry between projects is incredibly important, and will pay off well in the end!
h4. Entering the uDevGames 2002 Contest
I entered the uDevGames 2002 Contest with a relatively simple arcade game called The Belt. This helped in several ways. Since The Belt utilized the same engine code Solace does it meant that the code would get another round of public testing before Solace was released. Also, I was already exchanging emails with Jason (and in turn Ian Lynch Smith) about Solace when I decided to enter the contest. What this meant is that I not only got another notch on my belt with The Belt, but it also impressed them that I could halt one project and create another well-polished game in under three months! Of course, winning the uDevGames Contest was also handy, since I put the prizes I won (namely BBEdit and Carrara Studio 2) to use in creating Solace.
h4. Expanding my graphical talents
I spent a large amount of time over the past two years focusing exclusively on making better graphics. Going back and looking at the artwork in Vortex Next Generation and comparing it to the artwork in Solace is sufficient testament to the amount of effort I put into bettering myself in this particular area. I spent my time getting acquainted with the various 3D renderers, as well as expanding my knowledge of Photoshop. I’m continuing this today by studying and learning the (lost?) art of “pixel art,” with the hope that my next game will have a more “retro” feel to it.
h4. A great publisher
I cannot express fully the availability and openness Freeverse Software showed me. From the beginning they were both courteous and prompt. I’ve attempted to contact several publishers in the past, and my best experience was waiting approximately two weeks for a response to my email. Granted I’m sure said publishers were busy, but would you want to tie yourself to a publisher with whom you’ve had a bad first impression? I think not.

In contrast, I not only received replies from Freeverse promptly, but even before an official contract was signed they gave a large portion of their time to me. From providing feedback to the latest build, to suggesting areas in which they could improve upon the quality of the game (i.e. the wonderful voice-overs Colin provided), to allowing me to spend nearly four months from the time they first sent me a contract until I finally decided to sign it. They were open and understanding about the difficulties a hobbyist game developer with a full-time job has. In the end, my experience with them was nothing like the horror stories you read about on the web and in Game Developer Magazine; it was more like working with a close friend.
h4. An understanding wife
Finally, no married game developer can write a postmortem without thanking his or her spouse. This particular game was incredibly stressful due to the fact that it was being published. This is the first time I’ve really experienced the two-month crunch time before release—you can image what it must have been like for her! We are both working full time jobs and I was spending more than four hours a day at home programming. I could just say she’s been incredibly patient, but in reality her patience has reached goddess-like levels. Without her, I would never be able to have half of what I have today.
h3. What Went Wrong
h4. (Battleboard Screen) Lack of personal playtesting
Solace is made in the image of Axis & Allies, which is a large and complex game. In turn, playing a complete game of Solace also takes a couple of hours. Having this kind of overhead means that I spent almost no time actually playing my game, since one can spend their time either playing what they create or actually making their creation! Hence, there were several update and beta versions I released that had bugs which could have been caught had more effort been put into play testing a complete game. In the end, however, your hands are tied. There are only so many hours in a day, and I’d rather spend them adding new features and fixing bugs. Thankfully I had a great complement of beta testers as well as the guys at Freeverse to play test for me.
h4. Entering the uDevGames 2002 Contest
Yes, even though there were many benefits to entering the uDevGames Contest, one cannot discount the fact that it added nearly four months to the development time of Solace. Even so, it was worth it in the end.
h4. Massive hardware failure
It happens to everyone eventually, mine just happened to occur in February of 2003. My Lombard PowerBook G3 now reports an error where there is something wrong with the processor cache, and running it for any length of time is an uncertain procedure. I had planned to wait until the G5 processor was released before purchasing a new PowerMac, but the sad reality is I had to purchase early. Here’s hoping that Solace does extremely well so that I can purchase one in the future (that is, after my wife and I purchase a house).
h3. Conclusion
The creation of Solace is one of the major milestones in my life. I always told myself that one day I’d write a game that was published, printed, and put on store shelves. Having a great development experience and a wonderful publishing company were added benefits that made that milestone something I’m eager to attempt again.

I’d also like to say that Solace is the first project in which I’ve had the pleasure of working with both a musician and an artist, and in the end the experience was again a joy and not the hassle many game developers make it out to be. My gratitude goes out to Steve and Andrew for jobs well done!

So, what’s next? I’ve got a few ideas for uDevGames 2003, and now that Solace is complete and the beginning of the contest right around the corner, who knows? Perhaps I’ll be adding another notch to my virtual belt here soon!

Solace Credits

* Developer: Feline Games
* Genre: Turn-based Strategy/War
* Site: homepage.mac.com/felinegames
* Team size: 1
* Released date: June 20, 2003
* Project length: 17 months
Development hardware: PowerMac G4 (“Wind Tunnel”) 
* Critical applications: Carrara Studio 2.0, CodeWarrior, Adobe Photoshop

Download

* Demo

solace,feline,games

Further Resources