Now, results are somewhat shocking. Much more people participate in short compos than the long ones. But the best part is that quality of games created is just the same, no matter if the games was made in 2 hours or 4 weeks. Why?

1. Well, creating game in 4 weeks doesn’t usually mean neither 672 nor 224 working hours. In extreme cases 4 week compo is just a 2-hours compo, with 2 hours located at the very end of 4 weeks.
2. A lot of game value is an idea. Fact: you won’t come up with better idea in 4 weeks than in 10 minutes.
3. Development process for 2-hours game is very dense. And most of the time is spent on improving core features (because there are no others).
4. On the other hand, in long-term projects people start to focus on insignificant features. The moment you start improving abstract communication between task pools, adding GUI widgets so that you can make a built-in MP3 player or making splash screen data-oriented, your project is screwed to hell.

And this is probably the most important lesson to remember. If you need to do something very quick, code will be horrific, but also short, simple and fixable. With no time constraints, code will get new levels of complication, features and bugs. Time spent on maintaining won’t justify the result.

In 4 weeks, you can make several iterations of speed-coding, each time improving core features of the game. If you start with future proofness in mind, writing code and fixing bugs will consume most of the time. Sure, in 4 weeks you can make a ton of assets/levels, but how good are they is core gameplay is not good enough?

Finally, one solid C(++) tip: when adding new features, start with the smallest of available guns:

1. Global function — if you need to display score, don’t hesitate to add void DisplayScore() somewhere.  If your game is single-player, store score as a global variable. See? You have just saved 10 minutes of writing getters, setters and designing communication between modules. If your game is multi-player then you will need to store and display scores per-player. But there is no reason to be able to display arbitrary score of arbitrary player if your game is not yet multiplayer. Believe me, you’ll have bigger problems than displaying score with that.
2. If your functions share common code or require helper functions, group them somewhere, possibly in separate file. Remember about static functions and variables — contrary to “OO” static, file static is about visibility. But it’s cool, because you can have a file for all font-related operations and store internal data in static global variable. Helper functions can be static, and public ones go to one shared header (if you write simple code, compilation time is never your enemy).
3. Promote functions to classes only when it’s relevant and useful. Remember, classes means objects, objects mean relations and relations means complexity. Is your gameplay so cool that you have time for code complexity?
4. Any design patterns or other exotic stuff is the last resort if none of above is good enough. Personally? Never got there.

We have a String class. It is a reference-counted, immutable string. Typical data structures in C++ would look like:

struct string
{
  string_data * data;
};
 
struct string_data
{
  int refcount;
  int length;
  char * data;
};

So, string is merely a reference to actual string_data. Creating new string objects (string foo = "hello world") looks like:

1. string_constructor(const char *)
2. allocate string_data
3. string_data_constructor(const char *)
4. allocate char[]
5. copy data, set all other members

In memory, it would actually look like:

So, we have one stack allocation, two dynamic allocations and our data is in three different places in memory. But in C++ terms it seems impossible to improve it. However, we can go C way and change string_data definition:

struct string_data
{
  int refcount;
  int length;
  char data[1];
};

Array of one character? I must be crazy, right?

Most C++ courses are not very precise about pointers and arrays. Especially, what is the difference of following instructions?

const char * string1 = "hello world";
const char string2[] = "hello, C++!";

And what is the difference of those?

int foo(const char *) { printf("*\n"); }
int foo(const char[]) { printf("[]\n"); }

Unfortunately, in C++ world where really various things can be static, answers are different. In first case, string1 and string2 are something else. In second case, there is no difference — actually, that code won’t compile due to non-unique overload.

Maybe little investigation? Let’s print some data:

printf("%p %p %s\n", string1, &string1, string1);
printf("%p %p %s\n", string2, &string2, string2);

What we do is printing expression as a pointer, address of this expression as a second pointer and null-terminated string pointed by expression. Results:

0x08048650 0xbfddbfa4 hello world
0xbfddbf98 0xbfddbf98 hello, C++!

Now you see magic behind it. 0xbf…… are stack addresses while 0×08048650 comes from somewhere else (likely from static, read-only data section). So, while pointer types hold address inside, arrays points to themselves. And we can abuse it!

