Gamedev + Самоделки

Начать, наверное, надо с того как вообще эта мысль мне пришла в голову. А все просто - у меня родился сын. А это значит, что теперь я на совершенно легальных основаниях наконец-то могу ходить в игрушечные магазины и снова хотеть железную дорогу. Нука признайтесь, кто из нас не хочет железную дорогу? =) Пошел я значит искать железные дороги, читать за масштабы моделек и прочее, и нашел. И удивился, говоря цензурно, ценам. И тут приходит мысль, а что мешает мне ее сделать? Да в целом ничего, мало того, уже даже были попытки. В детстве отец учил меня делать из картона всякие крутые игрушки себе самому. Я ими даже приторговывал в школе. И тогда еще мы еще с одноклассником делали попытки создавать игрушечные путЯ, но к сожалению доступный нам серый картон "ладога" был капец убог в целом, и в частности в части износа будучи в качестве путей. А до этапа как сделать руками картон нужных характеристик из газеты мы тогда еще не доросли. Плюс я еще тогда будучи второклассником понял, что мероприятие весьма серьезное, трудоемкое, поэтому для разделения нашего труда надо какое-никакое но проектирование. Одноклассник-же Макс так увлекся, что собрал модель вантового моста длиной пролета больше метра - реально вместе с подъемами он по длине был как весь его стол.

И вот почти тридцать лет спустя я снова подошел к этой задачке. Но теперь-то у меня есть 3д принтер, интернеты, вы, и целая куча всего! Пора озадачится что делать и как.

Ближе к теме.

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

Железнодорожный tileset

НО! Затея-то была сделать игрушечные жд пути. Реальную такую игрушку, которую можно пощупать руками. А значит наличие двух прямых сегментов разной длины (по короткой, и по диагонали, см. картинку) как у него, совсем не подходит. Я, работая техподдержкой не первый год, ответственно заявляю: если дать возможность собрать "как-то не так", то пользователь именно криво и соберёт. Исключить-же диагонали (делать без четвертого варианта) на квадратных плитках принудительно и полностью ну совсем как-то не комильфо, какие-то одни сплошные повороты получаются, а оставить их – в реальности поедет вся сетка и собрать ее обратно никакой возможности. У единички длина 1, у четверки - корень из двух. Не выровнять потом никак по всей видимости.

Надо что-то думать. Первое естественное требование: тайлы надо такие, чтоб их можно было вращать, то есть они на плоскости и они правильные. Потом выкристализовывается второе не явное требование – прямые в тайлах должны быть все одной длины. Дальше, медитируя на картинки из статьи уважаемого JamaicaMURR, стало понятно, что пользователь легко из его набора сделает пересечение из данных ему в руки кусочков. Легко! На углах. А стоящего над игроком компьютера, который не дает этого делать, в моем случае просто нет.

Отступление: @JamaicaMURR, это не критика «в пух и прах» твоей статьи, твои измышлизмы используются в качестве почвы! За что тебе большая благодарность.

Так родилось третье требование - невозможность сделать из набора плиток никаким способом (кроме явного) пересечение путей. Но в чем блин проблема-то? А как обычно - соседи. Рассматриваем соседей. Все дело в соседях. И в тайлах. Тайлы… соседи… плоскость… Но что мы делаем с плитками, на которых у нас находятся разного рода прямые рельсы, стрелки, повороты? Замощаем плитками плоскость говоря математически. За-мо-ща-ем. ХМ! Да про это-же целых несколько лекций вещал Алексей Владимирович Савватеев, вот например: https://www.youtube.com/watch?v=5CQxcFHJIJA которого я почему-то, когда-то, чисто из любопытства смотрел. (Очень рекомендую. Оказывается мы, как человечество, не уверены что знаем даже о выпуклых пятиугольниках, хотя казалось-бы. А ведь считаем себя дофига пупами, хех). И какие варианты есть?

Собственно Что меня удивило.

А может попробовать шестиугольные плитки? Да, они в играх не столь популярны в отличие от квадратов, несколько сложны в реализации, но может что-то получится? И я начал отрисовывать варианты, опираясь на комбинаторику JamaicaMURR, и вглядываться в правильные шестиугольники.

