Bullfrog Listed on MacGameFiles.com

Finally, I’ve gotten around to actually submitting Bullfrog to some of the download sites.

The first site I’ve submitted to is MacGameFiles.com.

I’ve decided to spread the submissions out a bit to both make sure my server can handle the additional load and to get a feel as to which sites bring the most traffic.

I’ll try and put together a graph to give a breakdown of traffic before and after each submission.

You can find the new listing here: http://www.macgamefiles.com/detail.php?item=19259

This entry has also been posted to the Outer Level Blog

Marketing Plan for Indie Games

Gamasutra has a new article outlining a basic plan for marketing indie games. The plan is short and simple in presentation and uses Poly Count Productions‘ new indie game, Edoiki, to walk the reader through all the steps involved.

The author, Juuso Hietalahti (Poly Count Productions, GameProducer.net) makes a great point in his first step:

1. Goals – Make Sure You Know Where You Are Heading

I would bet that this one step is both the most important and most forgotten step of most marketing and project plans. I know when I plan my game projects, I forget this step. If you don’t know where you want to go, how are you going to get there?

By solidifying the goals of your project, the rest should be much easier to plan and execute. Not only will this help your marketing plan, but also your final product.

The Indie Developer’s Guide To Selling Games

A new book has just been published that hopes to help indie game developers in the area of business that most of us struggle with. Besides the actual game design and development, marketing is the most important aspect of reaching success as an indie game developer.

No matter how good your game is, if no one knows about it, your sales will suffer.

Joseph Lieberman of VGSmart specializes in indie game marketing and has taken his expertise and compiled it into one volume. The Indie Developer’s Guide to Selling Games is available in paperback ($34.95) and PDF (27.95).

Bullfrog: Top Priority Bugs Resolved

Tonight, I completed the last of my top seven prioritized “cases” for the next release of Bullfrog.

I have twenty total issues assigned to this next release, though a large portion of them are of the nice-to-have type. Depending on time, we’ll see how many of them actually make it into the release.

As part of the development going into this release, I’m putting FogBugz through its paces. So far it’s performing very nicely. I’ve been looking for an easy to use bug tracking tool and everyone seems to rave about FogBugz, so I decided it was time to give it a shot. I’ll be sure to let you know if I decide to stick with it.

Prototypes vs. Design Documents

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.

Bullfrog Alpha v0.80 Released

I’ve been very busy with the new day job. It’s really taken a huge chunk of my time. Fortunately I’ve been able to eek out enough time to finally ready a new build of Bullfrog.

This past week of heads down game programming has produced the following changes for this new release:

  • heavy bug animation optimization
  • added “loading…” title screen during pre-rendering of animation frames
  • all rotations are now pre-rendered for improved performance
  • rebuilt the bug rendering system to support full unlimited animation frames
  • upgraded project to Xcode 2.2
  • ScoreBoard is now renderred directly on the main game view instead of its own custom NSView

Items still to complete:

  • Add more bug varieties
  • Incorporate actual animation artwork
  • Add background to game view
  • Play Balance Levels/Rounds
  • Instructions/Help Screen
  • Options preferences need to be saved between sessions
  • Custom Control bindings
  • Allow player to enter their name for high scores
  • Registration/Demo handling
  • Difficulty Levels?

Some of these features most likely will not make it into the game by the OMG Cup deadline of Midnight November 28. But I’ll do my best. The OMG Cup only requires the game to be in Beta condition to be eligible, so some of the minor things can probably be pushed off until after the contest.

Download Bullfrog

The Adventures of El Ballo

Inside Mac Games has published an interview with ProRattaFactor, the developers of a new Mac game called The Adventures of El Ballo, soon to be released by Ambrosia. I was aware of the project before, but not in any detail. It seems like a fascinating game with a unique story.

What really got me interested though is their development log. Cudos to Ambrosia and ProRattaFactor for this gem. It’s a great read filled with an enourmous amount of information. The developers really allow us to follow along in every detail of development.

Ivan Milles, the programmer, reveals the secrets behind the game engine design and its use of cell-based animation instead of the tradional tile-based approach for side-scrollers. There are tons of screen captures showing game graphics, game play, and even some interesting bugs.

Casey Gatti, designer, artist and owner of ProRattaFactor, reveals his work on the graphics and design side as well. We get a look at the level designer, his work flow, and a hint at what tools he uses to produce his art and the cell-based animation that gives this game it’s unique and fun look.

Not only a great learning experience for interested readers, but a great marketing tool. It worked on me, I plan on checking out this game when it’s released.

Change of Plans

I’ve been working on the design of my first game for some time now, slowly ticking away tasks on my project plan.

The goal of the game design was to outline a simple game that would also be realistic to complete by the end of this year.

Several revisions into the draft of my design document, I realized something. I don’t want to play this game. I’ve been concentrating so much on trying to keep it simple and within a sane realistic limit with respect to budget and time that I forgot that it needs to be fun and interesting too. I can’t just approach this as a task to complete and get out of the way, the actual game needs to be something that people will want to play.

I selected the game idea out of many because I felt I could tackle it technically and within the budget I alloted myself. I figured it was more important to complete something, anything.

I’m now taking a step back and rethinking my choices. I need to work on a game that fits the budget and is fun. Duh!

Sometimes I get so focussed on the task at hand, I forget about the big picture. Back to the drawing board.