Редактор логики. Логические блоки.

При маштабировании, все дисплейные объекты увеличиваются переменной Zoom. При сохранении разности положений между, объектами и курсором, мы сам курсор
пропорционально зуму - уменьшаем. И при перемещении объектов, курсор тоже уменьшен. Затем увеличенные дисплейные объекты, мы смещаем относительно смещения мира. Которое происходит с помощью зажатой средней кнопки мышки.

Правильное маштабирование.
  Перемещение и маштабирование мира работало нормально, но маштабитрование происходило отностительно начала мира. Мир хоть и можно было смещать, но маштаб происходил всё равно относительно начала мира, даже НЕ отностительно правого верхнего угла дисплея, а мира. Нужна была точка на дисплее относительно которой нужно маштабировать мир. Маштаб и так происходил, но смещение мира при маштабировании не было.

Смещение мира при маштабе происходит так:
  1. Выбираем точку на дисплее, относительно которой будет маштаб. Это средина дисплея.
  2. Узнаём смещение мира относительно центра вьювера
    ScriptEditor.zWorldPosX := ScriptEditor.WorldPosX - Form1.GLSceneViewer1.Width/2;
    ScriptEditor.zWorldPosY := ScriptEditor.WorldPosY - Form1.GLSceneViewer1.Height/2;
  3. Вычисляем скорость (маштабирования смещения)
    ScriptEditor.WorldZoom := ScriptEditor.Zoom / 1;
Дело сдесь в том, что скорость маштабирования разная. И растояние от нуля до текущего зума, не всегда равняется единице, а всегда больше или меньше. А при вычислении правильного положения мира:
   ScriptEditor.WorldPosX := Form1.GLSceneViewer1.Width/2  + ScriptEditor.zWorldPosX * ZoomIndex;
   ScriptEditor.WorldPosY := Form1.GLSceneViewer1.Height/2 + ScriptEditor.zWorldPosY * ZoomIndex;
в котором ZoomIndex должен быть максимум единицей ПРИ ОБНОВЛЕНИИ СМЕЩЕНИЯ МИРА ВРУЧНУЮ. Значит нужно сравнить пропорциональность маштабов, что мы и сделали:
   ScriptEditor.WorldZoom := ScriptEditor.Zoom / 1;
Теперь зная с каким ускорением будет увеличиваться мир, мы вычисляем ZoomIndex
  ZoomIndex := ScriptEditor.Zoom / ScriptEditor.WorldZoom;
Тоесть мир увеличивается и смещается с одной скоростью, хотя увеличение и смещение определяются разными методами. Здесь я расматривал метод смещения мира. Так как с маштабом всё и так было в порядке.


Теперь о логическом блоке.
Логический блок это объект который состоит из:
  1. Заголовок
  2. Тело, в которм хранятся контакты ввода и вывода информации

Контакт ввода и вывода это объекты имеющие название, активность и принадлежность к логическому блоку. Алгоритм рисования блока, генерируется в визуализаторе. Тоесть по базовым данным визуализатор строит блок:
 1.Определяемся с шириной всего блока. В этом помогла одна замечательная сценовская функция
  vNameWidth := ScriptEditor.HUDText.BitmapFont.CalcStringWidth(vName);
  Хоть она хоть и возвращает Integer, что мне непонятно почему не Single, но она даёт ширину текста.
  Потом узнаём размер самого длинного имени Ввода и Вывода.
  // - Финальная Ширена блока
  if (vNameWidth > (vNameInputWidth + vNameOutputWidth)) then
    vWidth := 10 + vNameWidth
  else
    vWidth := 10 + vNameInputWidth + 10 + vNameOutputWidth;

  2. Устанавливаем высоту заголовка
  vHeightTitleBar := 20;

  3. Рисуем текст - название заголовка блока
  4. Нужно нарисовать рамку. Рамка это довольно не простая вещь в визуализации. Потому что у меня реализовано увеличение и уменьшение маштаба. Поэтому более широкий спрайт нарисованный споднизу основного спрайта, может подойти только при увеличении картинки. Но при уменьшении, когда размер рамки один пиксель, то на дисплее эта рамка рисуется через раз, потому что её перекрывает верхний главный спрайт. Поэтому для уменьшенной картинки я использую линии.
  Рисую их средствами OpenGL. Это LoopLine.
  Рамка (при увеличении) - спрайт
  Рамка (при уменьшении) - линия

  5. Нужно определиться с высотой тела блока. Для этого сравниваем количество вводов и выводов в блоке, и устанавливаем то что больше.
  6. Визуализация рамки при увеличении и спрайта тела.
  7. Рисуем названия вводов. Это цикл в котором считывается названия с вводов и ХУДТекстом визуализируется со смешением по высоте.
  Каждый шаг это 20 пикселей.
  8. Такой же подход и к визуализиции выводов.

