Либо набирать людей за минимальные деньги и урезать обьем работ, офис в подвале/ангаре, мебель и прочее с помойки б/у либо от компаний банкротов с аукциона и так далее. Могу порекомендовать брать офис где-нибудь на окраине города, можно бывшие админ. здания, желательно уже с мебелью (с любой) или на территории бывших предприятий. Софт использовать по возможности бесплатный. Если поднапрячься, то можно набрать непрофессионалов или фрилансеров на халтурку, менее чем за 30 к, но надо учитывать что возможно придется за ними доделывать/переделывать.

Вот это правильная мысль. Потому что делать нужно только то что действительно нужно сделать.

В плане баланса , точнее, цитирую

Это возможно реализовать, то есть запрограммировать такой алгоритм вообще можно. Вопрос лишь в разработке самого алгоритма. И как я уже говорил, в большинстве случаев в коммерческих проектах это не делается, либо делается что-то похожее в сильно урезанном и ограниченном виде.

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

Разработка софта (и игр) это работа. Но не для всех, понятное дело.

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

Поэтому я говорю тебе - геймдев для меня это работа. Поэтому твоя последняя фраза в 45 посте можно так сказать, ни о чем. Это все равно что ты врачу скажешь, что он пошел в поликлинику работать ради денег :))

Хотя я вот что скажу - есть на самом деле грань в геймдеве, где развлекуха заканчивается, и начинается работа. А вообще я начинал программить для своего удовольствия и лет наверное 7-8 назад делал софт для германских пользователей, бесплатно. Просто потому что людям нравилось то что я делаю. Но постепенно у меня стали появляться заказы, и....

Баланс это немного другое, к ИИ отношения не имеет, ИИ это определенный функционал, позволяющий боту делать 3 вещи - найти путь, собрать сведения о том что делается вокруг, и принять решение основываясь на этих данных (поведение). Больше там ничего нет. Практически во всех проектах, даже в топовых. Да, на экране это может выглядеть как угодно, но в движке это сделано именно так. В 99% процентах случаев.

Более того, в плане ИИ практически уже все развито, нового там почти ничего нет. Кроме поведения, разве что. Потому что : поиск пути это в целом несколько алгоритмов, и обычно это 2D методы, ну это на экране бот идет в 3Д мире, в двиге бот ищет путь по 2Д миру. Потому что никто не будет вкладывать деньги в разработку 3Д навигации, это ужасно дорого долго делать. Это значит - либо берется 2Д сетка с ячейками, ищем путь по алгоритму А*, либо по алгоритму Дийкстры, либо берутся вэйпоинты (дааа, те самые вейпоинты, вспомните POD bot из CS 1.5, которые в стены тыкались рылами, это тот самый алгос) и путь ищется тупо по ним, либо 3 метод навигационный граф, примерно как сеть связей между точками в пространстве. Дальше, логика и сбор данных о том что делается вокруг бота, это простые проверки на наличие определенных обьектов в определенном радиусе, и это все. Принятие решений - это в основном конечный автомат, то есть finite state machine. Либо просто набор определенных триггеров, это все, никто не делает нейросеть для игр для коммерции, разве что фанаты, и то я таких не знаю.

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

А баланс - это лишь способ использования функционала ИИ в данном случае. И это уже немного другой вопрос.

Все гораздо проще на самом деле. На экране вещи выглядят не так как в двиге. И никто из разрабов не пытается обычно прыгнуть выше головы.
Особенно если говорить о коммерческих разрабах.

Насчет идеального мира, обычно в шутере (насчет РПГ не знаю, я играю только в шутеры, да я серьезно, я действительно не играю в другие игры), делают чтобы боты появлялись в определенном месте, в определенном количестве, с каким либо оружием, патроны у бота обычно не заканчиваются. Вообще, да, есть некий алгоритм, который регулирует количество ботов на уровне и т.д., но обычно никто не делает ничего сверхсложного, даже в коммерческих проектах, таких как COD4 и Crysis в плане ИИ ничего особенного сделано не было, практические стандартный подход использован.

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

Это зависит от того, что именно нужно делать. Любой двиг имеет определенные возможности, которые позволяют сделать что-либо на данном двиге. То есть, если уже имеющийся функционал удовлетворяет необходимым требованиям, в таком случае можно просто использовать то что есть. Если возникла необходимость сделать что-то, что имеющийся не позволяет, тогда обьем работ зависит от того, что именно нужно доработать или разработать. Например, есть графический движок типа как Ogre, в движке нет вообще искуственного интеллекта, значит, доработать данный двиг сделав ИИ, будет гораздо проще чем переделать двиг в котором уже есть ИИ. То есть, в первом случае ИИ пишется с 0 и к этому делу подключается остальной функционал. Например, надо сделать бота, способного найти путь, собрать информацию о окружающем мире и принять решение, это чисто ИИ код, который пишется с 0. Также нужно загрузить модель бота и ее отрисовывать, допустим, эта возможность уже есть в двиге изначально, тогда к этому коду подключается код ИИ. Если же ИИ в двиге уже есть, значит есть какая-то архитектура. Это значит, что для доработки ИИ (например есть ИИ бойца, но нужен ИИ допустим, птицы), придется изучить архитектуру и код уже имеющегося ИИ и доработать его, либо выбросить то что есть и сделать свое. Либо можно оставить код, например, отвечающий за поиск пути, но переделать код, отвечающий за поведение.

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

