А чо - возьмем, к примеру, винду - 4-й сервис пак, как правило, работает намного лучше первого релиза. Как там работают обновления - понятия не имею, но объем дистрибютива ненамного больше объема релиза, никак не пропорционально количеству обновлений. Значит, даже в таком большой проекте можно менять код.
той игры не нашел, за то по первой стрке результатов в яндексе по запросу "скачать скрипт браузерной игры" нашел слитый откуда-то дамп похожей игры - http://shotsoft.ru/load/dizaj_i_grafika ... 72-1-0-112 Это PHP4, совметимый с третим - никаких объектов, только функции. Метод пректирования - самый популярный в то время - встраивание PHP в HTML. Я тоже полтора года назад писал игру за деньги (только деньги раньше середины написания кончились . Сейчас то можно писать просто чудесный код PHP: <?php $fight = fight::object($_GET['fid']); if ($fight -> status() !== 'go') { throw new Exception('fight->module: эта заявка не стартовала: '.$_GET['fid']); } $player = $fight -> player($personage -> uid); $emeny = $fight -> player($_POST['emeny']); // Ставим, что защищать $player -> set_protect($_POST['pr']); // Генерация удара if (!$emeny -> blocked) { $blow = $player -> give_blow($_POST['to'], $_POST['position']); $result = $emeny -> get_blow($blow); $fight -> game_over($emeny); } // Сохранение состояния $fight -> save($_POST['emeny'], $emeny); $fight -> save($personage -> uid, $player); объекты противников хранятся в мемкэше, ошибки можно обрабатывать исключениями. Тут, например, дуэль - когда от него получена информация (о защите и ударе), первая записывается в его объект (тут - player) и учитывается при следующем ходе противника, а по второй генерируется объект удара. Еще методом get_blow enemy'у ставится статус blocked (пока этот статус стоит, на него нельзя нападать). Blocked снимается в методе give_blow. game_over проверяет, соблюдены ли условия для входа игрока из игры с поражением. Конечно же, классы player и enemy зеркальны - когда твой противник ходит, то он - player, а твой персонаж - enemy. Я тогда не знал про такие паттерны, как MVC и Singleton, и все равно благодоря ООП получилось спроектировать игру намного лучше тех монстров )))
В том, как себе видит костыли автор доклада, я определнно вижу рациональное зерно. При выборе конфигурации команды разработчиков следует исходить из масштабности проекта, имеющихся инвестиций, сроков. Если со вторым или третьим все плохо, то тут естественно, не до перфекционизма. Но и откровенное Г не стоит нанимать, ибо проект рискует превратиться в один сплошной костыль. Все должно быть сбалансировано. В целом с мыслью я согласен - перфекционизм дорог и почти всегда неоправдан. ЗЫ отсюда совсем не следует, что сам не перфекционист
[vs] да уж, красивее, интересно как исходники попали в сеть... кто то украл или просто игру переписали, а старое выложили?