Immanuel Scholz

Ich hatte in der Vergangenheit schlechte Erfahrung mit großen State-Machines gemacht. Die Anzahl verschiedener Zustände wächst sehr schnell an. Implizite Zustände sind verdeckte Querabhängigkeiten zwischen verschiedenen Agenten und steigern die Komplexität enorm. Im schlimmsten Fall verdoppelt sich die Anzahl logischer Zustände aller anderen Agenten, wenn ein neuer Zustand in einem Agent hinzukommt.

Polling kostet häufig immense Performance. Strategien um die Performance zu verbessern sind meist kompliziert und schwerfällig (komplexere Datenstrukturen, Caches).

// Pseudocode, not from Nightwatch
void Unit::update()
{
	if (!unit_.touches(enemy_)) // collision polling.
	{
		moveToward(enemy_); // moves one step
		return;
	}
	if (enemy_.isAlive())
	{
		attackEnemy(enemy_); // attack one time
		return;
	}
	moveToward(origPosition_);
}

Polling oder Events?

Die Hoffnungen waren dabei vor allem:

1. Ich kann komplexe Eventsteuerung vermeiden. Die Ablauflogik wirkt nicht übermäßig unnatürlich.
2. Wenn komplexe Zustände in Teilstrategien zerlegt werden, wird die Anzahl der Querbezüge minimiert.

Strategielisten

Eine beendete Strategie wird vom Stack entfernt und im nächsten Tick wird die vorherige Strategie ausgeführt. Strategien können so sehr einfach Unterstrategien "aufrufen", indem sie diese auf den Stack schreiben.

Positiv ist der einfache Wechsel auf Unterstrategien. Durch die Stack-Modelierung wird der mögliche Zustandsübergang von Einheiten start vereinfacht. Viele Sachverhalte waren so einfach abbildbar. Die Logik komplexerer Strategien wie das oben beschriebene "Vorwärts" ist erstaunlich simpel und einfach zu lesen.

void Forward::update(float elapsed)
{
	auto p = nearestEnemy(unit.pos, unit.party);
	if (p.enemy && p.distance < unit.sense
		&& lineOfSight(unit.pos, p.enemy->pos))
	{
		// I see someone. CHARGE!
		unit.addStrategy(new Chase(unit, *p.enemy, true, true));
		return;
	}

	// steer towards the target destination, if completely out of order
	float alpha = Vector::normalize(unit.direction)-direction;
	if (abs(alpha) > 0.25)
	{
		unit.direction -= alpha * elapsed;
		return;
	}

	Vector d = Vector::polar(unit.direction, unit.speed) * elapsed;

	// sometimes, change direction a bit (dizzy walking)
	if (randf() < elapsed*unit.speed)
	{
		if (d.cross(target) > 0)
			d = d.rotate(randf()/4-0.1f); // rotate clockwise
		else
			d = d.rotate(-(randf()/4-0.1f)); // rotate counter-clockwise
	}

	if (!unit.tryMove(d))
		unit.addStrategy(new Pillage(unit, unit.pos + d));
}

Interessant ist auch, dass hier die Substrategien "Charge" und "Pillage" nichts von "Forward" wissen müssen. "Charge" wird beispielsweise auch von Soldaten der Menschen benutzt.

Für das Zerstören von Resourcen erwies sich Eventsteuerung als das simplere Konzept. Wenn z.B. Einheiten sterben, betrifft dies auch Strategien "weiter unten" im Stack von anderen Einheiten. Wird die Einheit gelöscht, werden Referenzen ungültig.

Um das nicht-vorhanden sein von Resourcen durch Polling testen zu können müsste man entweder eine weitere Indirektion einführen (z.B. std::tr1::weak_ptr) oder die Resource wird künstlich am Leben erhalten; die Resource bekommt ein "isDestroyed" flag und wird erst wirklich gelöscht, wenn sie nicht mehr referenziert wird. Die Resource gehört sich damit selber. (Der letzte Ansatz ist sehr typisch in Sprachen wie Java.)

In Nightwatch ist die Existenz von Resourcen streng an ihre Besitzer gebunden. Daher entschloss ich mich, das zerstören von Resourcen über Events zu signalisieren.