Подводя итоги прототипа, мы сделали вывод, что blueprint'ы хороши только для простеньких игр и несложных операций. Если вы хотите часть игр писать в C++, то лучше всё максимально уносить в код. К тому же через blueprint'ы написать свой movement component — это no way.
Настройка ничего не переустанавливет. С чего вы взяли это? Она сбрасывает конфиг mysql на свой стандартный. А кто вас просил его править? Если вы пользуетесь панелью, вы должны следовать её логике работы, чтобы не было подобных расхождений.
А что вас удивляет в данном поведении? У вас по внешним причинам, независящим от панели, отвалился сокет, панель должна подключить искусственный интеллект, погуглить и найти решение? Нет, она предлагает перенастроить mysql, привести настройки и сервис к начальному состоянию, при этом предупреждая о том, что пароль пора менять. Учитывая, что расчёт идёт на то, что вы управляли сервисом только через панель — всё адекватно.
Не надо ничего делать и пытаться спасти весь мир. Если кикстартер не будет работать — люди не понесут туда деньги. А раз несут — значит работает. Вклады в инновации, это всегда риски.
Есть законченные проекты на android — play.google.com/store/search?q=talennsy. Некоторые монетизированы. Сам писал движки и игры под них. Сразу отвечаю на вопрос «А кто ты, автор?».
Первое что меня интересует при чтение подобных статей — это ответ на вопрос «А ты кто такой?». Автор, кто ты? Какой у тебя опыт? Сколько лет? Какие профессиональные качества ты имеешь из игровой индустрии? Почему ты считаешь, что ты вводишь людей в заблуждение очередной статьёй?
По мне это статья менеджера, который решил игрушку придумать.
В идеале дизайн документ должен содержать технические подробности реализации использования оригинальных технологий в игре (как применение жанра импоссибилизма например). Должно быть понимание технологий и текущего положения вещей на рынке железа. Ведь если вы придумаете игру, где на экране должно быть 10 000 воинов, по 5 000 полигонов на каждого — то есть вероятность что среднестатистический игрок не сможет комфортно играть в игру. Тоже самое касается движков. Вы должны понимать какие технологии где имеются, чтобы понимать что вы вообще можете сделать. Сюда же относится и планирование проектов по времени. Если при использовании какого-нибудь ogre3d вам надо будет самому шейдеры писать, то при использовании модного UE за вас скорее всего решит phycial-base shading. Все это надо понимать и знать.
Также обязательно надо уметь ощущать очень тонкие эмоциональные состояние. Как например создать впечателние у игрока, что он перенёсся в прошлое? Или как сделать так, чтобы игрок мог ощутить вес виртуального предмета? А ощущение ветра? Это все вещи которые воспринимаются фантазией, которую надо подстёгивать её, надо уметь понимать как это сделать. А это уже вообще драматургия и психология.
P.S.
Я — начинающий гейм-дизайнер, разработчик с опытом 12 лет, тестировщик с опытом 5 лет, игрок с опытом 22 года. Движки: Irrlicht, Ogre3D, Unity3D, UE4. Языки: C++, C#, Java.
Вопрос по импорту и работе с Asset bundle. Сейчас я импортирую своим скриптом объекты сцен и привязанные к скрипты. Могу эти bundle'ы импортировать на любой ОС, без необходимости собирать под каждую архитектуру в отдельности. Как я понял с IL2CPP такое не проканает, ибо собранное на 64-битной винде не взлетит на других ОС и 32-битной архитектуре? Это будет решаться в рамках загадчного упоминания «Updated asset bundle system» в проморолике?
Никак не могу отделаться от ощущения что игры в браузере — это как шашлык на конкурсе на лучшее произведение искусства. Лишним кажется.
Я считаю, что будущее 3D игр, учитывая, что тенденция идёт всё больше и больше в мультиплеер, это такие проекты как JanusVR (www.dgp.toronto.edu/~mccrae/projects/firebox) или Divenet (divenet.talennsy.org). Последний, кстати, разрабатывается на основе Unity3D
Ощущения классные, но если не разрабатываете под неё — ждите осени и потребительской версии. Потому что разрешение надо поднимать и они это сделают, в devkit2 уже есть. А также пока проектов мало, всего около 400, но большая часть — это скучные демки.
По мне это статья менеджера, который решил игрушку придумать.
В идеале дизайн документ должен содержать технические подробности реализации использования оригинальных технологий в игре (как применение жанра импоссибилизма например). Должно быть понимание технологий и текущего положения вещей на рынке железа. Ведь если вы придумаете игру, где на экране должно быть 10 000 воинов, по 5 000 полигонов на каждого — то есть вероятность что среднестатистический игрок не сможет комфортно играть в игру. Тоже самое касается движков. Вы должны понимать какие технологии где имеются, чтобы понимать что вы вообще можете сделать. Сюда же относится и планирование проектов по времени. Если при использовании какого-нибудь ogre3d вам надо будет самому шейдеры писать, то при использовании модного UE за вас скорее всего решит phycial-base shading. Все это надо понимать и знать.
Также обязательно надо уметь ощущать очень тонкие эмоциональные состояние. Как например создать впечателние у игрока, что он перенёсся в прошлое? Или как сделать так, чтобы игрок мог ощутить вес виртуального предмета? А ощущение ветра? Это все вещи которые воспринимаются фантазией, которую надо подстёгивать её, надо уметь понимать как это сделать. А это уже вообще драматургия и психология.
P.S.
Я — начинающий гейм-дизайнер, разработчик с опытом 12 лет, тестировщик с опытом 5 лет, игрок с опытом 22 года. Движки: Irrlicht, Ogre3D, Unity3D, UE4. Языки: C++, C#, Java.
Я считаю, что будущее 3D игр, учитывая, что тенденция идёт всё больше и больше в мультиплеер, это такие проекты как JanusVR (www.dgp.toronto.edu/~mccrae/projects/firebox) или Divenet (divenet.talennsy.org). Последний, кстати, разрабатывается на основе Unity3D
Сейчас это будет вообще мейнстримом, но для тех, кто открыт для разработчиков, а не Сони.
Никакого заката не предвидется.