И в них, шестиугольниках, полезли разные интересности:

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

2. у шестиугольника все соседи доступны через сторону. Не через точку. Переходя через точку на шестиугольниках ты попадаешь в торец стены соседей. Т.е. других прямых кусков не надо в отличие от квадратов, где диагональные соседи доступны через общую точку. (И тем более в отличие от треугольников. Там дак вообще целый букет соседей через каждую точку). А других правильных многоугольников, таких чтоб без пробелов заполняли собой плоскость в известном нам 2d нет.

3. у шестиугольника наименьшее количество соседей из всех плоских фигур. Всего шесть.

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

Ну хорошо, а какие могут быть варианты путей на этих плитках? Нужно ехать прямо и все прямые куски одинаковые? Сделано. Нужно поворачивать и тоже одинаковыми кусочками? Окей. Плюс поворачивать составом желательно как и на взрослой дороге – с максимальным радиусом. Т.е при создании поворота соединяем нижнюю сторону и какую-нибудь из несоседних, вот так. (С минимальным радиусом «к соседней стороне» поворачивать я не буду т.к. слишком мал радиус.) И оказывается на шестиугольнике такой центр поворота лежит аж вне габаритов плитки. Шикарно! И плитка «поворот» так-же остается одна: поворот либо налево либо направо, достигается просто поворотом кусочка.

Дальше комбинаторика вариантов "парочками" с прямой и поворотом как товарищ в статье. Всего получается… пять уникальных вариантов. И всякие запрещенные – с двумя непересекающимися поворотами на одном тайле. Такой не пойдет скорее всего из-за габаритов паравозика, так что  его… да просто не буду делать, как и товарищ выше на квадратных тайлах и все. Перекресток двух прямых туда-же, его просто не будет во избежание аварий. Есть еще вариант тройной стрелки на одном тайле, но на взрослых дорогах его стараются избегать, так что и я его тоже откидываю. И не стоит делать две стрелки на одном тайле чтоб не путаться с адресацией. И три стрелки тоже не будем. Один таил=одна стрелка.

И вот в чем тут фокус именно "на шестиугольниках" – если не давать вариантов путей игроку, то он и не сможет создать проблем из уже имеющихся у него в руках! Все соседи доступны только через сторону!

Собственно и вот! Эти великолепные свойства правильных шестиугольников сводят всю идею к пяти основным звеньям железнодорожной игрушки если она на плоскости. И вот как получается. Не отказал себе в удовольствии пораскладывать всякие варианты. Набросал библиотеку плиток.

И пораскладывал. Например двупутный перекресток с возможностью развернутся на нем. И даже четырех путный (по две полосы в каждую сторону). И можно продолжать расширять.

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

Радиусы

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

Топологически да, их можно заменить и первым (зеленым) вариантом. С учетом всех поворотов получается вот такой набор. Прямые остаются те же.

Желтые элементы вписываются в общую сетку и не нарушают ее (с чего бы им это делать).

И изза совместимости топологии можно взять и заменить, допустим в перекрестке, все зеленые повороты и стрелки на все желтые раскукожив всё вширь. Красиво получается:

Но тут у меня происходит «жизнь» (как у Конвея, хех. Кстати! @epicrocus попробуй поискать за клеточные автоматы и игру "жизнь", хоть она и не совсем игра, но очень красив процесс. Как простое правило порождает такие зубодробительные структуры.) Я перекатываюсь на время ремонта из своей квартиры к родителям, живу на чемоданах, но мысль не остановить, и мысль виляет маленько в сторону, очень хочется погонять паровозики, а печатать нет ни времени ни средств ни места. А почему-бы действительно и не сделать какую-нибудь виртуальную шпунялку-каталку паравозиков по путям.. то есть…

Игру?

Конец первой части.

Я, как и многие мои читатели, очень люблю игры. Уже довольно обширное число моих статей было посвящено ремонту и моддингу самых разных игровых консолей — как китайских «нонеймов», так и брендовых PSP и PS Vita! Однако, меня тянет к железу не только желание отремонтировать и поставить в строй «устаревшие» девайсы, но и мания делать и созидать что-то своё! А ещё я очень люблю программировать игры и графику сам. Недавно я загорелся идеей разработать с нуля свой портативный «тетрис»: от схемы и разводки платы, до написания прошивки и игр под нее. Что получается, когда программист, который поставил электронику практически во главе своей жизни, пытается сделать свое устройство? Читайте в статье!

