[pokibor]

Значит, так. Я сдавал игру как дипломный проект в институте и потому могу кое-что сказать по этому поводу.

1) Планирование решает всё. Без написания диздока за игру даже не садитесь - до конца не доведёте всё равно. Если вы считаете "накой нам эта писанина, мы и так сами всё представляем", то у вас ничего заведомо не получится. В диздоке должна быть чётко расписана игра. В идеале, конечно, до последнего винтика, но хотя бы основные правила, формулы, интерфейс и так далее. По ходу работы в диздок нужно обязательно вносить все изменения, если такие потребуются по каким-то причинам. Короче, запомните: диздок - это текстовая версия вашей игры. Если нет его, то не будет и игры, ибо вы после первых же шагов запутаетесь что к чему.

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

3) Теперь наступает время программирования. Надеюсь, вы досконально знаете объектно-ориентированное программирование и его приложение в случае используемого языка программирования. В Delphi, насколько я помню (сам, ясное дело, уже давно использую только C++), реализованы практически все возможности ООП, пусть и несколько криво. В общем, по своему опыту могу сказать - без знания всех тонкостей наследования и полиморфизма (т.е. вирутальных функций) за более-менее серьёзную игру лучше не садиться. Намучаетесь. Только объектно-ориентированный подход, применяемый по максимуму. Он позволит потом легко добавлять новые классы (если вы вдруг в один прекрасный момент захотите добавить какого-нибудь особо крутого медведе-скорпиона с возможностью к телепортации), а также грамотно организовать базовые.
Но вообще-то все ваши знания ООП должны вылезать на этапе 2, этап 3 - это тупое программирование заранее продуманой архитектуры и никак иначе.

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

Да, и заранее разберитесь с быстродействием. Вы что собираетест использовать? Надеюсь, не стандартные Delphi'йные классы, а хотя бы DirectDraw? А то ж иначе у вас будет мерцать и тормозить всё... Запомните, игры пишутся "с нуля" либо на специальных библиотеках, либо на основе движков без использования стандартных виндосовских классов (надстройками над которыми являются делфийные). Так что сразу либо определитесь с движком, либо выучите DirectDraw.