ВОВ
-
ниасилил :shock:
-
Че тут ниасилить и не понять них блин???
Ползут два помидора по рельсам. Идет поезд. Один говорит - тебя первым раздавит. Нет, тебя. Нет, теб-уааааааа!.. Я же говорил, что теб-уааааа!
Все асилили?
-
-осторожно , тут лестница!
-пофиг-иг-иг-иг -
Расчлинитили кудрявых обезьян? О_о
-
-
И кто там говорил о вреде марихуаны? =))))
-
При чем тут марихуана? Слабоумие (ниасиленье) вызывает токсикация свинцом, из выхлопных газов.
-
Осилил. Бред. Тупая статья. Надо было сначала специально так сделать, чтоб инфекция переносилась, а потом править свои труды.
Вопрос в другом: Что по мнению квестовиков должно было стать с теми, в которых попал Хакар? Они должны были умереть? Это тоже правильно?Вобщем, предлагаю делать игру типа жизнь - с наикрутейшей графикой и галимейшим сюжетом.
-
Непонятно только, почему статья - бред. Она описывает ситуацию. Ситуация может быть бредовой или не бредовой, статья-то тут при чем?..
Лично для меня самое интересное в статье, помимо конечно самого казуса, было то, что на BBC поднимаются столь частные темы какой-то игрушки. Это как если б по первому каналу в Новостях рассказали как команда Урюпинска на чемпионате по Кваку объелась некачественных сосисок и выбыла из игры, что из этого получилось и как разруливали ситуацию организаторы... -
Smolniy, BBC вещает о новостях во всех сферах жизни мира. Эта проблема затронула многие тысячи игроков, причем очень серьезно отразилась на их моральном состоянии. Вполне логично, что BBC об этом сообщила.
-
Smolniy, это называется двумя буквами, и еще бывает черным. Если не догадался, то напишу сразу - PR.
Статья написана на очень низком, так сказать "обыденном", уровне без техподробностей. Вы хоть представляете, что значит сделать какой-то вид животных переносчиком инфекции с точки зрения хотя бы баз данных? Надо иметь, грубо говоря, ячейку памяти с признаком инфекции и у животного, и у зараженного.
Я точно так же могу рассуждать о чем угодно, даже сказать, что ураганы Катрина и Рита - плод воображения местных штатовских укурков и радикальных исламистов. -
Kimurin, вот об том и речь - игрища становятся социальным явлением без скидок.
TheEvilOne, ну, это перепечатка с ленты, надо первоисточник посмотреть... С другой стороны, популярные издания никогда не отличались технической точностью, я слежу за публикациями по космонавтике и иной раз просто в корчах бьюсь от сверхнекомпетентности журнашлюг. Так что нусутх.
Штука в том, что в описанных правилах взаимодействия вирт. мира обнаружились последствия, не предусмотренные разработчиками, нелокализуемого, неконтролируемого, саморазвивающзегося характера т.е. "мир себя ведет". Такие явления скорее свойственны для животного мира. Это уже давно наблюдается, просто еще одна иллюстрация, не более того. Широко известный пример с игрой live для масс неубедителен, т.к. слишком абстрактен, зато прост в понимании. Описанный казус еще более доступен в понимании
-
Давай еще про винды пообсуждаем.
Виртуальный мир - это просто набор данных и алгоритмов их взаимодействия.
В случае с инфекцией - должен быть четко прописанный алгоритм ее распространения, обработки и форматы входных/выходных/используемых данных. Низачто не поверю, что ВоВ сделан на совсем других принципах, а не на традиционном программировании. До реализации чего-либо путного на динамически изменяемых структурах данных, генетических и эволюционных алгоритмах мировой "порноиндустрии" еще далеко. -
Вот уж ерунда. Динамическая структура - элементарная вещь, используемая давно и массово. Есть структура, описывающая любой объект, есть атрибуты. Где-то описаны алгоритмы, регламентирующие переход признака из одной структуры в другую с сохранением в старой или без, или с модификацией. Главное - формализовать эволюцию атрибута. Т.о. получается нормальная гибкая динамичная структура, которую очень удобно наращивать. JAthena написана на си (даже не си++), довольно прямолинейно и тупенько. Зато надежненько.
Применительно к ММОРПГ динамические структуры очень удобны, позволяют легко расширять количество параметров объекта (персонажа, пета, оружия етс). Например, завтра нам приспичило ввести новый атрибут оружия "святость", накладываемого спеллом. Описываем как он должен действовать (например, при наличии у моба атрибута "живой мертвец" + 20% урона), описываем спелл и его последствия (добавление у объектов "ручное оружие" параметра "святое" с ограничением по времени), обеспечиваем в клиенте отображение (тоже динамический список, делов-то) и все. Ну и любое действие (напр. атака) проходит через конвейер обработок с приоритетами. Все это вместе обзовем "вирт. мир" - просто термин теории информации, мы же не спорим, что пачку "данные+функции" назвали гордо Классы? Удобно и сердито, хоть и не макс. оптимально. Когда я писал CMS, построил ее на этой схеме.
Что тут сложного? Все более чем традиционно, никакой "генетики"
Такие системы как раз уязвимы в том аспекте, который описан в статье. -
Почитай мой пост еще раз. Я специально сказал: "на динамически изменяемых структурах данных". Подумай еще раз. Одного раза тебе не хватило.
Насчет уязвимости по этому вопросу: сначала уязвимость надо создать. Допустим, основа уязвимости - это опускание проблем информационной безопасности. Здесь халявить нельзя. Но в нашем случае - это не эксплоит. Надо было сначала такую "уязвимость" создать, чтобы она работала. Я говорю тебе про то, что признак "болезни" должен быть заложен в структуру данных и обрабатываться алгоритмом, в простейшем случае - таймером смерти. А еще сказка про определенный вид животных - если бы была такого рода структура, то скорее всего заразу могли переносить все животные. По принципу наследования классов хотя бы.
Так что рекомендую подумать еще раз или два. -
Я прекрасно тебя понял. Ты сказал: "До реализации чего-либо путного на динамически изменяемых структурах данных, генетических и эволюционных алгоритмах мировой "порноиндустрии" еще далеко." Так вот, не далеко. Путные вещи "на динамически изменяемых структурах данных" делают пачками. Или ты под "динамически изменяемых структурах данных" подразумеваешь нечто другое?
О животных. (буду говорить в терминах РО, терминами ВОВ не владею) Допустим, заразиться могут только животные класса brute. Допустим, теймится только один вид животных класса brute. Он и стал разносчиком, т.к. люди тоже brute. Если структура динамическая, признак не нужно никуда закладывать, надо описать условия его "проникновения". Условие - принадлежность к классу brute. Положим, животные бессмертны, в отличие от персонажей (как на РО; отработка смерти пета в сырцах отсутствует). Таймер смерти у людей обеспечивает нераспространение инфекции за пределы нашей спецлокации - инфицированные не уйдут, помрут по дороге; животное же может вынести его наружу (особенно если его можно "законсервировать" в яйцо, как в РО, с сохранением его состояний).Уверяю тебя, я с легкостью придумаю непротиворечивый набор правил, при которых описанная схема будет иметь право на существование. Подумать для этого мне придется один раз.
А вообще - правильней всего почитать источники, что же там действительно произошло. Однако и так понятно, что случилось нечто достаточно экзотическое, что не предусмотрели разработчики.
-
Дословно повторяю, что я сказал: "динамически изменяемые структуры данных". То есть класс, который в любой момент времени может поменять свою структуру в зависимости от условий. То, про что ты мне три поста втолковываешь, называется динамическое распределение памяти, которое просто, как каменный топорик. То, о чем я говорю, не достигается сейчас даже шаблонами (templates), говоря на языке программирования, хотя именно шаблоны и являются сейчас самым передовым решением, отходящим от канонов объектно-ориентированного программирования.
Такого рода задача в теории решается методами искусственного интеллекта. Причем глобальными методами, а не так, как сейчас используют только выводы при написании скриптов поведения. Именно поэтому активное использование генетических и эволюционных алгоритмов откроет новые технологические решения в "игростроении". Сейчас даже идет речь о создании не только "физических" чипов, но и нейросетевых чипов с ориентацией на игровое ПО. Это заметка для размышления. Подумай еще пару раз. Лишним не будет.
Насчет источников согласен, только читать не буду, если что-то путное вынесешь оттуда, сообщи.
И все-таки эта ситуация напоминает мне известную поговорку - перекуем баги на фичи. Я останусь пока при своем мнении в том, что для того, чтобы был баг, кто-то должен его написать.
Вот только не надо сюда приплетать теорию сложных систем, синергетику и все с этим связанное. -
Ничего я приплетать не буду. "Извините пожалуйста" ((с) Служебный роман), я не понял твой термин, который можно трактовать разными способами, в т.ч. и так, как это сделал я. А для того, чтобы возникла сабжевая ошибка, нейросетей и прочей зауми не требуется. Ты сказал: "Вы хоть представляете, что значит сделать какой-то вид животных переносчиком инфекции с точки зрения хотя бы баз данных? Надо иметь, грубо говоря, ячейку памяти с признаком инфекции и у животного, и у зараженного." Ответ - таки да, представляем, таки без проблем реализуемо, таки разумеется плод концептуальной ошибки, и делается например на основе того, что ты назвал "динамическим распределением памяти". Не забывай, что повсюду используются в массе либо БД неправильные, не соответствующие набору НФ, и тогда некие данные вполне могут быть агрегированы в одной ячейке, и тогда суй их туда сколько хочешь. С другой стороны, несложно сделать правильную БД, заточенную на хранение произвольного кол-ва параметров для любого объекта (ключ: id объекта, название параметра). То же самое с хранением не в БД а в файлах. А ошибка может быть заложена не в алгоритмах перехода параметра при взаимодействии объектов, а в отсутствии ограничения на таковой переход, что и приводит к сабжевым ошибкам, без явного наличия "неправильного кода". Ошибка не в неправильном коде, а в его отсутствии.
Иными словами, к чему твое высказывание, становится непонятно.
А вот раньше ты сказал совершенно правильную вещь: "Надо было сначала специально так сделать, чтоб инфекция переносилась, а потом править свои труды." Ровно так, видимо, и случилось.И вообще, если есть ссылки на то, о чем ты говоришь (я уже боюсь произносить), то дай мне, я почитаю не отвлекая тебя. Все-таки видимо я не понимаю, что ты подразумеваешь под "структурой данных". Мне всегда мнилось, что речь об иерархии, зависимости данных. Менять зависимость данных по входящим воздействиям при формализации этих модицикаций - не является проблемой и есть все равно перекладывание переменных из одного кармана в другой. Без нейросетей.
-
Нейросети здесь просто к примеру.
Перейдем к структурам данных: Я называю структурой принцип расположения данных, в общем то же, что и ты. Иерархия, как таковая- очень жесткая структура. Как была запрограммирована, так и работает. То, что ты описал во фразе "ИД объекта - данные", дополнив словами о множестве таблиц, оказывается БД пятой формы нормализации. Причем это применимо для реляционных баз данных. Напомню, что также существуют объектно-ориентированные базы данных.
Я же предположил о саморазвивающейся структуре хранения информации и ее ассоциативной реализации на нейросетях. Простой пример: работа человеческой памяти, в которой хранится уйма информации по "ключевым полям", да еще и методы обработки различаются кардинально.
В свете этого представим себе абстрактную игру как набор взаимоувязанных блоков-нейросетей и методы взаимодействия в виде физических, генетических и эволюционных алгоритмов. Получим имитацию, некую модель, взаимодействия "разумных" объектов. Только вот пока до такого не доросла наша всеми любимая персональная вычислительная техника. Даже научные реализации таких принципов построения остаются довольно примитивными, грубо говоря, просто не хватает стандартной вычислительной мощности. Поэтому и существует специндустрия нейрочипов, хотя бы в плане аппаратуры распознавания образов.Это было небольшое отвлечение, ведь надо поддерживать статус флудера...
Так вот, я как минимум два раза тебе указал на то, что ты неверно трактуешь мои фразы. С третьего раза до тебя дошло. Ну хоть на этом спасибо.Отойдя от флейма и теории того, чего нет, я скажу так: По всей видимости, кто-то добавил некую "фичу", которая и превратилась в баг. Учитывая существующие технологии разработки ПО, я склоняюсь ко мнению, что этот "баг" был введен специально, либо специально, то есть намеренно, был оставлен без исправления.
Так что все эти статьи не несут никакой полезной информации, кроме пиара, и являются не только инфо, но и имхо. -
Иерархию данных менять столь же просто, как добавить элемент в связный список. Любая библиотека работы с xml заточена как раз на такие задачи - разбор, формирование и изменение связанных иерархических данных.
Вчера вечером я понял, что ты говоришь не о сабже, а оффтопишь. Извини, догадаться об этом без предупреждения было как-то непросто.
Что касается схемы твоей игры, то это будет игра без правил или с эволюционирующими правилами, что неинтересно или узкоспециально.
В обчем, договорились...
