Jump to content
  • Advertisement
Sign in to follow this  
Storyyeller

how to do conditional compilation

This topic is 2996 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

In my game, there are some cheats I put in which might be useful for testing purposes. However, I don't want them to appear in the finished version. So I put them inside blocks like

#ifdef CHEATS
#endif

My theory is that that way, I could easily enable and disable cheats just by changing the #defines under Project Build Options in Code::Blocks.

However, this doesn't work. For some reason, changing project defines does not cause the affected files to be recompiled. Therefore, to get consistent behavior, I have to rebuild my entire game each time, which is obviously undesirable. I tried searching the manual and looking online, but I have been unable to find any method to do what I want.

Share this post


Link to post
Share on other sites
Advertisement
Instead of putting the definitions in your project settings, put them in header files which are included by files which use the variables. You can have one header file for all your compile-time variables, or split them into different files based on what parts of the application they affect. Either way, changing the definitions will cause the IDE's usual dependency system to note the files that need recompiling. This also gives you one less thing to worry about if/when you move to a different IDE or build system.

BTW: For safety with this system, you should use #if CHEATS == 1 instead #ifdef CHEATS, so that you'll get errors if you forget to include the configuration header.

Share this post


Link to post
Share on other sites
I don't think I'd go with conditional compilation on something like this.

You've only get one real upside to it: players of the final game won't have access to the cheats.

The downsides OTOH are several:
More time wasted recompiling code for cheat/non-cheat versions.
More chances to introduce bugs between the two versions.
More difficulty tracking down obscure bugs since the two versions will have different binaries.
Eventually you'll want to have people other than yourself do some testing, it'll make things more complicated for them.

I'd just go the route that most of the big guys seem to use. Build your cheats into the game and just require various codes to turn them on. Or if it's only values than need to be changed, not actual code, just push them out into settings file(s) that can easily be swapped.

Share this post


Link to post
Share on other sites
Storyyeller has already made the decision not to include cheats in the final game. I would not expect someone can come up with any reason that he hasn't thought of already what could lead to change of that decision.

Visual Studio does recompile when project settings change, but it recompiles the whole thing. You'll need to do as Sneftel suggests if you want to only recompile the affected files.
Another option is to use different build configurations for it. The most basic thing is to consider whether you can simply enable it only for debug builds. Otherwise, try creating Debug/Cheat and Release/Cheat configurations.

Share this post


Link to post
Share on other sites
Right now, I'm just enabling cheats in the Debug version. I'll probably go with the separate header thing if I ever have to test cheats in the release build for some reason, but it doesn't seem likely.

Share this post


Link to post
Share on other sites
For every professional game I've worked on, we use extra build configurations (Debug, Release, Final, GM) for things like non-shippable cheat codes on in-game debugging GUI.

Final and GM (Gold Master) typically disable anything that the end user should not see.

We don't use Code::Blocks so I'm not sure how different its configuration options are.

Share this post


Link to post
Share on other sites
Quote:
Original post by Nypyren
For every professional game I've worked on, we use extra build configurations (Debug, Release, Final, GM) for things like non-shippable cheat codes on in-game debugging GUI.

Final and GM (Gold Master) typically disable anything that the end user should not see.

We don't use Code::Blocks so I'm not sure how different its configuration options are.

We did something similar using the build configurations as well. It's extremely important in console development to be able to just turn things off. It can significantly affect runtimes and memory usage. And if the end user can't see it, then there is no reason to let it slow down their game.

Remember, dev kits/machines will tend to have more ram than the final target (up to 2x for some consoles). You end up having a lot of "cheats" and other debug features that allocate buffers for things like: debug names, debug lines, state history, profile counters, statistics counters, etc. You have to remove those and any code you can to cut the memory usage in half so it works on the real console.

Also consider the fact that the difference in runtime between "debug" and "optimized" builds can be significant. You'll still want your "dev cheat" system to work in "optimized" builds, and even then, removing those dev cheats will still improve your framerate. (and 2-3fps near 30fps can be the difference between always being 'in frame' and not.)

And don't forget that dev-cheats are just as bad as any other piece of code for creating or removing bugs. Errors can show up from using compile flags to remove code. On the other hand, fixing those bugs is often better than having part of the game broken because a cheat is or isn't set. It is very very easy to forget to unset cheats, especially considering how much they help iteration time on your levels.

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!