❯ Как я к этому вообще пришел?

Проекты разработки самодельных игровых приставок стали очень популярны к нашему времени. Если раньше embedded-разработка была достаточно дорогой и доступной лишь для избранных, то сейчас на рынке можно найти все что хочешь — и мощные микроконтроллеры с кучей периферии за 300 рублей, и готовые дисплейные модули по 250 рублей, и макетные платы с удобными dupont коннекторами за весьма скромные деньги.

Собрать свой гаджет в пределах одной-двух тысяч рублей стало вполне реальным. Люди собирают себе самые разные устройства, а игровые приставки — одна из самых популярных тем. Однако, для многих людей, которые только начинают знакомится с миром embedded-электроники, собрать консоль в своем корпусе с Raspberry Pi на борту и RetroPie в качестве оболочки — за счастье.

Однако есть определенная категория электронщиков, к которой отношусь и я — нам нужно делать всё с нуля! Свои проекты я стараюсь реализовывать на самопальных фреймворках/движках, точно также я мыслю и в подходе электроники — ну не могу я использовать чужие решения и стараюсь разобраться в вопросе сам. За моей спиной есть весьма интересные демки. Например, это моя игрушка с незамысловатым названием «ралли-кубок ТАЗов», которую я написал за неделю с нуля (рендерер, звук, ввод, редактор уровней — все свое) в 2022 году:

Вот так, с любовью программировать игры, я и пришел к мысли сделать свою консоль, так как вижу её именно я. Только без чужих библиотек и наработок, но не прям уж bare metal. Сел я и начал думать, на чём же мы будем строить наш игровой девайс!

❯ Из чего будем делать?

Как я уже говорил выше, в наше время выбор железа для создания своих девайсов большой — тут и мощные микроконтроллеры/одноплатники, по производительности сравнимые с телефонами 2005-2006 годов, и различная периферия — аж глаза разбегаются. Однако проектировать будущую консоль нужно исходя из некоторых требований.

Характеристики моего девайса следующие:

1. Процессор: двухядерный ARM микроконтроллер RP2040 на частоте 133мгц, построенный на архитектуре Cortex-M3. Сам процессор распаян на плате Raspberry Pi Pico.

2. ОЗУ: 260 килобайт SRAM, встроена в процессор. Немного, но если грамотно распоряжаться ресурсами — то хватит.

3. ПЗУ: 2Мб SPI Flash-памяти, также распаяны на плате.

4. Дисплей: 1.8" TFT-матрица с разрешением 128x160. Выбор разрешения обусловлен производительностью будущей консоли — процессор банально не сможет заполнять матрицу с относительно высоким разрешением.

5. Ввод: 6 кнопок, 4 из которых — направление, 2 — действий. В будущем могут добавиться еще несколько.

6. Звук: динамик. Пока не знаю, с чего рулить будем — возможно, возьмем «железный» ШИМ-контроллер процессора, а возможно прикрутим внешний ЦАП с i2s.

7. Питание: 3.7в аккумулятор BL-4C. Да, да, тот самый с Nokia и современных кнопочников! Аккумулятора, емкостью в 800мАч должно хватать хотя-бы на 4-5 часов игры. При этом зарядка АКБ обеспечивается модулем TP4056.

Весьма неплохо для самоделки, согласны? Как я уже говорил раннее, эти характеристики примерно соответствуют мобильным телефонам 2004-2006 годов — Nokia 6600, Sony Ericsson K510i, Samsung D800. Отличие лишь в ОЗУ (в телефонах её 2-4 мегабайта) и периферийных модулях типа контроллера дисплея.

На фото E398 — мобилка 2004 года выпуска, но она здесь не просто так. :)

