Програмирование игр

[ser_13]

Меня интересует вопрос. Где можно "достать" полный разбор игровой програмы.
Взять программу и разобрать ее. У иеня ума не хватает.

Меня интересует игра WDW-не помню. Немогу найти. Возможно неверное наз.
Там под управлением играющего бежит чел. снизу экрана вверх, экраны меняются.
Бегает много людей и стреляют, пули летят не быстро. Есть экраны, с ямами в
которых седят люди с орудиями типа базука. На некоторых экранах по реке ездит
лодка, на некоторых экранах показана железная дорога.

[Advertiser]

[null_device]

ser_13, для понимания принципов написания игр, есть две замечательные книжки: "Как написать игру (на бейсике)" и "Как написать игру на ассемблере". Сразу, "с места - в карьер" даже на основе готовой игры, понять что-то слабо получится.

[Eltaron]

игра WDW

Это наверна Who Dares Wins 2, она всегда на кассетах WDW называлась.
http://www.worldofspectrum.org/infos...cgi?id=0005673

[jerri]

Меня интересует вопрос. Где можно "достать" полный разбор игровой програмы.
Взять программу и разобрать ее. У иеня ума не хватает.

Самое лучшее что существует на сегодняшний день по программированию игр на спектруме
http://zxpress.ru/book_articles.php?id=163
http://zxpress.ru/book_articles.php?id=175
http://zxpress.ru/book_articles.php?id=201
http://zxpress.ru/book_articles.php?id=212

[ser_13]

Who Dares Wins 2. Спасибо она. Написать хотя бы один экран.

это почти все читал.

Пытался писать Sex Crime на blitz3d все получилось, только не знаю как полицейского заставить ходить, ловить?
Самое гл. писать алгоритм это мне не получается

[ser_13]

Who Dares Wins 2. Экраны можно нарисовать, а вот дальше?
В книгах не написано как увязать все в единое целое и чтобы работало.

[jerri]

ser_13, ты ссылочки то почитай.

[Andrew771]

Почитал ссылочки от Jerri, одно место не понравилось от Стива Тернера:

Вот примерный список приемов плохого стиля:
...
3. Неправильное использование процедур.

Каждая процедура должна иметь один вход и один выход. Если Вам их нужно больше, то вернитесь на этап 2 и повторите проектирование.

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

Если бы была команда CALL (HL), то я неукоснительно соблюдал бы это правило. А так, как еще можно сделать вызов процедур по адресам, заданным в памяти блоками DEFW? Только подстановкой адреса непосредственно в машинный код после кода команды CALL? Это еще больше запутает код.
Также, иногда бывает нужно войти в середину процедуры, а не в начало, чтобы не писать второй абсолютно одинаковый кусок процедуры.
И один выход RET из процедуры - тоже жестокость. А как же выходы по условиям RET Z, RET C и прочее, если надо в середине процедуры?

[jerri]

Если бы была команда CALL (HL), то я неукоснительно соблюдал бы это правило. А так, как еще можно сделать вызов процедур по адресам, заданным в памяти блоками DEFW? Только подстановкой адреса непосредственно в машинный код после кода команды CALL? Это еще больше запутает код.
Также, иногда бывает нужно войти в середину процедуры, а не в начало, чтобы не писать второй абсолютно одинаковый кусок процедуры.
И один выход RET из процедуры - тоже жестокость. А как же выходы по условиям RET Z, RET C и прочее, если надо в середине процедуры?

скачай исходники любого из известных
Joffa, Медноногова, Тернера опять же и посмотри внимательно

Если написано так как советует Тернер то тебе будет все понятно.
Если написано так как пишу я, то ты ничего не поймешь.

ftp://ftp.worldofspectrum.org/pub/si...SourceCode.zip

[Hacker VBI]

Andrew771, ты говоришь о "kernel", там используется такой подход.
kernel нужен для блока вызовов стандартных процедур, в частности используется для работы плагинов и для совместной с кем-то разработки. и приносит совсем другой подход: во первых : стандартное положение адресов в памяти, стандартные для всех флаги, стандартный выход, обработки и т.д. это больше подходит для каскадной модели разработки, а там сначала идёт плотная аналитическая работа, что для нас не всегда приемлемо
Тёрнер даёт общие рекомендации для разработчиков - это упрощает кодирование, что облегчает разработку больших программ.
если в разных местах у тебя будут использованы разные техники - это может быть хорошо для небольших программ. в больших программах, которые долго пишутся, главная сложность держать всё в голове. поэтому лучше придерживаться одинакового подхода к кодированию везде.
сюда входит так-же стандартное по какому-то принципу наименование меток.

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