что интереснее на обычную работу пойти, чем разобраться там и играть

![]() |
roboforum.ruТехнический форум по робототехнике. |
|

а тз игры боюсь это будет анриал.
может просто еще вашего видения нет). даже, если умдрятся не уваливаливать сервер при просчёте кинематики и физики ещё на первом десятке игроков, для меня остаётся очень хитрая головоломка. есть куча деталюжек, их как-то там собрали, а дальше то что? по какому алгоритму эти все части робота будут что-то делать? ладно там оружие какое, можно кликая на иконки его активировать. ладно для моторов, к которым гусеницы/колёса привинчены как-то иконками или привязкой кнопок управлять. сюда же всякие реактивные турбины и прочее подобное. а как допустим управлять движением робота в общем для вот такой штукенции
или я с наворотами концепции переборщил или моя фантазия тут меркнет.что интереснее на обычную работу пойти
Выглядит действительно сложновато для indie разработки
Как будут выглядеть сражения PvP, PvE? Как будут драться роботы?
а как допустим управлять движением робота в общем для вот такой штукенции
если не сводить всё к ограниченному количеству базовых конструкций роботов
на хостингах файлы долго не живут. при написании/редактировании сообщения внизу есть закладка "Добавить вложения"
лучше начать с простого проекта
есть ощущение что игра настолько сложной будет,
что интереснее на обычную работу пойти, чем разобраться там и играть
, мне хотелось услышать именно Ваше мнение, т.к. вы являетесь програмером, ну или хорошо разбираетесь в этом, интересно мнение именно конкретных людей, а не выдержки из статей, потому как далее придется общаться с живыми людьми и общими фразами не отделаешься, а часть вопросов, думаю, будет схожей, и хочется заранее подготовится к этому, поэтому жду ваших изреченийЧто должен программер увидеть в диздоке и ТЗ для него.

