ТЕМА: Разработка Polarities

Здрасте... Начинаю свой дневник разработки игры Polarities.
Это фан-игра по Yume Nikki, отличающаяся от остальных свой однобитной графикой(только чёрный и белый цвета) и тем, что она делается не в RPG maker'е, а на своём движке на C++ с библиотекой SFML.

О названии
Название рабочее, возможно сменю его. Само оно переводится как "противоположности", которое как-бы намекает на однобитную графику.

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

Что уже готово?
Я пилю игру не с самого начала. Уже в создании есть небольшой прогресс и кое-кто даже протестировал эту игру.
Вот вам скриншот первой тестовой комнаты:


Примерно вот так это всё и выглядит.
Ещё, там есть уже несколько превращений, все я вам не покажу, только некоторые:


Если говорить о возможностях моего движка на данный момент, то вот список:

1. Можно ходить
2. Можно перемещаться между комнатами
3. Можно создавать карты
4. Можно сохраняться(конкретно сохраняются: координаты, комната, превращение)
5. Реализовано взаимодействие с картой(конкретно: стены и двери)
6. Инверсия

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

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

возникает резонные вопросы:
1) почему на форуме по мукеру ты делаешь игру не на мукере?
2) зачем свой движок если его возможности - это 1/100 возможности мукера?

yuryol пишет: А это разве запрещено?
Конкретно создать дневник разраба об этой игре мне разрешила Анька)) К тому же, эта игра похожа на мукеровскую.

yuryol пишет: Эээ... Ну тык эту игру даже пре-альфой назвать нельзя, она крайне сырая. А движок я буду ещё долго-долго дорабатывать.
И да, покажи мне где в мукере находятся тайлы 20 на 20 и спрайты NPC неограниченного размера?)

2Oth_Century_boi пишет:
в MV

Решил сделать скруглённые стены. Что-бы смотрелось лучше. Но по моему получилось как-то не очень.

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

2Oth_Century_boi пишет:
Ну да, это вышло не скругление, а такая мега-фаска, только недоделанная: можно положить полутень на всю её поверхность и сделать правильный скос на верхней части, тогда, наверное, будет нормально выглядеть.
Ну и предлагаю не страдать раньше времени. Если будешь выкладывать что-то интересное, то игрой будут интересоваться, отчего нет?

Alx_Yago пишет:
Ну вот я тут немного подшаманил со стенами. С полутенями хз, по моему замазанный шахматами скос будет не очень смотреться.

Хотя та жирная тень у краёв лишняя, попробую её убрать.

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

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

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

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

Получилось норм, это не получилось хорошо (8 есть над чем работать.

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

А вот с "неправильными" пикселями надо 100% бороться, очень тяжело воспринимать то, что видно на скринах.

Я подумал и решил, что сначала стоит оформить сами механики игры, а потом уже работать над графикой.
Ну так вот, один очень хороший человек мне подкинул идею, о том, что-бы превращения как-нибудь влияли на геймплей.
И так, есть превращение "бронежилет", где ГГ одевает броник и ходит в нём(логично).
Для чего нужен бронежилет в жизни? Для защиты от огнестрельного оружия.

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

Я нарисовал пушку, вот что получилось:


И ещё, я написал код, что-бы пушка "выслеживала" игрока. Но стрелять она пока ещё не умеет.


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

Две новости.

Первая

Я сделал небольшое оформление в комнате с пушкой на рельсах. Да, я говорил, что графикой бузу заниматься уже потом. Но, как-бы накалякать травы это дело секундное. Как по мне, с оформлением всё выглядит совершенно по другому.
Вот что вышло:


Вторая

Я добавил столкновения с пушкой и теперь через неё нельзя пройти. Также пушка теперь останавливается, если персонаж слишком близко.
Гифка получилась почему-то какой-то лагучей.

Вчера я писал это:А сегодня я сделал достаточно значимую вещь для проекта, написал класс для NPC. Теперь создание и управление NPC можно уместить в нескольких строках, раньше бы пришлось громоздить "процедурную кашу".

Примеры ниже.
(на этом форуме нет специального BB-кода для C++, поэтому использую [сode type=php] )
(Если вы скопируете и вставите код, то ничего работать не будет, т.к. нужно создать окно, поработав с SFMLевским классом RenderWindow)

Видите код сверху? Он достаточно громоздкий и быть может он выполняет кучу задач? Э... Нет))
Он создаёт картинку и двигает её вниз...
ВСЁ! Он даже не анимирует спрайт! Просто двигает и всё!

А теперь попробует сделать аналогичный код, но с использованием моего класса:

Код получился меньше! Более того, он не просто двигает спрайт, он ещё и анимирует его! Вот такая вот штука эти классы.
Для наглядности, по спойлером находятся фрагменты кода, напрямую связанную с функционированием NPC:


Теперь расскажу о конкретных методах класса.

Сам конструктор класса:
F — названия графического файла с текстурами для NPC.
X — длина спрайта по координате X.
Y — длина спрайта по координате Y.
Создаёт самого NPC.

