Страницы: «456789101112131415»

Общая > Байки возле уютного костра (там где Гыгыбря) 


  (22.03.22 13:49)  

(22.03.22 13:40)

(22.03.22 13:22)

Если что это- сарказм, ничего общего с БК и играми сайт не имеет, просто нужен человек который разбираться в написании кода и которому можно спокойно дать доступ к хосту не переживая что сайт уйдет в горы

http://capitalcity.combats.com/inf.pl?1190902384


Ок, это кто? И почему мне должно быть это интересно?


  (22.03.22 20:23)  

(21.03.22 23:29)
Я думаю формулу рассчета рейтинга излома вывести сейчас сможет 1-2 человека в бк даже зная исходные данные что главный критерий время и урон + доп параметры еще есть.


урон делить на квадрат времени было. Ну с коэффициентом, возможно, каким-то.


  (22.03.22 22:38)  

что там делат надо?


  (22.03.22 22:47)  

(20.03.22 22:55)
...


думаю только если с рук. Вроде как они были выпущены ограниченным тиражом, и были подарены во время встречи с игроками в рамках события "Искушение Спортом". Хотя могу и ошибаться.


  (22.03.22 23:04)  

(22.03.22 22:47)

(20.03.22 22:55)
...

думаю только если с рук. Вроде как они были выпущены ограниченным тиражом, и были подарены во время встречи с игроками в рамках события "Искушение Спортом". Хотя могу и ошибаться.