Добавление вводов и выводов ничего нового в код не добавило, кроме подстраховочных обнулений выделеностей всех объектов которые можно выделить. Невозможно выделить одновременно несколько контактов. Это важное правило для соединения.

В основном всё работает по приципам заложеным в фундамент.

Редактор логики. Самое начало.

  Редактор логики  это инструмент создания и редактирования логических схем, которые применяются в программировании везде. Логические схемы обычно пишутся вручную, если это не очень сложная, но при создании игр, а я столкнулся с этой проблемой именно при в игрострое, логические схемы бывают очень путанные.
  О чём я говорю? Это может быть всё что угодно, но меня прежде всего интересует функционал персонажа. Его сложные логические, древовидные структуры, у которых проихсходит переплетение ветвей, просто не реально создавать вслепую. А именно так я и создавал всё, поэтому то в этом и проблема. Нет инструмента которым можно было бы эти ветви создавать и САМОЕ ГЛАВНОЕ видеть эту схему. Ведь основная проблема в том, что не получается предусмотреть все возможные ошибки, когда не видишь схемы. Такую схему просто не реально держать в голове. Поэтому я начал писать редактор логики.
  На данный момент готова базовая работа с условными объектами. Я их назвал "дисплейные объекты"
  // - Перемещение дисплейного объекта.
  Перемещение дисплейного объекта происходит с позволения его свойства Moving.
Для нормального перемещения объекта, ему нужно закрепиться за курсором.
Объект всегда смещён относительно курсора, особенно это касается выделенных объектов,
когда курсор наведён не на них.
Поэтому в процедуре нажатия клавиш мышки, всегда сохраняем разность всех дис.объектов
относительно курсора. Это свойство (rPositionX, rPositionY).

  // - Каким методом мы добиваемся включения Moving?
  Первый метод - это прямое наведение курсора на дисплейный объект. Выделен только
Один объект (Selected).
  Второй метод - это выделение нескольких объектов, тот же (Selected).
  Третий метод - комбинированное выделение, это значит, что при зажатой кнопки TAB,
объекты не теряют свой выделености. При комбинированнном выделении, важном параметром является
(Selected) и (Moving). Все (Selected) объекты становятся (Moving) только при нажатии ЛКМ.
Тоесть в случае повторного выделения объекта вторым способом, но с зажатой клавишей TAB,
при обнулении выделености, мы сможем отличить Ранее выделенный объект от толькочто выделенного.
А значит сможем адекватно обнулиться.

  // - Все выделенные объекты сохраняют свою выделенность в двух случаях:
  1. Если мы выбрали один или несколько объектов и нажимаем ЛКМ только на них.
Тоесть в пустоту нажимать нельзя.
  2. Если мы зажали кнопку TAB, то мы можем нажимать сколько угодно и куда угодно ЛКМ.
