понедельник, 1 февраля 2016 г.

Итоги января

Всем привет, Охотник на связи.
Январь прошёл, пора подвести итоги.

В целом месяц получился достаточно плодотворный, я оформил базовую модель психики, парной социализации и завязанную на ней схему воспитания рабов. Чтобы это дело обкатать, и не городить лишнего в текущем билде ТВР, мы делаем отдельную тестовую модель, в виде игрушки про простого русского студента(-тку) Антошку и его(её) строгую, тираничную матушку. Пока где-то на полпути.
Там собственно будет опция игры за студента/студентку либо за мать. В случае игры за студента мы моделируем вариант когда наш персонаж находится в рабстве и компьютер пытается его воспитать в интересах компьютерного персонажа. В случае игры за мать, наоборот - моделируем воспитание компьютерного персонажа от лица игрока-хозяина. Получается что и в том и в другом случае мы играем как бы партию против компьютерного оппонента, но ассиметрично. Цели тоже разные - у студента самостоятельность и успешность в личной жизни, у матери - подчинить студента, контролировать его личную жизнь и заставить работать на себя. Как такового эротического контента в игре не предполагается, графического оформления тоже. В принципе в игровую форму это облечено только с целью тестирования модели, но результатами мы поделимся, кому интересно погоняют, нам не жалко. Сеттинг пародийный, на основе "бугурт тредов" двача. Чего либо значительного в плане геймплея или сюжета ждать не стоит. Но можно будет прикинуть как в общих чертах будет выглядеть взаимодействие хозяин/раб с обеих сторон.

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

Так же в каменты призываются мастера построения алгоритмов. Мы тут ломаем зубы об одну задачку. Дано: схема восстановления внутренних ресурсов. Внутренние ресурсы, это такие пойнты, привязанные к базовым характеристикам - выносливость, собранность, сила воли и т.п. Каждый из них может быть в диапазоне от 0 до уровня привязанной характеристики (условно до 5 максимум, у среднего персонажа до 3). Эти ресурсы можно тратить на выполнение различных задач, а восстанавливаются они раз в ход, но не простым а заковыристым способом. А именно. Каждое событие, активированное вручную, случайно или просто установленное в расписании, может нести маркер рененерации с думя характеристиками: 1) какие ресурсы этим маркером можно восстановить (например ["выносливость","сила_воли"]) и 2) какова сила восстановления (целое положительное число).
На каждую единицу внутреннего ресурса который мы хотим восстановить, необходимо потратить один маркер рененерации. При этом его сила, должна быть не меньше чем количество уже восстановленных на этом ходу внутренних ресурсов любого типа.
Например: мы поспали в удобной кроватке ("выносливость", 3), отказались делать неприятную работу ("сила воли", 2), отдохнули на солнышке ("выносливость", 2)  и съели чуть-чуть еды ("выносливость", 1).
При этом, например у нас не хватает одной единицы силы воли, и двух единиц выносливости.
Если распределять восстановление вручную то понятно что мы тратим восстановления выносливости 1го и 3го уровня и восстановление силы воли 2го уровня. В любом другом случае мы не сможем восстановить всё. Но хочется не грузить игрока этим менеджентом и отдать всё считать компьютеру. Но как сделать так чтобы он тратил восстановления в такой схеме оптимальным образом не очень понятно. У нас пока есть две модели: одна сложная и лишенная всякой элегантности, а вторая требовательная к вычислительным ресурсам (особенно когда мы вспомним что в игре могут быть десятки и сотни персонажей для которых это всё надо на каждом ходу считать).
Если у кого-то есть простой и красивый алгоритм решающий задачу, это бы нам помогло.


