Суть в наличии дополнительной мета-информации и чистоте доменной модели. Атрибут можно считать в run-time и сгенерить, к примеру, js-код для валидации на клиенте. Или в случае с desktop софтом, то сгенерить форму с автоматической валидацией. Или нагенерить какой-либо код — хоть SQL код для создания триггеров с проверками валидности данных в базе данных.
А свойства с точки зрения ООП лучше создавать всегда, чтобы потом не перелопачивать весь код — иногда требуется кинуть события при изменении данных, или совершать какие-то дополнительные, изначально не предусмотренные действия.
Всегда считал, что за рекламу ответственны вовсе не аналитики и специалисты по безопасности, а банальные маркетологи. Неужели вы действительно верите всему, о чём говорят в рекламе? Все пиарятся так, как могут.
Не соглашусь. Тишина (настоящая, давящая тишина, полное отсутствие звуков) угнетает и сводит с ума. Для нормального психологического состояния всегда должен быть какой-то легкий фоновый шум.
Причем создание новых задач в todoist.com мне нравится больше. Можно просто указать «next thu», а не искать, когда же там будет этот вторник. Или делать повторяющиеся задачи через «every monday». По-моему наиболее практичная форма задания даты задачи.
Почему же грустно? На самом деле очень эффективно. Т.е. игра представляет собой нечто вроде фильма, сюжет которого иногда на ходу меняется кем-то из игроков :-) Или можно это представить так, что каждый из игроков играет в свой вариант сингл-плеера, но действия компьютерных противников определяются действиями других игроков.
У подобного варианта есть большое преимущество — игра может поддерживать действительно гигантские карты (фактически произвольного размера) и произвольное количество объектов на карте. Можно устраивать баталии 1000 на 1000 и не бояться лагов или высокого трафика. И есть большой недостаток — очень высокая сложность реализации и синхронизации, особенно при увеличении количества игроков.
Почему вы считаете, что 10-20 тысяч классов — это показатель успешности и правильности проекта? Для уровня tankionline — это перебор. Я абсолюнто уверен, что на связке Javascript/WebSocket/WebGL реализация подобного проекта будет даже проще и дешевле.
Мне кажется, у вас сложился стереотип, что ООП наиболее удачная и удобная парадигма. На самом деле многие вещи проще делать в фунциональном стиле, в прототипо-ориентированном, а многие — и в обычном процедурном.
Причем, методы, метрики и подходы между парадигмами сильно разнятся. В условиях нетипизированного языка всё делается иначе. В функциональном стиле многое делается совершенно по-другому.
Контроль за кодом благополучно осуществляется благодаря грамотной архитектуре и юнит-тестам.
Если же есть желание использовать именно ООП, то никто не мешает взять GWT/script# и писать на них, используя все преимущества ООП языков высокого уровня — Java и C#. Буквально недавно смотрел порт Quake 2 на GWT/WebGL/WebSocket. Если вы хотите померятся количеством классов, то там их не более 400.
При вмешательстве игрока системы не пройдут проверок целостности и начнётся процесс синхронизации. Даже если игрок сможет вмешаться в механизм проверок целостности, то в этом случае он по сути будет играть в сингл-плеер. Ему будет казаться, что противники дико тупят :-) Что же касается остальных игроков, то у них будет возникать ощущение, что тупит именно читер :-) Это бессмысленно и крайне палевно :-)
Есть некоторые изначальные параметры для рандомайзера, которые получены при инициализации сессии игры. Как вариант, источником этого параметра может являться сервер. Эти параметры определяют всю последовательность чисел, которые могут быть возвращены генератором. Далее каждый последующий вызов Random.Next возвращает строго определенное значение. Это значение и является псевдо-случайным, и оно же определяет все условно-случайные игровые события.
Речь идёт не о waypoints и т.п. Например, самый простой пример. Сражение двух юнитов в игре. Повреждения, наносимые юнитами друг другу определяется синхронизированным ГПСЧ, который гарантирует, что повреждения, нанесённые на машине А, будут идентичны повреждениям наносимым на машине Б. Т.е. без вмешательства игроков, в общем-то система полностью определена и предопределены итоги всех возможных сражений. При этом не факт, что картинка на экранах машин А и Б будет идентична. На одной из машин картинка может запаздывать.
Из-за риска рассинхронизации при высоких latency, необходимы проверки индентичности систем. Грубо говоря, некий CRC. В играх, реализованных по этому принципу, лагов не бывает по определению, но иногда при высоком latency игра будет полностью останавливаться до тех пор, пока уровень задержек не достигнет определенного уровня или системы не станут синхронными.
Система сложна в реализации, очень хрупкая, требует тщательной синхронизации и выверенности, а также множества дополнительных телодвижений для поддержания целостности всего этого добра. Из крупных проектов я знаю, что нечто подобное используется в Starcraft (и в Warcraft, если я не ошибаюсь), Age of Mythology, в Majesty 2.
Сервер WoW, а также MMORPG реализованы по другому принципу, т.к. уровень энтропии вносимый массой игроков убивает эту идею на корню. Кроме того, поддерживать синхронность 8 систем значительно проще поддержания синхронности миллиона систем :-) Да и совершенно бессмысленно, т.к. каждый игрок владеет лишь необходимой ему информацией.
Ну или в мастабной схватке двух армий игрока, все юниты будут получать правильные псевдо-рандомные повреждения, и одинаково на всех машинах себя вести.
Зависит от выбранной реализации сетевой игры. Как я уже писал выше, в масштабных стратегиях зачастую эффективнее передавать действия игроков, а не состояние объектов системы.
Очень хитрый ГПСЧ :-) Исходника, к сожалению, привести не могу, так что, увы, без пруфа.
Используется это для уменьшения количества передаваемых данных, что соответственно уменьшает нагрузку на канал и уменьшает задержки. Например, у нас есть стратегия. Есть сетевая игра на очень большой карте, просто на огромной карте, с некоторым количеством игроков. Допустим, на этой же карте есть 1000 NPC, которые бесцельно бродят или сражаются друг с другом. Для того, чтобы не передавать от клиента к серверу и от сервера ко всем клиентам положение этих NPC и их состояние, можно использовать ГПСЧ. В случае правильной работы этого ГПСЧ положение и действия всех NPC будет одинаковым на всех машинах.
Более того, от сервера к клиенту и от клиента к серверу можно передавать лишь действия игроков, полагая, что на всех машинах положение всех игровых объектов абсолютно идентично. Разумеется, идентичное положение объектов достигается не только благодаря ГПСЧ, но и благодаря ряду других не менее интересных алгоритмов. Есть там и синхронизации, и проверки «целостности» мира.
В современных играх ИИ ограничен таким образом, чтобы игроку было интересно играть в игру. Причём я бы не стал называть используемые алгоритмы именно ИИ, скорее имитацией ИИ. Для упрощения алгоритмов используется множество читерских с точки зрения игрока вещей, т.е. например, знание о том, что и где происходит в игровом мире. Боты в стрелялках могут попадать в игрока со вероятностью, определяемой сложностью игры. Технически они всегда могут делать хедшоты. Противники в стратегиях просто знают местоположение всех юнитов игрока, т.е. эти противники не строят планов, не делают анализа вашей активности в разных частях карты, не производят анализ психологического портрета игрока и т.п.
Интересно, за что минусуют?) Во многих сетевых играх действительно используются алгоритмы генерации псевдослучаных чисел именно для того, чтобы на разных машинах получались одни и те же значения рандома. Помню даже, что очень много гемора было с тем, что эти алгоритмы иногда давали разные значения из-за того, что различные процессоры могли считать слегка по-разному.
Я вот их удаляю или архивирую, в случае отсутствия интереса к ним. Зачем удалять? Для поддержания в папке Входящие порядка. Во входящих у меня остаются только те письма, к которым я хочу вернуться чуть позже, или которые мне понадобятся в ближайшее время, т.е. они все для меня «помеченные флажком». Да, я знаю и про флажки и про ярлыки, но мне так проще.
KDE первой версии вышел после выхода 98 винды, а Konqueror там появился два года спустя.
После выхода Windows 95 Microsoft при разработке следующей системы сделали упор на интернет. Делать подобный упор в 95ой винде было слишком рискованным, т.к. в момент разработки 95ой винды не было уверенности, что интернет станет популярным. И большинству пользователей интернет нафиг не был нужен.
А свойства с точки зрения ООП лучше создавать всегда, чтобы потом не перелопачивать весь код — иногда требуется кинуть события при изменении данных, или совершать какие-то дополнительные, изначально не предусмотренные действия.
У подобного варианта есть большое преимущество — игра может поддерживать действительно гигантские карты (фактически произвольного размера) и произвольное количество объектов на карте. Можно устраивать баталии 1000 на 1000 и не бояться лагов или высокого трафика. И есть большой недостаток — очень высокая сложность реализации и синхронизации, особенно при увеличении количества игроков.
Мне кажется, у вас сложился стереотип, что ООП наиболее удачная и удобная парадигма. На самом деле многие вещи проще делать в фунциональном стиле, в прототипо-ориентированном, а многие — и в обычном процедурном.
Причем, методы, метрики и подходы между парадигмами сильно разнятся. В условиях нетипизированного языка всё делается иначе. В функциональном стиле многое делается совершенно по-другому.
Контроль за кодом благополучно осуществляется благодаря грамотной архитектуре и юнит-тестам.
Если же есть желание использовать именно ООП, то никто не мешает взять GWT/script# и писать на них, используя все преимущества ООП языков высокого уровня — Java и C#. Буквально недавно смотрел порт Quake 2 на GWT/WebGL/WebSocket. Если вы хотите померятся количеством классов, то там их не более 400.
Речь идёт не о waypoints и т.п. Например, самый простой пример. Сражение двух юнитов в игре. Повреждения, наносимые юнитами друг другу определяется синхронизированным ГПСЧ, который гарантирует, что повреждения, нанесённые на машине А, будут идентичны повреждениям наносимым на машине Б. Т.е. без вмешательства игроков, в общем-то система полностью определена и предопределены итоги всех возможных сражений. При этом не факт, что картинка на экранах машин А и Б будет идентична. На одной из машин картинка может запаздывать.
Из-за риска рассинхронизации при высоких latency, необходимы проверки индентичности систем. Грубо говоря, некий CRC. В играх, реализованных по этому принципу, лагов не бывает по определению, но иногда при высоком latency игра будет полностью останавливаться до тех пор, пока уровень задержек не достигнет определенного уровня или системы не станут синхронными.
Система сложна в реализации, очень хрупкая, требует тщательной синхронизации и выверенности, а также множества дополнительных телодвижений для поддержания целостности всего этого добра. Из крупных проектов я знаю, что нечто подобное используется в Starcraft (и в Warcraft, если я не ошибаюсь), Age of Mythology, в Majesty 2.
Сервер WoW, а также MMORPG реализованы по другому принципу, т.к. уровень энтропии вносимый массой игроков убивает эту идею на корню. Кроме того, поддерживать синхронность 8 систем значительно проще поддержания синхронности миллиона систем :-) Да и совершенно бессмысленно, т.к. каждый игрок владеет лишь необходимой ему информацией.
Используется это для уменьшения количества передаваемых данных, что соответственно уменьшает нагрузку на канал и уменьшает задержки. Например, у нас есть стратегия. Есть сетевая игра на очень большой карте, просто на огромной карте, с некоторым количеством игроков. Допустим, на этой же карте есть 1000 NPC, которые бесцельно бродят или сражаются друг с другом. Для того, чтобы не передавать от клиента к серверу и от сервера ко всем клиентам положение этих NPC и их состояние, можно использовать ГПСЧ. В случае правильной работы этого ГПСЧ положение и действия всех NPC будет одинаковым на всех машинах.
Более того, от сервера к клиенту и от клиента к серверу можно передавать лишь действия игроков, полагая, что на всех машинах положение всех игровых объектов абсолютно идентично. Разумеется, идентичное положение объектов достигается не только благодаря ГПСЧ, но и благодаря ряду других не менее интересных алгоритмов. Есть там и синхронизации, и проверки «целостности» мира.
kano.net/javabench/ — вот тут, например, заявляют, что в некоторых тестах ява быстрее :-) Уж не знаю, то ли врут, то ли на плюсах писать не умеют.
www.freewebs.com/godaves/javabench_revisited/ — а здесь повторение вышеуказанного теста. Тут, на мой взгляд, результат более реалистичный.
После выхода Windows 95 Microsoft при разработке следующей системы сделали упор на интернет. Делать подобный упор в 95ой винде было слишком рискованным, т.к. в момент разработки 95ой винды не было уверенности, что интернет станет популярным. И большинству пользователей интернет нафиг не был нужен.