• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
rbanke

Include paths best practices for mutli-person development

6 posts in this topic

Forgive me if this is not the right forum for this question, I couldn't decide which forum was most applicable.

 

I have recently moved to VS2012 and up until now have used windows environmental variables in my include paths (%DEV% = D:\Dev) this way my partner or others would not necessarily have to keep everything in the same location as long as they had their variables set. Now I'm noticing that IntelliSense is having problems finding those directories. A few searches show that it's been reported but not fixed.

 

What I really would like to know, is if there is a better way to do this than I've done until now? If our projects need DX, SDL, or other libraries, how do you guys include them in a way that is more friendly for multiple people working on the same project?

0

Share this post


Link to post
Share on other sites


I have recently moved to VS2012 and up until now have used windows environmental variables in my include paths (%DEV% = D:\Dev)

 

Don't do that!!

 

The correct answer is to set up your own system's environment variables so that when you do, say, #include <sdl.h> or whatever (sorry if it's not a real header - I don't know SDL, it's just an example) the compiler then looks in your $PATH environment variable and tada! Header found. Same goes for the libraries (.lib, .dll, ..). Then you and your friends set them differently depending on where your stuff is on your computers, yet <sdl.h> will always be found correctly.

 

A less intrusive way to do this is to give the locations of the libraries to the compiler via an include path/lib path argument instead, but this is annoying if the project file is included in source control...

0

Share this post


Link to post
Share on other sites

Ok, I'll give that a shot. Is there a reasoning why using Path (user variable) rather than a system variable is the better way to go?

 

Thanks

0

Share this post


Link to post
Share on other sites

Ok, I'll give that a shot. Is there a reasoning why using Path (user variable) rather than a system variable is the better way to go?

 

Thanks

 

Well, system variables have a wider scope that user variables, so if a user variable suffices that is what you should use (what if you have multiple users, each of whom use the same compiler? maybe they don't want to have the compiler look for a bunch of libraries you use because it could cause clashes or whatever, again this is probably not the case but *what if*). That isn't really the reason, though, it's just the compiler expects to find external resources in:

1. built-in directories (you can't change this), this is for system headers e.g. iostream, stdlib.h, ...

2. directories specified in the $PATH (this is implementation dependent) and - for most compilers - in a special compiler variable called $INCLUDE

3. directories specified on the command-line (if using an IDE, this is set via your project options under "header/include directories" or something)

4. the current directory (if using quoted includes)

 

As I said, it's "better" to pass that info to the compiler by modifying your project settings (lowest scope) but isn't ideal when the project file is shared by everyone since you'll end up clobbering each other's settings and you'll have the same problem. A good version control tool can handle that but in your case it may simply be more effective to use environmental variables and forget about it. This is also the case when installing SDK's since they typically insert themselves in the $PATH so you don't need to do anything special.

 

Using system-dependent variables e.g. %DEV% in headers is not something you should do, because:

1. its behaviour is not really specified by the compiler, making debugging harder (and, as you see, many integrated IDE tools don't play nice with it)

2. it is most definitely not portable (if/when you ever change compilers, or want to port things to another operating system)

 

In effect, how the path specified in an #include is interpreted is up to the implementation, so relying on it is kind of like "fixing" a broken door using duct tape instead of metal hinges: it will come crashing down on you eventually. It's much better to turn this into well-defined behaviour by using whatever facilities your compiler (or, failing that, your operating system) offers you when it comes to specifying where library files should be found.

1

Share this post


Link to post
Share on other sites

 

Ok, I'll give that a shot. Is there a reasoning why using Path (user variable) rather than a system variable is the better way to go?

 

Thanks

 

Well, system variables have a wider scope that user variables, so if a user variable suffices that is what you should use (what if you have multiple users, each of whom use the same compiler? maybe they don't want to have the compiler look for a bunch of libraries you use because it could cause clashes or whatever, again this is probably not the case but *what if*). That isn't really the reason, though, it's just the compiler expects to find external resources in:

1. built-in directories (you can't change this), this is for system headers e.g. iostream, stdlib.h, ...

2. directories specified in the $PATH (this is implementation dependent) and - for most compilers - in a special compiler variable called $INCLUDE

3. directories specified on the command-line (if using an IDE, this is set via your project options under "header/include directories" or something)

4. the current directory (if using quoted includes)

 

As I said, it's "better" to pass that info to the compiler by modifying your project settings (lowest scope) but isn't ideal when the project file is shared by everyone since you'll end up clobbering each other's settings and you'll have the same problem. A good version control tool can handle that but in your case it may simply be more effective to use environmental variables and forget about it. This is also the case when installing SDK's since they typically insert themselves in the $PATH so you don't need to do anything special.

 

Using system-dependent variables e.g. %DEV% in headers is not something you should do, because:

1. its behaviour is not really specified by the compiler, making debugging harder (and, as you see, many integrated IDE tools don't play nice with it)

2. it is most definitely not portable (if/when you ever change compilers, or want to port things to another operating system)

 

In effect, how the path specified in an #include is interpreted is up to the implementation, so relying on it is kind of like "fixing" a broken door using duct tape instead of metal hinges: it will come crashing down on you eventually. It's much better to turn this into well-defined behaviour by using whatever facilities your compiler (or, failing that, your operating system) offers you when it comes to specifying where library files should be found.

 

 

When I was talking about using a system variable (like %DEV%) i was using that in the projects include path not within the headers. Thanks for the tips!

0

Share this post


Link to post
Share on other sites

I use a similair scheme. I have an environment variable which points to the root of my source files directory.

Then in the project's settings i add the neccessary paths using that env variable to point to the root, and than specify it further down (something like $(DEV)/source for the source files, $(DEV)/lib for the libs etc).

Is this a good setup? Reason i'm using this scheme is because my source files are not located inside my solution dir, but are located elsewhere (per to my needs/liking), since i didn't want to make my source files dependant on a specific IDE setup. Say if i decided to use eclipse for some reason instead of VS2012, i dont have to change my source files directories at all, just add the neccessary paths to eclipse using the same scheme (or similair, haven't looked at how eclipse does it, i imagine it's not so different).

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0