In Part 1 of this discussion / entry, I went over a bare-bones analysis of the pitfalls created by investing in technology which is well meaning in theory..but can fall short during the execution phase.

So what was the end result you came to? What was the impact of end-user
usage and what language did it cause you to pick (if any)?

Great question. My answer just comes down to “Barriers”. The more barriers presented to the player / potential customer, the higher the chance of a missed sale / opportunity. Obviously the exception of course is to games and/or products which people will still buy no matter what ridiculous layers the company places between you and the software.

We can pick out just about any barrier, but I’ll try and focus on a few that relate to higher level languages.

#1 - Piece meal Install process: More annoying than forcing the player to go through several unneccessary clicks during a crappily made installer, the piece meal process is far worse. You download the game demo you wish to play. Uh oh..during the install, it seems as if you’re missing a certain library or runtime dependency (inevitably due to legal restrictions of this 3rd party dependency). No problem, here’s another link to an installer to run to fix that up. *sigh*.

#2 - Garbage Collection is fantastic…until it activates. Most higher level languages usually toot the horn of the ability for Garbage Collection which just means the runtime (beit something like Java and/or .NET) will keep and maintain a list of references to the objects in your code. Once all the references to a specific object fall out of scope, this object is marked for Garbage Collection. It’s a very important and terrific aspect of a higher level language to ensure stability, but to the novice developer, it can cripple the performance of your game while the runtime arbitrarily decides it needs to do some spring cleaning.

So everyone usually points to the “bonus” of Garbage Collection, without letting anyone know that they then proceed to do everything possible to disable / delay it.

#3 - Virtual Machines are getting better with new machines. Even with the newer VM’s for .NET and Java, there’s still a feeling that the more RAM / CPU, the better. On the majority of platforms out there, the VM’s have come a long way to be a viable competitor to native code. The only caveat I would add, is that it doesn’t seem to scale terribly well down the chain. I would love to see some more performance stats for those who are still running Windows98 on 512 - 1Gig of RAM.

Just to sum up this point, I think VM’s have come a long way and have made great strides in terms of providing an optimal performance environment…just make sure your target audience has the rig.

As for what technology I ended up choosing for my project, I’m sure there’ll be a part 3 of this article…

My apologies for the longer blog title, but it was necessary to try and communicate the overall goal / endpoint of this series I’ll be putting together for you.

What this is: This tutorial / blog series of articles is meant for the beginner .NET developer to introduce the reader to a few game concepts along with putting together a real small Role-Playing Game using C# and communicating to a database backend just for fun.

What this isn’t: While this is meant for an introductory audience, it’s not meant for the beginner programmer. You should already have some kind of background in programming concepts (regardless of the language). You don’t need to be an “expert” but understanding what a loop is, or how to comfortably put together a few statements and functions is about all that’s needed.

The “good” thing about producing this series in C# is that the higher level language created by Microsoft is readable enough to browse through and understand even if you don’t necessarily want to learn C# itself.

General Overview
What we want to produce is a small, but functional RolePlaying Game using the .NET framework and the C# language. By working through the development of this game, you will learn a few things about game development and (of course) the .NET framework / C# language. As an interesting “twist”, the series will also go through the process of using Linq to query a SQL Server database for game data. At its very heart, an RPG largely consists of matching up user actions / results with corresponding data in tables and so is a good “fit” for integrating your game with a database solution.

Game Overview
The Kingdom of Aspire is under siege by the forces of darkness. King Wazoo has put the call out for a brave adventurer to defeat the nasty creatures and retrieve the Orb of Celestial Harmony which was stolen from the castle. Brave knight, your adventure awaits!

The game will be a 2D RPG with a few tiles for distinguishing landscape and city roads from monsters, treasure and other NPC’s. The game will be mostly keyboard based due to the number of actions typically involved in an RPG. The overall gameplay will be turn-based.

Technical Design Overview
We can leverage some of the flexibility of the .NET framework to produce an RPG game solution that we’re comfortable with. The .NET language / approach allows you to typically create software in a few ways.

• Fat Client: This is the common approach to desktop applications. Your application runs on the desktop of the machine “in isolation” of the intranet / internet on the .NET runtime.
• Thin Client: This is the common approach of a web application. Your application codebase is hosted on a webserver fronted by IIS and the .NET runtime. There are virtually no components that need to be locally installed, but you have a total reliance on the intranet / internet in order to run
• Smart Client: This is a mash of the two design approaches. You typically have a desktop application running on the .NET runtime which has the capability of hooking itself across the internet / intranet to other .NET pieces. This approach gives you the benefits of each method; a locally running application solution which can also communicate across the intranet / internet.

For the purposes of this series, we will be crafting a smart client solution using C#. The IDE used for this series will be Visual Studio 2005, but I will attempt to test out the same solution files in the newer Visual Studio 2008.

That’s pretty much about it. While waiting for the next entry, you can verify that you have the following software:

• Visual Studio 2005 C# Express from Microsoft
• SQL Server 2005 Express from Microsoft

Stay tuned!