пошаговая стратерия

[korand]

Сейчас вынашиваю идею создания пошаговой стратегии похожей на шахматы, но никак не могу понять каким языком программирования пользоваться.
В прошлом году сделал основу под игру на Delphi с использованием формы как инструмента, но сейчас как-то не улыбается делать 300 элементов формы. К сожалению, я еще не имею опыта рисования в самой игре (а не присваивания image картинки из файла), но хочется попробовать.
Сейчас есть опыт программирования на Pascal, VBA, Delphi.
Серьезный вопрос- есть ли смысл переучиваться на С++, Java или мои запросы можно удовлетворить в Delphi?
Можете подсказать гайд/тему на форуме как делать игры "красивыми", то есть рисовать их, а не делать набор кнопок и картинок в окне windows?

Заранее спасибо
п.с. надеюсь, что не нарушил правил раздел, так как не нашел их =(

[Пепел Феникса]

можно и на Делфи.
главное желание.

[phomm]

Во-первых, прочитав твои сообщения ранее на форуме, сложилось впечатление, что програмировать на дельфи у тебя ещё получается не очень... (хотя прошло 9,5 мес, мб и поменялось сие) . Тебе не хватает простейших умений: как-то создавать дерево проектов (т.н. решение, project group, solution и т.п.), где будет несколько взаимосязанных модулей игросистемы для всех приложений, и отдельных модулей форм приложений , как минимум, тебе понадобится основное приложение и редактор карт, у которых , как минимум, один общий модуль - читалка-сохранялка твоего формата карт/сейвов, дублирование кода ник чему хорошему не приведет, лучше сразу делать единые для всей стратегии модули (формы, конечно отдельно). НО это конечно не проблема, можешь всё слепить пока что, но потом разделять умучаешься.

Второе, учись юзать справку и не гнушайся английского языка, юзай словарь и переводчики, если что.. но вникай в английский текст.

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

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

Пятое. Я по себе знаю, каково это писать достаточно большие для новичка проекты - более 1000 строк. Надо иметь план, причем, чем детальнее, тем лучше. Тут, как минимум, нужна структура игры. пример - меню, игровое поле и панель действий. В меню понятно что, на поле отрисовка и обработка щелчков и т.п. , а на панели действий - всё то, что представляет игровой процесс. Ну а главное, это то, что скрыто, это полная обработка геймстейта, игрового состояния, а именно, хранение всех данных и обработка их по заданным правилам игры. Вот это уже какая-то система, а дальше развивай и реализуй конкретику.

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

Но в любом случае, идущий да осилит дорогу ! главное делать и стремиться к результату, ведь опыт уже результат и его тоже надо копить и развивать !

П.с. спрашивай, коли что понадобится, но помни подпись Пепла Феникса

[korand]

Огромное спасибо phomm за большой и подробный ответ.

Еще в 9м классе я сделал ходилку по карте в Pascal-e с местностями итд
Почти год назад решил повторить это на Delphi, но при этом все осталось примитивно- карта=массив, армия=массив(правда 4х-мерный), поле боя=набор элементов формы. Все заглохло, когда я понял банальность самой механики игры.
Теперь у меня есть идея игры и желание сделать все не так примитивно и использовать возможности Delphi сильнее.

Теперь по пунктам:
1)спасибо, что перечислили эти умения, так как не зная о существовании project group не могу её использовать. Теперь сделаю research и пойму. Есть где-то хороший пример использования этого или просто гугл в помощь?
2)английского языка не боюсь, словарик врядли нужен вообще =)
3)что такое ООП?
4)я посмотрю что это и выбиру оптимальный вариант
5)план есть, а предыдущая прога была довольно "толстая", так что боязни нет
6)время тянется и находится когда есть желание

п.с. здесь советы за деньги? ^^

[Пепел Феникса]

3)что такое ООП?

Объектно Ориентированное Программирование.

[korand]

Сообщение от Пепел Феникса

Объектно Ориентированное Программирование.

Спасибо, уже начал читать =)

Не хотел бы "троллить", но есть ли смысл писать подробно вопросы и кого-то конкретного мучать или никто походу работы помогать не сможет?

Просто я как-то не вижу зачем и где мне использовать создание модулей и классов, но хочется узнать. Для этого я могу более-менее подробно из чего должна состоять игра, но для этого нужно, чтобы кто-то был готов помочь-сказать- "вот для упрощения этого создаешь класс", а то я могу по старинке писать неоптимизированное не-поймешь-что.

Отдельная история- как собственно получать приложение-игру, а не файл для Делфи (нужно что-то специально в программе делать или потом просто конвертировать)

[phomm]

Советы здесь не за деньги, я намекал на часть подписи, глясящую "Хорошо поставленный вопрос это уже половина ответа", а не "Халяву не поощряю!"

В целом, как я понимаю, твои сомнения сводятся к тому, как тебе писать программу, не что именно там писать, а именно как. Исходя из твоих слов, я заключаю, что у тебя до этого всё было в одном единственном модуле, и ты планируешь делать всё на одной единственной форме. Так вот, скажу честно, я когда начинал писать, то тоже всё делал воедино, но достаточно быстро понял, что это неправильно. И ООП и модульность это важнейшие принципы программирования на дельфи, в которых изложена мысль того, что абстрагирование и распредлеление задач - естественное исполнение универсальной, грамотной программы. Без этого твоя мегафункция чего-либо будет очень зависимой и сложновоспринимаемой и сложной в отладке. Разделение на функции, модули, классы, а также введение смысловых переменных и констант - это правильно, а правильно потому, что самому потом на следующих этапах разработки будет легче и продуктивнее, ибо сосредоточишься на развитии, а не модификациях предыдущей работы.

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

