Отчет для конкурса.

Подходит к концу август-месяц. Как-то произошло это внезапно и быстро. Что сделано? Похвастаться пока нечем. По сути - научился вырывать контент из флеш-приложений. Соответственно, занялся прикруткой этого самого контента к игровому проекту. Не будем здесь упоминать незаконность таких действий. Для меня - это опыт черновой сборки проекта с чужим артом. Для игры - это более опрятный и узнаваемый внешний вид. Если же посмотреть на количество загрузок конкурсных работ из раздела "файлы" сайта glscene.ru, то максимальное их число отдельной конкурсной работы не превышает 30тыс. По сравнению с миллионными gameplay'ями исходный флеш-игры, это просто ничтожно мало! Так что, надеюсь, никто не обидится за "вырывание" контента.

Вступление закончено. Теперь по сути. Прикрутил скрипты, начал описывать базовые классы. Стартовал с самого вкусного: основных объектов и апгрейдов для них. Как начал так и застрял. Это дело оказалось немного непривычнее, чем я думал. Делать программы, архитектуру которых ты никогда не продумывал и не реализовывал всегда и приятно и сложно одновременно. Все оттого, что при удачах испытываешь приятное чувство, которое раньше не встречалось, так как и дела-то такого не делал. Сложность же заключается в том, что по сути ты ходишь с завязанными глазами по полю с сотнями граблей, аккуратно лежащих в округе. Какие вопросы возникают тут же? Сейчас распишу...

• Неясно, куда запихивать систему апгрейдов: выделить контроллер, который будет тягать скрипты для нахождения возможных апгрейдов из данного состояния объекта? Либо хранить заранее всевозможные состояния объектов с заполненными параметрами и навигационный список переходов между ними? То есть по сути эти варианты можно расписать так: выполнять внешний скрипт при каждом запросе на возможные апгрейды объекта или же сначала заполнить некую матрицу всевозможных апгрейдов всех объектов и брать значения по необходимости оттуда?
• Хочется безумного единения игровых объектов в их иерархии. То есть, чтобы все объекты наследовались от одного базового TCommonGameObject. Чтобы для пушек был "нормальный" предок вроде TWeaponGameObject и т.д. С одной стороны - ну что здесь сложного? С другой - не хочется полностью повторять функциональность оригинальной игры. Хочется чуть большего разнообразия, чуть большего набора оружия и объектов. Сейчас же продумывать всю структуру и баланс нет времени. А вот подумать над будущей расширяемостью стоит довольно плотно.
• В оригинальной игре есть связи между объектами, по которым проходит электричество, питающее, собственно, эти самые объекты. То есть, для выстрелов нужна энергия, для добычи минералов - тоже, для запуска ракеты и всего остального. Встает вопрос - как хранить эти самые связи? Что под собой подразумевает эта связь? Какие параметры должна хранить связь и т.д. Также важно понять, что по этому списку связей нужно строить пути до ближайшей солнечной станции, по которым будет проходить электроэнергия. Как их строить? Из любого узла в любой единожды? Или же для каждого объекта запускать обход в ширину? Как часто это делать и т.д.
• Так встает вопрос отрисовки всего этого дела. Пока тревожат два момента: полноэкранный режим и размер линий при отдалении/приближении камеры. Про полноэкранный режим, думаю, все ясно. Оригинальная игра занимает где-то 700х500 пикселей экрана. Для стратегий не очень удобно держать маленькое окошко с игрой. Лучше, конечно же, иметь возможность развернуть на весь экран. Соответственно, неясно: менять ли разрешение экрана при этом или же как-то оставлять полосы по краям или еще чего с этим делать. Теперь по поводу линий. Наверно, проще их делать спрайтом, растянутым по одной стороне. Тогда при отдалении камеры он будет выглядеть немного ужасным. Тоже не знаю, как лучше с этим бороться. Надо думать))

Вот такие вопросы меня мучают, когда я открываю конкурсный проект. Кстати, остался ровно месяц. Надеюсь успеть, хотя пока прогресс невелик.

Желаю всем удачи!

Сообщения, схожие по тематике: