Шутер от первого лица в родном сеттинге с пиксельной 2D/3D графикой. Действие происходит в жутких городских уголках девяностых/нулевых в СНГ.
Прототип на итч: https://mihaileshmakov.itch.io/neighboringarea
👆👆👆
Над основным игровым циклом я еще работаю. Нужна обратная связь
Следить за проектом в телеге: https://t.me/MikhailAllowsHimself
Данную тему мы уже затрагивали в одном из прошлых постов. И да, мы ещё не закончили. Ведь говорить о Glide BTL можно столько же, сколько смотреть на огонь - бесконечно. Интересен ли Glide BTL? Что ж, представь себе…
Интересен ли Glide BTL? Что ж, представь себе…
Мультиплеер, поддерживающий разные стили игры. Гонки либо добыча ресурсов, а может уничтожение противников? Тренируйся с ботами и выходи побеждать реальных игроков. Веселье? Веселье будет обеспечено.
2. Управляемый тобой персонаж свободно двигается не только по земле, но и по воздуху, ты волен лететь в любом направлении. Каждая карта создана с учётом вертикальности, мягко направляя к контрольным зонам и чередуя безграничный полёт и ограниченные пространства
3. Glide BTL - не просто “гоночка”. Мы стараемся подарить игрокам разнообразный игровой процесс. Ловушки, интерактивность, продуманные боевые столкновения - это и многое другое ожидает тех, кто решится сесть за управление глайдом.
Есть много вещей, о которых в дальнейшем мы будем рассказывать подробнее, а пока на этом всё. И раз уж ты дочитал аж до сюда, то может поделишься своими мыслями? Или у тебя есть какие-нибудь предложения? Так как разработка игры идёт полным ходом, твои слова могут повлиять на финальный результат, ведь мы в самом деле стараемся прислушиваться к дельным идеям
Наш Steam
Свежие новости в Telegram
Дневники разработчиков №8 (Архивная запись 06.05.2024)
Всенепременно здравствуйте, товарищи подписчики! Мы продолжаем знакомить вас с процессом работы над новой версией GZM. Сейчас все старые миссии, которые были в предыдущих версиях нашего проекта, нормально запускаются на новом движке. Но, поскольку появились новые механики, заменяющие многие реликтовые костыли, нам хочется задействовать их на старых игровых картах. Без некоторых, например без новой воды, совсем не обойтись в миссиях про море.
На данный момент я, Александр Жиляев aka Tyrion, почти закончил модернизацию карт кампании США. Некоторые старые миссии мы заменяем новыми. Уже полностью переделана глава про Гуадалканал. Набор из перерисованных карт про Восточный фронт убран, и теперь там в трёх миссиях изображается реальная местность острова Гуадалканал.
Ссылка на оригинальную статью на английском: How much should we freak out about Silksong – How To Market A Game
В начале августа я перенес выход своей игры TOTAL RELOAD с сентября на ноябрь, а через две недели объявили дату выхода Hollow Knight: Silksong. Я как будто что-то знал.
Повлиял ли на вашу игру выход Hollow Knight: Silksong?
КДПВ
9 месяцев назад я написал ответ на пост про создание игр , и хотел спросить нужна ли игра у которой основной механикой является кодинг.
Пост утонул в ответах и никому не был интересен. Но тем не менее, что-то сам себя воодушевил и решил вновь поставить Юнити и попробовать что-то сделать. Скажу сразу игра еще не написана, мало того, не сделано даже и 15% того, что задумал, но я продолжаю ее писать - а этот пост или серия - скорее для само-мотивации и советов. :-) И так как я Нуб в геймдеве - "настоящие сварщики" - могут не читать, ничего технического и нового тут, они не увидят, хотя могут меня попинать за что-то, что наверное тоже на пользу.
Краткое описание сюжета: конечно это выживач :-) - ну я люблю выживачи. Но слава богу - без Зомбарей! А сюжет изначально был такой - наш герой юный программист(А точнее вообще не программист, а болван из колледжа не знающий ничего ), слабый физически переносится на 850 лет вперед. Человечество вымерло, природа восстановилась, кругом леса и остались роботы. Роботов много, но большая часть неисправна и враждебна. Цель конечно выжить, понять что случилось, вернуться обратно и спасти человечество от вымирания. Попутно научившись кодингу - так как без него этот дохляк тут не выживет.
Вы скажете - такой сюжет и геймплей никому не нужен! Ну или нужен паре задротов и мне. И наверное будете правы. Но мало ли... может кому понравится и потом это скорее для наработки навыков работы с юнити для меня и просто for fun... Плюс у меня дочь которая любить игры, и видит свое будущее так или иначе связанное с ИТ - поэтому с ней советуюсь и может быть когда нибудь она сможет в это поиграть.
Немного отступлю для классического- "Здравствуйте все, Я Тульмон и я Программист. Здраааавствуй... " Ну в общем все верно - только кодю на работе я на php. Но c# в целом прост и понятен. Проблемы у меня в основном с моделлингом и всяким прочим визуалом.
Так или иначе, в новогодние праздники сел за код игры. А сел я за него, вместе с DeepSeek-ом - ибо в юнити шарил слабо(да и сейчас тоже не особо ). Ну а коли у него спрашивал про код, решил с ним и общаться по гемплею и сюжету. Он в целом давал прикольные рекомендации типа такого (тут у него спрашиваю как наш поцык вообще попал в будущее ? ):
Эта мысль мне показалась забавной - ведь нужен какой то учитель этого лоботряса, так что это тоже стало частью сюжета. Потом он мне подавал еще пару занятных идей но о них позже чтобы не нарушать хронологию.
На начальном этапе самым трудным мне казалось встроить внутрь игры интерпретатор какого либо языка. Я посмотрел варианты:
- встроить C# - это для меня как начинающего показалось лютым гемором.
- встроить Lua - это было бы просто, но я ненавижу луа :-D (простите меня луа-воды - но так пошло с esp8266 там можно было кодить на плюсах или луа, и все делаю на плюсах, а от луа чот тошнило)
И вдруг мне подвернулся такой вариант MiniScript https://miniscript.org/
Чел запилил неплохой скриптовый язык , и у него даже есть ассет для встраивания в юнити. А так же свое коммюнити . И подумал что мне как новичку это будет несложно, а для того что задумал там все есть. И потом - задача не научить игрока C#, PHP или lua - а научить просто мыслить циклами, алгоритмами, переменными ну вот этим вот всем программистическим.
Тут мануал- https://miniscript.org/files/MiniScript-Manual.pdf и там в целом все что нужно есть.
Асет купить не смог ввиду сложности с оплатой в сторе, но автор сам пишет что ассет это опционально - и можно встроить и так.
Что я и сделал. Быстро накидал редактор скриптов, создал коробочку повешал на нее все что там требуется и подумал что мне понадобятся кастомные команды - благо там это делается достаточно просто - и сходу бахнул туда move() и turn() - ну а что? - самое нужное для роботов.
И ЭТО СРАБОТАЛО!
Я Очень веселился. Вот гифка того периода - подхожу к коробке нажимаю F2(тогда было так да...) Открывается реадктор кода в котором последовательные команды. Потом нажимаю пуск - и робот(коробка) - ползет и поворачивается - не потому что так написал разработчик игры(я) а потому что так закодил игрок (пока тоже Я :-D ).
Клево! А теперь надо добиться плавного поворота - для этого попробую заюзать корутину! И не тут то было - я получил лютую дичь!
Оно делало все и сразу! Покопал, покопал это дело но как то безрезультатно. И решил написать разработчику - ну с чем черт не шутит .
Ответа не ждал , но он последовал достаточно скоро!
Автор посоветовал не использовать корутины, а просто уже внутри моей функи немного двигать объект и при этом выдавать false пока не подвинем полностью. Что я и сделал и все стало просто и понятно и заработало так как следовало!
Чтож, теперь у меня был понятный инструмент для создания любых своих команд этому языку и куча пространства для творчества.
Тут стоит сказать, что пока я ломал голову над выполнением кода за 1 раз и ждал ответа автора минискрипта добавил :
- Роботика Фиерро - взяв конечно бесплатную модельку из асетов (к слову вчера смотрел у дочери R.E.P.O - имхо там та же моделька)
- Зачем то поменял ассеты графония на более яркие и мультяшные. Сейчас смотрю на старые гифки и думаю - зачем я это сделал...
- Систему диалогов текстовых. В целом взял некий ассет и просто допилил ему ветвление и разные состояния в зависимости от стадии игры. Могу это потом детально описать если кому то надо будет
- Менюшку управления роботом чтоб не держать в памяти все эти F2, F4 итп. Менюшка возникает при наведении на робота и дает доступ к редактору кода и запуску скрипта.
- Еще какие то мелочи типа баров - еды, здоровья, обведения предметов на которые смотрю и прочее баловство.
Следующее, что мне пришло в голову была система Батареек для роботов! Да не сильно логично в рамках этапов создания игры... но мне показалось правильным сразу сделать чтоб при выполнении скриптов роботы тратили энергию. Так было в Colobot - и мне это там нравилось . Я подумал пусть будет некий квант энергии, а разные операции тратят разное кол-во квантов за кадр. Ну например sin или там if() совсем мизер, а move или позже shoot или build гораздо больше. И пусть будут 2 типа батарей обычная - будем ее делать из гавна и палок потом и продвинутая из плутония какого-нить и разной емкостью. В общем вот что из этого вышло. (Сорри - тогда писал все в гифки почему то)
Как видно из гифки, у нас 2 коробки с разными батареями и одинаковым кодом, и синяя работает гораздо дольше. Ну и видно как они садятся. Над балансом конечно еще поработаю ибо садятся они крайне быстро но пока это был просто тест работоспособности.
На этом наверное закончу первую часть, не потому что, как тут пишут - кармадрочер, а потому что хочу даже для себя разбить на части и этапы по мере того, как мне приходили в голову разные идеи и их реализация, а во вторых может вы скажете выкладывать ли код или как реализовано то или иное. Хотя конечно это может быть интересным только новичкам в геймдеве. Возможно вы скажете - наоборот не углубляться в код, а просто описывать, что я придумал и как оно реализовано. А может быть, вы вообще ничего не скажете - что тоже результат конечно :-D
А вообще - подытожив, хотел сказать вот что: подзабросил написание игры весной, стало некогда и главное потерял смысл и мотивацию. Все твердили - накой черт учиться кодингу, тем более через игру если теперь код пишут машины... ИИ, дипсики вот это вот все. И верно подумал я! И думал так до прошлой недели, когда наткнулся на пост девушки(увы сейчас потерял его), что учит кодингу детей, она изучала ту же проблему (зачем учиться прогать, если есть ии) и пришла к выводу, что нужно учиться! Ибо будущее - не в замене прогеров - роботами, а в замене прогеров_без_роботов, прогерами_с_роботами. :-) Ну то есть она пришла к выводу, что не достаточно делать промт ии и тупо компилить его код - нужно понимать что он делает, и уметь поправить по мелочи. А значит нужно знать алгоритмы, условия, циклы, переменные итп...
Это как то мотивировало меня на написание этого поста и на восстановление работ по игре.
Так получилось что этот проект внезапно родился пока я создавал другой.
В мире блокчейна, разработка под экосистему ethereum очень сильно развита, много смарт контрактов "готовых", которые прошли аудит, много разных инструментов таких как Slither, Foundry, Hardhat и т.д., с ними комфортно писать контракты и тестировать.
Что делать со всем этим дальше? Нет инструментов которые бы меня устроили, или я не нашел, все идет на откуп команды разработчиков, то как они построят процесс обновления смарт контрактов, аудит, безопасность и т.д.
Честно говоря, на мой взгляд тут просто какой то бардак. Используются подходы к сопровождению проектов из обычной сферы разработки, но мы же с вами работаем с распределенным компьютером EVM и работаем почему то напрямую, без операционной системы.
Давайте вспомним что должна делать операционная система для классической ЭВМ:
Управление аппаратным обеспечением
Управление файловой системой
Предоставление интерфейса пользователя
Управление процессами и программами
Обеспечение безопасности и разграничения доступа
Управление пакетами, представьте сейчас любой Linux или MacOs без систем пакетного менеджера
EVM это тот же компьютер, только операционной системы под нее нет, есть просто разбросанный набор инструментов.
EVMPack это попытка создать что то хотя бы похожее на операционную систему для EVM совместимых блокчейнов, и первое что я реализовал, это пакетный менеджер, потому что это фундамент без которого ничего дальше не сделаешь.
У нас сейчас есть условно 3 источника откуда мы можем взять какие то библиотеки:
npm - по дороге со смарт контрактами мы тащим еще много зависимостей которые вообще к контрактам не имеют никакого отношения
foundry - фактически работает с гит репозиториями, получаем пакеты как сабмодули, но опять же, тащим по дороге кучу ненужного мусора по дороге с контрактами. отсутствует контролируемая система версионирования semver, подход не удобен для работы с жизненным циклом проекта
github - те же проблемы что и в foundry
И самое главное, ни один из вариантов не дает мне использовать готовую, проверенную, задеплоиную реализацию.
Есть уже огромное кол-во контрактов которые мы могли бы использовать не деплоя их и даже не клонируя.
Допустим есть реализация ERC20(самый популярный контракт для токенов) от крупной команды OpenZeppelin, если бы эта реализация была задеплоена и адрес этой реализации проверили сообществом.
Далее я могу развернуть простой прокси контракт, который только и делает что вызывает эту проверенную реализацию, а данные я напомню если кто не в курсе хранятся в самом прокси, а функции которые с ними взаимодействуют находятся в реализации. Сам прокси контракт один, его не надо писать, просто можно сделать одну кнопку "Создать токены" и быть максимально уверенным что все будет хорошо!
А теперь давайте добавим в эту всю историю SemVer версии 2.0.0. Получится что команда из OpenZeppelin выпускает новую версию этой реализации, она проходит так же проверку сообществом, и получает галочку - "проверено", в этот момент вам прилетает уведомление что у реализации которую вы используете для своего токена вышла новая версия, она проверена и можно без опаски обновиться, почитать что там нового добавили, что исправили. Далее вы просто нажимаете кнопку обновить и все! И таких как вы может быть сотни и тысячи которые используют одну и ту же реализацию, все вы толпой уверенны что никто не взломает этот контракт и не утащит ваши кровные токены, а так же все сообщество может легко проверить что вы никого не обманываете и используете проверенную реализацию.
Вот пример как это работает если это использовать другим смарт контрактом:
А теперь давайте увеличим масштаб, теперь мы будем работать не с одним пакетом, а с 5 или больше, ведь мы захотели построить свое приложение.
Мы заходим в стор evmpack (которого пока нет, но это не на долго) и смотрим какие есть уже готовые и проверенные реализации, видим что есть удобный контракт управлением пользователей, доступом, и т.д. И далее просто собираем один контракт который будет использовать готовые реализации нужных версий, evmpack проверить совместимость, и хоба! у вас уже есть готовый бэкенд на блокчейне который готов к продакшену практически сразу и вам провести аудит нужно только одного контракта! Процесс аудита можно так же легко встроить в эту систему, потому что ваш готовый бэкенд тоже является пакетом и вы его так же публикуете с версионированием и реализацией, если вам захочется что то добавить, то вы выпускаете новый релиз реализации, и уже после того как прошли аудит снова можете обновлять.
Вот ссылка на репозиторий - https://github.com/EMVPack/core
Всю обратную связь по проекту лучше пишите на github в issue, критику тоже, потому что спорных моментов может быть много и хорошо бы делить на разные дискуссии.
В следующих постах я буду создавать большой проект с использованием этого инструмента и показывать наглядно что и как, так что цикл статей объявляется открытым!
Если кому интересно, то в ТГ канале я буду писать о проблемах по дороге разработки, объявлять о стримах на которых буду разрабатывать проект.
