Learning pixelart 9 months

Aokigahara

InSomnia

Copulous

Наемники из Краслина-2: Нашествие

Избранное пользователя

Что значит локальные? Если ты хочешь хранить прогресс глобально - они глобальные.
Если объектов не сильно много то нумеруешь их. Например:
lever_1
lever_2
lever_3
И т.д.

У объекта level (рычаг) добавляешь variable с типом строка и названием, например event. В редакторе комнаты перезаписываешь этот variable кастомным. Например, lever_3.
В коде рычага:
1) При его активации проверяешь если значение этого event не пустая строка - закидываешь его в список событий.
2) В room start проверяешь есть ли этот event списке событий. И если есть - проводишь активацию рычага, типа он уже включен.

В случае с сотнями и тысяч коллектиблов это может быть геморно. Я бы сделал автоматизацию.
Во-первых, сделал бы отдельные списки событий, например apples_events, coin_events и т.д.
А у самого объекта вместо variable генерировал бы название event автоматически. В том же room_start, например.
В качестве идентификатора использовал бы название комнаты и координаты:

event = "apple_" + roomName + "_"+round(x)+"_"+round(y)
if eventExists(apples_evenets,event) then instance_destroy()

То есть если у нас уже в списке есть такое событие - значит мы собрали яблоко/монетку/итд.
Ну и при сборе добавлять в список событий собранный коллектибл. Поясню ещё, что roomName - это текущее название комнаты. Лучше, чтобы оно не было связано с названием ресурса, а задавалось вручную в виде строки. Ещё eventExists - функция проверки события, её нужно будет писать вручную и это зависит от реализации списка событий: массив, хэш-карта, очередь и т.д.

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

На асме. NESASM3...

Т.е. грубо говоря в блокноте (код потом компилировался из текстового файла), на этом этапе ром представлял из себя "куклу" с кучей пустых экранов и без текста:

3456789.png

В графическом редакторе DTM рисовались тайлы и собирались карты тайлов всех экранов (для разных локаций можно загружать свои палитры, что очень удобно, т.к. при этом всё выглядит так же, как будет выглядеть в самой игре):

image.png

А текст вставлялся в уже готовый ром с помощью спецпрограммы для перевода приставочных игр (вместе с текстом вставлялась и графика комнат в hex виде):

krupt.png

Так как я в основном перевожу приставочные игры на русский язык, то и инструменты использовал те, с которыми умею работать. И сама игра конструировалась так, чтобы легко можно было с помощью них вставлять текст/графику. Специально ещё написал конвертер графики в hex вид, чтобы её можно было вставлять в программу для вставки текста в 1 клик:

karta.png

Это всё очень тупо (нелогично) выглядит, но я не программист (образование энергетическое) и как мог, так и сделал. Поэтому и звуки в игре такие простые. Я смог добавить лишь элементарное звуковое сопровождение, так как звуковой движок для меня написать самому - непосильная задача (поэтому в игре недодвижок для звука)...

Вот, например, перетаскивай картинку на страницу этого сайта, и тебе всё расскажут :)

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

Про "постепенность" в переходе между крупными и общими планами:

IMG_20240501_003334.jpg

IMG_20240501_003349.jpg

Про "сохранение направления движения" и его непрерывность между сценами:

IMG_20240501_003413.jpg

Про композицию движущегося изображения; для дизайнеров:

IMG_20240501_003000.jpg

IMG_20240501_170652.jpg

Многие штуки там привязаны к конкретным урокам в курсе, так что вне контекста может быть непонятно о чем речь (например, задание стоит "найти пример вот такого-то инструмента в игре", и понятно что в чем суть самого инструмента я не пишу).

Новый челлендж для меня!

С 14 марта 2024 по 14 марта 2025 я участвую в джемах только как создатель звуков. Добавляйте в закладки, чтобы потом показать мне этот комментарий. =(^_^)=

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

Дата начала выбрана между 7DRL и Гаминатор 27.

Это волшебный шейдер https://www.youtube.com/watch?v=rlGNbq5p5CQ
А для PlayStation лука использовали вот это: https://github.com/Kodrin/URP-PSX

Есть ещё flickgame - просто картинки порисовать с переходами между ними. flicksy - что-то похожее но функциональнее. Pocket platformer - как битси, но для платформеров. Ну и PICO-8, конечно.
Вот ещё список с кучей всякого.

Мне все эти предложения напомнили об этом видео

Объясняю по хардкору. Как считать процент индёвости, называйте схему "формула 122".

0. Изначально присваиваем игре 100% индёвости.
а. Каждый разработчик после 1-го => -20% индёвости. Композиторов и переводчиков считать за => -10% индёвости. Переводчиков и модеров, не контактировавших с автором, не считать.
б. Готовый движок\фреймворк => -20% к инди.
в. Чужой контент в игре => -10% индевости за каждый ассет\текстуру\модель. Чужие шрифты и музыка идут как => -5%.
г. Туториал в игре => -10% к индёвости.
д. Карточки стима => -5% к индёвости.
е. Наличие крупного пикселя, и для 2д и для 3д => +10% к индёвости.
ё. Если жанр\тип геймплея уже был известен и в нем уже были успешные трипл-а игры => -10% к индёвости.
ж. Наличие элементов без логического объяснения => +5% к индёвости.

Пользуйтесь!

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

bez-imeni-1_01.png

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

bez-imeni-1_02.gif

Дальше. Немного поправляем кислотные цвета, чтобы не заболели глаза, пока рисуешь. Заливаем все полупрозрачные пиксели и примерно намечаем светотени и блики. Выглядит чмошно, поэтому идем дальше.

bez-imeni-1_03.gif

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

bez-imeni-1_04.gif

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

bez-imeni-1_05.gif

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

bez-imeni-1_06.gif

Тут, еще немного поработав с цветами и формой, получился материал более-менее напоминающий золото.

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