Because of all those distractions I have decided that I will take some extra time, relax, smell the roses and stuff and then start again this month. The result is that I will be behind, but that is OK and knowning myself I will most likely catch up at one point.

Image from: http://www.studiohajo.nl/ (license unknown)

For my current project I was conflicted about what to do with the terrain editor. I had two choices, either create a seperate tool or integrate the editor in the game. The first choice always has my preference as a tool and a game have different usage requirements which is reflected in the way they are programmed. The second choice is also a risk in my opinion as you might couple part of your codes that should not be coupled. Decoupling them afterwards is, as many programmers can tastify, a pain.

However the advantage of combining the code is that I don't need to duplicate code or functionality. This is also the reason why I have decided to create the editor in the game. The cool thing however will be I can review the results of my work in realtime.

However before I can start working on terrain editing, I need to write the terrain code, which means that I need to start thinking about the culling acceleration structure and refresh the knowledge about terrains.

So why, if everything is going so well, do I write an blogpost that is titled "scared to code"? Was I not getting more and more optimistic?

That is because soon I will be done with the majority of the architecture and I have to actually write the game code and to be honest there I no complete design document only an feeling that I want others to have when they play the game. The game design is therefor mostly informal which means that without a formal definition I won't be able to measure how far the game is complete. Now I know there are plenty of people who are able to work that way and get incredible results, but I know that unless I have a formal definition I will continue working on the game forever. So either I have to make a formal game design or learn how to cope work with informal game designs. I don't think I can do the first part as good as I used to and I fear what would happen if I choose the second option.

Now don't get me wrong, I have worked in both ways and got results. I do prefer formal game design as they are more predictable and it is easier to know what is inside or outside the scope of the project. The problem in this case however is that I have decided on a hybrid method. The game should be developed until the end of Juli which means that somewhere in August I need to release the game, as this is one of the restrictions I have applied on the project. So what I at least have is an schedule and I'm happy to say that I'm good with scheduling tasks and projects. However I have never made a schedule without having a formal definition of the end result of the product. It's not the way that I usually work and most certainly not the way that I prefer to work.

Writing a decent engine is pretty straight forward, there are some things you need to take in account, but if you have written a few, than writing a new one is more like a warming up then actually trouble. Each game however is a different so there are no warming ups. You might be able to use a few tricks that you have used for other projects and use it here, but overal the code is completely new. Now next to me is a single piece of paper on which I have written the schedule. The schedule is quite decent but at the moment I'm afraid of moving on to the game code.

The strange thing is however that once I start working on the game code, I know that the fear will disappear, but until then I'm scared to death, uhm.. scared to code.

The goal I have set is to create the first version (the so called "gold" version) within 6 months after starting. Meanwhile I'm ten days away of having the first month passing by and frankly not much is ready. I'm also running in a few challenges like how I would need do the terrain and whether I should focus on game-play first and then on the terrain.

This project has a huge experimental factor (I always try to add something knew in attempt to increase either my knowledge or frustration ). In this case the biggest one is to create a commercial game within 6 months using nothing else except my spare time (which turns out to be like 16 hours or so each week). At the same time I'm also running a smaller experiment which is a developer diary. Every day I write a post on a private site in which I explain what I have done, what can be improved and what I should do the next day.

Having to keep track of logs is a nightmare for me but that small experiment is turning out to be quite a life saver. Not only can I look back and see what I was suppose to be working on but it also gives me a form of accountablity, which is important if you want to create similar products.

Anway I hope that next month or so I'm able to report that the gameplay is working.

So I have checked out three engines (well, not Ogre3D, I have used that before and except a few minor (and I do mean minor) things I have no issues with it) and I noticed a few things. Neither NeoAxis and Unity are C++, which is weird since I favor C++ over almost any language, but being brave I decided to check it out.

I can be brief about NeoAxis, it has an incomplete documentation, which wouldn't be so bad if at least the functions were documented or the example code was clear. But instead it is not clear for me nor were the functions documented. Maybe I should put some more time in it, well, I should, but the lack of documentation is a huge turn down for me.

Unity on the other side, I can be quite positive about. It is basically the same as NeoAxis, except with proper documentation. The downside is that it uses C# scripts (among a variety of other formats) which means scripting and I'm not a big fan of that. Ignoring that I had tiny bit of time to check it out, but overall it seems quite decent. Now if only the price of the full version goes down, I might be really tempted.

So after checking out those two engines, the only one that remains is Ogre3D, which by now I believe is my best choice. My forte is C++ (even though I now develop in C#) and although I have no problem trying to do it in another language, I do prefer C++. Preference might not seem like a big deal, but it is for me.

So for now the odds seem to be Ogre3D (oh yes, it is also only one free). But I might experiment with unity some more before I make a final decision.

Anyway, I have been working on a new game design which slowly starts getting form. I'm actually surprised that is taking so long, but that is because I want to have certain core mechanic in the game (oh yeah, it's going to be released as a commercial game) and to implement that core mechanic is a pain when I take in account what I'm working with.

I can't go in much detail, simply because not everything is fixed and almost anything is subject to change, but one of the weirdest choices that I have made is the inclusion of zombies. And frankly I never ever cared about zombies. Zombies are slow moving, dumb and one of the undeads that should be easy to kill. I know that in some fiction zombies are fast, but I could never buy that. Why would a zombie suddenly be faster after it dies? Why do they suddenly have super human strength?

No for all I care zombies remain slow, dumb and easy to kill.

The reason why I start liking the zombie theme is because of the comic: The Walking Dead, which has quite a realistic view on a zombie apocalypse. Of course Shaun of the Dead, a comedy which is also nice horror movie, is a favorite of mine. The rest not. Left 4 Dead contains an example of zombies which I think are not zombies, although it is cited in the manual that the game doesn't contain "traditional dead zombies" but infected humans.

Anyway if you take a look at my research material (if you can call it that), it's obvious that I'm interested in the horror survival genre and I will try to tell more about it once I have more to talk about

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 [cci_cpp]sizeof(double)[/cci_cpp] 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.

[cc_text]
Sun has a size of 100
Sun is 2048 units away
Sun needs to be rendered.

To render it but maintain the correct look:
Scale sun down so that at 1024 it would have the same
size on screen as if it was rendered at 2048.
[/cc_text]

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;
	}
}