This might sound stupid, but try to comment every other line (unless you have a lot of repeating or similar tasks). By doing so you get two advantages:

1. Someone unskilled in programming or unfamiliar with what you are doing is able to read your code.
2. You know what you are doing

The first advantage is important unless you are working alone and never expect to see your code again. In that case you should really ask yourself if you should even be writing that code.

The second one is important even if you have no trouble reading code. Let's take a look at the following example.

for(int index_person = 0; index_person < persons.size(); ++index_person)
{
    for(int index_kids = 0; index_kids < persons[index_person].kids.size(); ++index_kids)
    {
        /* ... */
    }
}

And then take a look at this example:

/* Iterating through the persons in the lists */
for(int index_person = 0; index_person < persons.size(); ++index_person)
{
    /* Iterating through the kids of the persons in the list */
    for(int index_kids = 0; index_kids < persons[index_person].kids.size(); ++index_kids)
    {
        /* checking if any of the persons in the list have a kid who is dead */
        /* ... */
    }
}

In the last example I only have to track back to the first comment prior to my line of code to know what I'm doing here. It's a pain to write so many comments but it makes code a whole lot easier to read.

Anyway, today, while I was walking the dog, I suddenly realized how to fix a bottleneck for a certain game idea. The game idea was that the hero can interact and affect lives of other characters in the game directly, the bottleneck however was that each character affects another character, which affects another character and so on. A simple example would be if you decide to buy a weapon or not. If you do buy a weapon the merchant will be able to stay in business, buy some bread. When he buys bread, the baker will be able to buy the next shipment of grain from the miller and the miller we be able to pay the farmer and everybody will be happy. Now if you don't the miller might not be able to some bread (he needs to eat also) which means that he goes out of business. Since he is the only miller in the entire region, there will be no more bread for quite some time and everybody dies from the hunger.

The problem with that game idea is that if you even simulate a small village (say 25 people) you will have a lot of relationships to go through. Even if it goes in one direction it will still be 1 hero times 1 person times 25 people times 24 people times 23 people et cetera. The total amount of relationships within the village would be 1.6E+25 (16 with 24 zeros behind it). Even if we say that any action will have not have any affect after 7 relationships that would still be 2.4 billion relationships that are affected. If we limit the amount of relationships to 7 for each person (so 7x7x7x7x7x7x7) it will be 823543 of relationships that need to be updated when the hero does something. And maybe one of those persons affected will need to perform an action that affects the community which means the entire process starts over again.

Of course the game is real time and the other people in the village don't require you to perform any action so if you have 3 or 4 villages you will have almost a constant rate of large social updates. Until this morning it was my firm belief that the above game idea should be hard if not impossible to execute unless you have some monster system.

I always thought in forward direction, what happened now dictates the future, until I thought about reversing the flow, the past is dictated by the future.

Lets take the previous example of buying a weapon or not. Although this is a fact now by the player, the game does not have access at that information at the current time. Let's say you meet the miller and find out he is alive. No matter what happened in the past, the future dictates past events that no matter what the miller survived and kept his job. And the only way that he has kept his job if the baker bought his grain and the only way that the baker could buy his grain was if some paid for his bread. If you made a major investment by buying a weapon (say a gold weapon) then he might credit you for it. If you weren't the cause something else must have happened for the influx of money that allowed the community to stay alive.

Now lets take the same example but the miller is dead. The past generated from that point on could dictate that the hero not buying could have caused it. Or if he did buy the past could credit something else (disease, war, bad crops et cetera).
So what is so different about the reverse update compared to the forward update that it allows us to compact information in such a manner that the above game idea is possible?

Simply put: Forward updates are simulations, calculating exact future behavior, while reverse updates are emulations, imitation of past behavior. A forward update always has one cause (generally the hero) but has many effects (the merchant, the baker, the miller and the farmer). A reverse update has one effect (the baker) and will look for one cause for its current state which is a linear path.