Выделенность не потеряется, но перемещать объекты мы не сможем. Поэтому выделив объекты используя
первый или второй способ, нужно пользоватся первым способом сохранения выделености,
а значит - навести курсор на уже выделеные объекты и тащить их.

  // - Потерять выделенность можно несколькими способами:
  1. навести курсор на не выделеный объект и нажать ЛКМ,
выделеность всех остальных объектов пропадёт.               - "Не выбраный объект"
  2. навести курсор на выделеный объект и нажать ЛКМ.       - "Повторное нажатие"
  3. не навести курсор ни на один из объектов и нажать ЛКМ. - "Пустота"
  4. делать первый и второй способ без зажатой клавиши TAB. - "Не комбинированное выделение"


//----------------------------------------------------------------------------//
  Существует массив Дисплейных объектов и шаги.
  Шаг это запись которая имеет массив образов. Количество объектов в массиве, равно количеству
Дисплейных объектов при сохранении шага. Тоесть в разных шагах хранится разное количество объектов.
Переключение по шагам произходит по одному принципу:
  Удаляем все дисплейные объекты и на основе шага, как по инструкции, создаём новые дисплейные объекты
Которые заполняем пораметрами считанные с образов. Так мы и получем илюзию того,
что действия отменяются или возвращаются.

  // - Сохранение шага происходит по принципу:
  1. Счётчик повышаем на единицу.
  2. Выделяем память на массив образов в текущем шаге.
  3. Заполняем массив параметрами.
  4. Если сделанный шаг - последний в массиве,
то от счётчика отнимаем единицу и сдвигаем все шаги в сторону нуля на единицу.
  5. И указываем количество шагов сделанных от нуля. Если мы отменяли какието шаги, то
количество шагов должно быть уменьшено.

  // - Считываение шага с контроллера происходит так:
  1. Полностью удаляем все объекты со сцены
  2. Создаём новые на основе образов текущего шага

  // - Переход к Предыдущиму шагу происходит так:
  1. В счётчике текущего шага Отнимаем единицу, упор - не меньше нуля
  2. Считываем шаг с контроллера

  // - Переход к Следующему шагу происходит так:
  1. В счётчике текущего шага Прибавляем единицу, упор - не больше уже сделанных шагов
  2. Считываем шаг с контроллера

  // - Удаление объекта происходит про принципу:
  1. Выделенные объекты удаляем.
  2. Сохраняем шаг.

  // - Копирование объектов происходит так:
  1. Проверим наличие объектов вообще, иначе ничего не делаем
  2. Узнаем количество выбранных объектов
  3. Выделим память на образы копируемых объектов
  4. Заполним образы
  5. Снимим все выделения с объектов
  6. Создадим требуемые копии объектов
  7. Сделаем эти объекты выделеными
  8. Сохраняем шаг

  Ну вот собственно это пока всё что удалось сделать за полторы недели. У меня это получилось уложить в 1000 строк кода. Знаю что может показаться много, но я пока не научился срезать углы.

 

