Question

I’ve designed a C# game that makes use of an Access .mdb database file to store variables.

The basic idea is that one of the players will ‘host’ a game, and the other player will join said game, by connecting to the database, reading and writing items into the database. The database is needed to pass variables to and fro the host and client, and both programs check the database regularly for new messages / variables (yes, yes, I couldn’t get TCP/IP Remoting to work).

Now, there, the program works fine (mostly the client, since the host modifies only its local database), for as long as the client can find the database file. Currently, the connection string for the client is located in a .ini file, and for the program to work, it (or at least, the server) must be located in the Shared Documents of an XP machine, or the Public Documents of a Vista / 7 machine.

But then some questions occurred to me:

1. What if the client user places / installs it into another folder in the Shared / Public Documents? I suppose there’s a code out there that could ‘drill’ into the Shared Documents folders to find the path for the database, share names included… is there?

2. What about installation? The installer default is always “C:\Program Files\GameName”. Could it be set (or locked) to a specific folder into the Shared / Public Documents, by default? And is it even recommended to install it into a Shared Folder, what with problems such as Accidental Deletion?

3. Say, the default is “C:\Program Files\GameName”. I could see that a set installation path will solve any connection issues, since every client will look in the same path of the other computer, and it won’t matter if it’s XP or Vista. Could “C:\Program Files\GameName” be accessible by a C# program over LAN, without any system modification? Are there any security (UAC?) issues?

P.S. Details that people may find in handy:
I’m using Visual Studio 2005. So is my School.
I’m running .NET framework 2.0. So is my school, and unfortunately, I can’t change that.

Answer 1

I hate to tell you this, but this is why the approach is fundamentally flawed. What are you going to do when:

• File and print sharing on the server is disabled?
• The network client is disabled on a client computer?
• The server is configured to only allow authenticated users, and the client doesn’t have access?
• File and print sharing is blocked because of the firewall?
• File and print sharing is completely borked for other who-knows-why reasons?
• You need administrator access on the server to share a folder, but the current user is not an administrator?
• The Access database engine isn’t installed correctly on the server or client?
• One of the clients corrupts the database? (This is easier than you might think; all it takes is a network glitch where a client temporarily or permanently disconnects from the server).

These are fundamental issues that you can’t resolve with the current solution.

Get it working over normal TCP/UDP ports. You’ll have a much easier time. There are libraries to facilitate that, see C# Game Network Library – for example it sounds like Microsoft’s XNA SDK has functions for networking in a game. If you use a standard method / standard library to implement networking, your odds of success are much higher. Using a client/server architecture means that the server’s state won’t be corrupted if a client goofs up.

I realize that this probably involves a significant rewrite. Frankly, I don’t think you have a choice if you want this game to be commercially successful on a wide customer base without high support costs, and move beyond being a mere experiment.