Jonathan, you’re doing the typical new to Linux Development “OFGWTFBBQ THIS IS SHITTY SHITTY SHITTY BECAUSE THERE IS NO VISUAL STUDIO”
Yeah, there isn’t. As you’re apparently *very* used to IDE’s, and probably not even used to configuring it to use 3rd party tools that often. If I’ve read your lack of experience correctly, you’re in for some work, especially since you’re at your own little concern rather than at a shop with a person who can setup all this for you the first time as happens with most people new to Linux.
Unfortunately for your own learning, you are not under the tutledge of someone who can tell you to stop whining about this (which you are) and give basic pointers. I have no doubt you’re a talented developer, but like many talented developers, I think you’re over-valuing your own experience when evaluating this new area. Time to put on your humility hat, not your ridiculing asshole hat. You need us, we don’t need you. There is a lot of black magic and dragons in linux development, and one of them will eat weeks of your time if you aren’t careful.
gdb has tons of ways to insert callbacks, pullout data, pop between threads and other such fine controlled features that it will blow your mind when you actually have to use it to do one of these things. The VISUAL interfaces to gdb only allow you to access VS type control for the most part, you have to learn the command line part to really get into the very powerful features. Additionally, you have to learn a lot about gcc to compile in all the stubs to get gdb to do the fantastically awesome things it can do (including allow you to make your own routines that are called in any number of critera, a pile more powerful than “printf’s on a PS3″). I will point out any investment in learning this toolset will possibly pay off for windows too if you find an intractable problem, as you can also use it for much in the way of windows development.
Some changes of paradigms you need to get into your head to effectively develop on Linux.
1. It is often easier to develop software than to find software on Linux
It’s REALLY easy to get something effective but not very robust going on Linux. You may go “I don’t want to write a shitty sound layer by hand”. I don’t think you should. However, writing a tool that looks at sounds buffers, or a small patch to something you partially already understand in a library is probably something you can do in a few short days. This would take a LOT longer on windows usually, as there is an interface (the API) which you cannot pierce, or at least not easily. In Linux, while there is an API, you can burrow down deeper and instrument the hell out of a library, using some custom tool you make if you don’t want to learn about gcc, gdb and gprof. When pissed off how YUV overlays refreshed (in SDL) on one project, I used gprof to build a call tree and quickly rewrote 2 functions of the SDL library to fit our needs. This took 3 days to make it work perfectly, and this was an embedded project (which generally means, longer than desktop).
2. Make is a tool that is exceptional for many purposes. Some peoples’ makefiles are evil incarnate, and will torture you eternally if you don’t ask for help.
Make’s algorithm for determining what needs rebuilding is not very well suited to many projects, nor is the cross awareness of makefiles especially great in large tree structures of files. C++ projects, which have their own issues with nasty compile time lengths, really can hurt here.
That said, it’s an excellent build tool for a great many purposes it’s used for, because of the level of control and the low level of specification required by people who know what they’re doing. I like the directions lots of other tools are going, but nothing other then ant is getting a huge following, and it comes with many people a taint of Java (which is a four letter word to many people who aren’t java devs).
3. We don’t really give two craps who you are.
I personally like your game. But in general, a lot of the REALLY devoted people you want to answer your questions can have their head down in linux related stuff so much they have no clue who other people are. Also, their livelihood isn’t predicated on getting jobs necessarily, so they’ll frankly give you the finger if you’re nasty or will return nasty back at you. There is much more to linux development than anyone can ever learn, and being sure of yourself is just a recipe for sure embarassment in this world. I’m a pretty self assured guy, but I go and put on the humility hat whenever I ask for help or make statements about the tools. I don’t care personally about the adoption of desktop linux, and lots of people you need to answer your questions don’t either. And really that’s the only benefit braid on linux brings to linux. It’s another “Look, there ARE games on linux” sucess story if you get it working.
4. If you do this correctly, braid should port to OS X with little additional work (and using similar libraries and tools).
And your knowledge of the tools will port near completely and you’ll be able to understand the differences more easily.
–Michael
