понедельник, 27 августа 2012 г.

Теория и практика создания игр (часть 4)

Продолжим рассмотрение этапов создания игры:

6. Программирование игровой логики (бета-версия).
7. Создание и подгонка уровней для игры.
8. Оптимизация программного кода игры.


6. Программирование игровой логики (бета-версия).
Допустим у нас уже есть хотя бы один игровой уровень определенного формата (желательно формат не менять на протяжении всей разработки, а продумать его сразу). Теперь нам нужно написать само ядро игры (движок), которое будет работать обрабатывать все элементы игры: логику, прорисовку, звуки и т.д.
Сейчас я вам приведу пример структуры ядра моей игры Gravity Booster:
1) Установка параметров системы (разрешение экрана, скорость обновления игры, загрузка CPU, параметры очистки экрана, параметры связанные с качеством физики в игре).
2) Загрузка всех медиафайлов игры (картинки, музыка, звуки и возможно уровни).
Если файлов очень много, то лучше всего этот процесс автоматизировать. Вот пример кода на App Game Kit (это моя основная среда разработки):

for i=1 to 100
    mediafile$="image/objects/"+str(i)+".png"
    if GetFileExists(mediafile$)=1
        LoadImage(i,mediafile$)
    endif
next i

Этот код можно еще упростить, если убрать проверку на существования файла.
Вот собственно и сама среда разработки (AGK):

3) Создание основного цикла игры. Он будет выглядеть примерно так:
   а) проверка на прикосновение к экрану;
   б) обработка меню;
   в) загрузка и выгрузка уровней;
   г) сохранение настроек и игрового прогресса;
   д) обработка геймплея (проверка на выигрыш и проигрыш);

Желательно писать основной цикл не сплошным кодом, а разбить его на отдельные процедуры. Пример основного цикла с Gravity Booster `a:


DO
nowtime=GetSeconds()

TouchX=Round(GetPointerX())
TouchY=Round(GetPointerY())

gosub _touch    // процедура проверки прикосновений к экрану
gosub _check_menu   //  основная процедура игры которая управляет остальными процедурами

if GetRawKeyState(27)=1 then exit
if stop_game=1 then exit
 Sync()
LOOP

Хотя основной цикл игры очень маленький, но за процедурой gosub _check_menu  скрываются около 1000 строк программного кода. В свою очередь эта процедура разбита еще на 10 меньших процедур.


4) Тестирование кода (бета-версии) игры. Исправление явных ошибок в коде (частые вылеты с игры, зависания). Если вы писали исходный код очень аккуратно, то вам может и не понадобится исправлять ошибки, но тестировать игру нужно по любому (чем чаще - тем лучше).



 7. Создание и подгонка уровней для игры.
Я делал Gravity Booster `a для разрешения экрана телефона  960х640 (чем больше разрешение тем четче будет изображение на экране), но оказалось что мой телефон не может загрузить много изображений в таком разрешении (родное разрешение экрана моего Андроид  телефона 480х320). Поэтому мне пришлось переделывать свой редактор и создавать уровни заново под разрешение 480х320. Если бы я делал это в блокноте, возможно я бы никогда не доделал игру:) 
Создание уровней это процесс творческий и здесь посоветовать мало что можно, но есть несколько рекомендаций: 
1) делайте уровни по принципу от простых к сложным, 
2) постарайтесь (но не в ущерб производительности) добавить красочные декорации, 
3) уровни должны быть уникальны и по своему запоминающимися,   
4) старайтесь размещать динамические объекты так, чтобы они не пересекались.
5) по мере прохождения добавляйте новые элементы в игру (чтобы геймплей не надоедал).

8. Оптимизация программного кода игры.
После создания всех уровней, попробуйте пройти их все в своей игре (по несколько раз). Иногда баги выплывают именно во время прохождения уровней. Если у ваших родных или близких есть Андроид устройства, то попросите их стать вашими тестерами игры (чем больше людей протестирует вашу игру тем большей будет ваша уверенность в ее стабильности). Иногда во время тестирования уровней может оказаться, что некоторые из них очень "тормозят". Причиной может быть два фактора: 
1) количество объектов на экране, 
2) код не оптимизирован или использует много "медленных" команд.
С первой причиной можно разобраться очень быстро, а вот решение второй может занять много времени. Особенно если нельзя упростить код или убрать команды, которые потребляют много ресурсов. Поэтому мой вам совет: постарайтесь еще на первом этапе создания игры продумать возможные программные реализации вашей игры. Также постарайтесь делать код максимально "легким", чтобы за один такт выполнялось как можно меньше строк кода. Более  детально об оптимизации программного кода я буду писать в моих следующих сообщениях.

Вот так, например, выглядит проверка на прикосновение динамического объекта ко льду в моей игре (я думаю оптимизировать эту часть уже больше некуда:)   



Комментариев нет:

Отправить комментарий