Отчёт № 4

  С момента написания прошлого отчёта прошло около недели и должен сказать, что она не прошла зря. Но обо всём по порядку.
  То что я описывал в отчётах и показывал в видео ранее, это была разработка технологий которые буду использоваться в игре. Это и физика и логика мира и т.д. Но это только технологии, а о какойто игре говорить язык не поворачивается. Несмотря на матричную простоту мира и относительно простую логику работы с ней, бомбермен это не тетрис и не змейка, эта игра имеет все признаки "большой" игры. О чём я говорю? Дело в том, что без объектно ориентированного программирования очень тяжело описывать игровые объекты. Это персонажи и бомбы. Конечно можно обойтись и простыми переменными и даже записями record, но это очень сложно. Особенно если есть много похожих объектов, напр. персонажи.
  И поэтому прошлось придумывать каркас игры и всех её игровых объектов. Я чесно говоря думал, что без ООП всё и так получится, но это усложнило мне код и жизнь.
  И так начнём с мира и его объектов. Мир это матрица, а персонаж это объект который может перемещаться между ячеек матрици. Значит свойство положения такого объекта это число с запятой. А всё остальные игровые объекты могут находится только по целочисленным положениям. Это практически все объекты кроме персонажей. Каждый персонаж должен иметь свой контроллер движения, который я описывал раннее. И управление персонажем сведётся к нажатию виртуальных клавиш направления движения. Я не зря сказал "виртуальных", так как таким персонажем может управлять как человек, так и ИИ. Поэтому контроллер находится в теле персонажа. Значит без классов уже не обойтись. Можно и записью всё это сделать, но это громоздко будет. Теперь мы сделали фактически фабрику персонажей. Которая может выпускать достаточное колличество персонажей. Но это ещё не всё. Сам персонаж это не только его тело которым можно "ходить", это ещё и тот кто этим телом управляет. Например главный герой игры, это не только тот человечек который бегает по ту сторону экрана. Это игрок и виртуальное тело ГГ. Вот они в двоём и являются одним персонажем, играющим свою роль в игре. А если телом будет управлять ИИ, то они вдвоём будут называться персонажем. Поэтому конструкция классов такова:
  1. Сначала идёт "стандартный фундамент" персонажа. У которого будут такие свойства, которые есть у каждого разного персонажа. Напр. та же "хотьба", ходить могут все, поэтому фундамент перса в Бомбермене просто обязан иметь в себе физ. тело и контроллер движения, упрощающий управление им.
  2. Соответствующая надстройка над фундаментом. Эта надстройка поможет хранить в себе ИИ. Тоесть можно не создавать отдельно кучу интелектов, кучу тел, а потом каждому интелекту раздавать по телу. А создать такой объект, который будет иметь ИИ в себе. Вы скажете, - а почему нельзя запихнуть ИИ в фундамент и не делать этой надстройки? Ответ прост, - ГГ или второму игроку в своём теле ИИ не нужен. Тоесть надстройка позволяет создавать похожие объекты но со своими отличиями, без которых они не могут играть свою роль в игре. Тоже самое касается и наличие бомб. Только бомбермены могут ставить бомбы, а все остальные персонажи - нет.

  Ну с классами разобрались. Теперь о бомбах. Бомбы мучали и мучают меня довольно не слабо. Я начал писать логику для них дней пять назад и скажу, что даже сейчас они рботают не идеально. Все проблемы начались с того, что у персонажей количество бомб стало больше одной. Учёт подрыва соседней бомбы, усложнил логику просчёта (какие блоки всё же нада удалить в конце?) очень сильно. Это трудно описать словами, но я приведу один пример и на основе него будет видно как работает всё.
  Одна бомба стоит слева, другая справа. Первая взорвётся - левая. У каждой бомбы есть четыре направления взрыва. Сначала проверяем по каждому направлению растояние до ближайшего блока (не важно разрушаемый или нет). Всё, мы знаем растояние, теперь проверяем, какой это блок и если нада убиваем его. Такой подход работал нормально в одиночку, но если две бомбы, то каждая из бомб (если даже и подорвёт соседнюю), всё равно в рамках одного цикла взрывается поочереди, а значит каждая из них заберёт по блоку на себя. А это не правильно, согласно игрового процесса. И тут мне пришла идея, отключать взрывные волны по направлению к возможной бомбе, и тогда гарантия того что бомбы не будут отнимать блоки друг у друга, была обеспечена. Но в коде это выглядит немного перевёрнуто, поэтому и трудно читаемо.

  Теперь расскажу о рендере. Я конечно ещё в поиске финальной картинки, но сдвиг мира относительно дисплея меня привлекает. Сам мир к счастью работает не зависимо от рендера и это не даёт нам ни каких ограничений.
  Рендер опирается на цифровой костяк игры поэтому для простой визуализации я увеличил один блок до размера 40x40 единиц. Тоесть один условный метр это 40 единиц. Я не сказал пикселей, потому что это значение опирается на переменную "Zoom" которая руководит маштабом всего . Рабочий зум при котором все спрайты равняются пикселям их текстуры, виден на видео в прошлом отчёте. Теперь хочу показать пока ещё огрызок игрушки на данном этапе. Смотреть желательно на полный экран, так как нужно правильное восприятие.