спасибо! жалко((((


  (22.03.22 23:23)  

(21.03.22 23:29)

за 5 лет работы в клоне.


Так ваш клон был на PHP, как и все существующие сегодня. Это кто-то из энтузиастов изначально написал код и просто скопировал туда дизайн с бк. Получился некий схожий с бк проект на совсем другом языке программирования, а тут человек пишет именно про украденный код проекта, который на языке Perl. Я таких исходников БК на языке Perl в сети не встречал.


  (23.03.22 00:11)  



Энтузиасты и вызов ГД

Проблема горизонта планирования остро стоит в любом бизнесе. Но в игровых мирах она занимает едва ли не главное место в оперировании проектом. В тех самых мобильно-социальных флагманах, которые я упоминал до этого, аудиторию изучают, замеряют десятки, а то и сотни самых разнообразных параметров - от проведенного в игре времени и потраченных средств, вплоть до знака зодиака. Аналитики делят игроков на когорты, формулируют психотипы, моделируют поведение пользователей, чтобы выжать максимум из каждого, будь то "кит" или крохотная рыбёшка.

Нам не нравится относится к нашему игроку, как к строчке в таблице, кучке циферок в столбцах. Поэтому у нас в проекте существует своя, выработанная с годами классификация. Её вряд ли получится использовать где-то за пределами БК, кроме того она больше базируется на опыте и чуйке Ангелов. Благодаря тому, что сообщество игроков БК сложилось и давно устаканилось, у нас индивидуальный подход к каждому игроку.

Среди различных моделей поведения игроков БК можно выделить особый тип, который можно назвать... энтузиастами. Те, кто всегда впереди и раньше всех. Начинается новый квест эти люди выполнили его уже вчера и с нетерпением спрашивают, что делать дальше. По заданию нужно убить 10 монстров? Они уничтожат 100, просто чтобы посмотреть, что дадут за это. Ничего? Тогда расправятся с 1000!

Из-за таких активных деятелей очень тяжело строить прогнозы по времени прохождения того или иного квеста, подземелья. Вызов, стоящий перед разработчиком любого мероприятия в БК, непрост, с одной стороны, сделать так, чтобы обычный игрок не взвыл от завышенных требований, но одновременно не дать заскучать тем самым энтузиастам ("ну что это за задание такое уничтожить сто тысяч Болотных Троллей? Для меня это скучный вечер среды!"). Приходится идти на различные ухищрения. Например, вводить логарифмическую шкалу награды, лимитировать использование каких-то предметов, при этом пытаться не разрушить баланс. Иногда приходится создавать чуть ли не два параллельных ивента! Один для обычных игроков, которые предпочитают, не спеша, с чашечкой чая идти по уже проложенной дороге. Другой для тех, кто мечтает быть тем самым торителем троп, быть везде лучшим или хотя бы первым. Умение создавать подобные параллельные мероприятия приходит с опытом. Множество ранних вещей в нашем проекте делалось без учёта этого, подобные ивенты легко опознать по тому, насколько быстро всё это выполняет обычный игрок.

Например, когда создавались подвиги, ответственный за них молодой разработчик насчитал, что на взятие некоторых из них людям понадобится приблизительно около года. Для этого он поднял общую статистику, разобрался с активностью игроков, посмотрел как часто они занимаются чем-то подобным. Получилось, что средний пользователь выполняет аналогичную задачу раз в день. То есть за месяц будет 30, за год 360. Если поставить пять сотен как конечную цель подвига то самые старательные его выполнят где-то в пределах года, just as planned.

Вы уже догадались, что было дальше. После ввода подвигов поведение этого самого стандартного пользователя в корне поменялось. В нём проснулся энтузиазм! Вместо того, чтобы по привычке раз в день делать нужное по подвигу действие, они занимались этим всеми возможными способами сутки напролёт. Большинство умудрялось совершать это действие десятки раз в день, а особо преисполнившиеся энтузиазмом набивали до полусотни. Геймдизайнер ожидал, что игроки будут получать подвиг где-то на "заднем плане" - то есть, будут заниматься обычными делами и, сами не замечая, получать подвиг.

Конечно прогнозы отправились в мусорку. Энтузиасты составили себе чёткое расписание и словно по будильнику выполняли нужные действия, не теряя ни секунды даром. И всё ради того, чтобы получить этот подвиг чуть раньше других! Вы бы видели лицо стажёра, когда через три недели ему сообщили, что игроки уже завершили всю линейку... это было крушением всего его аналитического аппарата. В общем, математика для геймдизайнера штука необходимая, но психология и социология в данном случае куда важнее. Предлагаете игрокам возможность получить что-то постепенно? Ожидайте, что они предпочтут взять все и сразу. Я же до сих пор вспоминаю, как при моей первой попытке устроить подобное, опытные товарищи, едва скрывая улыбку, сказали: "сколько-сколько предметов ты требуешь? Умножь это тысяч на десять, и будет в самый раз". Интуиция их тогда не подвела большинство бкшников из спокойных и неторопливых копателей превратились в электровеники, что буквально пылесосили подземелья и сдавали ресурсы сотнями за поход. Я не зря прислушался к старшим товарищам - игроки уложились, примерно, в нужные мне даты. Плюс-минус пара дней.


  (23.03.22 00:19)  

какие такие энтузиасты???


  (23.03.22 00:22)  

Благодать, можете вернуть доступ к разделу новостей https://forum.combats.com/forum.pl?n=news ? Это же история самых первых дней проекта 2002-2004 годов. Более позднее можно найти на events.combats.com, современное на news.combats.com, а о совсем ранних временах ничего не осталось, а это было местом где все кто не играл в те времена мог составить представление о том какой была игра в 2002-03 годах или поностальгировать о том, чего уже давно нет в проекте, как например кольца мороза/огня которые били магическим уроном или кареты на вокзалах. Помню читал всё это, и мурашки по коже...


  (23.03.22 01:08)  

100к килов - вот тут переборщили, как мне кажется)


  (23.03.22 01:48)  

Ограничение это хорошо, но как быть с тем, что планку задают персонажи, которые много заливают в проект реала? Разве на них надо равнять остальных игроков, которые приходят в поисках удовольствия, а не вечного капания для достижения чего либо?


  (23.03.22 09:22)  

"у нас индивидуальный подход к каждому игроку" (с)


  (23.03.22 14:24)   +2 (+2/-0)

(23.03.22 00:19)

какие такие энтузиасты???


те, которых задротами называют в обиходе :)


  (23.03.22 14:48)  

вот для чего в новых натыкали таймеры?)


  (23.03.22 18:26)  

(23.03.22 00:11)

опытные товарищи, едва скрывая улыбку, сказали: "сколько-сколько предметов ты требуешь? Умножь это тысяч на десять, и будет в самый раз".

Так вот где Красти)


  (23.03.22 22:52)  

(23.03.22 00:11)

Вы бы видели лицо стажёра, когда через три недели ему сообщили, что игроки уже завершили всю линейку... это было крушением всего его аналитического аппарата.


