Именно в шутерах наличие физики — это не только прикольные взрывы, это, в основном, разные тактические уловки связанные с физикой, каждый раз разные сценарии игры (можно закидать коридор мусором и локация уже полностью меняется, можно всей командой подсадить одного лазутчика на высокую стену что бы он украл шары, хех) ну и всякое такое.
в майнркафте (более релеванты были бы шутеры типа block n load, ace of spaded) нельзя вытащить самый нижний блок и обрушить мост. Вот именно такой разрушаемости очень мало.
на билд машине для виндового билда использую stable
для разработки использую nightly. Единственное ради чего nighly — я через compiler intristics узнаю всякое для профайлера.
компилятор стабилен, на самых свежих nigtly я видел настоящие баги и падения, но — очень редко. Если хотя бы недельной давности nigtly — то всё вообще путём.
мемори лик был один раз — сервер падал с out of memory (я был удивлён, раст, безопасность, и out of memory?). Оказалось я всё в том же профайлере хранил вообще все фреймы.
Настоящий мемори лик получить практически нереально.
unsafe от безысходности я использовал один раз, и это привело к тому, что я писал мимо памяти, прямо как в c++.
Отвратительный код!
функция была примерно такая https://is.gd/PzW9O4 (без unsafe я бы мог написать только так: https://is.gd/gXIbJx).
я захотел обмануть раст, получить ссылки на элементы массива, да при этом еще и иметь возможность менять массив.
В результате — очевидные проблемы. С помощью unsafe можно взять отвестветнность на себя и делать такие вот вещи, но — лучше не стоит.
В общем — unsafe — опасен! не используйте unsafe :)
Очень тяжело считать предсказания в условиях падающих стен, поэтому тяжело сделать быстрый геймплей
Очень дорого считать физику на серверах и почти невозможно построить шутер без авторитарного сервера
Поэтому большим компаниям это не интересно, и, поэтому, у нас с быстрым растом есть все шансы! :)
в двух словах — из блендера пишем иерархию объектов, метаданные, пути до энтитей с компонентами в отдельный toml + экспортируем отдельно каждый уникальный меш.
assimp не используем, у нас свой формат, основанный на валвоском .smd.
Наш план — сделать игру с уникальной механикой (синхронная разрушаемость, командная игра с шаром) и найти свою аудиторию, готовую мириться с малым количеством контента ради специфичного игрового опыта.
А уже с аудиторией превратить малые силы — в большие!
Блин, открывал статью с мыслью «Ура, наконец-то прелюдии кончились и начали рассказывать про веб-разработку!». Однако, нет.
Присоединяюсь к коменту выше про чаще и больше.
Именно в шутерах наличие физики — это не только прикольные взрывы, это, в основном, разные тактические уловки связанные с физикой, каждый раз разные сценарии игры (можно закидать коридор мусором и локация уже полностью меняется, можно всей командой подсадить одного лазутчика на высокую стену что бы он украл шары, хех) ну и всякое такое.
в майнркафте (более релеванты были бы шутеры типа block n load, ace of spaded) нельзя вытащить самый нижний блок и обрушить мост. Вот именно такой разрушаемости очень мало.
для разработки использую nightly. Единственное ради чего nighly — я через compiler intristics узнаю всякое для профайлера.
компилятор стабилен, на самых свежих nigtly я видел настоящие баги и падения, но — очень редко. Если хотя бы недельной давности nigtly — то всё вообще путём.
мемори лик был один раз — сервер падал с out of memory (я был удивлён, раст, безопасность, и out of memory?). Оказалось я всё в том же профайлере хранил вообще все фреймы.
Настоящий мемори лик получить практически нереально.
unsafe от безысходности я использовал один раз, и это привело к тому, что я писал мимо памяти, прямо как в c++.
я захотел обмануть раст, получить ссылки на элементы массива, да при этом еще и иметь возможность менять массив.
В результате — очевидные проблемы. С помощью unsafe можно взять отвестветнность на себя и делать такие вот вещи, но — лучше не стоит.
В общем — unsafe — опасен! не используйте unsafe :)
Очень дорого считать физику на серверах и почти невозможно построить шутер без авторитарного сервера
Поэтому большим компаниям это не интересно, и, поэтому, у нас с быстрым растом есть все шансы! :)
assimp не используем, у нас свой формат, основанный на валвоском .smd.
А уже с аудиторией превратить малые силы — в большие!
Примерно так :)
опечатки есть!
liftF :: (Functor f) => f r -> Free fr
(пробел ненапечатался :D)
Присоединяюсь к коменту выше про чаще и больше.
Если уж начали делится ссылками на книжки
pcl.catap.ru/ — перевод очень хорошей книги по CL, сам по ней учусь
вот этой вот www.gigamonkeys.com/book/
www.paulgraham.com/onlisptext.html еще
и еще есть Мир лиспа в двух томах
думаю, во всем цикле статей можно будет собрать из каментов полный список учебной литературы по CL =)
текстового, вероятно
а так отлично, ждем
ебилдоврелизаэто же прекрасно, что сценеры могут легко найти хорошую работу.