Отчёт № 3

  И так со столкновениями персонажа и бетонными блоками покончено. И казалось бы можно идти дальше, но корявое управление не давало мне покоя. Поэтому это отчёт о проблеме управления.
  Сразу хочу предупедить, что я веду блог не только для того чтобы описать текущие успехи в разработке, но ещё и для того чтобы потенциальных новичков научить быть изобретателями. Поэтому второй отчёт мог показаться слишком раздутым. Но на самом деле это нужно для того, чтобы как следует отследить сам процесс изобретения, ход мыслей, тоесть как до этого дойти и т.д. Впринципе процесс разработки это сплошное изобретательство и здесь со мной согласятса все опытные игростроители. Так как какждый проект, каждая игра уникальна и нет стандартного решения для всего. Постоянно приходится извращаться и придумывать что то новое, а прой и переизобретать "велосипед" заново. Многие стараются описать какую то изобретённую технологию, но тех кто пытается научить быть изобретателем очень мало. Может я сильно зарвался и у меня ничего не получится, но тем не мение я попытаюсь.
  И так, после небольшёго отступления от темы, я продолжаю описывать процесс разработки. Как я уже сказал, управление персонажем страшно раздражает тем, что при одновременном нажатии более одной клавиши, перс. слушается не совсем так как нада. И первая моя проблема это не механика какая то, а моё легкомысленное отношение к самой системе управления. Ну казалось бы, что там такого? Всего же четыре направления по которым можно двигаться. Ну поставь просто четыре условия на движение и всё. И это меня, и тормозило примерно дня четыре. Я пытался как можно проще собрать систему управления и у меня не получалось. Заставить перса двигаться так как хотелось именно тогда, когда хочешь напр. идти вперёд и не отпуская эту клавишу, нажать клавишу влево и немного пройтись влево, что бы обойти препятствие. Таже ситуация если перед персом бетонный блок и не отпуская клавишу "вперёд", хочется обойти. Но не получается, потому что по условию нажатия клавишь, направление "вперёд" приоритетнее направления "влево". И так получается, что одним управлениям мы угодили, а другим нет. Вот в каком порядке приоритета, находились направления:
  1. Вверх
  2. Вниз
  3. Влево
  4. Вправо
  И тут можно отследить, кому мы угодили такой записью, а кому нет. Если главное направление "Вверх" или "Вниз", то в роли второстепенных направлений "Вправо" и "Влево" эти годятся. Но если главными направлениями будут "Вправо" или "Влево", то ничего мы не получим. Перс как пытался (к примеру) идти влево, так и пытается, и ничего нельзя сделать. Ну на первый взгляд, всё просто, возьми да и поменяй местами "Вверх" и "Вниз" на Вправо" и "Влево". Но это тоже самое даст, одним угодили другим нет. И этой ерундой я страдал где то дня три, приэтом с увереностью в себе, что мол я нормальный программист и вот вот сейчас я всё сделаю. Короче говоря расслабился я. Игра вроди бы простая, да чё там, несколько условий и пойдёт как нада. А он всё не шёл и не шёл. И тут я начал в серьёз задумываться о каких то контроллерах по нажатию клавишь и о контроллерах движения. Если бы в первый день разработки, мне ктонибудь сказал бы, что я буду писать специальный контроллер для перемещения перса, то я не поверил бы ему. Так как думал, что всё будет просто, на раз два. И эта моя ошибка мне стоила четырёх дней мучений. При чём почти на пустом месте. Поэтому любой даже маленький проект, требует к себе уважение. Но я понял это позднее чем нужно. И начал воплощать свою идею управления с отслеживания нажатий клавишь.
  Нажатия клавишь, как оказалось далко не самое последнее дело в управлении персом. Это может звучать смешно, но тем не мение. Контроллер отслеживания, должен был иметь в себе два типа отслеживания.:
  1. Какая клавиша была нажата первой? Это первая важная информация. Такой подход делает очень вожную вещь, он относится ко всем клавишам одинаково. Тоесть нет приоритета, какая клавиша главнее. Ну если только небыло нажато несколько клавишь при первом нажатии, тогда приоритет просто необходим. Но это крайне редко происходит.
  И тут получается, такая выгода, что если мы какуюто клавишу нажали первой, то последующие дополнительные нажатия других клавишь, не оказывают никакого воздействия. А это даёт нам гарантию того, что при первом нажатии мы определяемся с основным направление движения персонажа и это направление не собьётся до тех пор, пока мы не отпустим клавишу соответствующую этому направлению. Всё, теперь можно для каждого направления начинать описывать альтернативные направения.
  2. Альтернативное направение это направление в котром может двигаться персонаж если движение по основному направлению не возможно. Тоесть у каждого главгого направения есть свои альтернативные и в случий нажатия соответствующих комбинаций, персонаж не растеряется. Ну а что бы не быть голословным, просьба взлянуть на видео, демонстрирующее этот контроллер.

 

