Примеры ошибок

Избегайте статических классов и переменных

Аллен Джексон предостерегает от опасности попадания в «ловушку памяти» при использовании статических классов и приводит пример программы, демонстрирующей альтернативный способ обойти это часто встречающееся программистам препятствие.

Статические переменные подобны глобальным, так как они доступны из большинства классов, но одновременно может существовать только один экземпляр такой переменной. Существует несколько классов, таких как ClassOperatingSystem, ClassGameSound и ClassFileSystem, которые действительно подразумевают наличие единственного экземпляра класса. Некоторые другие классы выглядят так, будто для них тоже должен существовать только один экземпляр, хотя иногда допускается наличие и нескольких экземпляров. Классический пример подобного статического класса - ClassGameWorld:

class ClassGameWorld
{
public:

// статические данные игрового мира
static void* m_GameWorldData;


// статические компоненты-функции
static bool Install(void);
static bool Remove(void);
static bool AddObject(GameObject& _obj);

};

После определения класса программист мог использовать функцию World::AddObject() в любом месте в своих модулях, что удобно, но позволяет работать только с одним игровым миром. Если в дальнейшем замысел игры изменится и потребуется наличие многих игровых миров (например в случае большой сетевой игры), придется кардинально переписывать весь код игры.

Более правильным решением будет создать нестатическую версию класса ClassGameWorld, а затем завести статический шаблон списка игровых миров где-нибудь еще, например в классе ClassGame:

class ClassGame
{
private:

static TemplateList<ClassGameWorld*> m_GameWorldList;

public:

static ClassGameWorld& GetWorld(int _nWorld);

};

Это позволит программе иметь доступ ко многим экземплярам данного класса и в то же время сохранить только одно место для доступа ко всем данным игровых миров.

В главе 3 приведены общие советы Аллена Джексона по разработке игр.

Рагнар Шейерман (Ragnar Scheuermann), Wombat Games

Рагнар Шейерман работал в Origin Systems в качестве инженера-программиста над Ultima: Ascension и Ultima Online. Позднее он оставил Origin, чтобы стать ведущим инженером-программистом, дизайнером и вице-президентом компании Wombat Games.

Рагнар подчеркивает, что его советы в равной степени будут полезны как начинающим игровым программистам, так и новичкам-разработчикам, и сопровождает их примерами из собственного опыта.

Во-первых, убедитесь, что вы знаете игру, над которой собираетесь работать. Так, вы должны четко представлять, каким образом будете в нее играть. При этом ваше знание не должно быть секретом для вашей команды, и, как только вы придете к единому пониманию игры, скажите «стоп!» всем дальнейшим переделкам игровой концепции.

Во-вторых, максимальная отдача и инициатива возможны только в коллективах, влюбленных в свою работу. Если вы только начинаете проект, вам придется использовать все доступные стимулы, чтобы суметь его завершить. Я также обнаружил, что порой самое лучшее в играх - это «дополнения», введенные программистами или дизайнерами не потому, что их обязывает долг, а потому, что им хочется это сделать.

Наконец, если вы новичок, не пытайтесь сразу же прыгнуть выше головы. Не бойтесь пометить некоторые части проекта как необязательные, в первую очередь сосредоточьтесь на основных элементах. Выберите технологию, которая соответствует жанру создаваемой игры. Например, если ваша игра может обойтись без трехмерности (да и вам самому это 3D не нравится), не обращайте внимание на моду, другие вам не указ.