I'm not certain if the solution always works as the past needs to be consistent (you can't undo the past) and certain actions always have a forward update, but for now the game idea seems possible again.

Since I'm currently thinking about a space game, I was wondering how to create a huge battle field (a whole solar system) in real time while having all the precision I need.

Doubles are not fast and take a lot of space and although I don't worry about space, speed is a bigger issue. If I want a huge battle and here I'm going to throw some numbers: One side can have as maximum 85 huge ships, 3010 fighters, makes 3960 weapon slots, which makes 19800 bullets flying around. And that is only one side. Since I need two sides for a war, I need to double the values (190 ships, 6020 fighters, 7920 hardpoints, 39600 bullets). Lets say that everything is represented by one location (which a 3D vector) it would mean 53730 locations. 53730 locations times 3 would be 161190 and that times sizeof(double) would be 161190 * 8 bytes = 1289520 bytes (about 1MB) which is a lot to start with even if you ignore the fact that the problem is more that I have a lot than the doubles are bigger.

As I was considering the problem I realized something else. When I'm rendering, I will need to use floats. DirectX 9 requires floats and although I could send doubles it would half my data bandwidth. So what ever I choose, in the end I will need to use floats unless I want to have some penalty.

Using doubles for vertices are is a bad idea for the sake of precision alone.

But then I started thinking...

I don't need to render using doubles, I can simply render everything with floats and to ensure that precision is maintained. If something is not within the safe area of floating point rendering (let's say floats can have a maximum of 1024, and yes I now it can be a lot more) but the object in question is 2048 units away, I still want to render it. You can't simply let a sun disappear because it is beyond the range of your numbers, that would be weird.

Instead everything that is more than 1024 units away will be rendered first (farthest away first) and the distance also scales it down. Than I clear the Z buffer and render everything in the 1024 range.

It was so simple that I thought it was silly I never thought about it. How you scale it however depends on the view and projection matrix.

I'm still not certain if I want to use doubles, but for my second problem I have a solution. Now I need to find one for my first.

The only reason it took longer than anticipated was because of muscle memory. One of the features I wanted to test was the delay. For example you want to do the "asdf" combo, but you are for some reason not fast enough, than the combo should not start. Simulating this is easy, just begin the combo and stop somewhere for a second and then complete the combo. So "asd", pause and then "f".
However when I tried that for some reason the combo was sometimes completed. Only after adding the debug messages I noticed that I often automatically did complete the combo. The problem was muscle memory.

Anyway below is the code and if anyone wants to extend it (wrong next key, combo breakers, roman cancel, and follow-up combos) feel free to do so and let me know.

/*******************************************************************************
 * The MIT License
 *
 * Licensed under the MIT license:
 *   http://www.opensource.org/licenses/mit-license.php
 *
 * Copyright (c) 2010 Wouter Lindenhof (http://limegarden.net)
 *
 * Demonstration of a simple ComboHit system
 *******************************************************************************/

#include <Windows.h>
#include <iostream>
#include <vector>
#pragma comment(lib, "Winmm.lib")

#define DEBUGLOG 1 // Set to 0 to turn debug messages off

class KeyHit
{
public:
	UINT m_Key;
	UINT m_Delay;
	UINT m_Waiting;
public:
	KeyHit(UINT key, UINT delay) : m_Key(key), m_Delay(delay), m_Waiting(0) { }
};

class HitCombo
{
	UINT m_SequenceIndex;
	std::vector<KeyHit> m_Keys;
public:
	HitCombo() : m_SequenceIndex(0) { }

	void Cancel();
	void Update(DWORD ms);
	operator bool();
	HitCombo& operator << (const KeyHit& hit);
};

