Development Info Making of Grimrock: Rapid Programming

[VentilatorOfDoom]

Tags: Legend of Grimrock

Codex Workshop afficionados might be interested in this, the makers of Legend of Grimrock are blogging about their programming experiences, topic is the usefulness of LUA.

A typical game development workflow when working with C++ is something like this:
1. Design and write code in IDE (IDE being basically a glorified text editor)
2. Compile code (compilation turns the source code into machine executable sequence of instructions)
3. Run the game and wait for it to load
4. Test your changes (play the game to the spot where you have made your changes or load a saved game if you’re lucky and the save game is still compatible with your code changes)
5. Go back to step 1

Steps 1 through 5 is usually collectively called the “iteration loop”. Essentially step 1 is where all the innovation and fun happens, everything else is just lost time. The length of the iteration loop is usually somewhere between 30 secs to a couple of minutes (if it’s longer than that you’re pretty much screwed). On consoles and mobile devices the iteration loop is usually even longer because the code and/or data has to be transmitted to the device for testing.

In game development, especially when tuning game play, the code changes you make in step 1 are often very quick to make and development speed can become bottlenecked by redundant steps 2-5. There are two factors in this. First, the actual time lost to waiting due to compilation, waiting for the game to start up and getting the game state to where you want it to be in order to test the new feature. Second, and this is far more important in my opinion, with a long iteration loop your mind easily wanders off and you lose the trail of thought. For example, if you have to wait for a minute for the code to compile, there’s a pretty good chance that you check your mails, open a browser to check the news and suddenly you’re thinking about your girlfriend, wife, dog, whatever . And it’s this context switch that really hurts because getting back into the flow of programming needs considerable amount of time.

 

[Yaar Podshipnik]

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.

 

[VentilatorOfDoom]

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.

I just compiled something and it took 8 sec. What about you?

 

[pakoito]

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.

 

[Ulminati]

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.

I just compiled something and it took 8 sec. What about you?

My compliations usually take a couple of minutes. I spend complation time writing documentation for the code I just did or some other snippet that lacks it. Or browse the codex. There's usually an alert or inbox message whenever I hit compile

 

[kaizoku]

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

 

[Yaar Podshipnik]

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

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.

 

[Antagonist]

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.

 

[Castanova]

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

 

[Tramboi]

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.

 

[thesheeep]

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.

 

[Tramboi]

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.

 

[Davaris]

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.

 

[Surf Solar]

This reminds me of myself, even non programmers know this. Waiting hours and hours for a render to finish, bleh.