Важную пометку нужно сделать касательно дисплеев: эти 1.8" матрицы бывают приходят с «синевой» — это не железная проблема и не совсем брак. Сам контроллер в дисплея в них сильно греется (хотя токоограничивающий резистор стоит) и негативно влияет на клей, из-за чего матрицы отклеивается от подсветки и слои поляризации начинают «синить» картинку. Лечится проклееванием подложки матрицы суперклеем.

RPi Pico я решил выбрать, поскольку информации про них достаточно мало, характеристики хорошие и пока что никто особо ничего на них не делал, тем более в рунете. А ещё у них очень удобное и простое SDK, практически bare-metal. ESP32, например, работает на FreeRTOS и имеет кучу библиотек, здесь же API простое и понятное.

Закупаем все необходимое и начинаем творить!

❯ Графика

В первую очередь нам нужно подключить дисплей и что-нибудь на него вывести. Заодно и SPI погоняем на незнакомом чипсете, благо работа с ним очень простая — задаем конфигурацию пинам (gpio_set_function), настраиваем SPI-контроллер и можно посылать данные.

SPI у RP2040 работает на частоте вплоть до ~60мгц — это достойная скорость передачи, в том числе и для быстрого вывода графики. На самом деле, SPI даже предпочтительнее чем параллельный 8080-интерфейс для использования в микроконтроллерах: дело не только в количестве занимаемых пинов, но и в возможности использования DMA!

В подобных проектах всегда нужно делать так, чтобы дисплей можно было при необходимости поменять, а желательно вообще научить работать его с несколькими контроллерами: разные дисплеи одной диагонали могут использовать разные контроллеры. В моём случае, этоST7735. Для разрешений 240x320 используются ILI9325, ILI9341, ST7789. Команды инициализации дисплея честно позаимствованы, но именно в этом нет ничего зазорного — сама система команд относительно стандартизирована, отличается лишь первичная настройка питания, гамма-коррекции и т. д — часто init sequence вставляет сам производитель в даташит.

После инициализации дисплея пробуем что-нибудь вывести. Да, все работает без проблем. Пару важных нюансов: ST7735 требует посаженный на землю CS, в воздухе его оставлять нельзя, как некоторые ILI (вы ведь навряд ли будете вешать несколько устройств на одну шину с дисплеем, когда есть вторая?) и логическое состояние 1 на пине RESET (в воздухе и «на земле» он будет висеть в постоянном ресете).

Для полустатичной графики, можно обойтись лишь командами дисплея — например, тут есть удобные функции для заливки прямоугольников (setArea и пишем цвет без остановки) или скроллинга. Сделано это для более слабых микроконтроллеров. Нам они не подойдут — выделяем память под фреймбуфер/бэкбуфер и настраиваем канал DMA для разгрузки процессора в процессе передачи данных:

Саму картинку подготавливает процессор: именно он рисует картинки и он же делает их прозрачными. На него ложится основная работа, однако мы можем ему помочь разгрузиться, если отдадим передачу уже подготовленного кадра на дисплей на DMA (Direct Memory Access) — устройство в микроконтроллере, которое позволяет процессору настроить параметры передачи данных, а DMA их будет сам копировать из памяти или в память. Таким образом, можно реализовать асинхронное копирование нескольких блоков ОЗУ, или, как в моем случае — передачу буфера кадра на дисплей, пока процессор готовит следующий. Чем больше разрешение — тем больше эффекта от DMA!

Кроме того, важно выбрать формат цвета для нашего дисплея: я выбрал 2-х байтный RGB565 (5 бит красный, 6 бит зеленый, 5 бит синий). Это экономичный формат который выглядит красивее палитровой графики и кушает не так уж и много драгоценной памяти. Кроме того, на данный момент мы умеем отрисовывать изображения произвольных размеров с прозрачностью — вместо альфа-канала здесь используется так называемый colorkey — концепция, очень близкая к хромакею, только она берет в качестве трафарета конкретный цвет. В нашем случае это «255 0 255» (ярко розовый).

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

❯ Ввод

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

Кидаем общий минус на все кнопки, а второй вывод размыкателя кидаем на соответствующие пины GPIO. Я выбрал предпоследние т. к. на них ничего важного не висит, текущая конфигурация занимает 6 пинов. На фото выглядит не очень красиво — на то она и макетка.

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

