Development Info Making of Grimrock: Rapid Programming

Maybe it's different in game development, but when writing enterprise (I apologize for using such ugly words) C++ the compile time is essential to regain your sanity.

Mine, when fully compiled, takes 20+ minutes. Now, small changes, no engine changes, just testing, 30 seconds. Then a minute to deploy to device if the Windows version doesn't cut it, and whatever time it takes to get to the desired test state.

For the less observant ones, there is a HUGE difference between "build" and "clean ; build".

obligatory! http://xkcd.com/303/


I also need to buy a tshirt like this one

Precisely! There is shit that gets built in seconds. There are cases when you need to do clean build so that you can run some tests and be sure that your change really got picked up. That is especially painful and true if your product includes tons of generated code and you've just modified some stuff that makes thousands of files different.

There is very, very big difference between coding one does for fun and enterprise shit.

Some larger outlets have various build and test servers which are triggered whenever a commit to the repository happens and generate reports automatically for each build. This is essential in any setting where you develop cross-platform and in collaboration with other developers in order to be able to assign the correct "blame" if something should break. In my experience though it's custom that the changes you commit should at least build on your own development machine. And yes, incremental building FTW.

Seems like a pretty cool workflow although he doesn't give many details or references on how to actually set it up.

You can cut compile times by working hard but it is not always possible with huge projects.
What is important is fast incremental builds when you make isolated changes.
But then you often get bit in the ass by slow linking.

Scripting improves development cycles. News at 11.

Okay, okay, maybe some people didn't know that, but still.

That LuaJIT does sound interesting though. I used the normal Lua once, and it was already fast.

I'm not so much convinced by this.
Scripting improves rapid iterations but code often end up sloppy and not refactored.
It takes discipline and good programmers to avoid this problem.

I'm not a fan of traditional scripting, as you can't find bugs as easily as you can in C++. Also, scripting is not ideal for programming games, because you have to code explicitly for failures. Even worse, you can't run multiple behaviors at the same time, unless you create special data structures, that run behaviors after the script exits.

With Behavior Trees you get all of the above free. They are efficient, easy to make and use and you can rebuild them at run time. The only difficultly with Behavior Trees, is making a good editor.