• Advertisement
Sign in to follow this  

Build Directory Structure and Game Data in VS2003

This topic is 4304 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I am using Visual Studio 2003 to build my game. It seems that both a debug and a release directory are created for building my project, and I can switch between both in the development environment. My question is though about my game data. At the moment I have my game data in the c:\gamedata directory. I would like the path references in the code to be relative to the game executable, for example if I was loading a model it would be 'gamedata\mymodel.mod', but I don't want to have to keep updating two gamedata directories, one for debug and one for release. I tried changing the project properties and setting the linker output file to c:\game.exe, but when I try and run it, it says it always needs building (even if it's just been built), and then gives an 'unable to start debugging' error saying... 'unable to start program c:\program files\microsoft visual studio .net 2003\common\id3\game.exe' Why would it be looking here for the game when I set the output to 'c:/'? What is the best way to keep one set of game data yet easily be able to build debug and release executables? Thanks!

Share this post


Link to post
Share on other sites
Advertisement
I always suggest putting the paths in an ini file or a reg entry. .Net is trying to get away from reg enteries for paths so go with an ini file. This will allow you to quickly change where things are pointing.

theTroll

Share this post


Link to post
Share on other sites
Quote:
Original post by TheTroll
I always suggest putting the paths in an ini file or a reg entry. .Net is trying to get away from reg enteries for paths so go with an ini file. This will allow you to quickly change where things are pointing.

theTroll

Would you consider also using XML for this, or does .INI have any advantages?
Thanks for the reply!

Share this post


Link to post
Share on other sites
Raeldor,

It does not - .ini files are just formatted text files usually, which means you would be responsible for loading/parsing, etc...based on a format you designate.

If you're keen to use XML, definately go with it. There are many good XML parsers available (including those provided by .NET), which would save you time. As well, XML is a standard language, easy to write, and among other things, still a text file, so you can always modify it by hand or procedurally.

Cheers and good luck!

Share this post


Link to post
Share on other sites
Just change "Working Directory" property in Project properties/debugging/ to you game data path :)

Share this post


Link to post
Share on other sites
Quote:
Original post by alexlunix
Just change "Working Directory" property in Project properties/debugging/ to you game data path :)


This works fine if you're working on a project by yourself, but in general, if you're working on a project with someone else its a good idea to use a config file to set path properties, etc...

In general there are a few problems with the "Working Directory" solution.
1. Not everyone working on a project will have visual studio or will be launching from visual studio...this leads to problem number 2.

2. The working directory in Visual Studio doesn't have to be the directory the executable is physically located in...which means you can get different behavior when launching from visual studio vs. cliking on the executable. This can sometimes cause confusion.

3. Working directory used to be project specific, so everyone had to have the same file structure and paths. I believe this is changed now, and is instead a "machine specific" setting. But its something to keep in mind. Using a config file allows for the same flexibility, without needing to worry about loading visual studio to change the path, or worrying about different people on the project preferring different paths.

Cheers!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement