Приведу пример, как можно сделать делегат с параметрами без создания обертки, так это обычно и используют:
public class Health {
public delegate void DamageTaken(float damage);
public event DamageTaken OnDamageTaken; // will be triggered on damage
public delegate void PlayerDead(); // will be triggered when dead.
public event PlayerDead OnDead;
private float health = 100;
// call this to do damage
public void TakeDamage(float damage) {
if (health <= 0) return;
health -= 20;
if (OnDamageTaken != null) // null check is required because if there is no subscribers it produces error when invoking
{
OnDamageTaken.Invoke(damage);
}
if (health <= 0) {
if (OnDead != null) {
OnDead.Invoke();
}
}
}
}
С переменными идея понятна, т.к. хочется, чтобы можно было подписываться на изменение переменной. Но всё равно делать их публичными - очень плохое архитектурное решение. Если нужно подписаться на изменение здоровья извне, надо создать соответствующий ивент или делегат. Иногда можно нарушать правила, но в подобных статьях я не делал бы этого. Новичков и так постоянно учат плохому.
Насчет ссылок и указателей плохо понял. В С# любая переменная, содержащая объект, это аналог shared_ptr из C++ со всеми вытекающими проблемами. Есть кстати в C# и обычные C указатели, ими можно пользоваться в unsafe коде. Узнал недавно и удивился :)
P.S.: в этом примере делается проверка на null, но есть более короткая форма OnDamageTaken?.Invoke(damage);
По этой статье совершенно непонятно, зачем нужна обертка вокруг делегата, которая делает в точности то же самое, что и он? Также странное решение делать публичные переменные, обернутые в обертки. Какой-то ужасно приторный синтаксический сахар просто чтобы показать, что автор умеет писать шаблонные методы. Все это можно накодить в 3 строчки кода, если просто правильно пользоваться знанием среды и языка, не изобретая велосипед. Возможно, я неправ.
Подход делить логики и использовать делегаты сам по себе неплох. Но это тоже подходит не для всего. В некоторых случаях просто необходимо забить логику гвоздями просто чтобы никто ее не сломал неправильной настройкой компонентов. А делегаты - это больше чтобы звуки и партиклы на персонажа вешать
Автор сам себя дискредитировал тем, что пошел кодить критичную к производительности задачу совершенно не подходящим для этого способом. Там не только switch и c-стайл, но и ассемблер будет не лишним.
А чистый код это больше высокоуровневая архитектура и вот это вот все. Какие-нибудь сервисы, общающиеся с 1000 других сервисов. И это происходит в вэбе, в котором такие задержки, что выигрыш в паре тактов процессора вообще не принесет пользы.
Ну тут видимо изучалось одно конкретное явление. Вообще у ЧД уйма замудрённых свойств таких как специфические магнитные поля, виртуальные фотоны, смещение спектра (упомянутого в сообщении выше). В результате вращения ЧД ореол диска немного искажается и сбоку становится видно небольшой "пузырёк" (тоже линзирование, можно найти картинки с ним). Не представляю как вообще возможно было бы всё это симулировать :) Ну а в данном конкретном видео очевидно — сферическая черная дыра в вакууме.
На gamedev.ru гуляет легенда о том что те, кто пишут с нуля 3д движки, сходят с ума. И там еще был список из форумчан которые реально легли в дурку и скриншоты их наработок достаточнр
о неплохие
ну это уж слишком, зачем так-то жестко разваливать? это же удар ниже пояса. даже не знаю теперь как отмыться от такого позора. "обычная игра на анриле/юнити" — боже как я до этого докатился! пойду качать nvidia sdk и гуглить аудио библиотеки. вот прям чувствую, сразу все изменится
Ну можно вывести не треугольник, а два треугольника, получится квадратный спрайт. Практически готовый графический движок для 2д игр. Иронизирую конечно, но для легких мобилок актуально.
Есть еще разные уровни велосипедизма. Можно собирать движок из готовых библиотек, а можно начать с кода инициализации из туториалов по opengl. Или вообще запилить софтверный рендер. Я все три проходил, одну игру даже смог доделать (остальные забаговались), но сейчас слишком стар для этого
Справедливости ради стоит заметить, что чаще всего портирование одной кнопкой, как заявлено аторами движков, не работает в том плане, что все равно нужно частично что-то переделывать, оптимизировать, да и platform specific features никуда не деваются. Что-то может сломаться, не сработать на одной из платформ, самописные шейдеры могут не отрисоваться, все это надо отлаживать, а на это нужно время.
В засчиту Unity скажу то, что в нём предусмотрена переработка графического конвейера. В традиционном рендере есть Command Buffer, которым реально полностью убрать систему освещения и написать свою. Плюс у меня есть статья, где я костыльно улучшал освещение, модифицируя встроенные шейдеры (на этом принципе, а возможно даже на и моих наработках, реализован ассет Next Gen Soft Shadows). В новых версиях разработчики пошли дальше и сделали программируемый рендер конвейер, который можно полностью переписать, и в нем из коробки реализованы красивые штуки уровня Unreal.
Это все про рендер, то есть про самую требовательную для ресурсов и для многих критичную часть. Резюмирую: все можно переделать под себя или даже заменить полностью.
Что касается остального, то если допустим вам не нужна 2д физика, выключаете компонент, и ресурсы попросту не тратятся. Конечно, библиотеки все равно будут занимать в памяти драгоценные мегабайты, но это та цена, которая осознанно платится за удобство кроссплатформенности.
Что касается скриптов, системы объектов и всего прочего, то в самописном движке вы придете к тому же самому. Не знаю как тесно вплетено все в код Unreal и как трудно от этого отойти, но в Юнити можно реализовать кучу разных подходов, систем сообщений, достаточно легко пишутся расширения редактора чтоб сделать удобные тулзы. И даже ярый велосипедист окажется рад перекатиться в эту среду разработки, если приложит минимальное усилие на начальном этапе.
В целом в статье всё до банального очевидно. Если планируется совсем лютый эксперимент или мобилка — лучше не пользоваться тяжёлым движком.
Но абзац про динамические библиотеки в Unity и Unreal поставил в тупик. Мало того что библиотеки там вообще не для игрового кода ну никак, а для расчетов каких-то жестких или для расширений конкретного движка. Так еще и рассматривается вероятность в серьезном проекте поменять движок в середине разработки. Это как бы ошибка планирования и так делать не надо. Либо это долгострой, в котором на определенном этапе лучше что-то написать заново.
Как правило, люди, много читающие, жанровые книги предпочитают экспериментальным. Кто если не эти люди будут покупать инди-книги. Они отнюдь не "идиоты", а скорее, наоборот, начитанные интеллигенты, которым в какой-то момент стало мало того, что продается в магазинах, в том или ином смысле.
Ради собственного удовольствия можно писать максимум рассказики в интернете. Но даже с ними приходится проводить серьезную скучную работу, если дело доходит до самого мелкого конкурса (не ради победы так ради того чтобы попасться на глаза новым читателям и желательно не отхватить тухлых помидоров). А уж когда нужно довести до конца роман, не такая уж и большая разница — жанровый он или экспериментальный. Работы непочатый край. С книгой мечты, наверное, даже больше мучений. Особенно если учесть, что скорее всего, это пишется в стол.
Этот ход часто использовали в фильмах и книгах: сначала идёт эпизод из кульминации, чтобы завлечь в сюжет, а потом уже можно перейти к тому, «как всё начиналось».
Игра начинается в общественном туалете, что помогает игроку свыкнуться с тем, что его ждёт в игре. Когда я это написал, мне начало казаться, что это действительно могло быть задумкой авторов, учитывая их неординарность.
Единственное, что вспомнилось на фоне общей тенденции игровых завязок, это обучение из первой Half-Life. Такое циничное чёрно-юморное обучение, причём, игрока там действительно обучали. Ну, и начало из Half-Life тоже выделилось — десять минут в вагончике, после чего — бюрократия и нудная работа с пропусками, бесконечными «привет-привет» от людей, имена которых ты даже не знаешь, и так далее. Кто бы что ни говорил сейчас, когда игроки уже искушены навороченным сюжетом в играх, но первая Half-Life стала одной из важнейших вех. Правда, второй раз бомба в ту же воронку вряд ли упадёт. Лучше и правда ориентироваться на классическую схему — несложное знакомство с игровой механикой и немедленная интрига в сюжете. А смелые эксперименты оставить Гордону Фриману.
Меню и анимашки на CSS3 работают плавнее, чем реализованные через JavaScript. В этом главное достоинство CSS3. В остальном часто легче использовать JavaScript, т.к. в CSS3 на данным момент слишком уж много получается запутанного текста.
Без обид, но к статье это тоже относится. Есть простая поговорка «Краткость — сестра таланта», ей можно было бы заменить весь поток сознания из статьи. Хотя не спорю, есть люди, которые не понимают сути этой поговорки. Для таких людей статья с картинками — самое то.
Приведу пример, как можно сделать делегат с параметрами без создания обертки, так это обычно и используют:
С переменными идея понятна, т.к. хочется, чтобы можно было подписываться на изменение переменной. Но всё равно делать их публичными - очень плохое архитектурное решение. Если нужно подписаться на изменение здоровья извне, надо создать соответствующий ивент или делегат. Иногда можно нарушать правила, но в подобных статьях я не делал бы этого. Новичков и так постоянно учат плохому.
Насчет ссылок и указателей плохо понял. В С# любая переменная, содержащая объект, это аналог shared_ptr из C++ со всеми вытекающими проблемами. Есть кстати в C# и обычные C указатели, ими можно пользоваться в unsafe коде. Узнал недавно и удивился :)
P.S.: в этом примере делается проверка на null, но есть более короткая форма OnDamageTaken?.Invoke(damage);
По этой статье совершенно непонятно, зачем нужна обертка вокруг делегата, которая делает в точности то же самое, что и он? Также странное решение делать публичные переменные, обернутые в обертки. Какой-то ужасно приторный синтаксический сахар просто чтобы показать, что автор умеет писать шаблонные методы. Все это можно накодить в 3 строчки кода, если просто правильно пользоваться знанием среды и языка, не изобретая велосипед. Возможно, я неправ.
Подход делить логики и использовать делегаты сам по себе неплох. Но это тоже подходит не для всего. В некоторых случаях просто необходимо забить логику гвоздями просто чтобы никто ее не сломал неправильной настройкой компонентов. А делегаты - это больше чтобы звуки и партиклы на персонажа вешать
Автор сам себя дискредитировал тем, что пошел кодить критичную к производительности задачу совершенно не подходящим для этого способом. Там не только switch и c-стайл, но и ассемблер будет не лишним.
А чистый код это больше высокоуровневая архитектура и вот это вот все. Какие-нибудь сервисы, общающиеся с 1000 других сервисов. И это происходит в вэбе, в котором такие задержки, что выигрыш в паре тактов процессора вообще не принесет пользы.
Ну тут видимо изучалось одно конкретное явление. Вообще у ЧД уйма замудрённых свойств таких как специфические магнитные поля, виртуальные фотоны, смещение спектра (упомянутого в сообщении выше). В результате вращения ЧД ореол диска немного искажается и сбоку становится видно небольшой "пузырёк" (тоже линзирование, можно найти картинки с ним). Не представляю как вообще возможно было бы всё это симулировать :) Ну а в данном конкретном видео очевидно — сферическая черная дыра в вакууме.
В какой-то мере потемнение справа на симуляции НАСА можно отнести к этому эффекту.
Возможно, на симуляции не видимый спектр, а диапазон радиоизлучения (как на снимке, сделанном в этом году).
На gamedev.ru гуляет легенда о том что те, кто пишут с нуля 3д движки, сходят с ума. И там еще был список из форумчан которые реально легли в дурку и скриншоты их наработок достаточнр
о неплохие
ну это уж слишком, зачем так-то жестко разваливать? это же удар ниже пояса. даже не знаю теперь как отмыться от такого позора. "обычная игра на анриле/юнити" — боже как я до этого докатился! пойду качать nvidia sdk и гуглить аудио библиотеки. вот прям чувствую, сразу все изменится
( ;-p )
Ну можно вывести не треугольник, а два треугольника, получится квадратный спрайт. Практически готовый графический движок для 2д игр. Иронизирую конечно, но для легких мобилок актуально.
Есть еще разные уровни велосипедизма. Можно собирать движок из готовых библиотек, а можно начать с кода инициализации из туториалов по opengl. Или вообще запилить софтверный рендер. Я все три проходил, одну игру даже смог доделать (остальные забаговались), но сейчас слишком стар для этого
Справедливости ради стоит заметить, что чаще всего портирование одной кнопкой, как заявлено аторами движков, не работает в том плане, что все равно нужно частично что-то переделывать, оптимизировать, да и platform specific features никуда не деваются. Что-то может сломаться, не сработать на одной из платформ, самописные шейдеры могут не отрисоваться, все это надо отлаживать, а на это нужно время.
В засчиту Unity скажу то, что в нём предусмотрена переработка графического конвейера. В традиционном рендере есть Command Buffer, которым реально полностью убрать систему освещения и написать свою. Плюс у меня есть статья, где я костыльно улучшал освещение, модифицируя встроенные шейдеры (на этом принципе, а возможно даже на и моих наработках, реализован ассет Next Gen Soft Shadows). В новых версиях разработчики пошли дальше и сделали программируемый рендер конвейер, который можно полностью переписать, и в нем из коробки реализованы красивые штуки уровня Unreal.
Это все про рендер, то есть про самую требовательную для ресурсов и для многих критичную часть. Резюмирую: все можно переделать под себя или даже заменить полностью.
Что касается остального, то если допустим вам не нужна 2д физика, выключаете компонент, и ресурсы попросту не тратятся. Конечно, библиотеки все равно будут занимать в памяти драгоценные мегабайты, но это та цена, которая осознанно платится за удобство кроссплатформенности.
Что касается скриптов, системы объектов и всего прочего, то в самописном движке вы придете к тому же самому. Не знаю как тесно вплетено все в код Unreal и как трудно от этого отойти, но в Юнити можно реализовать кучу разных подходов, систем сообщений, достаточно легко пишутся расширения редактора чтоб сделать удобные тулзы. И даже ярый велосипедист окажется рад перекатиться в эту среду разработки, если приложит минимальное усилие на начальном этапе.
В целом в статье всё до банального очевидно. Если планируется совсем лютый эксперимент или мобилка — лучше не пользоваться тяжёлым движком.
Но абзац про динамические библиотеки в Unity и Unreal поставил в тупик. Мало того что библиотеки там вообще не для игрового кода ну никак, а для расчетов каких-то жестких или для расширений конкретного движка. Так еще и рассматривается вероятность в серьезном проекте поменять движок в середине разработки. Это как бы ошибка планирования и так делать не надо. Либо это долгострой, в котором на определенном этапе лучше что-то написать заново.
Автор в конце статьи так умильно показывает пример, мол, вот видите, вот и рассылочка )
Как правило, люди, много читающие, жанровые книги предпочитают экспериментальным. Кто если не эти люди будут покупать инди-книги. Они отнюдь не "идиоты", а скорее, наоборот, начитанные интеллигенты, которым в какой-то момент стало мало того, что продается в магазинах, в том или ином смысле.
Ради собственного удовольствия можно писать максимум рассказики в интернете. Но даже с ними приходится проводить серьезную скучную работу, если дело доходит до самого мелкого конкурса (не ради победы так ради того чтобы попасться на глаза новым читателям и желательно не отхватить тухлых помидоров). А уж когда нужно довести до конца роман, не такая уж и большая разница — жанровый он или экспериментальный. Работы непочатый край. С книгой мечты, наверное, даже больше мучений. Особенно если учесть, что скорее всего, это пишется в стол.
Без обид, но к статье это тоже относится. Есть простая поговорка «Краткость — сестра таланта», ей можно было бы заменить весь поток сознания из статьи. Хотя не спорю, есть люди, которые не понимают сути этой поговорки. Для таких людей статья с картинками — самое то.