Та пофиг, что добавить, вот что интересно, взлет не взлет меня не интересует
Добавляй то, что тебе интересно, во что бы ты сам поиграл. Если ты сам не знаешь зачем делаешь, то зачем вообще браться?
На чем сервер?
Был тут уже один долбоёб, который похожую хуйню с колобками делал.
Если у тебя тайлы - то какие коллизии? Проверяй тайл занят/не занят и разрешай/запрещай движение.
Лол, точно, после работки туплю сижу, благо завтра выходной
1218x566, 0:10
>Браузерка
Еб твою мать.
По-моему, на прямоугольной сетке тоже может нормально выглядеть, зато ассеты делать полегче будет.
Это если руки не из жопы. Если они не из жопы, то и текстовый квест будет выглядеть более чем нормально.
Автор, это не ты лет 5 назад выкатился с зоны и делал 3д-игру про колобков, которые катаются и стреляют?
Это так, но я не художник, а для TOP-DOWN игры нужен талант, особенно в 2020, но я обнаружил что обычные 2D Координаты легко конвертнуть в изометрию, только немного непривычно с координатами работать.
Это и так будет РПГ, я думаю на счет пошаговой боевки, сеттинг с большой вероятностью фентези
1920x1080, 0:45
- Полностью перевел игру в изометрию, но сохранил урезанный TOP-DOWN клиент
- Движение теперь полностью обрабатывается на сервере, игрок может только отправить данные куда он хочет двигаться, раньше за это передвижение полностью отвечал клиент
Сделай изометрию с приятной плоской текстурой ландшафта, а не этот паинт.
И йоб желательно заменить на элементарные спрайты с анимацией, для начала в пикселе хотя бы.
Тебе не трудно - тем кто заглянет, приятно
Вот мои простые спрайты, на коленках делал, если есть возможность, перерисуйте, я пока занимаюсь кодом
Была такая мысль, но кто то уже делает рим ворлд по сетке, да и как это будет в ММО смотреться? Ты же имеешь ввиду непрямое управление персонажем?
Нужен компактный шрифт
Как же хочется в хих, хоспаде.
Что ты пытался? Почему тайлы бледные, как твое лицо, когда игру не пустили в стим? Почему тайлы не симметричные, блядь?
Я не ОП.
> Почему тайлы бледные, как твое лицо, когда игру не пустили в стим?
Терпеть не могу насыщенные и яркие цвета. Но чет да переборщил.
>Почему тайлы не симметричные, блядь?
Тут я ниибу, я мимопроходил и использовал >>639564 как маску.
На будущее, если у кого появится вопрос:
>нахуй делаешь если не умеешь
Потому что никто ОПу не помогает, а это хоть что-то.
>Потому что никто ОПу не помогает
А нужно ли? Пока что мы видим только школьника, впервые решившего сделать мам-ммо, из говна и браузера. Не имея никаких наработок он высрал невнятное поделие, без описания, планов, и чего-либо. Очевидно что он сольется через месяц, просто потому что не осилит.
Ну да.
> из говна и браузера
вэй вэй, ващет я написал сервер на чистом Go, хорошо что сам язык позволяет так легко и просто писать на нем. Клиент на js, так что можно и декстоп клиент сделать и даже на мобилку, использую библиотеку Phaser, а не модные нынче движки и конструкторы, очевидно что я уже сделал более менее рабочий прототип, нужно проработать концепцию и стилистику, определится с боевой системой и т.д.
1. Универсальный вариант, в браузере.
2. Думаю
3. Песочку квесты не очень нужны, но я думал над созданием мирных городов, где можно будет их выполнять.
4. Как в раннем TZ
Все это в процессе вполне корректируется и изменяется
>1. Универсальный вариант, в браузере.
Я имел в виду ссылку. Подними бэк на каком нибудь хероку.
Или в докер запихни и на любом PAAS сервисе разверни.
>3. Песочку квесты не очень нужны, но я думал над созданием мирных городов, где можно будет их выполнять.
Квесты не нужны, но нужна как минимум затравка. Интересные ситуации сами собой не возникнут. Расы, противоборствующие стороны, конфликты, хоть какой нибудь маломальский лор.
Какую книжку читал последней или какая понравилась больше всего? Вот и копируй оттуда.
>4. Как в раннем TZ
Что это?
Зачем деплоить сырой прототип, который будет еще и падать иногда? Как только будет более менее рабочий вариант, я обязательно запущу его
>>639811
Хорошая идея, но я сначала хочу сделать основу, на которой можно будет строить полноценную игру, нужно так-же учитывать что я делаю только в свободное от работы время.
>Что это?
TimeZero
Ну как минимум раньше жеско разделялось все на профы, копалка в шахтах копает, сталкер охотится на монстров и т.д. Для получения профы приходилось делать сложные квесты и тратить очки перков не в боевые навыки, а в профессиональные. Из ресурсов делалось все, оружие, броня, химия, производили их владельцы фабрик, производили все по купленным чертежам. В каждом городе в шахтах были свои уникальные ресурсы, ну короче тебе лучше почитать, благо игра не ноунеймовая, но я думаю за основу именно такую систему взять
typescript дело хорошее, хотя в голове за тебя держать он объекты не будет) Можешь чуток порисовать в uml
А что по твоему нынче популярно?) Для рендера тот же phaser юзаешь или мб что-то more fancier типо pixi.js?
Да, для рендера тупа Phaser юзаю, легко и удобно
Если больше 16, то лучше задумываться делать то, что изи поднимется. По тебе видно, что ты не опытный в сфере геймдева.
Первые проекты делаются такими, чтоб подняться. Не оч потными и не рискованными.
Ты же делаешь ПОШАГОВУЮ ММО в 2020
На счет ммо я не имею ничего против, сам задротил. Но этот жанр морально устарел, и ничего кроме вова после открытия не держится +- норм(даже ААА, да и сам вов тонет)
Пошаговую ето уже страшно
Попытайся делать другой проект, там подняться сможешь, а после - соберешь команду, да сделаете.
Проект подобный те в соло не осилить бро
ВОт ты сделаешь - и что дальше? Как сервера держать будешь? Как организовывать?
А держание сервера - окупиться?
а кроме етого вопроса есть еще множество, которые тоже сложные, и(если не дурак), то поймешь что останешься без почки если попытаешься реализовать это сейчас. А если ты это делаешь тупо для опыта, то искать стак братьев(команду аутистов ) выгоднее в этом плане + имя сделаешь в паблик-медиа
ток жанры выбирай по перспективнее и движок модный аля говноюнити-гмк-анрил
>На счет ммо я не имею ничего против, сам задротил. Но этот жанр морально устарел, и ничего кроме вова после открытия не держится +- норм(даже ААА, да и сам вов тонет)
Просто забирают себе часть рынка
>Пошаговую ето уже страшно
Мне нравятся пошаговые бои
>Попытайся делать другой проект, там подняться сможешь, а после - соберешь команду, да сделаете.
Другой проект это стрелялочку для детей? Я ващет думал игру по самосбору сделать, мой механизм бесконечной генерации мира подойдет и для генерации гигахруща
>Проект подобный те в соло не осилить бро
http://www.westward-online.com/
>ВОт ты сделаешь - и что дальше? Как сервера держать будешь? Как организовывать?
До этого слишком далеко
>а кроме етого вопроса есть еще множество, которые тоже сложные, и(если не дурак), то поймешь что останешься без почки если попытаешься реализовать это сейчас. А если ты это делаешь тупо для опыта, то искать стак братьев(команду аутистов ) выгоднее в этом плане + имя сделаешь в паблик-медиа
Все вопросы решаемы, а местные аутисты это клепатели аркадок на движках
>ток жанры выбирай по перспективнее и движок модный аля говноюнити-гмк-анрил
Предпочтения в жанре всегда меняются и не люблю по чужим лекалам работать, движки это всегда лишние зависимости и т.д., есть хорошие годные библиотеки
>>640014
Ладно, вкину тебе идей
Пилишь ММО - значит упор делаешь на взаимодействие игроков. Нужен блок механик, которые будут ставить геймплей так, чтобы поощрять эти взаимодействия
Самое простое решение - деление персонажей на классы, как это реализовано в том же варкрафте, т.е. у одних персонажей есть опция торговать лицом, но нет опции наносить урон, а у других - кидать фаерболы, но такие не могут терпеть урон. Если развивать эту идею, то такой "маг" быстро складывается, у него сбиваются касты etc. подумой.
Подумол, понял, что игроки будут выбирать дпс-магов и игнорировать скучных орков-танков и решил уравнять всех игроков и сделать игру про волшебников. Тогда заставь их выбирать вектор развития своих школ магии, чтобы сделать их все равно разными и толкнуть на пресловутое взаимодействие, по типу - маг льда фиксирует огра, маг молнии бьет, а маг воды баффает урон. Сделай разнообразнее - заклинания льда не работают на железного голема, но зато школа огня плавит ему ноги, не давая ходить, превращаясь из урона в контроль. Что бы ты там не делал, если боевая механика центральная в твоей игре, то сделай её интересной и командной.
Но бой - не единственное, чем игроки будут заниматься в ммо, как не старайся. Когда они обнаружат, что шанс выпадения $ФЕСКИ ВЕЛИКОГО ШАТАТЕЛЯ$ 0.01%, а она дает аж +2 к силе шатания, они её захотят. И чтобы реализовать свои влажные мечты побегут на заранее приготовленный тобой аукцион, где часами будут пытаться порешать рыночек, добиваясь приобретения вожделенного головного убора.
И начнется - фарм мобов, профы, кланы, чтобы этим бесконечным гриндом было хоть сколько-то весело заниматься.
Как ты понимаешь, следуя моим советам ты сделаешь очередную невыразительную дрочильню. Чтобы этого избежать не следуй моим советам, за исключением двух вот этих:
1) Еще раз, все что ты делаешь - ты делаешь чтобы заставить игроков взаимодействовать друг с другом.
2) Не забывай про баланс. В ммо он такой - чтобы заработать на шапку ты можешь 2 дня бить мобов или 2 дня собирать реги для крафта.
Помни: геймдизайн - это наука про выбор, которого на самом деле нет
>>640014
Ладно, вкину тебе идей
Пилишь ММО - значит упор делаешь на взаимодействие игроков. Нужен блок механик, которые будут ставить геймплей так, чтобы поощрять эти взаимодействия
Самое простое решение - деление персонажей на классы, как это реализовано в том же варкрафте, т.е. у одних персонажей есть опция торговать лицом, но нет опции наносить урон, а у других - кидать фаерболы, но такие не могут терпеть урон. Если развивать эту идею, то такой "маг" быстро складывается, у него сбиваются касты etc. подумой.
Подумол, понял, что игроки будут выбирать дпс-магов и игнорировать скучных орков-танков и решил уравнять всех игроков и сделать игру про волшебников. Тогда заставь их выбирать вектор развития своих школ магии, чтобы сделать их все равно разными и толкнуть на пресловутое взаимодействие, по типу - маг льда фиксирует огра, маг молнии бьет, а маг воды баффает урон. Сделай разнообразнее - заклинания льда не работают на железного голема, но зато школа огня плавит ему ноги, не давая ходить, превращаясь из урона в контроль. Что бы ты там не делал, если боевая механика центральная в твоей игре, то сделай её интересной и командной.
Но бой - не единственное, чем игроки будут заниматься в ммо, как не старайся. Когда они обнаружат, что шанс выпадения $ФЕСКИ ВЕЛИКОГО ШАТАТЕЛЯ$ 0.01%, а она дает аж +2 к силе шатания, они её захотят. И чтобы реализовать свои влажные мечты побегут на заранее приготовленный тобой аукцион, где часами будут пытаться порешать рыночек, добиваясь приобретения вожделенного головного убора.
И начнется - фарм мобов, профы, кланы, чтобы этим бесконечным гриндом было хоть сколько-то весело заниматься.
Как ты понимаешь, следуя моим советам ты сделаешь очередную невыразительную дрочильню. Чтобы этого избежать не следуй моим советам, за исключением двух вот этих:
1) Еще раз, все что ты делаешь - ты делаешь чтобы заставить игроков взаимодействовать друг с другом.
2) Не забывай про баланс. В ммо он такой - чтобы заработать на шапку ты можешь 2 дня бить мобов или 2 дня собирать реги для крафта.
Помни: геймдизайн - это наука про выбор, которого на самом деле нет
Добавлю
Если хочешь вызвать у игроков разрыв шаблона и отличиться - используй в качестве основы для своей ролевой системы ролевую систему для нри.
За столом очень мучительно подсчитывать хит-поинты, и модель урона в них часто принимает вид: бросаешь 3д6.Чтобы убить слабого врага нужно выкинуть 8+, среднего 10+ и сильного 13+. На соседней доске /bg/ есть тред с целым архивом спираченных рулбуков разных ролевых систем. Спизди у них, покопайся, может найдешь что-нибудь интересное для себя.
Кстати, да, тоже задумываюсь о балансе, по любому будет какое-то имбовое направление, но до этого еще далеко конечно, надо техническую часть сделать
хуита, согалсен
Играюсь с разрешением
Ты ему советы даёшь, как будто у него игра готова. У него всё, что есть это блядский перс, который перемещается по одной локации. Даже наблюдателя нельзя сделать. И сервак у него валится, если он хочет сделать любое действие.
> У него всё, что есть это блядский перс
Несколько персонажей*
>который перемещается по одной локации
Бесконечно генерируемому бесшовному миру, который использует чанковую систему
>И сервак у него валится, если он хочет сделать любое действие
Валится при попытке зайти за персонажа который уже в игре
привет, а какие-нибудь библиотеки юзаюешь для игрового сервера
собирабсь пилить игрулю, нужно будет сервер замутить, я могу в ноду джс, но по опыту знаю для риалтайм будет хреново, я писал бэк на ноде на одном проекте по поиску авиабилетов, в итоге чтоб съэкономить на железе позвали чувака, который все на го переписал
ты случаем пикрил не читал, я заказал просто ее
Да, норм книженция, но можно и без нее обойтись, библиотеки все стандартные
Это иллюзия из-за того что на карте 16х16 было больше объектов, одинаково убого смотрится, я жи понимаю что говно, ибо в тестурки я вкладываю максимум 5 минут, и сейчас у меня заказ крупный и времени нет пока развивать проект, но на вырученные деньги думаю нанять художника, щобы он мне спрайты нарисовал
мимо ОП треда
Завтра сдаю проект и возвращаюсь к игре
Можно и нужно!
>вдруг решил что сингловые игры уже морально устарели и всем нужны именно ММОшки
А с чего это ты решил? По мне так как раз ммо и сетевые игры уже порядком подзаебали, и очущается острый дефицит хороших синглплеерных игр.
>По мне так как раз ммо и сетевые игры уже порядком подзаебали
Они подзаебали, потомущо их делают на конвейере
Они заебали, потому что кругом метаблядки и гайдопетухи, от игры с ботами в синглах интереса и разнообразия уже реально больше
Самые первые образцы мне понравились, а изометрия твоя — хуйня без души, ломающая глаза. Да, есть много хороших изометрических игор, но твоему проекту реально лучше было в оригинальном виде. Сейчас ты мне просто Рогалию напоминаешь.
Ты ведь в курсе печальной истории хахача уровня гд - рогалии?
Ну значит приобщайся к наследию дидов.
https://2ch.hk/gd/res/315944.html (М)
https://2ch.hk/gd/arch/2017-12-26/res/213157.html (М)
https://2ch.hk/gd/arch/2015-09-01/res/186546.html (М)
Блять, пздц, по их стопам пошел, аж стыдно
Это Рунскейп уровня /б/?
804x518, 0:18
Да тут вроде вообще одна проекция, да рисуются ножки\ручки в фотошопе, анимируются в spine который не найти, blender или dragon bones, как раз буду пробовать так сделать в блендере, но это сложновато, во первых рисовать надо хорошо, изучить прогу по анимации, саму анимацию, как то все подогнать под стандарт одежды, оружия одноручное\двуручное. Вот в BB еще больше сократили затраты на анимацию, нет ног от рук только кулачки.
Ну это уже уровень кубов, в вот корейцы хорошо придумали
Идея сделать современную ммо в 1 рыло утопична даже больше, чем полёт на Марс в 2020 году.
Я скажу сколько времени тебе потребуется на подобную реализацию. Примерно 20-40 лет и то получится хуже, чем у любой студии из 30-40 человек.
Просто отсекай априори нелепую траты времени, чтобы после не оказаться в ситуации депрессии.
Всегда нужно делать что-то минимальное. Фичи и контент ты будешь запиливать уже после написания готовой игры. Сейчас все игры продаются до релиза, либо не продаются в принципе.
Ну хз, можно основу сделать , рабочий прототип, а дальше уже предложения пойдут и желающие помочь
Не РИП, я сейчас занят немного, так же переписываю алгоритм перемещения на поиск Пути - А, кумекаю вот, надо ли из всех тайтлов граф делать или на ходу перемещать, пока что у меня дичь выходит
Анон, я нахальный пидорас, покажи свой код? Не понимаю как оно всё работает и хочу почитать чужое. Можешь и не свой, может сам чьё нибудь читал и сможешь показать?
Лол, думаешь поймешь що я карябую?
Короче вот, статью на хабре сделал на случай если надоест разработку вести, а передать опыт ннадо бы
https://habr.com/ru/post/488752/
С тебя звездочка на гитхаб
https://lolodin.github.io/My2DGame/
Надо другую шумовую функцию найти
Ладно, для прототипа на коленке пойдёт
Теперь надо запилить двухсторонний A*, чтобы персонаж не ходил по воде
И уменьши камеру, чтобы всё было побольше и персонажа можн было хотя бы разглядеть
Игра давно в изометрии, а поиск пути вот калякую, вроде ласт функцию дописать осталось, но лень пздц
Мобов пилю, ща на РАБотку еще на гошника устраиваюсь
1. делаешь бесконечную генерацию до определенных пределов, сколько осилит сервер (даже у того же кубача есть лимиты в сколько-то миллионов чанков)
2. делаешь всех игроков на один сервер
3. делаешь игру в браузер с адресом типа nazvanie.io
4. делаешь цветные ники и шапки за донат
5. ???
6. PROFIT
Фенкс, я вот тут поиск пути набросал и думаю над боевкой и генерацией мобов, что вот лучше сделоть, щобы интересно было
800x480, 0:24
Загони ботов пачку туда. Часто такое бывает, что вроде хорошо работает, а потом при росте нагрузки оказывается, что потребление ресурсов растёт нелинейно.
> что вот лучше сделоть, щобы интересно было
1. Самое очевидное с такой "полу-пошаговой" системой, чтобы как в Рунескапе боевка была по принципу - нажал кнопку>персонаж сам подошел к мобу>персонаж начал бить автоатакой, если не прожимать доп скиллов
2. Сделать мобов разными в разных точках карты. Типа на юге карты мобы слабые, в центре посильнее, на севере самые грозные. Не знаю, что у тебя будет в плане прокачки-развития, но с такой системой будет какое-то ощущение прогресса.
Если карта бесконечная во все стороны - делай разные биомы. Типа в лесу максимум волки и медведи, а засыпанная снегом поляна спавнит каких-нибудь йети и ледяных големов и тд
>Еще раз, все что ты делаешь - ты делаешь чтобы заставить игроков взаимодействовать друг с другом.
Имхо бред. Что если игроков мало? Что если игроки конфликтуют? Что если игрок хочет аутировать где-нибудь в углу карты подальше от всех, изредка выходя к "цивилизации" для торговли? Лично я ненавижу, когда игра вынуждает на социальное взаимодействие. Я бы хотел ММО, в которой ты можешь играть с кем-то, но только потому, что сам этого хочешь, а не потому, что твой персонаж ничтожен без помощи других персонажей (чувствуешь себя ущербным даже в тупой игрушке, мне этого и в жизни хватает, и наверняка я не один такой). К тому же такое насильное сближение игроков заставляет создавать ботов, бегающих паровозом за главным персонажем, даже если ботоводство запрещено.
>Не забывай про баланс. В ммо он такой - чтобы заработать на шапку ты можешь 2 дня бить мобов
Это не "баланс", это "растягивание контента/прохождения". И у него есть очевидная мотивация - игроку будет скучно, когда он откроет весь игровой контент (получит все шапки, ачивки и т.д.), следовательно свежий контент нужно поставлять регулярно, а поскольку это трудно, освоение текущего контента делается максимально длительным. То, что в сингле ты можешь освоить за 10 часов, в ММО ты будешь осваивать 1000 часов, потому что если ты освоишь за 10, тебе станет скучно и ты уйдёшь в оффлайн, а у ММО просядет онлайн вплоть до следующего апдейта новым контентом (а часть игроков будет потеряна навсегда). Но это не имеет никакого отношения к игровому балансу. Если бы существовал способ создавать разнообразный контент для игры каждый день, то необходимости растягивать прохождение ММО не было бы, не было бы необходимости в гринде и т.д.
>>638913
>РПГ песочницу
"ММОРПГ-песочницы" - это когда ты спавнишься в центре огромного поля, полностью застроенного приватными некрасивыми или одинаковыми домиками, и около часа пилишь за пределы этого безобразия, чтобы собрать хотя бы веточки для своего убогого шалашика, который быстро разломают скучающие "бати" сервера? Я не понимаю, как люди в это играют... Вайпы и "саморазрушение" построек всё лишь усложняет: ты либо начинаешь играть за неделю до вайпа, либо твоя постройка разваливается сразу же, стоит тебе один день не зайти в игру для её починки. Кто в это вообще играет, мазохисты?
>>668025
>Накалякал поиск пути, чет месяц потратил
В чём проблема оставить только WASD/стрелочки? Откуда такое повальное увлечение мышкотырканьем? Это же извращение - "ходить мышкой". Сделай WASD, это намного удобнее - двигаешься одной рукой, а стреляешь, собираешь лут, выбираешь цель и т.д. - второй рукой. Для примера посмотри Realm of the Mad God - да, это ММО-шутер (2D), но управление там идеально, WASD-движение и мышка только для наведения прицела и окошек. Бесят ММО, которые зачем-то заставляют перемещаться мышкой, дебилизм какой-то. Знаю, "диды так играли и мы будем играть", но это реально неудобно и пора бы от этого отказаться, чай не 90-е. В древних играх на буквенные клавиши биндилось дохрена команд и потому ничего кроме мыши для движения не оставалось, но сегодня этим никто не парится, никому в современных играх не нужно биндить что-то именно на WASD, так что можно сделать адекватное перемещение персонажа без накручивания системы поиска пути (поиск пути для аватара игрока - даже звучит абсурдно). Да, у меня бомбит. :(
>>678106
>нажал кнопку>персонаж сам подошел к мобу>персонаж начал бить автоатакой
Бесит такое, из-за этого случайно агришь нейтральных мобов или бьёшь игрока, которого не хотел бить.
>Еще раз, все что ты делаешь - ты делаешь чтобы заставить игроков взаимодействовать друг с другом.
Имхо бред. Что если игроков мало? Что если игроки конфликтуют? Что если игрок хочет аутировать где-нибудь в углу карты подальше от всех, изредка выходя к "цивилизации" для торговли? Лично я ненавижу, когда игра вынуждает на социальное взаимодействие. Я бы хотел ММО, в которой ты можешь играть с кем-то, но только потому, что сам этого хочешь, а не потому, что твой персонаж ничтожен без помощи других персонажей (чувствуешь себя ущербным даже в тупой игрушке, мне этого и в жизни хватает, и наверняка я не один такой). К тому же такое насильное сближение игроков заставляет создавать ботов, бегающих паровозом за главным персонажем, даже если ботоводство запрещено.
>Не забывай про баланс. В ммо он такой - чтобы заработать на шапку ты можешь 2 дня бить мобов
Это не "баланс", это "растягивание контента/прохождения". И у него есть очевидная мотивация - игроку будет скучно, когда он откроет весь игровой контент (получит все шапки, ачивки и т.д.), следовательно свежий контент нужно поставлять регулярно, а поскольку это трудно, освоение текущего контента делается максимально длительным. То, что в сингле ты можешь освоить за 10 часов, в ММО ты будешь осваивать 1000 часов, потому что если ты освоишь за 10, тебе станет скучно и ты уйдёшь в оффлайн, а у ММО просядет онлайн вплоть до следующего апдейта новым контентом (а часть игроков будет потеряна навсегда). Но это не имеет никакого отношения к игровому балансу. Если бы существовал способ создавать разнообразный контент для игры каждый день, то необходимости растягивать прохождение ММО не было бы, не было бы необходимости в гринде и т.д.
>>638913
>РПГ песочницу
"ММОРПГ-песочницы" - это когда ты спавнишься в центре огромного поля, полностью застроенного приватными некрасивыми или одинаковыми домиками, и около часа пилишь за пределы этого безобразия, чтобы собрать хотя бы веточки для своего убогого шалашика, который быстро разломают скучающие "бати" сервера? Я не понимаю, как люди в это играют... Вайпы и "саморазрушение" построек всё лишь усложняет: ты либо начинаешь играть за неделю до вайпа, либо твоя постройка разваливается сразу же, стоит тебе один день не зайти в игру для её починки. Кто в это вообще играет, мазохисты?
>>668025
>Накалякал поиск пути, чет месяц потратил
В чём проблема оставить только WASD/стрелочки? Откуда такое повальное увлечение мышкотырканьем? Это же извращение - "ходить мышкой". Сделай WASD, это намного удобнее - двигаешься одной рукой, а стреляешь, собираешь лут, выбираешь цель и т.д. - второй рукой. Для примера посмотри Realm of the Mad God - да, это ММО-шутер (2D), но управление там идеально, WASD-движение и мышка только для наведения прицела и окошек. Бесят ММО, которые зачем-то заставляют перемещаться мышкой, дебилизм какой-то. Знаю, "диды так играли и мы будем играть", но это реально неудобно и пора бы от этого отказаться, чай не 90-е. В древних играх на буквенные клавиши биндилось дохрена команд и потому ничего кроме мыши для движения не оставалось, но сегодня этим никто не парится, никому в современных играх не нужно биндить что-то именно на WASD, так что можно сделать адекватное перемещение персонажа без накручивания системы поиска пути (поиск пути для аватара игрока - даже звучит абсурдно). Да, у меня бомбит. :(
>>678106
>нажал кнопку>персонаж сам подошел к мобу>персонаж начал бить автоатакой
Бесит такое, из-за этого случайно агришь нейтральных мобов или бьёшь игрока, которого не хотел бить.
>Для примера посмотри Realm of the Mad God
Блин, спасибо анонче, все же я наверное откажусь от изометрии, и буду пилить в таком стиле, мне понравился процесс игры, и стилистика, переделать клиент можно в две секунды, к тому-же я сохранил обычный топдовн клиент, поиск пути оставлю для ботов
Глядя на труды ОПа задумался над своей РПГ. Точнее задумывался-то давно и даже что-то частями пилил.
А тута решил забросить делать шутан и попробовать РПГ. Хочется чтобы рельеф/карта были красивыми поэтому сейчас делаю небольшой редактор карт безовсяких тайлов, но т.к. игра задумывается в 2Д, то встаёт вопрос над уровнями рельефа (имею ввиду всякие холмы, горки и тд).
Есть ли какие-то красивые\интересные реализации уровней рельефа для 2Д?
>реализации уровней рельефа для 2Д
ИМХО, лучше сразу забей, любая горка выше одного роста персонажа будет перекрывать собой большую территорию, на которой по логике могло бы быть что-то размещено, но из-за проекции (изометрия или сбоку-сверху - не важно) разместить там ничего нельзя. По той же причине в 2D эрпоге не бывает небоскрёбов, все домики 1-2 этажа - ведь если запилить небоскрёб, он займёт половину карты и за ним уже ничего не будет видно.
Так что обычно большую карту делят на кусочки, соединяя порталами-переходами: портал на вершину горы, портал в пещеру, портал в каньон и т.д. И если на таком кусочке и есть большая возвышенность, то она всегда на верхней части карты, вплотную к краю, а где-нибудь рядом портал на эту возвышенность (хотя на самом деле за порталом такая же плоская карта, но из-за других текстур кажется, что мы поднялись на гору).
Но если подумать, я бы вот хотел сделать типа 2.5D реализацию: карта состоит из 2D-тайлов, но при этом её можно вращать на 90 (60) градусов. Получается не одна проекция, а целых 4 (6 для гексагонов) - и вот тут-то и становится возможно увидеть, что расположено за горой или высоким домом, заглянуть за широкое дерево без "рентгена" и т.д. Можно спокойно пилить любые холмы и ямы, игроку просто придётся нажимать Q/E для разворота проекции. Хотя тут возникает вопрос - не придётся ли пилить слишком много дополнительной графики? Для каких-нибудь цельных домиков скорее всего да, а вот круглые (дерево, столб) и просто тайловые (горы) объекты, наверное, можно слепить из всё тех же ресурсов...
В общем, что-то вроде Don't Starve или того же RotMG - и там, и там есть вращение карты, однако в этих играх карты полностью плоские (не считая стен и порталов). Собсна не совсем ясно, зачем в этих играх нужно было делать возможность вращения карты, если все объекты мелкие и одинаково выглядят с любой стороны... Вот с крупными объектами было бы интересно, да.
> Так что обычно большую карту делят на кусочки, соединяя порталами-переходами
У меня пока задумка делать мир бесшовным. Порталы будут в города\подземелье.
Ещё думаю над тем как сделать воду, точнее чтобы берег был не тайловый, а красивые изогнутые линии + речки всякие.
А про графику и ресуры. Можно моделировать здания, деревья и тд, а потом рендерить их в текстуру (заранее имеется ввиду) под нужным ракурсом.
Как-то давно наткнулся на пикчу и захотелось сделать свой варик, но для соло игрока.
>я бы вот хотел сделать типа 2.5D реализацию: карта состоит из 2D-тайлов, но при этом её можно вращать на 90 (60) градусов. Получается не одна проекция, а целых 4 (6 для гексагонов)
Вот, сделал в Inkscape набросок того, как я это вижу. Получилось прикольно, но с шестиугольниками для вращения на все 6 сторон придётся сделать дополнительные тайлы; с квадратами было бы проще. Ух, теперь хочется такую игру запилить, хотя из идей только вот такая вращаемая карта, лол.
>>679498
>У меня пока задумка делать мир бесшовным
Тогда либо все горки/овраги будут низкими, либо придётся вращать карту как я предложил) У тебя на втором скриншоте видно, как высокие горы/столбы блокируют чуть ли не половину карты. Даже если позади них можно было бы пройти (в рпгмейкере вроде нельзя), без "рентгена" игрок слеп, да и размещать там что-либо как-то нехорошо.
>Ещё думаю над тем как сделать воду, точнее чтобы берег был не тайловый, а красивые изогнутые линии + речки всякие.
Тут два варианта:
- делаешь >9000 тайлов разных кривых берегов и ручейков, по желанию можно сделать автоматическое размещение подходящих кусочков;
- либо рисуешь реки как отдельные объекты (как дома или деревья), но тогда они не смогут быть длинными, иначе будут зря нагружать рендерер (хотя сегодня это мелочь, конечно). Нет, конечно, можно сделать их из кусочков, тогда будет как отдельная тайловая карта, но с другими параметрами тайлов (тайлы намного крупнее основной карты).
Хотя, имхо, если уж делать реки "гладкими", то и остальные тайлы/объекты должны сочетаться. Будет некрасиво, если реки выбиваются из общего стиля карты.
>Можно моделировать здания, деревья и тд, а потом рендерить их в текстуру
Знаю про это, но в любом случае это нагрузка на художника/свой художеский скилл)
>но с шестиугольниками для вращения на все 6 сторон придётся сделать дополнительные тайлы
Похоже, я ошибся, новые тайлы нужно рисовать только для вращения на 12 сторон, для вращения на 6 сторон достаточного всего одного набора тайлов. Попробовал вручную повертеть простенькую карту 5x5 - выглядит неплохо (хоть и немного странно), к тому же более-менее разобрался, как такие карты вообще строятся (на интуитивном уровне, лол). Осталось только допилить свой движок под это дело, сделать редактор карт, и можно делоть игоры)
Что думаете на счёт таких карт?
если что, я не оп, просто мимо пробегал и заинтересовался темой 2Д-(ММО)РПГ
> агришь нейтральных мобов
1. Как вариант - один раз кликнуть, чтобы просто выбрать целью а там уже кликнуть еще раз, чтобы начать атаку или нажать что-то еще для всяких там суперударов(если они будут)
если человек промажет и даблкликом - то ему лучше отойти от компа, пока еще по меню "Пуск" попадает
> бьёшь игрока, которого не хотел бить.
в 99% ММО пвп-действия включаются отдельной галочкой или вообще ограничены отдельным локациями(типа WvW в гильдварс2), так что не вижу особой проблемы - нейтрального игрока не заденет, враждебного атакует по правилам п.1
> Похоже, я ошибся, новые тайлы нужно рисовать только для вращения на 12 сторон
Нет
Их нужно нарисовать только с одной стороны, но нужно их структурировать и рисовать по слоям: вода, уровень земли 1, уровень земли 2 и тд
Алсо, для графики ещё хочу попробовать пикрелейтед - texture splatting
Если применять твою методу, надо будет ещё подумать как текстура ляжет на всё это при поворотах
>>для вращения на 12 сторон
>Нет
Я имею в виду, что шестиугольник мы можем использовать один и тот же для 6 сторон, а для ещё 6 сторон его нужно повернуть на 30 градусов. У меня шестиугольники смотрят в сторону зрителя всегда одним из углов, так вот чтобы они могли смотреть не углом, а одной из сторон, придётся их перерисовать (на самом деле это не гексагоны, а немного приплюснутые шестиугольники - ровный гексагон показался некрасивым). Но вообще тут ещё вопрос того, что изображено на тайле - если это что-то строго ориентированное (как табличка, строго указывающая направление) - придётся нарисовать 6/12 раз, иначе будет дезориентировать. В том же Don't Starve предметы всегда лицом к зрителю, и это немного раздражает/дезориентирует (лично я стараюсь карту не вертеть).
>рисовать по слоям: вода, уровень земли 1, уровень земли 2
А, ну да, забыл про это. Персонажи ведь всегда к какому-то из уровней принадлежат... Хотя в моём случае всё равно непонятно как это прикручивать к принципам ECS...
>Алсо, для графики ещё хочу попробовать пикрелейтед - texture splatting
Это ведь только для реалистичных текстур и сложных ландшафтов имеет смысл? В таких 2D РПГ ведь графика собирается вручную/полуавтоматически, это проще (посмотри тайлсеты для RPG Maker, например, как там сделаны переходы между водой и землёй).
> Я имею в виду, что шестиугольник мы можем использовать один и тот же для 6 сторон
Короче говоря, нужно поворачивать текстуру на гексагоне, а сам он всегда одинаковый.
> Хотя в моём случае всё равно непонятно как это прикручивать к принципам ECS
Просто не задрачивать ECS сильно.
Хранить уровень земли (если таковой будет) и номер гексагона. Тем более планируется ли переход между уровнями? Как персонаж спустится на воду или заберётся на холмик?
> Это ведь только для реалистичных текстур и сложных ландшафтов имеет смысл?
Что ты имеешь ввиду? Это я немного увлекался редактирование вакрафта и для неё создали редактор noggit. Там этой техникой разрисовывается ландшафт. Вот и подумал что вместо обычных тайлов можно попробовать её использовать.
> В таких 2D РПГ ведь графика собирается вручную/полуавтоматически
Над этим я тоже подумал. Можно вот такую методу применить https://archive.gamedev.net/archive/reference/articles/article934.html
>Короче говоря, нужно поворачивать текстуру на гексагоне, а сам он всегда одинаковый.
Ну да, но даже текстуру можно не поворачивать, если она равномерная со всех сторон и плоская. Какой-нибудь песок, голая земля или очень мелкая трава - какая разница, под каким углом смотреть, в таком масштабе изменения незначительны, особенно если текстуры мелкие.
>Просто не задрачивать ECS сильно.
Это уже костылирование будет, чревато лапшой, которой я пытаюсь избежать всеми силами. Подозреваю, что опять запутаюсь в архитектуре и буду переписывать с нуля очередной раз... но это даже интересно, пока получается.
>Тем более планируется ли переход между уровнями? Как персонаж спустится на воду или заберётся на холмик?
По ходу дела сымпровизирую. Или нет. Пока представляю как короткие прыжки. Надо сначала просто карту сделать, всё равно нет чёткой идеи игры, скорее попрактиковаться хочется)
>Что ты имеешь ввиду?
Я имею в виду, что для простых "мультяшных" тайлов а-ля классические RPG Maker'ские пилить какое-то сложное смешивание текстур - оверкилл. Тем более, что такие тайлы рисуются вручную, и программное смешивание может плохо выглядеть - лучше пусть этим займётся художник... А вот с фототекстурами - другое дело, их вручную смешивать слишком трудно/нет смысла, программно получится не хуже.
>Можно вот такую методу применить
Интересно, мельком просмотрел статью - похоже, то, о чём я когда-то задумывался, давным-давно было решено) Всего-то нужно оставить часть тайла прозрачной и накладывать на другой тайл...
Мне кажется, мы мешаем ОПу, всё-таки это тред его проекта, а не просто любой 2д мморпг...
> Это уже костылирование будет, чревато лапшой, которой я пытаюсь избежать всеми силами.
Тогда у тебя все эти компоненты будут разбухать на все случаи игры
> пилить какое-то сложное смешивание текстур - оверкилл.
Ну вот грейвярд кипер выглядит классно
Правда, я как-то раз смотрел. Там многое сделано из готовых чанков.
Вот, например, речка состоит из двух берегов, а где сама вода - там ничего нет, просто пустота.
800x600, 0:07
>Тогда у тебя все эти компоненты будут разбухать на все случаи игры
Так ведь суть ECS - на каждый случай игры создавать отдельный компонент, и на каждый компонент создавать отдельную систему для работы с ним. Хотя зачастую одной системе нужно несколько компонентов для работы... Сейчас вот мне потребовался компонент для слоя карты, компонент палитры тайлов и уже имевшийся компонент текстуры (в составе палитры), а работает с этим только система карт (пока только рисует).
>Ну вот грейвярд кипер выглядит классно
(усиленно пытаюсь не сравнивать свои убогие потуги в геймдев с чужими играми)
Мне кажется, для такого всё-таки художник нужен, а не какая-то особая фича движка...
> Так ведь суть ECS - на каждый случай игры создавать отдельный компонент
Это дико бесит, меня по крайней мере.
Вместо того чтобы взять bbox игрока и сравнить с bboxами, например, предметов чтобы их подобрать, нужно придумывать разные компоненты для этого.
> Мне кажется, для такого всё-таки художник нужен, а не какая-то особая фича движка...
Нужен человек со вкусом просто.
800x600, 0:03
>Это дико бесит, меня по крайней мере.
Ну, не знаю. Вроде логично, если, например, для расчёта здоровья монстров используется тот же компонент, что и для расчёта здоровья игрока, только с поправкой на шмотки (тоже компоненты). С одной стороны слишком мелкий компонент, но зато как удобно - что угодно можно оживить, наделив здоровьем, или точно так же сделать бессмертным, отобрав компонент здоровья. :D
>Вместо того чтобы взять bbox игрока и сравнить с bboxами, например, предметов чтобы их подобрать, нужно придумывать разные компоненты для этого.
Эм? Если это для обработки коллизий/физики, то этим занимается отдельная система. Если где-то ещё потребовалось узнать, сталкивается ли игрок с чем-то - достаточно проверить компонент коллизии, а наполняется он системой коллизий автоматически (в первую очередь для системы физики). Т.е. компонент коллизии потребуется в любом случае, если есть физика, а вот для каких-то особых взаимодействий с предметами новый компонент уже не нужен - достаточно проверить состояние компонента коллизии (в нём будет лежать флаг "есть столкновение!" и ссылка на виновника столкновения).
Но вообще это тема для другого треда, наверное)
>Нужен человек со вкусом просто.
Человек со вкусом не обязательно умеет рисовать, а умеющий рисовать обычно вкус имеет)
>>680042
Добавил слоёв - получились холмы; осталось реализовать повороты и ещё кучу всего, если делать игру.
Мучаюсь: мне создавать свой тред, чтобы уже там хвастаться? Я пока не уверен, что смогу развить из этого наброска какую-то серьёзную игру, изначально хотел просто показать, как это могло бы выглядеть. Идеи на подобную тему когда-то давно были, но теперь я понимаю, что не смогу красиво всё нарисовать, а брать чужую графику/покупать/заказывать не хочу...
> а вот для каких-то особых взаимодействий с предметами новый компонент уже не нужен - достаточно проверить состояние компонента коллизии (в нём будет лежать флаг "есть столкновение!" и ссылка на виновника столкновения).
Ну вот, например, пекмен. Там есть предметы которые игрок собирает. Чтобы не городить какие-то ссылки на другие сущности, достаточно циклом пройтись по массиву предметов и сравнить bboxы с игроковским. Если есть пересечение, то считается что предмет подобран и его можно не рисовать на экране и дать игроку бонус какой-то.
>Ну вот, например, пекмен. Там есть предметы которые игрок собирает.
Ну, пакман - маленькая простая игра, в ней, наверное, действительно нет смысла "городить" ECS. Но мы же в треде ММОРПГ, так? Даже если это маленькая инди-ММО, она должна иметь большие возможности для расширения. Пакмана не нужно расширять, ты напишешь его один раз и забудешь, и нет особой разницы, как реализован подбор предметов. А вот в постоянно обновляемой ММО это важно. Важно, чтобы код был расширяемым.
Вот ты собираешься
>циклом пройтись по массиву предметов и сравнить bboxы с игроковским,
а где ты это будешь делать? В обработчике поведения игрока, типа player.update? А сколько подобной логики там будет сконцентрировано? А если понадобится лишить игрока части этой логики, без ущерба остальным сущностям? А если вдруг захочется сделать так, чтобы монстры тоже собирали предметы? А если вдруг понадобится, чтобы у каждой подбираемой вещи были свои условия подбора? И т.д., и т.п. Лень выдумывать, но можно выдумать массу способов расширения геймплея, из-за которых код игрока будет разрастаться, а контроль над ним - теряться. Ну и кроме игрока, монстров и подбираемых предметов могут быть и другие сущности, их нужно как-то внедрять в уже имеющуюся базу кода...
А, да, обычно пытаются решить проблему переиспользования кода через ООП - не писать же код передвижения отдельно для игрока и отдельно для монстров, проще унаследовать их от общего класса "подвижные сущности" или более сложного "животные". Но такой подход порождает множество трудностей и решающих их костылей - и вот ECS придумана в первую очередь решить эти проблемы, отказаться от сложного дерева наследования в пользу композиции из компонентов. Поэтому-то на примере пакмана профит ECS незаметен - в пакмане мало зависимых классов сущностей, нечему запутываться, нечего распутывать.
...так, ладно, я могу на эту тему слишком много говорить. лучше б игры делал
>эххххх завидую я вам, на юнити наверное быстрее писать чем самому корябать на Го и ЖСе
Кому завидуешь?
Я это >>680042 >>680336 на FreePascal с SDL2 сделал (мог и без SDL2, но надоело копаться в различных API; может потом как-нибудь откажусь и от SDL2). Заготовка движка с системой ECS была готова с декабря (в очередной раз переписана с нуля, теперь ещё более ECS-но, чем ранее), но я не знал, куда её можно было бы применить с учётом моих ограниченных навыков. Идея с гексагональной картой показалась интересной, решил попробовать, тем более идея "Don't Starve"-подобной игры несколько лет вертится... Ну и на реализацию нужных компонентов с системой, примитивную генерацию и многослойный тест суммарно ушло около 3-4 часов - в то время как на Unity или Godot можно было бы просто набросать стандартных компонентов или взять готовый ассет... Но мне не хочется натягивать графику на готовые компоненты готовых движков, мне интересно самостоятельно изобретать велосипеды и видеть, как они начинают работать) Наверное, эффект IKEA - готовый движок или библиотеку ты просто берёшь и используешь, а с нуля всё делаешь своими руками, оттого выше интерес и ценность самодельного движка. Игру так сделать труднее, но интереснее, если всё получается)
Может потом тоже попробую сделать сервер (тоже на FreePascal), но онлайн-игры имеют множество собственных проблем, с которыми мне не хочется сталкиваться. В итоге можно долгое время совокупляться с чисто сетевыми проблемами, забыв о геймплее и контенте для игры... А ведь потом ещё этот сервер где-то поддерживать нужно, а у меня нет белого IP и не хочется оплачивать VPS/VDS ради онлайна в 1.5 человека включая себя. Т.е. сетевые игры намного труднее даже без какого-либо сложного контента/геймплея (как те .io-игры).
>Может потом тоже попробую сделать сервер (тоже на FreePascal)
Не, на поскале это будет совсем муторно делать, надо учесть что у тебя будет общие данные, которые как то распределять между потоками нужно, хз как на паскале это проворачивают
> а где ты это будешь делать? В обработчике поведения игрока, типа player.update? А сколько подобной логики там будет сконцентрировано? А если понадобится лишить игрока части этой логики, без ущерба остальным сущностям?
В классе Game (он ведь по мимо этого содержит и информацию об игре) функция Update/Frame
У игрока функция Touch которая принимает указатель\ссылку на предмет
Функция может просто возращать булево значение и уже потом решать какой бонус дать игроку, а можно реализовать логику прямо внутри неё
> А если вдруг захочется сделать так, чтобы монстры тоже собирали предметы?
Делаешь им функцию Touch
Ну потоки на паскале делаются легко, для этого есть простой в использовании класс TThread. Для сети тоже есть куча компонентов/модулей, но я только когда-то давно пробовал по туториалам использовать компоненты для HTTP и UDP на Delphi, с тех пор с сетью никак не взаимодействовал, не было интереса/задач, так что это новая тема для меня. Главная проблема в том, что я почти ничего не знаю про архитектуру сетевых приложений и т.п., а уже рвусь пилить игровой сервер)
>>680563
>В классе Game (он ведь по мимо этого содержит и информацию об игре) функция Update/Frame
Главное, чтобы этот класс/метод не превращался в монстра, делающего всё что угодно...
У меня вот нет класса "игра", есть "движок", абстрактно занимающийся разными низкоуровневыми вещами (ввод-вывод, обновление систем), а вся игра должна собираться из сцен, наполняемых сущностями, состоящих из компонентов и обрабатываемых системами. Т.е. в идеале после создания класса TEngineCore я к нему не возвращаюсь и просто соединяю между собой нужные сцены, сущности, компоненты и системы. И если где-то происходит проблема, это проблема нового кода, ведь он не может просто взять и сломать старое, занимаясь какой-то своей работой. В общем, выглядит лучше построения сложного дерева классов с последующим рефакторингом и выкидыванием половины сделанного, чем я занимался год назад (изначально собирался сделать ECS, потом осознал, что сделал обычное ООП-дерево и запутался в нём, начал переделывать в сторону ECS и ещё больше запутался, потом переписал с нуля, но решив взять для простоты 2D пространство вместо 3D)...
>Делаешь им функцию Touch
Копипастом из класса player? Или унаследовать их от общего предка, и поместить Touch в класс-предка? А потом двигать методы туда-сюда по дереву и ставить костыли, чтобы монстр-пешеход мог открывать ящики, а монстр-птица не мог, но при этом игрок по-прежнему имел способность летать (способность ходить; способность летать; способность атаковать; способность открывать ящики - комбинируя их получаем разные классы, но дерево из таких классов будет выглядеть жутко)...
Ой, всё, об этом можно долго спорить, тем более я сам пока слабо разбираюсь (например, много слышал про "систему сообщений", но так и не понял, как её делать и использовать, и не знаю, как у меня будут взаимодействовать между собой разные сущности).
Ну потоки на паскале делаются легко, для этого есть простой в использовании класс TThread. Для сети тоже есть куча компонентов/модулей, но я только когда-то давно пробовал по туториалам использовать компоненты для HTTP и UDP на Delphi, с тех пор с сетью никак не взаимодействовал, не было интереса/задач, так что это новая тема для меня. Главная проблема в том, что я почти ничего не знаю про архитектуру сетевых приложений и т.п., а уже рвусь пилить игровой сервер)
>>680563
>В классе Game (он ведь по мимо этого содержит и информацию об игре) функция Update/Frame
Главное, чтобы этот класс/метод не превращался в монстра, делающего всё что угодно...
У меня вот нет класса "игра", есть "движок", абстрактно занимающийся разными низкоуровневыми вещами (ввод-вывод, обновление систем), а вся игра должна собираться из сцен, наполняемых сущностями, состоящих из компонентов и обрабатываемых системами. Т.е. в идеале после создания класса TEngineCore я к нему не возвращаюсь и просто соединяю между собой нужные сцены, сущности, компоненты и системы. И если где-то происходит проблема, это проблема нового кода, ведь он не может просто взять и сломать старое, занимаясь какой-то своей работой. В общем, выглядит лучше построения сложного дерева классов с последующим рефакторингом и выкидыванием половины сделанного, чем я занимался год назад (изначально собирался сделать ECS, потом осознал, что сделал обычное ООП-дерево и запутался в нём, начал переделывать в сторону ECS и ещё больше запутался, потом переписал с нуля, но решив взять для простоты 2D пространство вместо 3D)...
>Делаешь им функцию Touch
Копипастом из класса player? Или унаследовать их от общего предка, и поместить Touch в класс-предка? А потом двигать методы туда-сюда по дереву и ставить костыли, чтобы монстр-пешеход мог открывать ящики, а монстр-птица не мог, но при этом игрок по-прежнему имел способность летать (способность ходить; способность летать; способность атаковать; способность открывать ящики - комбинируя их получаем разные классы, но дерево из таких классов будет выглядеть жутко)...
Ой, всё, об этом можно долго спорить, тем более я сам пока слабо разбираюсь (например, много слышал про "систему сообщений", но так и не понял, как её делать и использовать, и не знаю, как у меня будут взаимодействовать между собой разные сущности).
> Копипастом из класса player?
Я не знаю какой ты программист
Можешь делать в меру своих навыков
> монстр-пешеход мог открывать ящики, а монстр-птица не мог
Эти монстры отличаются лишь визуальным представлением и логикой движения
Возможность взаимодействовать с чем-то можно дать/забрать у кого угодно (как, например, возможность атаковать и тд)
> комбинируя их получаем разные классы, но дерево из таких классов будет выглядеть жутко
Тут наследование не нужно
>> Копипастом из класса player?
>Я не знаю какой ты программист
>Можешь делать в меру своих навыков
При чём тут я, я спрашиваю, как избежать дублирования кода, который нужен для разных классов? В ООП всего два пути - наследование и агрегация/композиция. Наследование - страшное неуклюжее дерево, плохо подходящее для геймдева, а агрегация - зайчаток ECS. ECS просто даёт возможность собирать объекты в реалтайме, полностью абстрагируясь от данных (компоненты, могут содержать что угодно) и логики (системы, могут делать с компонентами что угодно).
Копипаст кода = трудности с его модификацией во всех местах сразу (когда нужно обновить логику).
Вызов внешних процедур из разных классов = смешивание ООП и процедурного кода, не все ЯП разрешают.
>Эти монстры отличаются лишь визуальным представлением и логикой движения
Ну и? Будешь делать класс Monster и потомки RoadMonster и FlyingMonster? Логику-то ведь нужно где-то разместить. А графика будет в классе Renderable, от которого наследуется Monster... или он наследуется от Movable?
>Возможность взаимодействовать с чем-то можно дать/забрать у кого угодно (как, например, возможность атаковать и тд)
Каким образом? Через флаги? А нужно ли добавлять флаг CanAttack в класс LootBox? А если мы вдруг захотим сделать мимика, который функционирует как сундук, но умеет нападать? Наследовать Mimic от LootBox или от Monster? Или добавить в LootBox функцию Attack и флаг CanAttack? Всё это слишком сложно и чревато проблемами в будущем, когда придётся что-то менять...
>Тут наследование не нужно
Ну не знаю, я бы всё-таки отделил движущиеся объекты от атакующих. Могут существовать мобы, которые умеют ходить, но не должны атаковать (курицы). И могут существовать монстры, которые атакуют, но не двигаются (вспоминаем HL). То есть разные объекты - разная функциональность, зачем их смешивать друг с другом в одном классе? Эдак можно вообще один класс Entity создать и напихать в него всю функциональность, которая может быть у игровых объектов, а менять поведение он будет по значению какой-нибудь переменной... вот только это бред, который обязательно приведёт к проблемам.
По-моему это уже холивар.
>> Копипастом из класса player?
>Я не знаю какой ты программист
>Можешь делать в меру своих навыков
При чём тут я, я спрашиваю, как избежать дублирования кода, который нужен для разных классов? В ООП всего два пути - наследование и агрегация/композиция. Наследование - страшное неуклюжее дерево, плохо подходящее для геймдева, а агрегация - зайчаток ECS. ECS просто даёт возможность собирать объекты в реалтайме, полностью абстрагируясь от данных (компоненты, могут содержать что угодно) и логики (системы, могут делать с компонентами что угодно).
Копипаст кода = трудности с его модификацией во всех местах сразу (когда нужно обновить логику).
Вызов внешних процедур из разных классов = смешивание ООП и процедурного кода, не все ЯП разрешают.
>Эти монстры отличаются лишь визуальным представлением и логикой движения
Ну и? Будешь делать класс Monster и потомки RoadMonster и FlyingMonster? Логику-то ведь нужно где-то разместить. А графика будет в классе Renderable, от которого наследуется Monster... или он наследуется от Movable?
>Возможность взаимодействовать с чем-то можно дать/забрать у кого угодно (как, например, возможность атаковать и тд)
Каким образом? Через флаги? А нужно ли добавлять флаг CanAttack в класс LootBox? А если мы вдруг захотим сделать мимика, который функционирует как сундук, но умеет нападать? Наследовать Mimic от LootBox или от Monster? Или добавить в LootBox функцию Attack и флаг CanAttack? Всё это слишком сложно и чревато проблемами в будущем, когда придётся что-то менять...
>Тут наследование не нужно
Ну не знаю, я бы всё-таки отделил движущиеся объекты от атакующих. Могут существовать мобы, которые умеют ходить, но не должны атаковать (курицы). И могут существовать монстры, которые атакуют, но не двигаются (вспоминаем HL). То есть разные объекты - разная функциональность, зачем их смешивать друг с другом в одном классе? Эдак можно вообще один класс Entity создать и напихать в него всю функциональность, которая может быть у игровых объектов, а менять поведение он будет по значению какой-нибудь переменной... вот только это бред, который обязательно приведёт к проблемам.
По-моему это уже холивар.
> Наследование - страшное неуклюжее дерево, плохо подходящее для геймдева
Это ты как опытный игростроитель говоришь?
> Копипаст кода = трудности с его модификацией во всех местах сразу (когда нужно обновить логику).
Повторюсь, если ты программируешь так, то это не значит что у других точно также
> Будешь делать класс Monster и потомки RoadMonster и FlyingMonster? Логику-то ведь нужно где-то разместить
Для логики есть класс Movement
> А если мы вдруг захотим сделать мимика, который функционирует как сундук, но умеет нападать?
И опять ты мимо
Можешь посмотреть как сделаны банкиры в mangos (эмуляторе сервера вов): обычные юниты, могут атаковать
Щёлкаешь на них ПКМ открывается окошко банка, а рядом с ними гильдбанк, не двигается, не летает, не умирает и с ним игрок тоже взаимодействует
> Ну не знаю, я бы всё-таки отделил движущиеся объекты от атакующих.
> То есть разные объекты - разная функциональность, зачем их смешивать друг с другом в одном классе?
Ты иерархии строить не умеешь
Есть такой принцип: разбиения задачи на подзадачи и ты его игнорируешь
Ты все классы смешиваешь в кучу, а когда надо расширить (например, движение) ты зачем-то делаешь вообще новый класс, а не занимаешься классом движения
Я не понимаю, как ты предлагаешь делать игры без композиции и наследования, но с ООП.
Чисто на процедурах тоже сложно, слишком много протаскивать через аргументы придётся.
Я, кстати, поддвачну, а то гейм-дизайнеры вечно плачут, что не умеют в кодинг, а так бы сделали убийцу всех игр. Так расскажите кодеркам без фантазии и мне тоже, чего бы такого сделать
> расскажите кодеркам без фантазии и мне тоже, чего бы такого сделать
У нас целый тред есть с охуительными идеями игор. Бери любую. Даже если рофельная.
Упс. Тред-то утонул. Жаль.
Штош, тогда вот тебе парочка охуительных идей прямо ИТТ:
Тред живой, оптимизировал вебсокеты чтобы юзерам доставляли только актуальные изменения в чанках. Раньше я скармливал соединениям все ивенты которые происходили в мире, теперь будут только актуальные. Сейчас делаю коммерческую херню, будет время вернусь к игре.
Мимо ОП-гей
702513-кун писал не про этот тред, что он утонул, а про другой, с охуительными кириллоидеями. Хотел сам написать свои идеи, но проебался с разметкой
Красава, наш челвоек.
Если вдруг захочешь какое то сотрудничество (Например видосы об играх друг друга запилить), то пиши по контактам:
https://plugfox.dev/make-world-ru/
Мимо тоже делаю мультиплеерную игру с сервером и клиентом и даже потом планирую запилить глобальный мир, как в ММО
Напиши на псевдоязыке как ты запрогал бы мобов тогда. Условно: обычного монстра, сундук и сундук-мимика
Иди нахуй с рекламой своего говна, залётнй
Делаю, правда долго это все, но набил опыт по архитектуре, вроде дело пошло на лад, с нуля начал писать
https://www.mediafire.com/file/ugrc29p5if9fd4e/main.exe/file
Сделал первую версию и арендовал самый бичевский вдс, пока можно просто ходить по бесконечному мирку
галку ОПа хоть поставь. Рандомный экзешник запускать как то не хочется, проверять антивирусом пока влом
Лол. Чем тебе поможет галка? ОП такой же рандом который может подкинуть что угодно.
так он хотя бы зашквариться когда я заморочусь, проверю антивирусом и запущу на старом ноуте его экзешник.
могу под линух клиент кинуть, но тут без говняка не ссыте
Делал на JS, а теперь пересел на Go?
>можно просто ходить по бесконечному мирку
Это у тебя и в 2020 было. Нет смысла тестировать.
Да, на гошке полностью, для графики ebiten для интерфейса ebitenui,
Сервак без фреймов писался
640x360, 0:06
Ну что, ОП, как дела продвигаются?
Уже 4 годика исполнилось твоему проектику на Phaser. Легендарный батя-гд татрикс примерно за это же время с нуля запилил свою ммо рогалию, вышел в ранний доступ на модели б2п, релизнулся, перешел на ф2п и похоронил игру.
Идет разработОчка....
Вообще дело туго идет, я еще лидом на основном проекте работаю, так что времени мало остается на игрулю.
Из последнего що сделал:
1. Менюшка реги\логина, пока не понял как это сделать более гибким, топорно в общем получилось. Пока не придумал как облегчить себе работу с интерфейсом
2. Решил что будет управление мышкой, запилил поиск пути, на стороне серверочка, реализация в процессе пока.
3. Вечно пытаюсь улучшить архитектуру, чтобы добавлять фичи в 3 строчки.
Такие пойдут?