When I called up bfg’s tech support number I was pleasantly pleased with the wait and how quickly the tech support agent on the other end of the line realized that it was an issue with the card. He proptly gave me a case number and tranfered me to the RMA department. On the RMA side, they quickly gave me the info I needed and let me go on my way.

Hopefully, the rest of the RMA process will be as issue free.

Just doing some quick research, you will find that there is a near overwhelming choice of game engines available. Just take a look at this list that I found at wikipedia .

When you research just a bit further you find that these engines vary in price from “free” to “a whole lot of money”. Besides price you will also find that the feature sets, capabilities and, the number/quality of published titles vary greatly.

For myself, as I am evaluating these engines I am looking at the following items:

1. Price: I can afford a few hundred dollars but, not much more.
2. Features: As I further build out my design, I will be able better discuss this. For now, I am looking at generalities such as shaders, lighting, indoor and outdoor environment capabilities.
3. Documentation: This is universal for the free and “cheap”engines and SDKs. Since this is my first independent attempt at a game I don’t want to spend a lot of time fighting the platform.
4. Scripting Systems: A scripting system is imho vital for prototyping features.
5. Support: Obviously, if you are counting on an engine to be the foundation to your “dream” game you’d like the assurance of an active community in the case of a free engine. Likewise, in the case of a commercial engine you’d like a reasonably responsive support.

At this point I’ve narrowed the decision down to one or two engines. However, I’ll save that for hopefully the next post in this series.

For the uninitiated, a design document is your project’s bible. It is where all of the high level decisions and features are documented. It should be the basis for all scheduling and planning. I’ll say it again another way, without a design document, any schedule or, talk of a percentage of tasks that are complete, is purely fiction. Having stated that about as strongly and politely as I know how, lets look at what I think a design document should be.

A design document contains every screen, every item, every piece of data, and every feature that will be in your product. It provides these items in detail enough for you to estimate how much time it will take to produce them. However, be cautious that it does not go to deep into detail that it hinders the actual development process.

Once your design document is finished, you can begin to plan your work at a high level and start scheduling tasks. You do this by taking all of the features in the document and breaking them down into task. You can then break these high level items down even further until you can look the time it take to accomplish the task in terms of weeks or months. Additionally, the design document is useful as it eliminates unnecessary discussions about requirements. When there is such a moment, all parties should consult the design document and move forward based on it.

At gamasutra, this article is a great example of a well written design document.

So, I hope you can see why I think that a design document is absolutely vital to the success of a software project. A well thought out and written design document eliminates developer time wasted on feature creep, it servers as a starting point for all scheduling activities and, it provides the big picture of your project.

For those reading that are interested in such things, drop me a note about what you think.

Funny enough, I didn’t think I’d score so high.

I’ve played numerous top down games like FF and Baldur’s Gate and found that they are very fun as they seem to introduce very enjoyable combat systems.

On the other hand I’ve also had a blast with the First Person games like Deus Ex and some of the online RPGs. These seem to be a bit more immersive and popular these days.

Based on my playing experiance and the fact that I want to build something that I would like to play I deciding to go with the 1st/3rd person style rpg.

My next big decision will be about the engine behind the game. There are a lot of choices so that may take a while.

The theme will follow the standard “Heros Journey” type of theme in a SCI-FI setting.

Some of the items that I am going to journal and comment on will be

• settings

• tools

• game engines

• technology (shaders, OpenGL, DirectX, lighting)

• design choices

I’ve been scribbling down ideas for this project for over a year now. Sadly however, I haven’t come up with a name yet

From what I’ve gathered by asking and attempting to practice myself is that it isn’t something magical or some kind of secret obtained through years of work. It is, on the surface, pretty simple. You just work through it and find ways to enjoy your work.

For example, I have a project that I am working on that I don’t find very interesting. And, it is difficult sometimes to keep myself focused and on task. But, if I don’t I’ll lose the contract and ruin my reputation. So, I just work through the mundane parts and take as much joy as I can in writing solid code.

How do you get yourself working may be different from person to person. For me, it is often just opening up the IDE or editor and reading my “TODOs”.

For the few readers I do have, I’d be curious how you get through your slumps, assuming you experience them.