Привет всем =) К сожалению этому проекту оказалось не суждено увидеть свет. Но наработки из него и полученный опыт определенно сыграли свою роль. Если кому интересно, мой новый проект -- Evospace. Можете найти в стим. Не знаю имеет ли смысл завести тут какую нибудь тему по старой памяти. Скажите =)
Андреич
Спасибо, по правде говоря сейчас дело пошло довольно активно, но из за того, что заниматься приходится в основном восстановлением старого функционала написать о каком-то прогрессе не получается, т.к. фактически раньше было больше того, что можно показать, но сейчас гораздо больше инфраструктуры и возможностей внутри, жаль об этом быстро и красиво не поведать.
Привет всем, я все еще живой )
Хотел поведать, что дело все еще идет и рассказать в 2х словах о решении старых проблем с компонентами. Я взглянул на юнити и позаимствовал схему оттуда, вышло довольно приятно.
Суть в том, что любой объект, даже проигрывающийся звук или монстр -- это просто контейнер некоторых компонентов, которые я по какой-то причине назвал агентами.
Каждый агент может выполнять какие-то функции, скажем агент CreatureBase хранит положение существа и все такое, а агент Wander генерирует приказы беспорядочно бродить, агент Chest хранит предметы. Некоторые агенты имеют интеракцию, так объект, содержащий Chest при клике на него откроет окошко с теми самыми предметами.
ТАк же удалось сделать автоматическую десериализацию данных об этих агентах и абстрактную фабрику, так что их добавление не вызывает совершенно никаких проблем. Если кому интересно приложу исходники этого дела, могу пояснить любой кусочек, но думаю там и так все довольно понятно.
Сейчас занимаюсь тем, что восстанавливаю генерацию карты, пилю окошки (элементы более-менее готовы) и рецепты. Старые предметы и все такое уже более-менее импортировано
Пилю только по вечерам и при наличии настроения, так что это будет долго, впрочем как и всегда )
и даже можно приближаться, правда пока атмосфера все затмевает надо HDR чтоли делать, короче говоря вот без атмосферы то же самое, только поближе.
1
Могу тему запилить, поподробнее рассказать, если интересно кому
Кстати я еще живой )
Сейчас проект переписан на с++, получил z уровни и ogl рендер. Ясно дело никто ничего уже не ждет, просто решил донести, что помаленьку дело идет. Возможно скоро обновлю шапку
ну это как бы в заглавии темы заложено. я просто хочу заинтересовать участников еще пока коммьюнити геймдевом, на пальцах описав, что есть что в каком то движке
Pray_AD, еще раз говорю - донейт. Утром стулья, вечером деньги. и без того понятно, что на хгм пока не готовы к нормальному товарно-денежному взаимодействию.
Я не совсем понимаю кому могут потребоваться такие статьи, про тот же Construct есть статьи на самом сайте разработчиков.
А если говорить про обычное программирование игр, то тут вообще тонны материала уже написано. Отсюда и вопрос: чем предлагаемый тобой материал будет лучше?
Не совсем ясно зачем "платить за инфу", если есть целый огромный интернет, который просто ломится от подобной инфы, чем предлагаемая сдесь будет лучше?
Мне думается, что стоит начинать по-крупному, с того же юнити, но не с Construct. Я не утверждаю, что в Construct нельзя сделать что-то стоящее, но опыт, полученный в нем не так ценен, как опыт того же юнити, та и сам юнити весьма похож на редактор wacrcaft 3, что упрощает вхождение. Для меня весьма загадочно, почему до сих пор каждый второй на этом портале, не просиживает в нем.
Всё кроме 1 бред, есть интерфейс Entity, у которого есть методы update итд итп, от него все наследуется, не нужно мудрить. Если нужна поддержка скриптов она реализуется конкретно в объекте. Типичная новичковская ошибка пытаться все сделать супердуперуниверсальным.
Я тоже так считаю, надо посильнее выделить в тексте оценку каждого метода, просто решил привести все, что придумалось, 2 3 определенно слабее, но тем не менее они используются, например система флагов взята из DwarfFortress/Canaclysm.
Не знаю почему там выбран именно этот способ, вообще качество кода в этих проектов не лучшее да и решения, но сами проекты прекрасны
Получается, что развитие рогалика вам было бы интереснее, чем развитие космосима? Меня они примерно одинаково увлекают сейчас, так что хотелось бы определиться что интереснее. Откровенно говоря космосим вряд ли когда нибудь выберется из стадии доработки движка, но движок сам по себе может оказаться весьма занимательной штукой.
Проект немного заморожен, я увлекся графикой и на XNA стало тесно. В принципе в графику я наигрался, есть 2 варианта развития событий: перевести этот проект на новую платформу по графике или рассказать про то, что у меня вышло, пока с этим был перерыв. В двух словах там движок графический на c++ glew glfw, который достаточно всего умеет, в частности планетный рендер. Если будет фидбек что интереснее -- буду очень рад
ну и для затравки пара скриншотов: просто рендер стандартной сцены и atmospheric scattering
А 10+к строк логики - не многовато ли?
Хотя я сужу только по скриншотам. Если и переписывать что-то, то, очевидно, на чем-то более высокоуровневом. Зачем сюда с++, в котором черт ногу сломит? Ведь фпс больше 75 не нужно. (мнение, но небезосновательное, хотя я и с++неосилятор)
Профиты избавления от привязки к платформе и её компонентам - ценно, но есть ведь и иные способы?..
ну на самом деле около 7к, сужу по гитхабу, если вычесть графику (на xna ее выходит мало по объему), в любом случае выйдет не меньше 6к, так это c# еще весьма компактен, т.к. я обильно юзал LINQ и лямбды.
На счет ломания ног, это даже приятнее, лично мне
Кстати, на счет фпс, XNA не тянул 60 фпс на стареньком ноуте в 1080, на glew 300
Ууу..... зачеееммм???? Неужели тебе важнее каких то там пару килобайт, по сравнению с затратой времени на упаковку и распаковку строк? Строки очень плохое решение.
Во-первых затраты на хранение снизились не на пару килобайт, а на 69 килобайт или в 100 раз. Во вторых сериализация -- это отдельный метод, сделать двоичную сериализацию никто не запрещает. В-третьих, скорость упаковки\распаковки не слишком важна, все равно гораздо больше времени уйдет на ожидание ответа сервера да и происходит распаковка на фоне.
P.S. Накладные расходы на строку -- 14 (26 для x64) байт, плюс до 4 байт на выравнивание.
P.P.S. Также стоить добавить, что все Id -- это интернированные, во время загрузки базы блоков, строки.
Кст, если мне не изменяет память, то хэш структуры занимают много памяти. Тобишь ты сам себе противоречишь. Одно место оптимизируешь по памяти в ущерб времени, другое наоборот...
Был бы рад узнать решение для разреженного массива неограниченного размера, лучше, чем хеш-таблица
К слову, какие-то пару килобайт выходили в ограничение по памяти для приложения где-то за пол часа.
Замерил время на сериализацию\десериализацию: UnstoreSector TotalMilliseconds = 1.0504 (в основном из-за выделения памяти, пул секторов сократит это время тоже до 0.25 мс), StoreSector TotalMilliseconds = 0.2683, на ноутбуке 7ми летней давности
Отредактирован Pray_AD
» JARG / Главная страница
alexprey, зы, рад видеть старичков
» JARG / Главная страница
» JARG / Главная страница
Спасибо, по правде говоря сейчас дело пошло довольно активно, но из за того, что заниматься приходится в основном восстановлением старого функционала написать о каком-то прогрессе не получается, т.к. фактически раньше было больше того, что можно показать, но сейчас гораздо больше инфраструктуры и возможностей внутри, жаль об этом быстро и красиво не поведать.
Отредактирован Pray_AD
» JARG / Главная страница
Хотел поведать, что дело все еще идет и рассказать в 2х словах о решении старых проблем с компонентами. Я взглянул на юнити и позаимствовал схему оттуда, вышло довольно приятно.
Суть в том, что любой объект, даже проигрывающийся звук или монстр -- это просто контейнер некоторых компонентов, которые я по какой-то причине назвал агентами.
Каждый агент может выполнять какие-то функции, скажем агент CreatureBase хранит положение существа и все такое, а агент Wander генерирует приказы беспорядочно бродить, агент Chest хранит предметы. Некоторые агенты имеют интеракцию, так объект, содержащий Chest при клике на него откроет окошко с теми самыми предметами.
https://github.com/ishellstrike/sge/blob/master/core/agents/agen...
» JARG / Главная страница
Отредактирован Pray_AD
» JARG / Главная страница
1
Могу тему запилить, поподробнее рассказать, если интересно кому
» JARG / Главная страница
Отредактирован Pray_AD
» JARG / Главная страница
Сейчас проект переписан на с++, получил z уровни и ogl рендер. Ясно дело никто ничего уже не ждет, просто решил донести, что помаленьку дело идет. Возможно скоро обновлю шапку
Отредактирован Pray_AD
» Fa_losophy / Руковыпрямительный колледж имени Факова
Отредактирован Pray_AD
» Fa_losophy / Руковыпрямительный колледж имени Факова
Отредактирован Pray_AD
» Fa_losophy / Руковыпрямительный колледж имени Факова
» Fa_losophy / Руковыпрямительный колледж имени Факова
» Fa_losophy / Руковыпрямительный колледж имени Факова
Отредактирован Pray_AD
» Fa_losophy / Руковыпрямительный колледж имени Факова
» Fa_losophy / Руковыпрямительный колледж имени Факова
Отредактирован Pray_AD
» Fa_losophy / Руковыпрямительный колледж имени Факова
Отредактирован Pray_AD
» JARG / Представление игровых объектов
Не знаю почему там выбран именно этот способ, вообще качество кода в этих проектов не лучшее да и решения, но сами проекты прекрасны
» JARG / Главная страница
Отредактирован Pray_AD
» JARG / Главная страница
» JARG / Главная страница
Отредактирован Pray_AD
» JARG / Главная страница
Отредактирован Pray_AD
» JARG / Мысли о с++ glew+glfw
Отредактирован Pray_AD
» JARG / Мысли о с++ glew+glfw
Отредактирован Pray_AD
» JARG / Работа с секторами карты в JARG
P.P.S. Также стоить добавить, что все Id -- это интернированные, во время загрузки базы блоков, строки.
» JARG / Главная страница