int main(int argc, const char* argv[])
{
	std::cout << "-----------------------------------------------" << std::endl;
	std::cout << "This is a combo key tester: " << std::endl;
	std::cout << "Press \"ASDF\" quickly to do a combo hit" << std::endl;
	std::cout << "Press \"Wouter\" quickly to write my name" << std::endl;
	std::cout << "Press SHIFT and then escape to quit" << std::endl;
	std::cout << "-----------------------------------------------" << std::endl;
	HitCombo QuitApplication, ComboHit, WouterCombo;
	QuitApplication << KeyHit(VK_SHIFT, 250) << KeyHit(VK_ESCAPE, 250);
	ComboHit		<< KeyHit('A', 250) << KeyHit('S', 250) << KeyHit('D', 250)
					<< KeyHit('F', 250);
	WouterCombo		<< KeyHit('W', 250) << KeyHit('O', 250) << KeyHit('U', 250)
					<< KeyHit('T', 250) << KeyHit('E', 250) << KeyHit('R', 250);

	DWORD lastTime = timeGetTime();
	DWORD curTime = lastTime;
	DWORD difference = 0;

	while(true)
	{
		curTime = timeGetTime();
		difference = curTime - lastTime;
		lastTime = curTime;
		if(ComboHit)
		{
			std::cout << "You did a combo hit!!" << std::endl;
			WouterCombo.Cancel();
			QuitApplication.Cancel();
		}
		if(WouterCombo)
		{
			std::cout << "You wrote 'Wouter', good for you!" << std::endl;
			ComboHit.Cancel();
			QuitApplication.Cancel();
		}
		if(QuitApplication)
		{
			std::cout << "You quit the application!" << std::endl;
			ComboHit.Cancel();
			WouterCombo.Cancel();
			break;
		}
		ComboHit.Update(difference);
		QuitApplication.Update(difference);
		WouterCombo.Update(difference);
	}

	return 0;
}

void HitCombo::Cancel() {
	m_SequenceIndex = 0;
}

// Implementation
HitCombo& HitCombo::operator <<(const KeyHit &hit) {
	m_Keys.push_back(hit);
	return *this;
}

HitCombo::operator bool() {
	return m_SequenceIndex == m_Keys.size();
}
void HitCombo::Update(DWORD ms)
{
	if(m_SequenceIndex < m_Keys.size())
	{
		KeyHit& hit = m_Keys[m_SequenceIndex];
		hit.m_Waiting += ms;
		if(GetAsyncKeyState(hit.m_Key) != 0)
		{
			if(hit.m_Waiting < hit.m_Delay)
			{
				hit.m_Waiting = 0;
				m_SequenceIndex++;
#if DEBUGLOG = 1
				std::cout << "you pressed key " << (char)hit.m_Key << std::endl;
#endif
			}else
			{
#if DEBUGLOG = 1
				std::cout << "Delay too long" << std::endl;
#endif
				hit.m_Waiting = 0;
				m_SequenceIndex = 0;
			}
			if(m_SequenceIndex == 0)
			{
				hit.m_Waiting = 0;
			}
		}else if(m_SequenceIndex==0)
		{
			hit.m_Waiting = 0;
		}else
		{
			if(hit.m_Waiting > hit.m_Delay)
			{
				m_SequenceIndex = 0;
				hit.m_Waiting = 0;
#if DEBUGLOG
				std::cout << "Delay too long" << std::endl;
#endif
			}
		}
	}else
	{
		m_SequenceIndex = 0;
		KeyHit& hit = m_Keys[m_SequenceIndex];
		hit.m_Waiting = 0;
	}
}

I don’t know what exactly went wrong (besides the obvious) but I guess that instead of using another library I just have to finish and improve my own math library. It’s a good thing SVN allows me to revert.

A good math library is essential for a game developer. It has to be easy to use and clear but I also want answers on the following questions when I’m using it:

• When I define a quaternion is it written as W-X-Y-Z or as X-Y-Z-W?
• Does a multiplication operator between two matrices do a matrix multiplication or an unit multiplication?
• Also how safe are the functions?
• How do I prevent hidden cost?
• And how easy is it to cast from one to another? Vector3<float> to Vector3<int> might seems obvious but it requires code to support it. And I could also cast Vector3 to Vector2.