О спрайтовой анимации я поведаю в следующих отчётах.

Отчёт № 2,5 =)

  Это продолжение второго отчёта. прошлый отчёт закончился тем, что нужен алгоритм столкновения персонажа с блоками. И тут всё достаточно просто. Персонаж должен знать по какому направлению он должен двигаться. К счастью для нас этих направлений всего четыре и нам не нужно будет использовать косинусы и синусы для перемещений в вольном направлении. Поэтому рисунок слева демонстрирует следующее отношение между персонажем и бетонным блоком. Персонаж двигается по главной оси (относительно выбранного направления, ось X в данном случае выступает - главной), а переменная h - скажет персонажу на сколько ему нужно будет сдвинуться по перпендикулярной оси (в данном случае это ось Y).
  Ну если проще говоря, то персонаж из за этой формулы преобретает сталкивающуюся поверхность - круг. Конечно можно использовать и ромб (линейное перемещение по второстепенной оси), но я усложнил себе жизнь и сделал круг. На этом этапе персонаж получил адекватное столкновение с миром и следующий ролик демонстрирует это.

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

Отчёт №2

И так, работу начал с игрового пространства. В отличии от других игр, игровой процесс Бомбермена использует два типа игрового пространства. О чём идёт речь?
Дело в том, что на заре игростроя, игровое пространство большинства игр состояло из матрици. Поскольку игры двумерные были, то и матрици двумерные. Интерпретация матрици - здесь является пространством. Тоесть пространство состоит не из бесконечного количества точек, а из конкретных не делимых блоков. Это означает, что любой игровой объект может находиться только в каком то конкретном секторе. А находиться между секторами он не может, так как там пространства нет. Точно такой же подход был в реализации всех игр в игрушке тетрис, которая разошлась огромным теражём по всему миру и имела в себе: танчики, тенис, гоночки, все возможные стрелялки и т.д.
Все эти игры использовали игровое пространство - двумерную матрицу, или проще говоря - мир в котором перемещение осуществлялось перескакивением через блоки мира.
С таким миром в принципе работать достаточно легко и все алгоритмы связанные с перемешениями и столкновениями в этом мире, достаточно просты и не требуют более чем четыре условия для описания адекватного столкновения. Да, я имею ввиду все четыре стенки любого самого маленького программно не делимого куска игрового пространства.
 
  Это было описание игрового пространства с неделимыми секторами.