“Typical” C++ allocation of string_data would look like this:

string_data * foo = new string_data;

It would allocate sizeof(string_data) bytes (9 + padding, probably 12). But in fact, we can allocate as much as we want! For example:

string_data * q = (string_data*)malloc(2 * sizeof(int) + 12);
new (q) string_data;

In this case — 2 ints and 12 bytes of string data. After successful allocation we need to manually invoke constructor, using placement new. Similarly, regular delete q won’t work — following code will:

q->~string_data();
free(q);

Of course if data type is simple (built-in datatypes, relaxed POD, whatever) there is no need to call constructor and destructor (although those calls probably would be simply optimized away). And malloc/free can be replaced with custom allocation routines.

And after such allocation, we can use data like it was not a char[1] array but rather a char[as much as we have allocated] array! How does memory look like with this data structure?

And there are numerous benefits of such approach:

• one dynamic allocation less
• data is less scattered in memory
• we saved some memory (how much? size of the pointer + size of allocation metadata)

In the next part, I’ll show how we can save even more allocations/memory (but probably only on my personal blog, so subscribe if you’re interested).

But this isn’t really a problem. Why? Let’s compile this simple shader with Nvidia Cg using different profiles.

1
2
3
4
5
6
7
8

in float var;
float4 main() : COLOR
{
  if (var > 0.5)
    return float4(1 - var, 0, 0, 1);
  else
    return float4(0, sin(var), 0, 1);
}

First, arbfp1 assembly (roughly SM 2.0 equivalent):

1
2
3
4
5
6
7
8
9
10
11
12
13
14

#const c[0] = 0 1 0.5
PARAM c[1] = { { 0, 1, 0.5 } };
TEMP R0;
TEMP R1;
TEMP R2;
SLT R0.x, c[0].z, fragment.texcoord[0];
ABS R0.x, R0;
CMP R2.x, -R0, c[0], c[0].y;
MOV R1.xzw, c[0].xyxy;
MOV R0.yzw, c[0].xxxy;
SIN R1.y, fragment.texcoord[0].x;
ADD R0.x, -fragment.texcoord[0], c[0].y;
CMP result.color, -R2.x, R1, R0;
END

As ARB shader assembler has no branching, both paths are executed and correct version is selected at the end. Now gp4fp version (~SM 4.0):

1
2
3
4
5
6
7
8
9
10
11
12
13

TEMP R0;
TEMP RC, HC;
OUTPUT result_color0 = result.color;
SGT.F R0.x, fragment.attrib[0], {0.5};
TRUNC.U.CC HC.x, R0;
IF    NE.x;
  MOV.F result_color0.yzw, {0, 1}.xxxy;
  ADD.F result_color0.x, -fragment.attrib[0], {1};
ELSE;
  MOV.F result_color0.xzw, {0, 1}.xyxy;
  SIN.F result_color0.y, fragment.attrib[0].x;
ENDIF;
END

This time assembly generated is very similar to original code. If you play with compiling shaders on different profiles, you’ll also notice that in newer profiles like gp4*p optimizations are not pushed so hard. So my point is that:

1. newer shader assembly profiles are way more complex than old SM 2.0
2. and feature quite complex control flow instructions (branches, loops etc)
3. many optimizations are left to the driver
4. all advanced GLSL features (like UBO) would have to be implemented in assembler

Basically, GLSL assembler would like much like optimized GLSL source code with control flow slightly modified and variables renamed to r0…rN. But you can do it yourself! :) I’ve seen a least one game that used GLSL pre-optimization (same shader codebase was used for desktop and mobile OpenGL ES versions). And I think that there are bigger issues to address by Khronos than precompiled shaders.

On the other hand, an ability to dump compiled shader and reuse it later is a real killer. Also, in current deferred days number of shaders permutations is way lower than it used to be…

But this is so wrong. The key to success is using right tools at the right time. Just few ideas:

1. If doing X in some language/tool is difficult, outsource it. Maybe other languages/tools are more suitable to do it.
2. If you can isolate X in separate module/application, do it. Unix is all about small task-oriented application communicating over simple interfaces — and after 40 years it’s still doing great!
3. Pre-processing and post-processing is not only about lighting and shading. They can be applied to any kind of data, including code.
4. Auto-generated code is cool (as long as you control its generation).
5. Have flexible build system. Be able to plug any kind of processing into it.
6. Keep things simple!

And now, few stories and one longer example. When I started building my engine/pipeline in early 2009 I had many questions to be answered. One of them was game [engine] and editor communication. For some reason I decided to use C++ for all game code but C# for the editor**. I needed communication between those two — that includes sending some objects in both directions. C# features rich reflection/serialization support, but C++ is far more inferior about those. However, instead of using some template/#define trickery, I just made a simple application that generated both C++ and C# classes with all serialization needed from simple classes description in JSON-like language. Generated C++ code was extremely simple — no templates/macros/virtuals. Can I call it a win?

Once I was working on (non-gamedev) application that was using REST-like web services. How can you access web methods in your app? Some languages/frameworks (like C#/.NET) feature built-in support for those. For other toolsets the best solution could be similar to .NET — have a generator that creates code for all requests. And having custom generator is neat, because you’re not limited to one specific data/services descriptions (like WSDL/SOAP for .NET***).

Finally, live example. But first let me present a disclaimer: this is not a post about implementing properties in C++. Implementation is rough and may make your HDD and/or eyeballs explode. Thank you.

So it’s about properties. I mean C#-style properties. Imagine such code:

class Square
{
private:
  float _edge;
public:
  @property float edge
  {
    get
    {
      return _edge;
    }
    set
    {
      _edge = value;
    }
  }

  @property float area
  {
    get
    {
      return _edge * _edge;
    }
    set
    {
      _edge = sqrtf(value);
    }
  }
};
void print(float edge, float area)
{
  printf("edge = %f, area = %f\n", edge, area);
}
int main()
{
  Square s;
  s.area = 25;
  print(s.edge, s.area);
  s.edge = 3;
  print(s.edge, s.area);
  return 0;
}

to be valid C++. Well, using code pre-processing it’s possible.

Using this program: http://gist.github.com/923509 you can transform this “C++” into real C++: http://gist.github.com/923634

Results?

edge = 5.000000, area = 25.000000
edge = 3.000000, area = 9.000000

Final thoughts: using code generators/pre-processing you can avoid using many unnecessary C++ features like templates. Keep things simple. C++ is hell, you will never be able to fully parse it without complex tools. Just assume good faith of your users while creating code processing tools. And I hope that such code processing will be integrated in future language (Metalua seems to be quite cool!).

Other files: input C++, makefile.

template <typename T, typename T1> virtual T foo(T1 t, ...) = 0;

There are many failful designs out there that suffer greatly from generalization. Fine example is a 3D renderer I’ve seen once. It was written by a pro-OOP guy, and it was heavily templated, STLed and smart pointed. There were many [C]Material classes and various [C]Meshes and everything was tightly design patterned. So I’ve asked the author to add simple vertex extrusion along its normal. He instantly refused, pointing that he would have to add many additional classes for extended materials, shaders and parameters. Objects properties and internal tools would also require changes. He said it would take about 10 to 20 man-hours. I said Wait, it’s one line in shader and one additional parameter — why would it take so long? And he replied: My engine is designed to be easily extended, so such modifications require a lot of work.

This can be described as vicious circle of generalization:

1. We want the code to be as generalized as possible.
2. We design everything future-proof and extendible.
3. When a feature request arrives, we’re doomed we need to change a lot of code.
4. Why?
5. Because everything was designed as generalized as possible.
6. goto 1;

And visual version:

So — at least in my opinion — reject toxic design patterns and KISS instead. Small functional changes should not require big code changes. And everytime you over-engineer something, another startup dies (and there aren’t many left after all singleton experiments).

Disclaimer: this post is related to IGK presentation [PL only, unfortunately] about efficient C++ and DOD from Adam Sawicki and me.

CI toolkit we are about to make consists of 3 separate parts:

1. The Notifier

Somehow we need to know that there is a work to do. Most VCSes are pluggable, allowing custom hooks occur on certain events (for example commit/push). But personally I prefer scheduled checks instead (as post-commit hooks may be slow). So basically cron (or Windows Task Scheduler) is your friend here.

2. The Builder

You need an automated build system here. On Windows it’s quite easy, because Visual Studio’s solution files can be used directly (devenv.com YourProject.sln /rebuild Release). On Linux/OSX there are makefiles/autotools, but for me using bash+make is quite painful. After all, the thing that programmers do the best is programming — so I’ve just wrote simple scripts to find all sources and build them, using PHP as scripting language of choice. Also, using PHP for whole “build system” is more cross-platform — it’s usually easier to bundle PHP executables than force anyone to install Cygwin shell (however I can’t imagine using Windows without it).

After building process is complete just call some simple API (see #3). Informations you need to send (you can use CURL for this) include project ID, OS/build version, build status, build logs (especially when build failed) and any other information you find useful. If you have unit tests you can attach them to logs. It’s also uber-cool to have automated test process (i.e. run game and start playing replay/script), taking screenshots at certain moments. You can also upload zipped package of game bundle (nightly builds).

3. The Server

Server receives API calls from building scripts. Data can be stored in DB. You will also need few pages that user can see (list of projects, versions, last N builds, specific build log). No rocket science here — average housewife can do it with PHP & MySQL in no time. E-mail notifications about failed builds sum up the effort. If you use some project management tool you can send notifications there as well. For example Assembla.com lets you create/update a ticket with a plain old e-mail.

BTW: build process can be moved server-side if you are able and willing to do it. But it’s usually easier to find cheap PHP+MySQL hosting than fully-equipped server with SSH access and build tools (GCC + friends) installed (let alone running the game to take some screenshots).

I’ve been using such system for my small cross-platform experiments. I do most dev on Windows (where I have Visual Studio) but I want to keep Linux/OSX versions alive and kicking. Small open-source teams can (and should!) try it as well.

C++ is a terrible language. I’m pretty sure all of you already know C++ Frequently Questioned Answers — it’s a bible of C++ quirks, a must-read. C++ claims to be multi-paradigm; procedural, object-oriented and generic. But it fails on all levels — I mean, have you ever tried to implement delegates in C++ without external libs? Or STL containers, they should be so superior to C# generics due to compile time evaluation, but have you ever seen assembly generated? And I’m pretty sure that the whole metaprogramming idea inspired many folks to build a CPU inside Minecraft.

But to be fair: a lot of good software was build and shipped with C++ (or not entirely crippled by C++ as FQA would state). So perhaps people may find use of various C++ features, depending on personal taste. But the real problem with C++ features is an amount of them. There are tonnes and tonnes of those features, some widely known and some remaining in the dark, waiting for years to shoot your foot off. And C++0X is only going to make things worse. I greatly admire people behind C++ compilers. Those guys are real heroes. But I’d love them to improve optimizations, not some bizzare and/or creepy features that are likely to explode when used together. If I didn’t care about performance, I would not use C++ anyway, right? But the sad fact is that a lot of C++ features prevent optimizations in direct (e.g. side effects you don’t care about) of indirect (because compilers are getting extremely complex) ways.

And you can’t expect people to know all those tiny little features of C++. It can be expressed like this:

(∀ x ∈ C++ programmers) (∃ ε > 0) x is the only one who knows some bizarre C++ feature around radius ε

And so, to keep people sane and deliver some software, most companies that still use C++ put a lot of restrictions, mostly “don’t use …” (exceptions, RTTI, non-container templates, whatever you hate). In extreme cases, only “C with classes” is left. Not that it’s bad, it’s something I use personally (BTW: usage of C++ features can be perhaps measured in ratio of Release/Debug performance — and I know some games in which Cornell box level is just a little too much for debug build). But the compiler doesn’t know that we disrespect that “bad part” of C++ and still have to do its job.

Any alternatives to C++? It’s not easy. The sad fact is that most languages have compiler/library/IDE issues. D haven’t ever gained attention, C# is not crossplatform and Java is <insert your favourite joke here>. At the moment there is no easy replacement or at least I don’t see one.

But I keep my fingers crossed for LLVM. LLVM is a complete compiler infrastructure, but the most interesting part is backend: optimizations and generation of machine code (either static or JIT). Our job is “just” to make a front-end for our language, which is quite simple for simple languages (especially using tools like Flex/Bison). But why limit yourself to one language? I can think of following scenario:

• “main” language, similar to “C with classes and whatever we really need” used for most engine/game code
• “computational” language, similar to shaders (see my previous post here)
• “gameplay” language, similar to Lua

The greatest benefit I see is that using uniform infrastructure we could glue those pieces of code without additional layers of wrappers (like in typical C++&Lua code). Another win is uniform debugging using one tool only (LLVM IR may contain standardized debugging information). And of course another huge advantage is an ability to fine-tune each language to specific needs:

• “computational” language doesn’t need to have classes
• but must have robust vector/matrix support
• “no side effects” functions and compile-time optimizations using this
• SSE/Altivec  is mandatory
• GPU/SPU support would be cool, too (although some folks would be very unhappy not having to manually adjust SPU assembly)

On the other hand:

• “gameplay” language could implement a number of Lua-like features
• like functions as first-class citizens
• maybe also coroutines
• garbage collected, duck typed? a lot of options here

But wouldn’t maintaining three different languages be harder than just one? Well… if you need a language suitable for any job with a bunch of features, I can’t help noticing that there is one already, yet I think you already know that I don’t like C++ very much. And wouldn’t maintaining any number of custom languages be harder than just shutting up and continuing to use C++? Honestly, I don’t know. While C++ is horrible as a language, it has excellent IDE/debugger/libraries/etc support. This would be very tricky to fight and you probably won’t get far without some kind of C/C++ compatibility in “main” language. However, I’d still give it a shot.

But how can you do transformations the smart way? Actual vertex transformation is quite an easy case (if you’re not doing anything fancy) — do some (fixed) math and you’re good to go. Particle systems would be harder. Some systems could be stateless, some not. For some of them you would like to have billboards, for other some DOF unlocked. Some would use simple textures while others… etc. This can quickly get very complex. But let’s go even further — imagine a Diablo-like (or top-down shooter) game where you have hundreds of opponents, all of them casting spells or just throwing knives and chairs into you. There are many nice Flash games out there, but unfortunately most of them is no longer fun after first 200 sprites visible on screen.

1. Fixed function

You can start with something like (in pseudocode)

SpellsSystem::Update(float dt)
{
  for each (Spell s in spells)
  {
    // do some calculations and update s state
  }
}

This is OK, but how many different effects can your spell make? What is their relationship? Maybe some effects depend on certain conditions like time delay or other objects state? The bottom line is that it may end with heavily conditioned code or use of class inheritance/virtuals/etc. Either way this causes several problems:

• while the code itself may be more or less readable, it will be very hard to track what is exactly going on with specific object
• performance will be rather choppy (it may not be so bad with good branch prediction — but there are other platforms than X86)…
• …but it’s certainly going to be terrible in Debug mode. And what is the purpose of using Debug mode when your game hardly hits realtime (in SIGGRAPH terms) framerates, let alone  smooth gameplay?

2. Oh my XML

But don’t forget that you also need to specify settings for particular data system. Some may be expressed with simple flags like Particle::isTransparent or Attack::isLethal. But what if you want to express something like “attack with acid cloud for 5 seconds and then throw fireball unless below 10 HP”? I’ve seen an actual game that used XML for such things:

<effect type="bullet">
  <emitter>
    <speed value="0.0" />
    <acceleration value="0.0" />
    <ttl value="0.5" />
    <count value="1" />
    <width value="0" />
    <explode-on-fade value="1" />
    <bullet value="data/physicals/invisible-bullet.xml" />
    <filter value="none" />
 
    <flight-effect type="list">
      <effect type="delayed">
        <time value="0.15"/>
        <effect type="retarget">
          <target-chooser>
            <filter value="none"/>
            <range value="2.0" />
            <angle value="60.0"/>
            <aim-at-ground value="1"/>
          </target-chooser>
          <effect type="list">
            <effect type="jump">
              <name value="crawling-lightning"/>
            </effect>
            <effect type="bullet">
              <emitter>
                <speed value="0.0" />
                <acceleration value="0.0" />
                <ttl value="0.5" />
                <count value="1" />
                <width value="0" />
                <explode-on-fade value="1" />
                <bullet value="data/physicals/invisible-bullet.xml" />
                <filter value="none" />
 
                <flight-effect type="delayed">
                  <time value="0.15"/>
                  <effect type="retarget">
                    <target-chooser>
                      <filter value="none"/>
                      <range value="1.5" />
                      <angle value="60.0"/>
                      <aim-at-ground value="1"/>
                    </target-chooser>
                    <effect type="list">
                      <effect type="jump">
                        <name value="crawling-lightning"/>
                      </effect>
                      <effect type="bullet">
                        <emitter>
                          <speed value="0.0" />
                          <acceleration value="0.0" />
                          <ttl value="0.5" />
                          <count value="2" />
                          <width value="0" />
                          <explode-on-fade value="1" />
                          <bullet value="data/physicals/invisible-bullet.xml" />
                          <filter value="none" />
 
                          <flight-effect type="delayed">
                            <time value="0.15"/>
                            <effect type="retarget">
                              <target-chooser>
                                <filter value="none"/>
                                <range value="1.0" />
                                <angle value="60.0"/>
                                <aim-at-ground value="1"/>
                              </target-chooser>
                              <effect type="jump">
                                <name value="crawling-lightning"/>
                              </effect>
                            </effect>
                          </flight-effect>
                        </emitter>
                      </effect>
                    </effect>
                  </effect>
                </flight-effect>
              </emitter>
            </effect>
          </effect>
        </effect>
      </effect>
    </flight-effect>
  </emitter>
</effect>

Other possibility is to use graph nodes editor and carefully connects all such effects, actions and conditions.

(image omitted — too big and scary)

3. Programmable pipeline

Some time ago I’ve written a blog post about data transformation pipeline build around Flex/Bison/ASMjit (and recently LLVM). This can be thought as something like regular data shader (or object shader if you like silly buzzwords). You can basically write a piece of code that is somewhere between a shader and Lua script and compile it in runtime. You can use your favourite approach (class hierarchy-based, components-based) and it’s still going to be fast because it’ll end as (hopefully) branchless piece of raw data processing code. You can even use XML or nodes editor to prepare such code, but <rant> I have no idea why anyone would like to link graph nodes instead of writing C-like code. I mean, try to implement, debug and optimize HBAO using only your mouse. </rant>

struct State
{
   float4 * positions;
   float4 * orientations;
   uint32_t * hps;
};
struct Output
{
   State new_state;
   uint32_t * attack_types;
};
 
void (*transform_data)(State &, Output &);

Using such method, you gain performance boost in general, thanks to:

• using struct-of-arrays data input & output
• agressive inlining
• not including unnecessary code in transformation (hopefully branchless)
• optimizations of data transform code are independent with general profile so you can still enjoy thousands of objects in Debug
• ability to target to specific machine (I mean, most of general JIT-ted languages like C# don’t really benefit from SSE etc., but here you can enjoy full processor power not relying that all end-users actually have SSE 4.2 and fancy DPPS ops)
• last but not least, it can be easily parallelized

Why don’t use OpenCL/CUDA/DirectCompute for this?

As far as I can see, CPU OpenCL implementations are still not production-ready (at least when I was digging the subject). And other solutions are too vendor-specific.

Why don’t use GPU for this?

Well, most of the time you could. But most GPGPU evangelists have trouble noticing that in typical video game, GPU already has a lot to do. So, depending on your specific needs, using GPU for heavy computations could only slow down the application in overall. But this is also system dependent. Gamers can have powerful GPU combined with low-end CPU and vice-versa. Additionally don’t forget that there is a lot of overhead in copying data between GPU and CPU. So there is no silver bullet but of course the ability to do those computations on GPU is cool.

PS. I’ll try to post some benchmarks if this is interesting enough. And feel free to correct any errors — after all, I’m not AAA veteran with 30 years of experience. ;)