По команде, основные проблемы имхо это (в основном уклон на коммерческие проекты, но может подойти и некоммерческим)

1. Стабильность команды и наличие нужных/ненужных людей. Люди могут уходить и приходить, то есть команда из интернета потенциально не стабильная. Никто не знает, решит ли завтра тот или иной человек свалить из проекта. То есть, в идеале хотя бы основные мемберы команды должны находиться в одном городе (или стране) и иметь возможность лично встретиться для обсуждения деталей. Скайп и прочее это хорошо, но личную встречу это не заменит полноценным образом.

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

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

Это в основном мой подход. Третий пункт подойдет не всем, поскольку я ориентируюсь в первую очередь на уменьшение расходов, то есть подхожу к вопросу разработку чисто капиталистически, и без сожаления буду вырезать что-либо из проекта для уменьшения расходов или по приказу инвестора.

Обычно уровень делится октарным деревом (octree), либо похожими алгоритмами, например, BHV, чтобы уменьшить нагрузку на вычисления по collision detection, физике и так далее. Практически везде, уровень делается отдельно от моделей, то есть можно подгружать нужные данные по необходимости. Для дальней отрисовки используют LOD, рост детализации геометрии зависит от расстояния между игроком и обьектами. В целом, оптимизация рендера и прочего предусматривает отсечение как можно большего числа невидимых игроку обьектов от их процессинга, также вычисления по коллизиям и физике сводятся к локальному пространству (вблизи от игрока, за 5 км например, вычислять физику для стакана на столе никто не будет) и так далее.

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

Размер отрисовываемой геометрии зависит от возможностей железа плюс от возможностей софта, т.е. движка. Это означает, что здесь играет роль количество полигонов в кадре вообще и количество вызовов на отрисовку (дипы). То есть, твой мир быть плоским в виде 2 треугольников любого размера, без проблем, хоть 10 ткм х 10 ткм, либо может быть рельеф 1 км х 1км в виде 100000 треугольников. Вот это и есть та разница, которая ограничивает твои возможности.

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

Добавлено (31.05.2009, 01:11)
---------------------------------------------

Деньги выплачиваются издателем/инвестором согласно договору, который ты подписываешь, заслуги разраба перед индустрией (или кем-то еще) никому не интересны. Таковы реалии, продашь проект за 1000 рублей, значит, 1000 рублей ты и получишь.

Про такое достаточно уже книг написано, я конечно понимаю, что в основном они на английском, но язык все же учить надо.

Да и всего в статье не напишешь.

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

А самое главное при коммерческих разработках (и самое геморное), это сроки, бюджет, расходы и доходы.

Если каждый в команде будет делать то что он хочет делать, то такая команда имхо не протянет долго. Потому что есть план разработки, где указано, как, за сколько времени и денег должно быть что-либо сделано. Кроме того, есть лид проекта, который дает указания сотрудникам относительно того, что надо делать. Это значит, что если я выполняю коммерческий заказ по разработке (уже выполнял разные заказы) и директор приказывает прикрутить именно тот дизайн вместо того, значит, прикручивается то что сказано прикрутить. То есть, если я говорю моделлеру что делать сценарных персов не нужно, это значит - что их делать не нужно. Это не значит, что моделлер захотел - сделал или не сделал.

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

Что касается энтузиазма, ну я лично хз как там дела обстоят с некоммерческими проектами, а в коммерческих проекты могут разрабатываться несколько лет, причем никакого инвестора не волнует, нравится тебе работать или нет, потому есть договор о разработке. То есть тут хобби заканчивается и начинаются - работа, опыт, знания, и много другого разного гемора. Ну и самое главное - бабло, то есть сколько расходов и сколько доходов.

Что касается выдержки, то для спецов разработка двига или пусть даже конструктора, это не хобби, это работа, которую они делают. Вообще разработка софта (и игр тоже) это такой же бизнес как и любой другой. Что же касается создания простенькой игры в FPS Creator, то это уже хобби.

Да вроде не видел я в правилах требований только по-русски, походу на инглише тоже можно писать :))

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

Дело не в том как я отношусь к ним (нейтрально вобщем-то), а том, каковы их возможности. ОК, проехали, для сюжета, тем более для фантастического, покатит.

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

Нет для меня вообще показателей :)

Я же не говорю, что все плохо сделано. Я говорю, что есть немного спорных моментов. А дальше сам решай, мне то что.