Результаты поиска
| |
Artaniel | Дата: Понедельник, 13 Октября 2014, 20:55 | Сообщение # 21 | Тема: 2D Physics и космические корабли |
частый гость
Сейчас нет на сайте
| Наверное самое мудрое - не использовать rigidbody для персонажа.
В качестве костыля: Делаем гдето вне доступа камеры копию корабля (хотяб коллаедры без графики). Он стоит на месте, без Rigidbody, просто работает системой стенок, как ее должен воспринимать персонаж. По этому фальшивому кораблю ходит персонаж с Rigidbody по всем правилами. Т.к. корабль никуда не спешит, персонаж не слетит с него. В другом месте, перед камерой, движется настоящий корабль с Rigidbody и физическим управлением. Нам остается только раз в фрейм устанавливать фальшивое изображение персонажа на настоящем корабле точно так же, как сейчас расположен физический персонаж относительно фальшивого корабля. И второая камера не нужна и физика корабля не будет влиять на физику персонажа. Не забыть повороты. Продумать процедуры стыковки/расстыковки (переносить физического персонажа на настоящее поле перед камерой, убирать фальшивку).
|
|
| |
Artaniel | Дата: Воскресенье, 05 Октября 2014, 17:19 | Сообщение # 22 | Тема: [3D] - Бессознательное - FMV |
частый гость
Сейчас нет на сайте
| Для сюжетной игры сценарист весьма важен. Кому то надо заниматься диалогами и вариантами сюжета. У программера и художника наверняка и без этого приключений найдется достаточно.
|
|
| |
Artaniel | Дата: Суббота, 04 Октября 2014, 15:45 | Сообщение # 23 | Тема: Набор команды для нового проекта |
частый гость
Сейчас нет на сайте
| Такой вопрос: какой реальный онлайн предполагается вечером? Немного цифр. Работал я в саппорте небольшой ММОРПГ вконтактике (да, злой корпоративный PayToWin, можете меня ненавидеть), к через 2 года развития игры у нас было где то 4 миллиона установок и вечерний онлайн 200-300 человек. При том игра была из успешных, кормила человек 30 персонала и 3 дочерних стартапа. Соответственно прикидываем сколько людей реально будут заходить на сервер вечером с ограничением в 600 зарегистрированных пользователей и получаем единицы. Это точно стоит делать ММО? Как бороться с забитыми слотами, которые никто не использует?
Плюс весь смысл ММО в социальных связях. Люди могут месяцами возвращаться в игру, потому что там друзья. Выгонять человека через месяц с сервера - разрыв связей, шансы что он после этого будет искать новое сообщество на новом сервере весьма низкие. Вероятность что он найдет другую игру и перетащит друзей туда существенно выше.
Permadeath и MMORPG несовместимы. Это весьма распространенная идея, она приходила в голову всем геймдизайнерам MMORPG от самых первых MUD-ов. Но ни одна игра реализовавшая ее не выжила достаточно чтобы стать известной. Просто люди заканчиваются, не образуется комьюнити и игра умирает.
Другое дело сессионные игры. Рекомендую обратить внимание на Space Station 13. С одной стороны тот самый жесткий хардкорный permadeath, возможность предавать, обманывать и просто побыть чудовищем. С другой, сессия идет 2-3 часа и кто б кого не убивал все можно быстро начать сначала с теми же людьми. Игра живет уже больше 10 лет.
|
|
| |
Artaniel | Дата: Четверг, 25 Сентября 2014, 20:52 | Сообщение # 24 | Тема: Набираю команду |
частый гость
Сейчас нет на сайте
| Цитата Gravity_falls ( ) Раньше создавал игры А можно ссылочку, хотя бы скриншотики посмотреть?
|
|
| |
Artaniel | Дата: Среда, 10 Сентября 2014, 20:42 | Сообщение # 25 | Тема: Ищу товарищей и единомышленников |
частый гость
Сейчас нет на сайте
| Я немного о другим спрашивал. Какие технологии нужно знать программисту, который будет заниматься сервером?
Например Бойцовский клуб, если не ошибаюсь, написан на чистом web-е, PhP, js, html вероятно какой то SQL внутри PhP. Социалочки на юнити часто пишутся на связке Unity+PhP. Т.е. в скриптах юнити формируются веб запросы, PhP на них реагирует, сам общается с базой данных. Есть вариант собственно юнити сервера. Сам в руках не держал, но говорят там большие проблемы с массовостью, каждая комната - отдельный экземпляр юнити плеера. Если не прав - поправте. Есть самописные сервера на C# или C++ (мб и Java), общаются с юнити клиентом через вин сокеты как правило. Есть полу-готовые серверные решения типа PhotonCloud. Опять таки в руках не держал, но подозреваю программист нужен будет не такой как для скриптинга юнити клиента.
Цитата akyl91 ( ) Достаточно просто хост зарегистрировать с поддержкой MySQL. Эт я так понял прямо из клиента делать запросы в БД? Не будет ли проблем с секурностью (походить за противника, сообщить "я закончил каст" когда еще закончить не мог) ?
Сообщение отредактировал Artaniel - Среда, 10 Сентября 2014, 20:45 |
|
| |
Artaniel | Дата: Среда, 10 Сентября 2014, 20:05 | Сообщение # 26 | Тема: Ищу товарищей и единомышленников |
частый гость
Сейчас нет на сайте
| А на чем серверная часть планируется? В смысле язык программирования.
|
|
| |
Artaniel | Дата: Воскресенье, 07 Сентября 2014, 14:16 | Сообщение # 27 | Тема: Можно ли создавать себя, указывая на себя? |
частый гость
Сейчас нет на сайте
| Если ты пытаешься создать объект со скриптом, который сразу после создания попробует создать следующий, скорее всего будут проблемы. Вангую зависание намертво, фрейм не закончится пока не будут созданы все бесконечность объектов.
|
|
| |
Artaniel | Дата: Воскресенье, 31 Августа 2014, 23:27 | Сообщение # 28 | Тема: Переделка игры. Ваша помощь. |
частый гость
Сейчас нет на сайте
| Цитата Andy-go ( ) В случае с Unity нужна уже не просто графика а 3d модели что выйдет как минимум на порядок дороже. Хотя думаю что где-то я читал что теперь в ней можно и в 2d игры делать, но близко не знаком. Да, юнити уже работает с 2д спрайтами. И всякие гибридные варианты типа изометрии тоже не сложно реализовать.
|
|
| |
Artaniel | Дата: Пятница, 29 Августа 2014, 16:04 | Сообщение # 29 | Тема: Набор в команду |
частый гость
Сейчас нет на сайте
| Если бы убрать одно маленькое слово "онлайн", шансы найти программиста сильно возросли бы. Делать хороший, шустрый, устойчивый к взлому мультиплеер - дело не быстрое. Очень маловероятно, что вы найдете адекватного программиста на это дело без зарплаты. А если вдруг проект действительно выстрелит, мультиплеер с деньгами будет сделать уже проще. Ну и презентация мягко говоря не супер. Слова "оригинальный", "юмористический", "не традиционный" не возбуждают интереса ни у игроков, ни у соискателей. Попытайтесь изложить суть идеи, а не рассказать какая она хорошая. А еще описание игры в группке на стеночке вконтактике будит во мне грамар наци. Понятно что никто не идеален, в этом посте тоже наверняка есть баги. Но все же "Эта игра должна быть контролируемая хаусом."
|
|
| |
Artaniel | Дата: Вторник, 26 Августа 2014, 00:01 | Сообщение # 30 | Тема: Вопрос-[ответ] по Unity |
частый гость
Сейчас нет на сайте
| polous, у меня два варианта. Логический: после клика по GUI элементу надо както отменить действия совершенные кликом на террейне (на случай если тиррейтн уже обработал клик) и блокировать реакцию на клик (на случай если обработает позже) на один фрейм. Может быть сложно, если при клике на тиррейн происходит чтото совсем уж необратимое и легко восстановить состояние до клика не получится.
Геометрический: делаешь для камеры маску из коллаедров (наверное можно и триггеры), так чтобы эти коллаедры закрывали нужные участки поля видимости камеры. Маска естественно прозрачная, дочерний объект камеры. Клик по объектам за этими коллаедрами будет обработан только ими и не пропущен дальше. Я например так при всплывающих окошках блокирую все сзади них одним сплошным забралом. Весьма геморройно при перспективной камере, адово сложно при большом количестве подвижных GUI элементов.Добавлено (26.08.2014, 00:01) --------------------------------------------- А потом я подумал, погуглил и понял что всю жизнь делал все не так. Третий способ: есть такой метод GUILayer.HitTest(Vector3 screenPosition) Он пробует что будет если кликнуть по так то позиции на экране. Возращает GUIElement. Т.е. Код Camera.main.GetComponent<GUILayer>().HitTest(Input.mousePosition) == null будет true, если под мышкой сейчас нет GUI элементов. Просто вставляем эту проверку в клик по тиррейну и должно работать. Если сильно захотеть, можно получать сам GUI элемент, анализировать его и разбираться должен ли он быть прозрачным для клика или нет.
|
|
| |
Artaniel | Дата: Понедельник, 25 Августа 2014, 23:22 | Сообщение # 31 | Тема: Выделение ГО |
частый гость
Сейчас нет на сайте
| Цитата polous ( ) . Нужно реализовать более сложный вариант, где у бота может быть тру для одного, но фолс для другого.
polous, я честно запутался что ты пытаешься сделать. Ты правильно расписал о том как это можно хранить, 2-мерный массив bool-ов - вполне удачный вариант, лишь бы за 1 фрейм успевало все посчитать. Но я уже говорил что не нужно все хранить, если ты его можешь использовать сразу, как только посчитал.
Я подумал, тебе нужно выводить на экран тех противников, которые видны, хотябы одним юнитом игрока (ты их своими игроками называешь на сколько я разобрался). В таком случае хранить незачем, кого надо показываем, кого не надо прячем. А в следующем фрейме всё равно всё заново считать.
Если нам нужно знать кто из своих персонажей видит сколько врагов, мы можем сделать практически такой же скрипт на каждом своем персонаже. Только он будет не показывать-прятать, а накапливать количество увидинных противников и чтото с ним сразу делать.
Или мы вообще делаем мультиплеер? Это отдельная ситуация и с точки зрения видимости даже проще, на каждом конкретном клиенте нас волнует только то что видит этот один игрок. Но вылазит куча других вопросов.
|
|
| |
Artaniel | Дата: Суббота, 23 Августа 2014, 12:46 | Сообщение # 32 | Тема: Выделение ГО |
частый гость
Сейчас нет на сайте
| Не вполне понимаю зачем это вообще хранить по массивам, если оно используется один раз, сразу после расчета и в каждом новом фрейме пересчитывается заново. Я б делал так. Есть скрипт нашего игрока, в нем нужны aov и dov в публичных переменных. Есть скрипт врага. Он действительно должен висеть на каждом враге, а значит быть включен в префаб врага, который мы инстантиируем, когда создаем нового врага. Каждый враг только для самого себя перебирает наших игроков. Если хоть один его увидел - рендерер рисуется, иначе прячется.
Код bool inFOV; float distance; float angle;
void Update(){ inFOV = false; //пока не найдем того кто видит считаем что не видят. foreach (GameObject p in GameObject.FindGameObjectsWithTag("Players")) { distance = Vector3.Distance (p.transform.position, transform.position); angle = Vector3.Angle (p.transform.forward, transform.position - p.transform.position); // поскольку это в скрипте противника, то можно брать значения своего transform if (angle < p.GetComponent<Player>().aov & (int) distance < (p.GetComponent<Player>().dov) ) { inFOV = true; } //иначе ничего не делаем, если там был false, он и остается. Если уже успел сменится на true, то ктото другой уже видит, значит должен быть true } //и только когда обошли всех кто мог видеть, в inFOV либо остался false в случае если не мог видеть никто, или true, если видел хоть ктото. if (inFOV) { e.renderer.enabled = true; } else { e.renderer.enabled = false; } }
Считать GameObject.FindGameObjectsWithTag("Players") в скрипте противника или в менеджере - имхо не важно.
|
|
| |
Artaniel | Дата: Пятница, 22 Августа 2014, 16:31 | Сообщение # 33 | Тема: Вопрос-[ответ] по Unity |
частый гость
Сейчас нет на сайте
| error111, самое простое, там где ты меняешь значение isMoving, сразу же запускать GoEnemy() или StopEnemy(). Сложнее, делаем еще одну bool переменную LastIsMoving Код if (LastIsMoving!=isMoving) { //сюда мы попадем только если isMoving в этом фрейме не такое как в прошлом if (isMoving) GoEnemy(); else StopEnemy(); } LastIsMoving = isMoving; Таким образом мы помним двигались мы или нет в прошлом фрейме, и если это изменилось, меняем и силы.
|
|
| |
Artaniel | Дата: Среда, 20 Августа 2014, 23:21 | Сообщение # 34 | Тема: Система анимации ударов в игре. |
частый гость
Сейчас нет на сайте
| Ну тогда это сложный путь. Готовся к морю векторной алгебры и дремучему лесу кватерионов вращения. К тому что все это поначалу будет выглядеть как очень плохие куклы-марионетки в руках кукловода с болезнью паркинсона. Рекомендую ознакомится с такой игрой как Toribash. Это правда не юнити, какбы сама игра не была древнее юнити (и до сих пор в разработке). Но в общем то разработчики пошли именно по этому пути, именно силовое физическое управление каждой независимой группой мышц. У них есть свои поклонники благодаря оригинальности геймплея. Так что задача решаема, но не простая ниразу. Повторю, задача не для новичка. Если перед тобой еще стоит вопрос какой язык учить, сделать чтото попроще, разберись с базой (те же вектора, вращения, силы), тогда берись за такой хардкор.
Сообщение отредактировал Artaniel - Среда, 20 Августа 2014, 23:22 |
|
| |
Artaniel | Дата: Среда, 20 Августа 2014, 22:26 | Сообщение # 35 | Тема: Система анимации ударов в игре. |
частый гость
Сейчас нет на сайте
| В целом согласен с предыдущим оратором. Задача не ясна. Если ты хочешь чтобы игрок выбирал из уже имеющихся анимаций, как это например было в боевой системе Remember Me, то это несложная задача с точки зрения скриптинга, но кому то надо сделать анимации-запчасти, из которых игрок будет собирать последовательность. Я например их не умею (пытался, они сильнее меня), потому для скриптера именно эта часть сложная, а код там вполне рутинный. Если ты хочешь сделать какой то конструктор движений, в котором игрок будет как то передвигать суставы, а из этих передвижений будет формироваться анимация, то это весьма непростая задача. Готовся к неделям, а то и месяцам разработки и отладки. Для новичка крайне не рекомендую.
От выбора языка очень мало чего зависит. Сложность изучения скриптинга под юнити - почти никак.
|
|
| |
Artaniel | Дата: Понедельник, 18 Августа 2014, 19:09 | Сообщение # 36 | Тема: Как удалить клонированный обьект? |
частый гость
Сейчас нет на сайте
| Коллаедры нужны и для нажатий и для тапания точпадов и для raycast-ов и прочего определения есть там объект или нет. Кроме того, походу клик мышкой и обрабатывается как выстрел raycast-ом из камеры. В какой коллаедр первым упрется такой raycast, тому и приходит эвент.
|
|
| |
Artaniel | Дата: Понедельник, 18 Августа 2014, 15:25 | Сообщение # 37 | Тема: наследование и полиморфизм |
частый гость
Сейчас нет на сайте
| Цитата MANMANA ( ) Artaniel, понял, а если я буду искать по тэгу всех врагов, а затем для каждого из массива (foreach) я буду делать подобный switch... это изменит ситуацию?
По крайней мере параметры каждого из объектов-врагов будут доходить до swich. Если записывать результаты swich в одну переменную offset и ничего с ней не делать в промежутке между запросами параметров врагов, то значение в ней будут затираться следующей записью. В общем я бы не делал это отдельно, а включил в public void EnemyFinder(), внутрь цикла foreach (я так понял что он тоже перебирает врагов), как раз перед тем местом где offset нужен.
Сообщение отредактировал Artaniel - Понедельник, 18 Августа 2014, 15:27 |
|
| |
Artaniel | Дата: Понедельник, 18 Августа 2014, 15:05 | Сообщение # 38 | Тема: наследование и полиморфизм |
частый гость
Сейчас нет на сайте
| В public void EnemyPosition() , в swich, GameObject.Find ("Enemy") , будет возвращать всегда один и тот же геймобжект(ну если не инстантиировать и не удалять их). А значит и offset будет высчитываться всегда для одного и того же. Даже если ты будешь вызывать этот метод столько же раз, сколько у тебя врагов, он всегда будет брать первого и смотреть его параметры. Добавлено (18.08.2014, 15:05) ---------------------------------------------
Цитата polous ( ) когда я в объекте с именем Enemy делаю изменения, объект с именем Enemy2 (на котором, повторюсь, тот же скрипт, что и на Enemy) тоже принимает эти измнения... Где их видно, в инспекторе переменные меняются? или какой то скрипт работающий исходя из offset-а меняет его не так как надо?
|
|
| |
Artaniel | Дата: Понедельник, 18 Августа 2014, 13:09 | Сообщение # 39 | Тема: наследование и полиморфизм |
частый гость
Сейчас нет на сайте
| Конечно хотелось бы видеть код скрипта полностью. Отладка кода которого не видел это всегда тыканье пальцами в небо.
Тыкну вот сюда: Если включить выполнение программы, изменить чтото в инспекторе, потом выключить, изменения вернутся в то состояние, которое было на момент запуска. Возможно этот эффект виноват. Если пытаться настраивать параметры после запуска приложения, даже на паузе, все отменится при остановке выполнения. Может еще каким то образом были выделены оба объекта во время правки. Юнити достаточно хитрож...умная среда чтобы самостоятельно распихать переменные по схожим скриптам.
Сообщение отредактировал Artaniel - Понедельник, 18 Августа 2014, 13:20 |
|
| |
Artaniel | Дата: Суббота, 16 Августа 2014, 22:00 | Сообщение # 40 | Тема: Вопрос-[ответ] по Unity |
частый гость
Сейчас нет на сайте
| Да, боюсь простого способа нет. Надо както запомнить список детей, оторвать их от папы ( .transform.parent = null), переместить папу, потом снова задать детям папу. Если папа пустой, чистый пивот, то можно заспавнить нового, поставить в новом месте и за один обход детей сменить им папу. Не забыть обновить все ссылки на объект во всех скриптах. Можно попробовать записать кудато позиции-ротации детей, подвинуть папу и сразу присвоить детям их старые позиции-ротации.
|
|
| |
|