Вот тут засмеялся в голос! :-D


  (24.03.22 00:41)  



Программисты и художники


В современной доктрине управления во главу угла ставятся отношения в коллективе. Без прикрас скажу - в нашем проекте с этим всё в порядке. Каждый участник команды обладает железным правом как высказать свое мнение, так и быть за него осмеянным. Голоса всех разработчиков обладают одинаковым весом, в обсуждении любой задумки учитываются интересы каждого, кто вовлечён в проект. Геймдизайнер может предложить добавить в очередную пещеру динамическое освещение и трёхмерные объекты. Программист в ответ имеет полное право послать геймдизайнера в края, где динамическое освещение ему точно не пригодится, так как солнце там не светит. Впрочем, и куда более обоснованные нововведения приходится обосновывать и отстаивать, ведь как известно, любой хороший программист должен быть в меру ленив, а значит прикладывает все усилия для того, чтобы не делать лишнюю (с его точки зрения) работу.

Вот пример из жизни - получение случайного числа. Совершенно тривиальная для обычного человека функция, повсеместно распространённая, а уж в геймдеве так вообще едва ли не основная. Однако, если взглянуть на неё с позиции программиста, оказывается, что для её реализации не всегда достаточно написать в коде random_variable, особенно когда требуются какие-то специфические условия. Поэтому, каждый опытный программист старается всеми способами избегать этих самых случайных чисел вообще и особых условий в частности.

Но вот дизайнеру нужно сложить два случайных значения от 1 до 5. Программист, пожав плечами ("чудные эти геймдизы, честное слово..."), пишет один вызов от 1 до 10. Казалось бы, результат один и тот же, так зачем усложнять, да? Но нет. С точки зрения теории вероятностей эти два уравнения не тождественны. Странно, контринтуитивно, кажется нелогичным, но это так.

В варианте, который реализовал программист (обычный рандом от 1 до 10) все значения равновероятны. А вот в задумке геймдизайнера число 6 будет выпадать в пять раз чаще, чем 2 или 10. А 1 не выпадет вообще - потому что итоговое значение получается из суммы двух бросков виртуальных костей (1+1). Как это доказать уверенному в своей правоте программисту? Создать в Excel таблицу и сделать график распределения. Наглядная демонстрация действительно стала последним аргументом в том споре.

Другой случай - у одного из программистов появилась идея создать механику сражения на поле 3 на 3 клетки и выставление двух атак и четырёх блоков. Опытный геймдизайнер видит фундаментальные проблемы этой задумки уже на этапе концепта. Но как убедить программиста? Тут графиком уже не отделаешься. Нас рассудит плейтест: берём лист бумаги, чертим поле и играем по новым правилам. Спустя двадцать абсолютно безрезультатных ходов программист соглашается, что механика имеет свои недостатки...

Программисты, которые работают с приёмами, вообще страшные люди. Они в своём познании настолько преисполнились, что попытка понять принцип работы созданных ими заклинаний, для простого человека может закончится психическим расстройством. Обычные приёмы в нашем проекте составляются из заранее заготовленных блоков, словно домик из кубиков. Кубик - это тип воздействия, вроде нанесения урона или снятия другого эффекта. И у этого эффекта будут параметры - тип урона, размер повреждений, будет ли игнорироваться броня и так далее. Из этих элементарных частиц собирают самые разнообразные механики. Но всё меняется, когда в дело вступает программист.

Кубики в их приёме - это просто вещь в себе. Никаких настроек или параметров, всё скрыто глубоко в недрах кода, куда не всякий новичок рискнёт заглянуть. Кроме автора, никто в целом свете не может понять, как работает этот ящик пандоры, а в отдельных случаях внятно объяснить это не может и сам создатель. Конечно, почти каждый такой кубик является штучной разработкой, которая больше нигде и не используется, ведь любое вмешательство в его работу может привести к непредсказуемым последствиям: от невозможности использования лечения магами до отключения света в Воронеже.

Понятие об удобном графическом интерфейсе у таких людей тоже своё. Они могут создать дизайн, где галочками будут выделяться параметры, которые НЕ НАДО включать. Пять кнопок, которые нужно последовательно нажать, чтобы получить подтверждение - это всё к ним.