85 комментариев:

  1. Этот комментарий был удален автором.

    ОтветитьУдалить
    Ответы
    1. http://radikal.ru/fp/a9130eb00e81480499173c29f1c4618b
      Да уж. Как-то туговато у блогспота с загрузкой картинок(((

      Удалить
  2. Этот комментарий был удален автором.

    ОтветитьУдалить
  3. Прочитал условия, вроде понял, прочитал ответ и понял, что не понял :) Ну или в ответе ошибка. Если единственное требование это сила маркера выше, чем количество восстановленных за ход ресурсов, а восстанавливает все по единице, то для выносливости нам достаточно 1 и 2 маркера, зачем нам 3?
    Дальше, нужно понимание сколько маркеров (для одного ресурса) может присутствовать в задаче. Потому что если 2-4 (а больше, вроде как и незачем), то тупой перебор комбинаций даст почти тот же результат, что и заковыристый алгоритм. Есть смысл думать над алгоритмом, если таких маркеров десятки (в одной задаче).
    И еще об йогуртах. Пару лет назад работали над моделью для некоего "симулятора жизни". Там народ выкатил сложную модель метаболизма, наподобие той, что ты упоминал в старом диздоке, но еще заковыристей. А потом все задумались как это обсчитывать для сотен персонажей (с учетом поведенческой модели) и приуныли. А потом пришел умный человек и спросил - а накуя? Большинство персонажей игрок видит спорадически, редко и красоту модели он просто не может оценить. Потому что просто не видит даже "входных данных" (что персонаж ест и как проводит время). Поэтому есть смысл подробно моделировать только самого персонажа и его ближайшее окружение, а для остальных - примитивная имитационная функция. Так что подумайте, а реально нужно всю эту ресурсную модель считать для сотен персонажей? :)

    ОтветитьУдалить
    Ответы
    1. Нет, однако надо как-то переформулировать задачу. Как я ее понял изначально - там вообще задача оптимизации примитивная получается, видимо я чего-то не понял.

      Удалить
    2. Ок, да. Читай "сила маркера выше чем количество восстановленных ресурсов + 1". Немного обсчитался я тут, но суть задачи прежняя.
      Как минимум десятки персонажей будут актуальны. А учитывая что есть тут любители содержать рабынь целыми дивизиями, наверняка разлочат множители и вперёд...
      Так что нужно.

      Удалить
    3. Тогда распиши примитивный алгоритм, может мы тут просто затупили - такое тоже бывает.

      Удалить
    4. Я бы не ориентировался на любителей собирать дивизии рабынь. Предполагаю, что статистически большинство не будет собирать больше пары десятков, а то и вообще двух-трёх. Значит, если будет стоять принципиальный выбор, то желательно ориентироваться на большинство. В данном конкретном вопросе.

      Удалить
    5. Вспомнил про игру одну, нашу, про танки. Симулятор серьезный. Когда ее показывали на выставке, она дико глючила, даже на мощном железе. Оказалось, что игрушка была настолько хардкорна, что обсчитывала танкистов и их состояния, хотя их самих никто и не видел никогда по ходу игры (танк подбили, он просто стоит и горит).
      С одной стороны - логично, что надо экономить ресурсы и не нагружать железо тем, что игрок не видит и не может пощупать, как не имеющее гейплейной сути в текущий момент. А с другой стороны - познакомился ты в деревне с персонажем, пообщался. А он весь такой немного болезный, с горшка, извините, не слазит. Плюнул ты на это, пошел монстров бить в туманы, попал в плен, отрастил бороду, выбрался обратно. Проходил мимо деревни, а то за сараем опять ваш новый знакомый. Такой же болезный и гадит везде. Ничего не изменилось. А должно бы, ведь неаутентично..

      Я если ничего не путаю, то обсчитывать всякое надо же не только у рабынь и всяких таких, но и у просто NPC?

      Удалить
  4. Ну если я правильно понял, то нам просто нужен маркер силы n+1 или выше, где n - количество уже восстановленных ресурсов. Поэтому просто пробегаемся по списку маркеров и ищем любой (если нет других условий), маркер подходящей силы, если нет - ищем на единицу выше и т.д. Для ускорения поиска имеющиеся маркеры распихиваем по структуре. Типа двухуровневого динамического массива или hashtable, там уже надо дополнительно условия смотреть. Первый уровень - деление по ресурсам, второй - по силе. Если маркеров в пределах десятка и сила 1-5, то там ничего сложнее и не нужно. Все равно ничего оптимальнее "использовать маркер с минимальной силой из тех, что ниже n" тут не придумать. Или есть еще какие-то детали?

    ОтветитьУдалить
    Ответы
    1. Пардон, там должно быть "из тех, что выше n" :)

      Удалить
  5. Охотник, сотню персонажей современный компьютер потянет не поперхнувшись, особенно если игра вроде как текстовая.

    Проще всего использовать сложную модель для героя, и рандом для тех, кем управляет компьютер. Это просто потому, что если компьютер восстановление ресурсов будет считать оптимально, игра станет унылой, т.к. компьютер будет всегда выбирать идеальную схему восстановления ресурсов для всех, да ещё и как пить дать один и тот же. Сделай - "пока есть варианты действий, случайно выбирать рандомно вариант из доступных" и посмотри что выйдет.

    Проблема попадает в классическую "knapsack problem". ( https://en.wikipedia.org/wiki/Knapsack_problem )
    Вот рекомендую глянуть туда и дёрнуть любой вариант из доступных.

    Или же сделайте тупой рекурсивный перебор всех вариантов. Разогнать всегда можно будет позже.

    ОтветитьУдалить
    Ответы
    1. В том-то и дело, что в текущем виде там даже близко не knapsack, тупо поиск ближайшего имеющегося :) "Вес" одинаковый у всех.

      Удалить
    2. Потому и начинается в DF лагалище на больших крепостях. В DF Проводится расчёт жизнедеятельности каждого из сотен дварфов. У каждого дварфа есть потребности, учёт которых ведёт железо. У каждого дварфа (почти) есть домашнее животное, у которого тоже свои потребности... в общем полный расчёт жизнедеятельности каждого персонажа может положить на лопатки любое железо. Хватило бы персонажей. Тут единственным вариантом становится упрощение. Если делать полными всех и сразу, то тормозить будет в любом случае.

      Удалить
    3. Лагалище в DF начинается потому что там общая модель мира запредельно сложная, обсчитывается каждый чих и каждая капля крови на камне. Одно дело обсчитать отдых лишь по длительности и другое дело когда нужно учесть материал и качество кровати, температуру воздуха в помещении, уровень шума (а не стучал ли кто за стеной киркой? а не пробегал ли кто мимо с громкими воплями?), наличие миазмов и т.д. и т.п.

      Удалить
    4. На лавры ДФ я не замахиваюсь, но всё же хотелось бы использовать адекватные программные решения, а не городить по принципу - комп мощный, он обсчитает.
      Что касается проблемы в нашей задачке, то она возникает тогда, когда надо выбрать какими весами оплачивать восстановление чтобы восстановить максимум возможного. Ведь можно упустить при прямом подборе и перекрыть одним выбором другой.

      Удалить
    5. Понимаешь, тут все равно нет варианта оптимальнее, чем "берем маркер с минимальной силой из тех, что выше n" :) При этом учти, что на маленьких наборах данных примитивный перебор может работать быстрее сложного аппроксимирующего алгоритма. Это во-первых. Во вторых ты пишешь не реалтайм-игру, где надо эти задачки решать тысячи раз за секунду, да еще оставить ресурсы для других расчетов. Выигрыш в 0.01 секунды при обсчете хода никто не заметит. Но при этом ухудшается читабельность кода и вполне могут быть дополнительные проблемы с отладкой. Стремление к идеальным решениям вредно для практической разработки :)

      Удалить
    6. Разберем подробнее. Есть пул маркеров с силой (1)(3)(3)(4)(5). У нас уже восстановлена одна единица в этом ходу, надо восстановить еще три. То есть нам нужно три маркера (>1)(>2)(>3). Ищем первый маркер в последовательности, (>1). Однозначное решение - один из (3). Потому что (4) и (5) - излишняя расточительность, а (1) не подходит по условиям. Тем же макаром ищем два остальных, учитывая уже "занятые". Все, это оптимальное решение. Ничего оптимальнее тут не придумать. Если, конечно, я понял правильно и маркеры простые, нет возможности восстанавливать сразу два ресурса или восстанавливать больше, чем на единицу.

      Удалить
    7. @Old Huntsman Рекомендуемый подход - сначала делается тупой/простейший вариант решения проблемы, потом он тестируется, и тольео ЕСЛИ он СИЛЬНО тормозит, вот только уже тогда его надо оптимизировать. Также см "Premature Optimization".

      Это тупо потому, что "комп мощный, он обсчитает" (как правило комп действительно мощный и обсчитает) дешевле, чем тратить кучу программистского времени на поиск оптимального решения проблемы которая на самом деле может занимать мало времени и возможно позже будет удалена из проекта полностью. Я понимаю, если б у тебя уникальных нпцов был хотя бы миллион ну или тысяч так сто. Тогда можно было бы беспокоится о производительности. У тебя же пошаговый, как я понимаю, геймплей. Ты можешь спокойно несколько (десятков) миллионов операций за ход делать, машина не поперхнётся. Да же в Питоне.

      А что касается Dwarf Fortress, так там помимо психики персонажей ещё обсчитывается передача температуры между тайлами, погодные эффекты, течение воды, нахождение пути и ещё куча всего, плюс она в памяти держит нехилый такой воксельный блок данных, которой каждый ход обрабатывается.

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

      Удалить
  6. Меня смущает запись ["выносливость","сила_воли"]. Означает ли это что один маркер, может быть потрачен на восстановление одного из нескольких ресурсов?

    Если может и тем более с разной силой, то задача подозрительна похожа на "knapsack problem".(Я про эту задачу слышал, но не сталкивался)

    Если нет, то решение вроде тривиально, как и написал Гарпо.

    ОтветитьУдалить
    Ответы
    1. Разных на выбор. Т.е. можно восстановить либо выносливость либо волю, смотря что нужнее.
      И вот именно в том и загвоздка. Как определить что сейчас важнее придержать, а что использовать чтобы восстановить всё нужное и не закрыть окна возможностей для остальных восстановлений.
      Впрочем у нас вроде бы всё решилось.

      Удалить
    2. А, этого я не заметил. Если маркер может восстанавливать один из ресурсов на выбор, то нужно вводить оценочную функцию. Например нам нужно восстановить волю с силой 2, есть маркер восстанавливающий волю или выносливость с силой два и маркер восстанавливающий волю с силой 3. Нам нужно решить что лучше. В таких случаях используется оценочная функция, которая условно оценивает каждый вариант. Но алгоритм оценки уже выходит за пределы имеющейся модели. Тут либо эвристическая функция типа "излишняя сила * 10 + общее количество вариантов восстановления" и выбираем самое дешевое, либо сложная функция, учитывающая прогнозы на ближайшее будущее. Тут нужно смотреть на остальную модель. А в остальном принцип тот же, но найдя решение не останавливаемся, а оцениваем, запоминаем и продолжаем перебор. Если найдено другое решение с более "дешевой" оценкой - запоминаем его и дальше сравниваем уже с ним. Для больших переборов обычно используют аппроксимацию типа "если цена решения ниже n, то дальше искать не нужно", но у тебя не такие большие объемы данных чтобы с этим морочиться.

      Удалить
  7. А если использовать систему как Torment: Tides of Numenera там уже умные люди все подсчитали и сбалансировали, и похоже на вашу задумку.

    ОтветитьУдалить
  8. В общем как я и думал, условия я понял неверно. Попробую уточнить.
    1. Маркер может восстановить только один ресурс, но при этом может иметь выбор какой из ресурсов восстановить.
    2. Маркер всегда восстанавливает ресурс на единичку.
    3. Задача может иметь составную цель типа "восстановить волю на 2, выносливость на 1 и здоровье на 4".

    Я правильно понял? Если да, то тут уже более сложная комбинаторика. В целом все также для того, чтобы найти идеальное решение нужно найти все возможные комбинации маркеров, которые позволяют решить задачу, потом оценить варианты и выбрать наиболее "дешевый". Но вот перебор комбинаций уже усложняется и тут можно подумать. Сразу напрашивается вариант с построением дерева решений. Нужно? :)

    ОтветитьУдалить
    Ответы
    1. На самом деле нужен не самый дешёвый, а любой который позволит восстановить максимум возможного. Если восстанавливается всё, то не важно каким из способов.

      Удалить
    2. Ты же писал, что хочешь, чтобы ИИ по возможности придерживал маркеры про запас? Т.е. если нам нужна просто единичка ресурса с силой 3 и есть подходящие маркеры с силой 3 и 5 - то неважно какой использовать, лишь бы получить требуемую единичку? Как вообще работает основной алгоритм? Один раз за ход восстанавливается максимум возможных ресурсов и все? Или для каждого действия мы смотрим чего не хватает и пытаемся восстановить необходимое?

      Удалить
    3. Понимаешь, нет идеального алгоритма вообще. Есть алгоритм оптимальный для определенного набора данных и определенной задачи (конечной цели). Для другого набора данных и задачи он может быть уже неоптимален. Кроме того ни к чему искать оптимальный алгоритм, достаточно подобрать просто "хороший". Даже если брать чисто построение дерева решений, то можно искать в ширину, можно в глубину, можно вводить промежуточные оценки и "путь наименьшего сопротивления", можно вводить ограничение глубины поиска, аппроксимацию оценки, можно джойнить дублирующиеся состояния или забить на это и т.д. А могут быть и принципиально другие подходы. И чтобы понять какой из них оптимальнее, как минимум нужно четко понимать условия задачи и цели. Крайне желательно представлять размерность данных. Могут понадобиться и другие параметры типа дисперсии оценок. И обычно окончательно оценивать варианты алгоритмов приходится опытным путем. Так что если нужно подобрать алгоритм - сформулируй четко задачу, желательно в математической форме, но можно и "на пальцах". Потом я уточню что нужно по размерности данных. Или я могу просто прочитать длинную лекцию о построении дерева решений вообще и основных путях оптимизации построения, а дальше думайте сами :)

      Удалить
  9. Давайте уточним задачу - сколько предполагается типов ресурсов ("выносливость","сила_воли" и т.д.) и какой максимальной силы может быть сила восстановления?

    ОтветитьУдалить
  10. Если типов не очень много то напрашивается решение как на приложенной картинке (вообще это задача на поиск наикратчайшего пути)

    Пусть N - число восстанавливалок
    Пусть M - количество свойств


    сложность O(6^M * N), если возможных свойств не так много то вполне пойдет. Например для 8 свойств и 100 восстанавливалок сложность порядка 10^8, меньше секунды. Для 10 свойств значительно хуже )

    https://lh3.googleusercontent.com/-y3mVRjI0-y4/VrCfvETBMiI/AAAAAAAAA0Y/gnzqsOqheWk/s0-Ic42/algorithm.png

    ОтветитьУдалить
  11. В конце работы алгоритма надо будет пройти по всем строкам и найти достижимую строку с максимальной суммой цифр (опционально для экономии ресурсов из достижимых с наименьшей цифрой в ней). Затем откатываться назад, проверяя был ли применен восстанавливатель N (это будет понятно по предыдущей строке, мы либо прыгаем "наверх", либо влево - соответственно применен или нет). Если конкретный набор использованных неважен, то памяти достаточно использовать для хранения только одной колонки, если важен, то нужна вся таблица.

    ОтветитьУдалить
  12. "Ок, да. Читай "сила маркера выше чем количество восстановленных ресурсов + 1". Немного обсчитался я тут, но суть задачи прежняя."
    Я делал пример для исходной задачи ("При этом его сила, должна быть не меньше чем количество уже восстановленных на этом ходу внутренних ресурсов любого типа."), но в общем правило перехода из состояния X в состояние Y может быть любым. При переходе по вертикали проверять это правило, а по горизонтали просто все имеющиеся сдвигаются.

    ОтветитьУдалить
  13. Если я правильно понял описание, то решать можно с помощью максимального паросочетания. Хотя не могу сказать, что это простое решение, но по моему довольно красивое.
    Для этого нужно составить двудольный граф, в одной доле которого будет N сил маркеров, в другой каждая единица ресурса, которую надо восстановить (всего M штук). Если существует маркер силы i который восстанавливает ресурс j, то i-я вершина первой доли соединяется со всеми вершинами второй доли которые соответствуют j-му ресурсу.
    Например, нужно восстановить 2 единицы ресурса А и одну Б, плюс маркер [А,Б] силы 1 и два маркера [Б] силы 2. Тогда во второй доле будут вершины А, А, Б. Вершина первой доли с номером 1(все маркеры силы 1) будет соединена со всеми вершинами второй доли. Вершина с номером 2(маркеры силы 2) только с вершиной Б.
    После того как решение будет найдено, нужно будет среди всех маркеров соответствующей силы найти подходящий. Тут можно искать не просто любой, а самый самый - и чтобы время жизни маркера было минимально и чтобы другие более крутые маркеры оставить про запас и т.д.
    Время генерации такого графа L*M (L - количество всех маркеров), время нахождения паросочетания M*N^2, время нахождения маркеров которые следует потратить - L.
    Правда здесь не учитывается относительная важность ресурсов. Если покрыть все ресурсы не получится, решение может потратить все маркеры не на выносливость, а на силу воли и т.п.
    Маркеров разных уровней это тоже касается. Например, может быть потрачен хороший маркер силы 2 вместо плохого силы 3.
    Впрочем если пойти совсем в хардкор, от этого наверняка можно избавиться, если свести паросочетания к задаче о назначениях.

    ОтветитьУдалить
  14. >Если я правильно понял описание, то решать можно с помощью максимального паросочетания
    Ну да, если оказывается что повторное использование одного уровня невозможно то так лучше конечно.

    ОтветитьУдалить
  15. Да вариантов реализации алгоритма дохрена просто. Но без деталей обсуждать все это нет смысла. Хитрый алгоритм с проверкой идентичных состояний и аппроксимацией оценки будет быстрее, чем банальное построение полного дерева решений... на задаче с размером пула маркеров в тысячи экземпляров, десятком восполняемых ресурсов и сложной оценкой решений. А на задачах, где пул маркеров от силы десять штук и три ресурса тупой перебор отработает быстрее и точнее. Дьявол в деталях.

    ОтветитьУдалить
  16. У каждого маркера есть 2 параметра: "название ресурса" и "сила маркера".
    Сортируем маркеры по силе.
    1. Проходим таблицу от наибольших значений силы к наименьшим. Если среди маркеров одинакового уровня силы все маркеры содержат одинаковое название ресурса, применяем этот маркер и удаляем его из таблицы.
    Если ресурс с названием из примененного маркера полностью восстановлен, удаляем из таблицы все маркеры с таким ресурсом.
    Повторяем шаг 1, пока не наступит ситуация, когда невозможно применить маркеры - это значит, что для всех оставшихся значений силы остались только "конфликтующие" маркеры.
    2. Берем все маркеры с наибольшими значениями силы. Среди маркеров этого уровня силы делаем rnd(1..n), где n - количество маркеров на рассматриваемом уровне силы. Применяем выбранный рандомайзером маркер. Удаляем из таблицы все маркеры этого уровня силы. Если ресурс с названием из примененного маркера полностью восстановлен, удаляем из таблицы все маркеры с таким названием и возвращаемся к циклу 1, иначе делаем новый проход цикла 2.

    Цикл 2 можно усложнить, добавив в него сортировку "конфликтующих" маркеров по параметру [максимальный_запас_ресурса - текущий_запас_ресурса] и отдавая предпочтение восстановлению наиболее потраченных ресурсов.

    ОтветитьУдалить
    Ответы
    1. Народ, всем спасибо, но мы уже разобрались и закодили. Можно закопать стюардессу.

      Удалить
  17. Охотник. Насчет алгоритма, почитай про венгерский метод транспортной задачи: https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BD%D0%B3%D0%B5%D1%80%D1%81%D0%BA%D0%B8%D0%B9_%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC , под твою задачу ложится 1 в 1. Математический аппарат не сложный, а задача будет решаться самый оптимальным и не ресурсоемким способом.

    ОтветитьУдалить
  18. Старый Охотник, ваш коллега, Белый Шарик, выпустил демку своей игры. Вы уже успели попробовать?

    ОтветитьУдалить
    Ответы
    1. Неа, я успел попробовать XCOM2 и пропал на неделю из мира )

      Удалить
    2. Понимаю. Сам хотел попробовать в XCOM2 поиграть, но убогая оптимизация не позволила даже на минималках, хотя комп рекомендуемые с запасом выжимает.

      Удалить
    3. Я недавно посчитал время, уходящее на игры, переустановил машину и снес нафик все игрушки :) Во избежание соблазна. За две недели провернул просто офигенный объем работы, успеваю и заказчиков удовлетворить и над своей игрой поработать :)

      Удалить
    4. Охотник НЕДЕЛЮ??? я прошел XCOM2 за 15 часов она короткая даже в отличие от XCOM:EU )))) неделю))) ты перегнул)) или я такой один?

      Удалить
    5. Кстати играл на максималках при процессоре в 3.4г, 24гб оперы и видяхи 3гб))))

      Удалить
    6. Это самая первая крякнутая верса была)))

      Удалить
    7. Было ожидаемо что первые версии игры будут работать плохо.

      Удалить
    8. да говорю же ни лага не было))) ни зависи не выкидов всё плавно и гладко на максах

      Удалить
    9. Похоже дело в утечке памяти. У меня банально в 3 раза меньше оперативки.

      Удалить
    10. Если играть по 2 часа в день, то 15 часов - это как раз неделя. А играть по 15 часов в день большинство нормальных людей просто не могут :)

      Удалить
  19. можно для новой игры по твр взять несколько идей из аниме "Shinmai Maou no Testament", там есть много интересных идей которые хорошо бы вписались в сеттинг и геймплей.

    ОтветитьУдалить
    Ответы
    1. Маг. Клеймо было уже в Валете а стимулизация в види удовлетворения немного бред))
      Чуть забыл и раб подох))))Ха Ха

      Удалить
  20. Привет Охотник, когда выйдет альфа ТВР, хотелось бы пощупать.
    P\s У белого шарика игрушка вышла очень слабая

    ОтветитьУдалить
    Ответы
    1. очень слабая, потому что не очередной симулятор школьницы с дешманскими порнофотками?

      Удалить
    2. У белого шарика она скажем так "мутная" пока текст не читабелен + нет оптимизации под хоть какое нибудь разрешение(у меня например 1920*1080 постоянно приходится скролить)

      Удалить
    3. А что вы хотели от сырой альфы? Шарик сам говорил что выпускать пока рановато, но таки сдался под давлением. Играйте теперь в это и ждите патч.

      Удалить
    4. Знаю, если почитать комментарии автора то по сути я лишь подтверждаю его слова

      Удалить
  21. Что в Влете Плетей, что в Крыльях Осквернителя, были реализованы простенькие формы питомцев, в виде отродий дракона и отродий туманов, а в ТВР мы встретим данную систему и кого мы сможем заводить, для каких целей?

    ОтветитьУдалить
    Ответы
    1. Вполне реально завести боевую или красивую животинку. Такая или в бою поможет или солидности во время проведения сделок прибавит.

      Удалить
    2. Я пока не прорабатывал тему питомцев - это не основной приоритет. Но что-то вероятно будет

      Удалить
  22. Этот комментарий был удален автором.

    ОтветитьУдалить
  23. Здравствуйте.

    Я представляю группу в ВК, которая занимается публикацией подобных игр (порно-эро тематика). Не буду указывать на ее ссылку, да бы вы не посчитали ее за рекламу. Сразу к делу)

    Нашим подписчикам хотелось бы, чтобы мы провели с вами интервью. Подписчиков у нас более 10.000, да и статистика ежедневная около 2000-3000 в сутки.

    Не могли бы вы связаться с нашим админом данной группы в ВК? Я искал, но не нашел вашего емэйла и вообще не знал как связаться. Решил написать здесь, т.к. вижу что вы отвечаете на комментарии людям.

    Интервью у вас возьмет она - http://vk.com/id292281258

    Прошу вас, напишите ей. Она в курсе, я ее предупредил (это была ее идея по поводу интервью). Заранее вас благодарю.

    ОтветитьУдалить
    Ответы
    1. Почта Охотника есть в FAQ. old_huntsman@yahoo.com
      Здесь он по-моему не очень часто появляется.

      Удалить
    2. А вам не хватает той информации, что выложена в FAQ?

      Удалить
    3. А вот ссылку было-бы неплохо. Где потом интервью читать?

      Удалить
    4. По ссылке на интервьюера находится без проблем :)

      Удалить
    5. Оно конечно да, но без регистрации в ВК нельзя посмотреть страничку. Ссылка на группу, а лучше на интервью была бы желательнее.

      Удалить
    6. Пишите на почту. Я не регистрируюсь в соцсетях.

      Удалить
  24. Ага! Значит, жив-здоров! Это радует. Но почему игнорируются мои письма и запись на github по поводу желания работать над улучшением графики?

    ОтветитьУдалить
    Ответы
    1. графики не анимэ картинки норм)))))

      Удалить
    2. Дмитрий, там целый вал писем с которыми у меня нет ни времени ни желания разбираться. Я не работаю над своими старыми играми. А если над ними хотите работать вы - просто сделайте это, наздоровье.

      Удалить
  25. Выкатишь или нет, а охотник?

    ОтветитьУдалить
    Ответы
    1. так вроде писали что ничего конкретного нету, так только мелкие наработки, ничего полноценного (ну или хотя бы демки)

      Удалить
  26. Вопрос может быть глупый хз, но игра будет только за человека?

    ОтветитьУдалить
    Ответы
    1. Охотник говорил, что хочет реализовать игру за разные расы.

      Удалить
    2. Каджиты и аргонианцы будут?))

      Удалить
    3. Читайте описания и комментарии под ними. Там всё обсуждалось.

      Удалить
  27. Охотник, мартовский пост будет? Мы понимаем, что ты, наверное, занят, но может расскажешь еще о своих задумках и о прогрессе разработки. А то, на поприще взрослых игр, сейчас очень тоскливо (одни проекты недоделки). Порадуй нас)

    ОтветитьУдалить
    Ответы
    1. ВОТ-ВОТ !!! ПРИСОЕДИНЯЮСЬ ! А то целый МЕСЯЦ НИКАКИХ НОВОСТЕЙ НЕ ПИШЕШЬ !!!

      Удалить
    2. Да куда вы всё вперёд батьки в пекло? 28 число на дворе. До марта куча времени.

      Удалить
    3. Ага, а в феврале Охотник пост не делал. Мы просто, скромно, просим от имени общественности проинформировать, как дела)

      Удалить
    4. Вообще-то делал. Первого февраля был его пост за январь.

      Удалить
  28. До мартовского поста ещё три дня, а ты спешишь куда-то)

    ОтветитьУдалить
  29. Этот комментарий был удален автором.

    ОтветитьУдалить
  30. Извините конечно за такой вопрос, просто интересно сколько вам пожертвовали? Я знаю что неприлично считать чужие деньги, но как я и сказал ранее просто грызет интерес, буду рад если вы ответе :)

    ОтветитьУдалить
    Ответы
    1. и тут наступило неловкое молчание)))

      P.S. кто знает что с охотником а то чет пропал ни слуху, ни духу(((

      Удалить
    2. А теперь смотрим, когда были написаны итоги сентября и октября, например, и успокаиваемся)))

      Удалить