Есть ещё способ реализации больших клавиатур и геймпадов: когда все кнопки вешаются на пару линий, где на выходе каждой кнопки есть резистор определенного номинала. ЦАП микроконтроллера считывает это значение (допустим — 1024 это вверх, а 2048 — вниз) и таким образом определяет текущую нажатую кнопку. Таким раньше любили промышлять китайцы, из-за чего нельзя было нажать одновременно вверх и вправо, или вниз и влево и т. п.

❯ Пишем игру

Теперь у нас есть минимально-необходимая основа для написания игры. Первой игрой для своей консоли я решил написать классический шутер в космосе — летаем на кораблике и сбиваем врагов, попутно уворачиваясь от их пулек. Заодно проверим консоль на стабильность.
Писать я её решил в классическом C-стиле, как и принято в embedded-мире: без std и тем более stl, без ООП и виртуальных методов, аллокаций по минимуму. В общем, примерно как писали игры под GBA! В первую очередь, подготавливаем спрайты нашей игры, прямо в пейнте, а затем конвертируем их в представление обычного массива байтов в виде header-файла. На первых порах это удобнее, чем делать свой ассет-пул:

Архитектуру я организовал в виде нескольких подфункций, каждая из которых занимается своим стейтом (world/menu) и своими объектами (playerUpdate) и их отдельные версии для отрисовки. Сами игровые объекты я описал в виде структур, а центральным объектом сделал CWorld.

Время я решил описывать в тиках, а не миллисекундах, как я обычно это делаю на ПК — у консоли железо одно и там следить за этим нужно меньше.

Единственные аллокации, что я использовал — это для пулов с пулями, и с врагами. Оба пула четко ограничены — до 8 врагов на экране, и до 16 пулек — вполне хватает. Динамические аллокации помогли мне найти серьезную ошибку в коде — в один из моментов игра просто валилась с Out Of Memory. После того, как я немного поменял условия и делал аллокейты тех же самых объектов каждый кадр — игра переставала крашится. Причина оказалась простая — невнимательность (вместо >= было >), по итогу при отрисовке спрайтов за пределами экрана, программа сама начинала портить вунтренние структуры аллокатара и самой игры (проявлялось в глюках и телепортациях). После фикса, все заработало как нужно. :)

Ну и для основной части геймплея с выстрелами и столкновениями, я предусмотрел несколько функций, которые спавнят игровые объекты и сами управляют пулом. Противники обновляются как обычно, для коллизий используется AABB (axis aligned bounding box, ну или его 2D-подмножество в виде rect vs rect).

По итогу, у нас получилось простенькая, но рабочая игрушка, которая без проблем работала почти все время, что я писал этот материал, а значит устройство работает стабильно. И я очень горд, что у меня получилось сделать рабочий прототип своего собственного гаджета!

Ниже выкладываю принципиальную схему устройства, она очень простая, поэтому смысла делить ее на несколько листов нет. Разводить учился, читая сервис-мануалы и схемы :)

❯ Заключение

Полная цена сборки прототипа составила:

• Raspberry Pi Pico — 557 рублей (но я брал на Яндекс Маркете, на «алике» дешевле — около 300 рублей).

• Дисплей — 380 рублей, заказывал на «алике».

• Макетка — 80 рублей, в местном радиомагазине.

• Кнопки. По 5 или 10 рублей штучка, пусть будет 60 рублей.

По итогу, прототип мне обошелся в 1077 рублей. Бюджетненько, да, с учетом того, что можно сделать еще дешевле? Я тут так подумал, у меня есть желание развивать и поддерживать консоль в будущем и под консоль уже можно делать что-то своё… может, если вам будет интересно, делать их на заказ? Соберу вам по себестоимости (до 1.000 рублей) + доставка, если хочется попрограммировать под что-то маленькое, но самому паять не хочется. Мне было бы очень приятно. Пишите в личку или комменты, если вас заинтересовало бы такое! :)

Весь процесс разработки этого девайса занял у меня всего несколько дней. Я и до этого понимал концепцию работы 2D-графики на видеокартах прошлого века, поэтому ничего особо нового я для себя не открыл. Однако, я попробовал свои силы в разработке игровых девайсов, которые могут приносить удовольствие — как ментальное от самого процесса сборки и программирования, так и физическое от осознания того, что игра на нем работает. :)