dimaris писал(а):Попробую объяснить, как я это вижу. Для начала хотел бы напомнить о своем первом посте, где был главный вопрос, что взять за основу при построении робота, где все мне сказали, что это не проблема, не заморачивайся, ну так вот, этот вопрос для меня до сих пор остался без ответа, поэтому не знаю, на сколько точно смогу ответить Вам на ваш вопрос. Ну а теперь к самому ответу. При конструировании, да и вообще в игре, базовые модули для построения робота нужно разбить на классы. Тот что на картинке, это явно вертикальный модуль для перемещения на двух ногах. Вернее не так, это просто, вертикальный модуль. Вместо ног могут быть и колеса и гусеницы и реактивный двигатель. Но вот модуль для перемещения будет вертикальным двухногим и другим его сделать нельзя будет, можно будет сделать ноги похожие на руки - да, можно будет изменить амплитуду перемещения ног относительно корпуса - да, можно будет сделать шесть ног - нет. Т.е. при построении подобных модулей будут существовать шаблоны и если в выбрали построения модуля на 6-и ногах, то гусеничный принцип туда впихнуть не сможете. Что касается сложных модулей, таких как двигателей внутреннего сгорания или реакторов, то в ручную их изменять будет нельзя, там будет стандартная прокачка как и во всех остальных играх. Вернемся к нашему предмету. Так вот, мы его разбили на несколько принципиальных модулей - базовый вертикальный модуль, вертикальный модуль перемещения на 2-х ногах, руки - механизмы для активации. Для меня тут ни каких логических вопросов не возникает как им управлять, скажите если это не так и я что то пропустил.
да как угодно, хоть в пластну посредине воткуить, чтоб он с двух сторон торчал. непорядок. вот и думаете как ограничивать возможность крепления одних моделей к другим. сделаете фиксированые точки крепления или в како-то диапазоне возле края пластины мотор-редуктор можно будет двигать + естественно ограничиваете на какой стороне пластины в какую сторону может быть направлен вал. тоже и с валом и колесом/шестернёй.
банально придумываете правила, какие модули с какими могут соединяться, сколько к чему можно присоединить и как + вагончик других мелких моментов.
в этом плане нет никаких проблем ни с точки зрения программиста ни с точки зрения дизайнера моделей, поэтому вам и писали "это всё ..., не заморачивайтесь". если вы начинаете пытаться въехать как это всё должно в коде выглядеть и у вас это не получается, значит вы банально лезете не в своё дело, что мягко говоря просто тупо. умеете программировать, программируйте. не умеете, пусть эту часть возмёт на себя другой. получается только хорошо 3д модельки рисовать, рисуйте и не пытайтесь натянуть на себя чужую рубаху.dimaris писал(а):Когда я спрашивал, мне хотелось услышать именно Ваше мнение, т.к. вы являетесь програмером, ну или хорошо разбираетесь в этом, интересно мнение именно конкретных людей, а не выдержки из статей, потому как далее придется общаться с живыми людьми и общими фразами не отделаешься, а часть вопросов, думаю, будет схожей, и хочется заранее подготовится к этому, поэтому жду ваших изреченийЧто должен программер увидеть в диздоке и ТЗ для него.
пардон, какой к лешему тз? очнитесь. во первых паписать тз для программиста это почти тоже самое, что написать игру, не написав её. с одной стороны это надо уметь, т.е. быть программистом. с другой смысла в этом очень мало, если не упрощать тз до уровня, стремящегося к диздоку. именно по этому тз делают только для относительно простых игр.dimaris писал(а):Ну а за финансированием хочу обратиться к независимым бекерам, в данной среде можно получить достаточно серьезные деньги, если правильно все сделать, обращаться к издателям, считаю, это уже последнее дело, да и они могут погубить проект, а скорее всего попросту не возьмутся за него.
опять пардон, забудьте. в здравом уме деньги выделять просто на ваше обучение геймдэву никто не будет. на тебе конфетку, садись рядом с нашим спецом по ... и учись, чтоб был хоть немного полезен. это возможно. поднатаскаешся, будет конфеток побольше. ... [смысловой усилитель] это не школа/вуз/курсы, где с вами будут возиться, разжевывая каждую мелочь. деньги могут выделить только на проект, а проект и игра вещи совершенно разные и к тому же, он как минимум должен подавать признаки окупаемости.
но идея классная.
у них своя игра есть, она им похоже больше нравится, раз развивают. берут любые из миллионов готовых модулей/компонент или свои создают, соединяют это всё, ограничиваясь чуть ли одной только своей фантазией. +пошли еще дальше - предоставили возможность попрограммировать.
а физический движок в этой игре, ммммм... и всё в риалтайме. а всякие lego, bioloid и прочие?мои личные "корованы" местами пересекаются с авторскими
диздок это примерное описание что и как должно быть. тз это детальнейшее прописывание вообще всего. вот эта точка должна быть такого цвета, потому, что вот по этому алгоритму с такими-то формулами это всё вычисляется. вот эта кнопочка должна быть тут или тут, чётко и однозначно описываете правила. при нажатии картинка должна стать сначала вот такой, затем вот такой и такой. при нажатии срабатывает вот этот код, который вот так и так делает то-то. а вот этот класс должен быть таким, он должен делать вот это и вот так. пардон, какой к лешему тз? очнитесь. во первых паписать тз для программиста это почти тоже самое, что написать игру, не написав её. с одной стороны это надо уметь, т.е. быть программистом. с другой смысла в этом очень мало, если не упрощать тз до уровня, стремящегося к диздоку. именно по этому тз делают только для относительно простых игр.
опять пардон, забудьте. в здравом уме деньги выделять просто на ваше обучение геймдэву никто не будет.
деньги могут выделить только на проект, а проект и игра вещи совершенно разные и к тому же, он как минимум должен подавать признаки окупаемости.
идея классная
но идея да, хорошая, хоть и не новая. +только на одной этой идеи далеко не "уехать".
dimaris писал(а):а можно поподробнее, тоже интересно.
Я написал практически все, что я об этом думаю.Мое видение концепции подобной MMORPG:Т.е. вот это и есть ваши "кораваны":
Берем три палки, два линейных актуатора и источник энергии, пишем алгоритмы работы актуаторов на псевдоязыке для движения вперед и назад, привязываем запуск алгоритмов к горячим клавишам, получаем гусеницу.
Берем одну палку, два колеса, один двигатель и источник энергии, пишем алгоритмы... получаем тележку.
Добавляем к тележке палку, актуатор и алгоритм, получаем тележку с простейшим манипулятором. Если источника энергии хватит, конечно.
Ставим перед игроками набор задач, требующих для решения различные конструкции, чем разнообразнее, тем лучше. И за их решение выдаем игрокам ресурсы и ЧСВ.
Задачи - прохождение трасс с препятствиями, просто так и на скорость, PvE и PvP, цель которых - вывести из строя робота противника, например, ударами своих блоков. Какие-нибудь спортивные состязания, вроде тенниса и т.д.
Ресурсы - материалы (прочность, вес, размер, уникальные свойства), приводы (мощность, вес), источники энергии (мощность, вес, размер).
Физику можно просчитывать в двух измерениях, так будет легче обсчитывать, легче конструировать, вырезать из материала детали нужной формы можно хоть в пайнте. Но в трех механика игры будет сильно разнообразнее, конечно. Проблему создания блоков сложной формы можно частично перенести на игроков, обеспечив достаточную мотивацию игровыми ресурсами.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0