CLM logo Development Blog by CLM

Remote tweaking

A long time ago in 2010, I have read an interesting article about Remote game editing by Noel Llopis, but it was just last year that we have implemented something similar and I must admit it makes a big difference during development. Basic concept is the same, although we’ve made some implementation choices that I think are really interesting.

First of all, our primary intent was to tweak global constants. Let’s say that there is something like this in the code:

	const float EnemyKillRadius = 36.0f;

It might take a few “edit-compile-run” cycles to find an optimal value for that variable and it takes that precious development time that could be better spent. To speed it up, we can register it in Tweak Server like that:

	WOMBAT_TS_FLOAT(EnemyKillRadius, 36.0f);

But hey, what this line of code actually does? Well it depends. In release builds it evaluates to simple constant variable, but in debug/test builds it’s a little more complicated:

#define WOMBAT_TS_FLOAT(name, value) WOMBAT_TS_FLOAT_INTERNAL(__FILE__, __LINE__, name, value)
#define WOMBAT_TS_FLOAT_INTERNAL(file, line, name, value) \
	float name = value; \
	static Wombat::TS_RegisterFloat WOMBAT_COMBINE(registerFloat, __LINE__)(file, line, #name, &name, value);
class TS_RegisterFloat
	TS_RegisterFloat(const char* file, int line, const char* name, float* ptr, float value)
		TweakServer::Instance()->RegisterFloat(file, line, name, ptr, value);

TweakServer instance is created by the first Instance() call and it stores information about all registered variables (including variable name, source code file name, line number, pointer to the variable and initial value).

Communication between the server and a GUI client is handled with protobuf messages over network socket. When the Tweak Client is running, it looks like this:


One of the most important features is the magical Apply button — as each variable is registered with an additional information about the place in the source code, GUI tool can put the new value directly into the code, so it will be there during the next compilation.

First tab in the GUI tool allows us to pick files which should be included in the tweaking process. It helps to see only the things you are about to change and minimizes unnecessary scrolling.

Our Tweak Server / Client implementation allows us to use it with floats, ints, colors and also execute of simple actions. The next screen shows a little more real example of actions and variables:


There is still a lot that can be improved and added, but the current solution just works and we are very happy with it. It already saved us a lot of time and effort.

Portable audio with FMOD

I definitely need to start following gamedev news more closely — just a moment after we integrated openal-soft for Android version of our framework, Firelight Technologies has made FMOD Studio free for indie devs*! What does this mean for us? FMOD is used in thousands of commercial titles (and that should prove it’s quality), provides great documentation and has a very clean and simple portable API.

Our audio subsystem is using simple handle manager to provide multiple backends (OpenAL, XAudio2) so integration of FMOD should be pretty simple, right? It took me just about 3h to have it up and running at the same functional level as other backends, at least on Windows. With iOS build we faced very strange problems, it looks like the provided libraries contain duplicated object files and that caused duplicate symbols at the linking stage. To confirm this:

$ lipo libfmod_iphoneos.a -thin armv7 -output libfmod_iphoneos_armv7.a
$ ar -t libfmod_iphoneos_armv7.a | sort | uniq -d

After manual fix of the libraries I was able to complete the build. I hope that this will be fixed in the next FMOD Studio release, till then we need to use ‘fixed’ library.

* indie in this case means game budget under $100k.

Keeping things organized

We are busy with Anodia update, so just a short entry this time. I want to share a great tool from Fog Creek that we use daily — Trello.

Just take a few minutes to get familiar with it:

In our current setup we use one board per project (framework, Anodia, Hexbee). Each board is divided into four columns:

  • To Do — current task list
  • Ongoing — tasks that we are working on
  • Done — completed tasks, to be deleted after verification
  • Future — tasks to be done in distant future

This simple setup works like a charm and overhead from having everything written down is minimal.

BTW. From other news, iCloud synchronization for score, stars and unlocked levels is awesome ;)

How we organize our projects

Today I want to share a little bit information about how our projects are organized from the technical side. As a foreword I should mention that 99% of our code is written in C/C++ and we’re using Objective-C only for communication with iOS.

One of our fundamental concepts is that we should share the most of the code between our projects instead of copying it. That’s the reason why we have a separate Framework project. Every one of our games or prototypes is using this Framework and during the development we’re trying to expand it with additional features. Currently it’s responsible for game states, memory, resources (Textures, sounds and audio streams), GUI, input, social features (leader boards, achievements) and simple data storage. When we think that some part of game code is reusable, we try to make it a part of the Framework.

Framework is also working as a layer between operating system and the game code, so there is almost no platform specific code in games. Currently we’re supporting iOS (iPhone, iPod Touch, iPad), OS X and Windows. System specific part of the Framework have API in C and this simplifies making it cross-platform.

Compilation of our Game for iOS looks like that:
1) compile Framework to framework.a
2) compile External Libraries to libraries.a
3) compile Game to game.a
4) copy .a files to Xcode project template that implements API, build and link it together

Xcode project may be customized by additional scripts to change project name, version, etc.

We store our projects in Git repositories. Whole building process is automated and we’re using Jenkins for continuous integration. We’re able to download latest builds from it with AdHoc distribution which is pretty great.

I think that this process works well for us and we’re going to expand it further in the future.

As a final note I just want to mention that our Framework is called Wombat ;)

Debugging iOS HTTP connections with Fiddler

Recently we were experimenting with NSURLConnection and for some reason it was not working as intended. URL received in connectionDidFinishLoading was different than the one from redirects done on our server and verified in the browser. We double checked the implementation and decided to take a look under the hood and see how the connection is actually performed.

There is a great tool for Windows called Fiddler2, HTTP debugging proxy. With a very small amount of configuration it’s possible to see all HTTP requests done from the device.

In the Fiddler just check “Allow remote computers to connect” in “Tools” -> “Fiddler Options” -> “Connections”. On the device edit connection configuration and set IP address of the PC with Fiddler as the proxy address and 8888 as the proxy port (can be changed in Fiddler configuration). It’s as simple as that!

And what about our problem? We forgot about caching! After changing cachePolicy of NSURLRequest everything works perfectly.

It might be a little strange that iOS developers write about Windows tool, but we are using multiple platforms in our daily work. And if you’re looking for a cross-platform alternative there is one called Charles but it’s not indie friendly (paid, I mean).