Однако, это далеко не конец проекта! У нас ещё много работы: нужно развести и протравить полноценную плату, реализовать звук и API для сторонних игр, придумать корпус и распечатать его 3D-принтере. Кстати, я ведь обещал что скоро будут и другие интересные проекты с 3D-принтером: как минимум, мы доделаем предыдущий проект игровой консоли из планшета с нерабочим тачскрином и RPi Pico.

Пост подготовлен при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!

Улучшать можно только редкие и эпик предметы, редкие можно улучшить до 10, эпические до 15, позже сделаю чтобы на более высоком уровне, улучшать можно было до 20+

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

Звуки добавлю попозже, следующее на очереди, хм, наверно буду делать умения, даже не умения, а умениЕ - кровотечение, ну и ветку с талантами, пока не придумал ничего лучшего, чем прокачивать скил - кровотечение и две пассивные ветки, на здоровье/урон, а как кровотечение вкачается до 10 уровня, можно будет выучить пассивку на аое урон, т.е. теперь обычная атака будет наносить урон всем, по кому попадёт.

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

Монстров еще надо добавить, штук 5 разных видов. Может ещё какой уровень придумаю, мб с боссом, но это надо будет ещё и механику боссу делать, ну или будет просто бить автоатакой, но будет бить больно))

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

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

Пока план - закончить эту игру))

- информацию об уровне\статах в UI персонажу

- переделал чуть UI, зачем я делал разного размера слоты для экипировки я не знаю :D

Cделал всем слотам одинаковые размеры

- отскалировал статы у предметов в зависимости от itemLevel-а предмета

- сохранение статов у персонажа, если предмет снять, то статы которые были у предмета отнимутся.

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

Щас сидел думал какой бы еще видос добавить, что ещё показать. полез, в итоге сломалось скалирование монстров, чинил часа два ._.

Всё, следущее на очереди город с вендором и кузнецом)) Кузнец будет улучшать вещи, а у вендора будут продаваться вещи, рандомные, так же в городе вендору можно будет продать предметы из сумки и заработать голды)

А уже далее буду делать умения персу, пока кроме кровотечения, ничего не ум не пришло))

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

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

Это всё что у меня получилось, больше пока показывать нечего)

- Тул тип при клике на монстра. В тул типе отображается информация о монстре, что с него падает, с каким шансом, сколько было уже убито монстров этого типа

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

second item drop и third item drop это шансы на дополнительный дроп предмета. Золото кристаллы и экипировка ролятся каждый отдельно

- Сохранил кол-во убитых монстров соответствующего типа, сохранил кол-во открытых сундуков и если следущий открываемый сундук будет редким и если выйти из игры, то при заходе в игру, следущий сундук будет - редкий, счетчик не сбросится

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

В общем вот это всё что я за сегодня сделал) Завтра наверно начну уже делать сцену с городом. И буду тестить переходы с уровня на уровень, что придется чинить если сломается))

С сундуков щас падает много всего, в реале же будет меньше, будет два шанса на дополнительный лут, у всех сундуков щас стоит по 100% для дополнительного Лута, т.е. золото упадет 1 + 2 дополнительных раза, тоже самое с вещами, а я переделаю эти шансы в соответствии с качеством сундуков, т.е. у эпик сундука шансы будут где-то 40%\20% на доп лут, у обычного сундука 5%/2%. Всё это цифры, их можно легко подкорректировать))

Пришла идея как-то отображать на экране что поднял персонаж, примерно знаю как это сделать, но не уверен, надо тестить)

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

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

Блин, как же классно когда всё сохраняется!!!)) Мотивации ещё больше)

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

Добавил собственно лут, пока весь лут просто при нажатии кнопки дропается, добавлю ещё чтобы при выпадении, вещь слегка подлетала вверх

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

Какую в целом хочу сделать игру, что в неё я хочу запихнуть?

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

Ну и соответственно, чем вещь более редкая, тем более мощные у неё характеристики)

Чего не хватает на ваш взгляд, пишите, буду добавлять)