alexprey:

Pray_AD, есть смысл, но не тут)

Конечно не в этой теме =)
alexprey, зы, рад видеть старичков

Привет всем =) К сожалению этому проекту оказалось не суждено увидеть свет. Но наработки из него и полученный опыт определенно сыграли свою роль. Если кому интересно, мой новый проект -- Evospace. Можете найти в стим. Не знаю имеет ли смысл завести тут какую нибудь тему по старой памяти. Скажите =)

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

Привет всем, я все еще живой )
Хотел поведать, что дело все еще идет и рассказать в 2х словах о решении старых проблем с компонентами. Я взглянул на юнити и позаимствовал схему оттуда, вышло довольно приятно.
Суть в том, что любой объект, даже проигрывающийся звук или монстр -- это просто контейнер некоторых компонентов, которые я по какой-то причине назвал агентами.
Каждый агент может выполнять какие-то функции, скажем агент CreatureBase хранит положение существа и все такое, а агент Wander генерирует приказы беспорядочно бродить, агент Chest хранит предметы. Некоторые агенты имеют интеракцию, так объект, содержащий Chest при клике на него откроет окошко с теми самыми предметами.

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

github.com/ishellstrike/sge/blob/master/core/agent.h

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

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

:3

и даже можно приближаться, правда пока атмосфера все затмевает надо HDR чтоли делать, короче говоря вот без атмосферы то же самое, только поближе.
1
Могу тему запилить, поподробнее рассказать, если интересно кому

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

Кстати я еще живой )
Сейчас проект переписан на с++, получил z уровни и ogl рендер. Ясно дело никто ничего уже не ждет, просто решил донести, что помаленьку дело идет. Возможно скоро обновлю шапку

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

double Noise2D(double x, double y, int seed) {
return ((0x6C078965*(seed ^ (((int) x*2971902361) ^ ((int) y*3572953751)))) & 0x7FFFFFFF)/(double)int.MaxValue;
}

Симплекс шум чуть сложнее, но сложность алгоритма не мешает его использовать, передали параметры -- получили шум, profit.

RSQR, Что значит разобраться в шуме перлина? )

Fakov:

Pray_AD:

Т.е. будет некоторая постоянная обратная связь

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

Ну для меня это было не слишком очевидно

Fakov:

Pray_AD:

чем предлагаемый тобой материал будет лучше?

встречный вопрос - а отчего он должен быть лучше? я просто разберу создание простой игры от начала и надеюсь до конца - ничего сверхестественного.

Гугл "создание простейшей игры" -- тысячи видео, еще и бесплатно

Эльрат:

Pray_AD, я так понимаю, что автор будет не просто писать тебе статьи, но и тыкать носом в те моменты, которые ты не догоняешь. Т.е. преподавание.

Т.е. будет некоторая постоянная обратная связь? Если все так, то дествительно за такое вполне справедливо брать деньги.

Fakov:

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

Я не совсем понимаю кому могут потребоваться такие статьи, про тот же Construct есть статьи на самом сайте разработчиков.

А если говорить про обычное программирование игр, то тут вообще тонны материала уже написано. Отсюда и вопрос: чем предлагаемый тобой материал будет лучше?

Не совсем ясно зачем "платить за инфу", если есть целый огромный интернет, который просто ломится от подобной инфы, чем предлагаемая сдесь будет лучше?

Мне думается, что стоит начинать по-крупному, с того же юнити, но не с Construct. Я не утверждаю, что в Construct нельзя сделать что-то стоящее, но опыт, полученный в нем не так ценен, как опыт того же юнити, та и сам юнити весьма похож на редактор wacrcaft 3, что упрощает вхождение. Для меня весьма загадочно, почему до сих пор каждый второй на этом портале, не просиживает в нем.

Doc:

Всё кроме 1 бред, есть интерфейс Entity, у которого есть методы update итд итп, от него все наследуется, не нужно мудрить. Если нужна поддержка скриптов она реализуется конкретно в объекте. Типичная новичковская ошибка пытаться все сделать супердуперуниверсальным.

Я тоже так считаю, надо посильнее выделить в тексте оценку каждого метода, просто решил привести все, что придумалось, 2 3 определенно слабее, но тем не менее они используются, например система флагов взята из DwarfFortress/Canaclysm.
Не знаю почему там выбран именно этот способ, вообще качество кода в этих проектов не лучшее да и решения, но сами проекты прекрасны

alexprey:

Pray_AD, космосим уже есть, тот же Space Engine

Так и Cataclysm DDA уже есть, суть в исполнении ну и в самом процессе, конечно же.

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

SomeFire:

Pray_AD:

перевести этот проект на новую платформу по графике

Смотря как он будет выглядеть в новом виде. Как ты хочешь его в таком случае запилить?

Рогалику графики много не надо, примерно так (WRONG URL - imageshack), камера сверху -- вид как на скриншотах в шапке темы.

Проект немного заморожен, я увлекся графикой и на XNA стало тесно. В принципе в графику я наигрался, есть 2 варианта развития событий: перевести этот проект на новую платформу по графике или рассказать про то, что у меня вышло, пока с этим был перерыв. В двух словах там движок графический на c++ glew glfw, который достаточно всего умеет, в частности планетный рендер. Если будет фидбек что интереснее -- буду очень рад

ну и для затравки пара скриншотов: просто рендер стандартной сцены и atmospheric scattering

Mihahail:

А 10+к строк логики - не многовато ли?
Хотя я сужу только по скриншотам. Если и переписывать что-то, то, очевидно, на чем-то более высокоуровневом. Зачем сюда с++, в котором черт ногу сломит? Ведь фпс больше 75 не нужно.
(мнение, но небезосновательное, хотя я и с++неосилятор)
Профиты избавления от привязки к платформе и её компонентам - ценно, но есть ведь и иные способы?..

ну на самом деле около 7к, сужу по гитхабу, если вычесть графику (на xna ее выходит мало по объему), в любом случае выйдет не меньше 6к, так это c# еще весьма компактен, т.к. я обильно юзал LINQ и лямбды.

На счет ломания ног, это даже приятнее, лично мне

Кстати, на счет фпс, XNA не тянул 60 фпс на стареньком ноуте в 1080, на glew 300

zerotul:

Сначала тоже использовал glfw, используй SDL - возможностей больше, если есть смысл переходить, то лучше сразу на него.

glfw это просто кроссплатформенная обертка для создания окон и контекста. Для самой графики я использую glew

Nerevar:

независимость от XNA, Mono, .Net

?

да, спасибо

alexprey:

Ууу..... зачеееммм???? Неужели тебе важнее каких то там пару килобайт, по сравнению с затратой времени на упаковку и распаковку строк? Строки очень плохое решение.

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

P.S. Накладные расходы на строку -- 14 (26 для x64) байт, плюс до 4 байт на выравнивание.
P.P.S. Также стоить добавить, что все Id -- это интернированные, во время загрузки базы блоков, строки.

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

Был бы рад узнать решение для разреженного массива неограниченного размера, лучше, чем хеш-таблица

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

Doc:

Очень плохие решения уровня варкрафта

Предложения?

Замерил время на сериализацию\десериализацию: UnstoreSector TotalMilliseconds = 1.0504 (в основном из-за выделения памяти, пул секторов сократит это время тоже до 0.25 мс), StoreSector TotalMilliseconds = 0.2683, на ноутбуке 7ми летней давности

Uber:

Добавил вас к нашим проектам в колонку объявлений слева. Мелочь, но может быть приятно.

https://xgm.guru/p/gamedev

Благодарю.