Это просто в твоем случае удобнее, вместо кучи несвязанных процедур/функций и наборов данных и массивов записей, иметь четкие классы, хранящие жестко описаные данные и следящие за выполнением всех правил и условий посредством методов класса.

Мучать можно хоть кого... если захотят связываться, ответят, нет - так нет.

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

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

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

[korand]

Разделение на классы, модули итд- это удобно и полезно, но имея опыт довольно тупого программирования я до сих пор не понимаю как это огранизовать. Давайте обсудим простейшую ситуацию как рекламе "до и после".

При выделении юнита(дружественного) показывается клетки возможного передвижения, после клика по какой-то юнит перемещается.

В моей старой игре: (1) клик по форме => (2) определение клетки поля по координатам клика (ф-я) => (3) проверка "наш ли юнит" путем просмотра значения в массиве "карта" в точке поля => (4) если наш, то идет выделение (визуальное) доступного движения на основе мобильности юнита из массива армии типа armyA[1,2,2,3] => (5) новый клик, его обработка, проверка доступности по мобильности+пустота клетки=> (6) юнит меняет координаты в массиве армии+меняется массив "карта"

Мне хочется узнать как это оптимизируется с помощью ООП и выглядит после шага 1 или 2. Для меня критично понять как будет задан класс (что в нем хранится- характеристики, особенности или что), так как всех юнитов я собираюсь разделить на классы в игре, которым свойственны стандартные особенности, которые почти не зависят от умений итд. Я могу реализовать это в своей простой программе, но уже не хочу писать неумно.

[Андрей 93]

Класс должен содержать в себе все данные о персонаже: координаты, род войск, здоровье, принадлежность к той или иной стороне конфликта и т.д.

Но не обязательно использовать классы. Я предпочитаю записи. Они по сути являются предком классов.
Приведу пример использования записи в своей игре (облака, которые появляются в определённой точке, потом пролетают над картой и удаляются):

type PCloud = ^TCloud; // PCloud - это указатель на запись облака (как бы ссылка). Указатель мне нужен потому что я храню облака в "списке". 
     TCloud = record     //а это сама запись облака
      p,v:cpVect;          //позиция и скорость - векторы (две координаты типа single)
      tex:integer;        //номер текстуры для облака (все текстуры хранятся в отдельном модуле в массиве под своими номерами)
      prev,next:PCloud; //Указатели на предыдущее и следующее облака (для реализации "списка"). Именно указатели!
     end;

А собственно сам модуль во вложении.
Можно писать код иначе, например, с использованием классов. Я подражаю программистам, создавшим/портировавшим физический движок chipmunk на delphi. Ведь именно с ним я начал создание игры. Прошло много времени, пока весь смысл кода уложился в моей голове, но зато теперь я могу похвастаться своими умениями.

[phomm]

Всё просто.

с одной стороны:
Имем структуру игры в виде 2 массивов (абстрагируемся от всего остального) - карта, двумерный массив записей (запись - клетка, в которой хранится номер игрока и номер его юнита, ну и параметры типа проходимости) и массив воинов, двумерный, количество_игроков*количество_юнито в, из записей типа воин (всякие параметры, 2 координаты) и вагона, большого вагона процедур и функций, как минимум :
1. выбрать юнита на карте (для отрисовки доступности клеток и подсветки), чтобы игра знала его (допустим записали в переменную)
2. отрисовать текущего воина (для этого сохраняли в переменную), и рисуем его обводку или "ауру выбранности" -кружочек или ещё что, при этом в функцию передается либо номер юнита, либо сама запись юнита, получаем либо обращение к массиву юнитов, либо непосредственное оперирование с записью юнита. СПОСОБ отрисовки зависит от ещё каких-то параметров (картинку летящего, например, надо поднять в воздух), и эти параметры надо опять где-то брать, либо хранить в записи воина, либо передавать в функцию отрисовки.
3. проверка доступных клеток. Для загона в функцию нахождения пути, или проверки длоступности клеток надо передать либо номер либо саму запись юнита, ведь допустим летящий пролетит над домом, а ходячий - не пройдёт. Также надо передать что ? правильно, параметры клеток. либо сами записи о клетках, либо их координаты, либо вообще всю карту/список путей (в случае алгоритма нахождения пути, но там отдельные заморочки, лучше пока это даже не брать, у нас тупо пошаговая игра с перемещением поклеточно )))).
4. отрисовка доступных клеток. Передаем координаты клеток которые надо отрисовать. клетки - записи, сами знают если на них что-то стоит и вызывают отрисовку этого (опять же передавая параметры тем функуциям отрисовки)

это мы только выделили юнита

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

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

вот теперь вроде шагнули, вроде ничего не забыл. отметь сколько загруженных аргументами процедур мы имеем.


из-за невозможности оправить более 5000-символьный текст нарезаю на 2 куска