Но сушествует и более совершенное пространство, тоже двумерное, но с бесконечным количеством неделимых секторов. И перемешение по этому пространству осуществляется тоже перескакивением по секторам (бесконечно маленьким), но по другому алгоритму. Который выглядит примерно так:
  Character.Position.X := Character.Position.X + (deltatime * индекс скорости);
индекс скорости - если равняется единице, то в течении одной секунды выполнения такого алгоритма:
  Character.Position.X := 1;
На протяжении всего времени, персонаж за один цикл перескакивал через некое количество секторов, которое равно скорости работы кода FPS поделённую на одну секунду времени. И мы получим растояние пройденное за один цикл. И тут не нужно быть гением, чтобы понять, что чем ниже скорость работы кода, тем через большее количество сектров перескочит персонаж за один цикл. А это в свою очередь говорит о том, что характер (а не скорость) перемещение персонажа напрямую зависит от скорости работы кода FPS.
  И тут задачка: Стоит два блока, между ними такое растояние, что персонаж идеально в притык между ними залезет. И у нас есть задачка просто тупо между этими блоками протись.
  Ну еслибы у нас пространство состояло только из конкреного числа неделимых секторов - матрици, то проблем не было бы ни каких. Мы просто поднялись бы на один сектор выше и мы находились бы идеально посредине между этими блоками, а значит смогли бы пройти между ними.
  Но у нас пространство состоящее из бесконечного количества веротностей, где может находиться персонаж. А значит и перемещается он специфически, для своего пространства, тоесть в зависимости от FPS он перескакивает, хоть и на микро уровне но в всё же перескакивает, по этому пространсву. А зная это, мы получаем не утишительный вывод:
Что вероятность стать перед блоками так, что бы быть идеально между ними, сводится почти к нулю. А учитывая, что это воспроизводится на конпьютере, то это вообще почти не возможно. Персонаж никогда не войдёт между двух блоков! 
Он сможет это сделать только тогда когда FPS будет бесконечно большим =). Но вы понимаете, что это не возможно...
   
  Уверен, каждый из учасников в этом конкурсе столкнётся с этой проблемой. Как её решить, и как её решил я, я опишу подробно в своём следующем отчёте. 

Конкурс 15 - Бомбермен

  И так 15-й конскурс стартовал, а я с опозданием подключаюсь к нему. И сразу к делу. Конечно же я не стал участвовать в конкурсе если бы у меня не было идеи или какого то замысла. Поэтому я старался прежде всего определиться:
  1. Что я вообще делать буду?
  2. Зачем?
  3. Какими средствами я это буду воплощать?
  4. Успею ли я, к нужным срокам?
И поскольку первые два пункта я обдумывал задолго до участия в этом конкурсе, то мне нужен производственный план. Который я составил примерно таким:
  1. Определиться с главным алгоритмом игрового процесса, тоесть разработать игровое поле и правила игры для игрока.
  2. Создать протоип игрового поля и научится с ним взаимодействовать. При этом неважно кто с ним будет работать, игрок или бот, это не важно. Главным здесь является правильное отношение к игровым элементам.
  3. Разработать правила управления для игрока.
  4. Подселить в игровое пространство инные сущности (боты).
На этом базовая конструкция готова будет. Дальше не имеет смысла развивать механику, иначе она может пойти в разрез с основной идеей игрового процесса.
Тут подход таков, что создаётся макет игровог процесса. На этом этапе идёт тест возможностей тхнического воплощения задуманного, а потом из этого макета вылепливается нужный/финальный игровой процесс.
Отношение к сюжету конечно не такое трепетное ибо времение особо нет. Но сама концепция:
  1. Чего то нет.
  2. Ты это можешь создать, достать, вернуть, выиграть и т.д.
  3. Развитие событий.
  4. Целосность возврашена, завершение действий.
Но об этом поподробнее во второй половине разработки.