Лично мне нравится нажимать как можно больше настроек.Причина этого в том, что в какой-то момент я могу захотеть использовать код, написанный для игры, совершенно по-другому.Если исходный код изобилует ссылками на детали реализации, это становится намного сложнее.
Один интересный недостаток подхода к конфигурации возникает, когда вы хотите начать описывать поведение объектов в дополнение к их значениям.Рассмотрим простой пример, где у вас есть кубковый объект, который должен «ловить» шариковые объекты.Вы можете выразить их как:
<object name="ball">
<property key="shape" value="circle"/>
<property key="movable" value="true"/>
<property key="speed" value="10"/>
</object>
<object name="cup">
<property key="shape" value="rectangle"/>
<property key="movable" value="true"/>
<property key="speed" value="6"/>
<property key="catches" value="ball"/>
</object>
Проблема здесь в том, что где-то вам еще нужно определить, что "ловит", что делает внутри вашего кода.Если вы используете интерпретируемый язык, вы можете сделать что-то вроде:
<object name="cup">
<property key="shape" value="rectangle"/>
<property key="movable" value="true"/>
<property key="speed" value="6"/>
<oncollision>
if (collided.getName() == "ball") {
collided.destroy();
points++;
}
</oncollision>
</object>
Теперь вы получили возможность описать, как объект ведет себя , а также то, чем он является .Единственная проблема здесь заключается в том, что если вы не работаете на интерпретируемом языке, вы не можете позволить себе определять код во время выполнения.Это одна из причин, по которой Lua стал настолько популярным в разработке игр.Он хорошо работает как декларативный и процедурный язык, и его легко встроить в скомпилированное приложение.Таким образом, вы можете выразить эту ситуацию как:
object {
name='ball';
movable=true;
speed=10;
}
object {
name='cup';
movable=true;
speed=6;
oncollision=function(collided)
if collided:getName() == "ball" then
collided:destroy();
points++;
end
end;
}