Look into eclipse, that is a good IDE which is in some areas quite close to VS. Debugging is better on VS, though...

I'm using Code::blocks and I think it works great. It is multi-platform, has a nice integrated GDB and is being actively developed. Swap between header and source files (one key), code completion etc. I would recommend downloading the mingW setup.

http://www.codeblocks.org/

@[b]Tobing[/b] - I totally forgot about Eclipse. I've used it alot but only for Java. Althought I remember setting up eclipse with MinGW to try and compile OBJ-C on windows and saw the C++ port. Thanks.


@[b]O-san[/b] - Code::blocks I have always heard of it but never looked into, checking out the features and avaialble plugins the suite looks complete, thanks for the tip.

Thanks for the post! Keep us updated with what you find out. I'm very interested in knowing some tips and caveats you find while developing for multiple platforms simultaneously. In my future projects I would like to target Win/Mac/Linux and code as generally as possible to make any specific porting I have to do minimal.

I second O-san's recommendation of Code::blocks. I've been using it for a while on my work computer and I enjoy how robust and powerful it is.

Keep on keeping on!

@Sir Funk - Will do. Thanks for the motivation.

Was this for a income producing game or a free release? Was this project for fun or not? I'd seriously consider what the goal is of the said project, and how you see it ending when you're done with it. For a income producing game, I'd really target mobile or windows if I wasn't proficient in programming. Since I use major AAA game engines myself, 2 of which I have the hard code C++ to, I generically do not need to do much backdoor coding. Instead I look to their scripting languages. When it comes down to it all, you will need more focus on artwork, sound, and combat / game mechanics (including story and how your game / ideas are perceived by the players) than coding. Coding is next important. You will need to be able to have a vision of the game before you begin, unless again its for practice. For me, what defines a indie game also is advertising and marketing campaigns. How well is public relations working for you? These things added into a indie game will boost sales and publicity. Any additional income should be going into pax, e3, ect. You want as much publicity as you can get. But this doesn't apply if you want to do it for fun. Personally, I have nothing against doing games for fun, as one of my future Steam releases will be Free, supported by buy able DLC. Finally, to top off the cake you should not worry about your coding as much. Decide 1 thing at a time, do that, then see if you want to expand or not into another area. Trying to preset for ALL = Disaster. Gl, and hope the game turns out decent.

@RedPin -- huh? [img]http://public.gamedev.net/public/style_emoticons/default/wacko.gif[/img]

I recommend QtCreator as an IDE. Even if you don't use the amazing Qt APIs, QtCreator is still a great IDE.

Choice of IDE ought to be orthogonal to the desire to support multiple platforms -- Furthermore, people are most productive when they are using the tools they are most comfortable with, whether that's Visual Studio on Windows, XCode on Mac OSX, KDE on Linux, Vim on... well, on anything capable of running code... And everyone has a different preference.

What you really are after is a cross-platform build system -- I use CMake, which is free, open source and available on all platforms. Essentially what it does is has its own language for defining different builds and the dependencies amongst them. You modify these files when you add a new file, change the dependency structure, or change build settings such as optimizations. CMake parses these files and generates the native build files for just about any platform you can think of -- It'll make solution/project files for Visual Studio or Xcode, GNU Make files, etc. In the case of project files, you can then load these into the IDE of your choice and see the entire project just as you would for a project created exclusively in those IDEs.

The biggest difficulty is getting everyone to *not* try to effect build changes by modifying the platform-dependent build files -- you've got to always make those changes to the cmake files themselves, otherwise they get over-written the next time cmake is run. This isn't difficult, its just something you have to change your way of thinking about to break the habit. A good way to do this is the have your source control configuration ignore the platform-defendant build files, and they can never be checked into the source tree (of course, its nice to be able to fiddle with those platform dependent files locally when you're trying to figure out what changes are desirable to make to the cmake files).