Then there are the bigger question about optimization, like do we use SIMD or not.

The biggest problem is of course to ensure that all math is correct. Most of the time I use it by instinct, but in this case I actually have to relearn all the math again, double check, ensure that I’m using the right version, triple check. Obviously I experience it as a pain, but it as they say:

No pain, no gain!

Smart pointers are useful, I use the boost variant often enough, but like everything you shouldn’t fully depend on it. Pointers are in many cases good enough. The only thing why smart pointers are so useful is that you don’t have to worry about the lifetime of the object (when the object is destroyed).

In many cases the only time you worry about is when data needs to be shared, for example a texture, as you don’t want to load the same data twice. But another simple technique is the IUnknown interface which creates an object that will delete itself when it has been released as many times as it was created. You still don’t have to worry about the lifetime of the object, you only have to remind you to call release when you no longer need an object. If nothing requires that object the call to release will cause it to delete itself.

Here is the basic code:

After some thought on the issue I have decided that IUnknown is far superior to a smart pointer. The majority of the smart pointers I have encountered and written work on the same basic principle. Each smart pointer has a pointer to the object and also a pointer to an integer in which you store the amount of copies. That means that if you look at the code it will look something like this:

When you think about how smart_ptr really works, you will think how stupid the idea is. For every copy of the object you will have two extra pointers, assuming 32 bit system, that would be 8 bytes extra for every copy.
The second issue is a bit more hidden but if you have this function:

You will be making an copy of the object, which means that you will have an extra construct and destruct function to take in account. Which means that a smart pointer not only increases the amount of memory needed, but also reduces the speed. With a pointer you won't have the above problems.

There is however one huge advantage that a smart pointer has but IUnknown doesn't: Smart pointers can work with virtually any type while to use IUnknown the object needs to be derived from it. However since I'm writing the code for Nova I can just make sure that all objects derive from IUnknown.

To add an conclusion, I have decided to before using smart pointers I should first try and see if there is another solution.

At my internship I have been developing for the iPhone and boy oh boy, can I make a list of things to complain about. Luckily there are also a few good things and they balance each other but it’s a pain when you cannot unleash every bit of skill you have. Let’s start with the sour part.

1. There is no stencil buffer. I think that the stencil buffer is as old as Duke Nukem 3D, which was released in 1993. It’s used for shadows and a few other things. However for some reason it is not supported on the iPhone (at V2.2.1 but this might change in the future) and it makes no sense.
2. Secondly the iPhone is under clocked (meaning the CPU is running at lower speed than what it should run at). The majority of the hardware these days are able to dynamically set the clock speed of the hardware. I can accept the reason why apple has done it (preserving the battery) but when it comes to games it’s like with racing cars. You don’t want a F1 car being capped at 120 KM/H because you aren’t suppose to go faster than that on the highway. In apple’s defense, the iPhone has never been intended to be primarily a gaming device.
3. Third is apple is really strict in what is allowed or not and some parts of the iPhone (like the photo camera) should only be accessed by calling a function and then except you have no longer control until a picture has been taken using the graphical user interface apple designed. Using it directly in some other fashion increases the chance that the application will be rejected. On the other hand some applications are allowed because some big guys back it (google is one of the companies that ignored the guidelines of apple and still got accepted).

There are still a few other problems (no multitasking for example, API might break with new firmware update) with the iPhone but let’s move on to the sweet part of the iPhone.

Actually the only one I can think of is that the distribution of applications can only be done through the apple app store. There is no such thing for the windows mobile or symbian. This way apple can also guarantee the quality of the applications, however I find it a mood point since an application that is poorly written is unlikely to be successful.

Actually there are a few more things, the emulator is good (better than the one for the Nintendo DS) and the API is reasonable documented (inconsistence in quality, but overall reasonable).