Метод телепортации:X — координата X.
Y — координата Y.
Телепортирует NPC в заданные координаты.

Метод отрисовки:Самый простой, но самый важный метод. Отображает спрайт NPC в окне игры.

Метод движения:X — скорость движения по X.
Y — скорость движения по Y.
TIME — временной стабилизатор/коэффициент для привязки ко времени. Это переменная, обратно пропорциональная скорости работы процессора. Делает движение равномерным.
Двигает NPC с заданной скоростью.

Метод... указания кадра?:L — координата самого левого пикселя кадра спрайта.
T — координата самого верхнего пикселя кадра спрайта.
Задаёт спрайту нужный кадр. Если метод анимации нельзя использовать по каким-то причинам, можно использовать этот метод.

Метод анимации:M — количество кадров.
TIME — коэффициент для привязки ко времени.
S — частота кадров.
L — координата самого левого пикселя второго кадра спрайта(обычно равна длине).
T — координата самого верхнего пикселя второго кадра спрайта(обычно равна высоте).
Анимирует NPC.

Метод получения координат:Записывает координаты NPC в переменные класса XC и YC.

Фух... Вроде всё перечислил.
В принципе, в вот и всё. Теперь для создания новых NPC не придётся писать тонны кода! .

На прошлое сообщение вообще никто не обратил внимание и я чёт приуныл((
Но теперь я разуныл и запилил кое что для игры.

Первое
Добавил новое превращение. И оно с одной стороны оригинальное, т.к. в YN такого не было, с другой стороны оно не очень оригинальное, т.к. в YN было похожее превращение. Также, с одной стороны оно необычное, с другой, это весго лишь "свободная трансформация" из ФотоШопа Само превращение я назвал "Сплющивание". Вот оно:


Второе
Я начал работу над меню. Я уже написал для него класс, но он очень маленький и писать о нём подробно нет смысла.
Меню я научил сохранять и загружать, пример под спойлером.

Решил попробовать создать что-то наподобие локации. Я решил, что первая локация будет лесная. В оригинале тоже есть лесная локация и она вполне могла бы стать моей любимой локацией в YN, если бы не страшная музыка((
Я нарисовал елок и расставил их по карте. Пока-что выглядит немного пустовато, но уже смотрится неплохо.

Опять я долго пропадал...
Ну ладно, что же я сделал сегодня для игры? Добавил фон для локации. В оригинале также у локаций всегда был фон. И на фоне всегда была какая-то хрень. Лично решил не заморачиваться и фон это просто скриншот локации, увеличенный с помощью high-tech технологии "Ctrl+C, Ctrl+V". Но скажу, что фон одной из локаций в оригинале был сделан точно также. Пока фон не зациклен и просто движется по диагонали.


Ещё я, кстати, добавил музыку в локацию. Взял я её из оригинальной Yume Nikki, из тёмного мира. И знаете, уже чувствуется даже какая-то атмосфера! Правда, гифки не могут играть музыку(

Написанный на C++ main loop это очень интересно(на самом деле самая скучная часть кода).

На самом деле в предложенном варианте имхо нет лока фпс и на разных машинах будет разная скрость движения спрайта вдоль экрана(а может просто показалось)

F15h пишет: Как-бы, он там есть))

Вот в этой части кода ниже переменной "time" присваивается значение, обратно пропорциональное быстродействию процессора в данный момент.
Если посмотришь на код, который у меня был выше, то там увидишь, что скорость движения спрайта умножена на "time".

2Oth_Century_boi пишет:
И сколько ядер процессора это скущает?)
Обьясняю. Ну опять же я не вижу всех моделей, может быть ответсвенность за перерисовку спрайтов реализована с какой-нить веселой логикой.


Но то что я вижу по мейн лупу.
1) проц выполнил получение времени за 0.000001 секунды
2) сбросил таймер
3) выскачитал время
4) посчитал логику
5) отрисовал спрайты на том же самом месте
6) ушел на пункт один

итого имеет фпс в 1600 - с полной загрузкой одного из ядер(скорее всего но это не точно)

F15h пишет:
Так, я чёт не очень понимаю о чём ты... Но ты по моему тоже не очень меня понял

F15h пишет: Эээ... А почему ты считаешь, что оно должно сжирать столько мощности процессора? Или ты думаешь, что этот цикл будет выполняться 1000000 раз в секунду?

F15h пишет: С какой стати именно за это время?
"float time = clock.getElapsedTime().asMicroseconds();" тупо задаёт значение переменной "float". Объясняю: если процессор смог выполнить этот цикл за 1 микросекунду, то time = 1, если за микросекунду процессор выполнил этот цикл 2 раза, то time = 0.5, а если процессор за микросекунду выполнил лишь половину цикла, то time = 2.

F15h пишет: Деление на 800 нужно лишь для того, что-бы переменная "time" не была такой огромной и не слишком люто изменяла скорость спрайта.

F15h пишет: Откуда эта цифра?