Показателен один пример разницы подхода ГД и программиста. Нужен приём, который уничтожает персонажа, ультимативно и безаппеляционно. Сделать это мы можем с помощью "кубика" под названием "убить". Однако, проблема: если у персонажа есть дух, после убийства он восстанет. А нам нужно, чтобы этого не происходило. Предложение программиста: "залезем внутрь профиля игрока, находим там параметр "возможность переворота" и стираем его! Но надо будет написать скрипт, проверяющий, что этот параметр действительно там есть, иначе может произойти коллизия с непредсказуемыми последствиями. Хм, можно сделать запрос в БД прямо во время боя... Интересно, мы такое сможем сделать? Нужно будет написать скрипт, который...". Предложение ГД: "Просто подряд используем два кубика со смертью!". И да, этот вариант сработал.

Художники же - полная противоположность прагматичным программистам. Чистая фантазия и полёт вдохновения. Просишь их нарисовать защитницу, валькирию, сильную женщину, охраняющую границы заповедника - получаешь Гемайю. Требуется иллюстрировать походную сумку-узелок - получаешь картинку с двумя связанными верёвочками. Ты же узелок просил. Вот оно, какие проблемы? Помните знаменитого кровавого хомячка из первоапрельских масок? Он появился из простого технического задания - "нужна семейка зомби. Ну там папа, мама, сынок и всё такое". "Всё такое" художник понял по-своему. У любой же семьи есть хомячок? У него в семье, видимо, был. Значит, и тут пусть будет. Что с ним делать дальше? Ну, вы же Геймдизайнеры, вот и придумайте!

И да, именно геймдизайнеры стоят между этими двумя крайностями. Мы все согласовываем, убеждаем, что вот так лучше не делать. Например, что игроки не поймут, если вместо строки с вводом значения, они получат выпадающего список из сотни пунктов. Или что образу зловещего воина не нужна железная метёлка, как бы это не было в тему.

Но, как я уже сказал, в БК нет чистых "программистов", "геймдизайнеров" или "художников", каждый из нас нередко окунается в обязанности соседнего отдела. Мне вот приходилось рисовать несколько иконок для приёмов, когда художник был занят. Программисты часто делают дизайн интерфейсов (под чутким надзором). Ну а в придумывании и тестировании механик вообще принимает участие весь коллектив. Поэтому для нас БК - не просто узкая прослойка обязанностей по должностной инструкции, а настоящий сын полка, в комплексном воспитании которого каждый выкладывается на полную.


  (24.03.22 00:59)  

(24.03.22 00:41)

В варианте, который реализовал программист (обычный рандом от 1 до 10) все значения равновероятны. А вот в задумке геймдизайнера число 6 будет выпадать в пять раз чаще, чем 2 или 10. А 1 не выпадет вообще - потому что итоговое значение получается из суммы двух бросков виртуальных костей (1+1). Как это доказать уверенному в своей правоте программисту? Создать в Excel таблицу и сделать график распределения. Наглядная демонстрация действительно стала последним аргументом в том споре.


Это многое объясняет ) Ну в смысле об уровне тех, кто программирует БК ) Теперь можно удивляться чуть меньше )

(24.03.22 00:41)

Предложение ГД: "Просто подряд используем два кубика со смертью!". И да, этот вариант сработал.


Вот почему, когда каким-то бонусом было допспасение в пещере, цветных ботов в ВПК убивали без свитков? Логично )


  (24.03.22 01:10)  

А ведь логичнее было бы просто поставить условие:
триггер -> если персонаж жив -> применить смерть -? возврат на шаг назад (повторно пройти условие)
Тогда бы никакие тройные спасы не помогли)
Но спасибо за доп возможности в сентябре))


  (24.03.22 01:31)  

неплохо было бы серия известных "секретов бк" )

(это реально не нытье или что то, просто пример, давно знаем и уважаем) =>
против мф.уварот 11к, арб с 1800 антиуварот попадает 50%, когда топор/крит 10-20%?
тут точно не рандом) для каждого класса что то доп.секретный мф есть в Мире БК?


Страницы: «456789101112131415»
© 2002 - 2024, «www.Combats.com»™
All rights reserved