UnityФорумОбщее

Unity3d - ограничения (38 стр)

Страницы: 137 38 39 4044 Следующая »
#555
7:57, 11 сен 2014

war_zes
> Вот ты рисуешь активный круг (на нем пальцем можно щелкать) радиусом в 1.0 единицу. Теперь игрок запускает твою игру на смартфоне с экранчиком 320х240 (есть и такие с андроидом). Твой круг будет на экране в 24 пикселей - довольно сложно
> тыкнуть пальцем. Теперь игру запускают на большом планшете с экраном 1200х1000. Твоя кнопка будет в 100 пикселей - огромная.
Мне кажется, что в большинстве случаев именно такое поведение и нужно.

#556
8:19, 11 сен 2014

SunnyBunny
> Мне кажется, что в большинстве случаев именно такое поведение и нужно.
нет - иначе пользователю на маленьких экранах придется брать лупу и иголку (текст не видно, и пальцем не тыкнешь). А на больших будут огромные кнопки и маленькое игровое поле

Вот такой пример. Допустим делаю рогалик (или двухмерную пошаговую стратегию). Все в логических координатах. Размер тайла, как выше мне вы и предлагали - 1 единица. Экран - 10 единиц. Поле состоит из 5 тайлов - то есть 5 единиц. Теперь я запускаю игру на планшете с 1000 высотой.

Так скажи, какое решение должно быть вернее - игровое поле должно растянуться и состоять из 5 тайлов занимая 500 пикселей? Или оно все таки должно остаться того же самого размера, но количество тайлов должно увеличиться?

Я считаю что именно последнее - чем больше экран, тем больше тайлов должно вмещаться.

Как я это сделаю? Вот так:
количество видимых тайлов по ширине = ширина экрана в пикселях / количество пикселей в одном тайле.
Например ширина 1024, размер тайла - 32 пикселя. Количество тайлов на экране - 1024/32=32
Так как поле должно занимать не весь экран, мы можем предварительно отнять от ширины отступ

В логических ты такое простым способом не сделаешь. если у тебя игровое поле занимает пять единиц и состоять из 5 тайлов, то на экране в 1000, оно также будет занимать 500 пикселей, состоять из 5 (!!!) тайлов размером в 100 пикселей.

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

Другой пример - игровое поле имеет фиксированный размер и должно всегда вмещаться на экран все (то есть все тайлы). Тут логические координаты уже подходят... Но дело в том что и в реальных это тоже не сложно сделать:
Размер тайла = высота экрана / количество тайлов в игровом поле
например высота 900 пикселей. На экран надо вывести 5 тайлов. Тогда каждый тайл рисуем размером в 180 пикселей.

То есть с логическими не все так однозначно и фигово что в юнити это сделали единственным способом.

#557
8:40, 11 сен 2014

SunnyBunny
> Вот такой пример. Допустим делаю рогалик (или двухмерную пошаговую стратегию). Все в логических координатах. Размер тайла, как выше мне вы и предлагали - 1
> единица. Экран - 10 единиц. Поле состоит из 5 тайлов - то есть 5 единиц. Теперь я запускаю игру на планшете с 1000 высотой.
>
> Так скажи, какое решение должно быть вернее - игровое поле должно растянуться и состоять из 5 тайлов занимая 500 пикселей? Или оно все таки должно остаться
> того же самого размера, но количество тайлов должно увеличиться?
Первое решение. Что на маленьком экране, что на большом количество тайлов должно быть одинаковым. В противном случае игроки с большими экранами получат преимущество - у них радиус обзора будет в разы больше.
С левелдизайном наступит полный пипец - сложно будет спланировать, какая часть локации открыта взору игрока, а какую можно сделать секретной. Если в игре есть сетевой режим и оружие дальнего боя, то тем более не честно делать разным игрокам разный радиус обзора.

#558
8:49, 11 сен 2014

SunnyBunny
> Первое решение. Что на маленьком экране, что на большом количество тайлов
> должно быть одинаковым. В противном случае игроки с большими экранами получат
> преимущество - у них радиус обзора будет в разы больше.
А теперь запусти любой рогалик на ПК. Увеличивается именно количество тайлов, а не их размер.

>>В противном случае игроки с большими экранами получат преимущество - у них радиус обзора будет в разы больше.
Можно ограничить туманом войны, FOV и LOS.

>>а какую можно сделать секретной
Если что-то секретное, то игрок это и не увидит

>>С левелдизайном наступит полный пипец
В случае с логическими координатами приходит полный писец вообще ко всему дизайну. Если художник рисовал тайл размером в 32 пикселя, то при увеличении в 100 - тайл будет выглядеть ужасно, а при уменьшении в 16 - половина работы художника будет выкинута. Рисовать тайлы под разные размеры экрана? Дороговато вообще-то.

#559
8:54, 11 сен 2014

SunnyBunny
и например в случае градостроителя я (в качестве игрока) бы хотел видеть все что настроил, поэтому тут вариант с увеличением количества тайлов тоже лучше - чем больше экран, тем больше я увижу

#560
8:59, 11 сен 2014

SunnyBunny
> В противном случае игроки с большими экранами получат преимущество
Сейчас запустил Battle for Wesnoth (гексагональная стратегия) в окне, и стал менять размер - и таки тоже увеличивается именно количество тайлов на экране (размер тайла фиксированый).

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

#561
9:04, 11 сен 2014

war_zes
Ладно, ты прав

#562
12:55, 11 сен 2014

war_zes
Маленький экран же != маленькое разрешение.
Что если экран в 5 дюймов и 4K разрешение?

#563
14:54, 11 сен 2014

Всё считать в логических координатах. Дальность обзора/масштаб регулировать настройками камеры. Нахаляву получаем возможность зума и независимость от разрешения текстур.

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

#564
22:59, 9 окт 2014

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

http://fogbugz.unity3d.com/default.asp?638445_7ml222c2813itb7s
http://fogbugz.unity3d.com/default.asp?638459_72au4bulcoobsgm1

#565
23:10, 9 окт 2014

я подумывал их юзать, но теперь не буду, спасибо =)

#566
0:31, 10 окт 2014

antipolizai
> Что если экран в 5 дюймов и 4K разрешение?
Либо настраиваемый размер тайлов/игровое разрешение, либо кровоточащие глаза.

#567
10:39, 10 окт 2014

alexzzzz
> Процедурными текстурами (substances) никто не балуется? Они подглюкивают с постоянной периодичностью. Надоело, решил отправить багрепорт. Уже отправил 2 бага и ещё один пытаюсь воспроизвести. Может, у всех всё норавльно, а я один такой счастливчик?
В 4.5.4 не пробовал, но в 4.5.3 тоже были проблемы: текстура генерировалась в два раза больше по каждой оси, чем было указано в настройках и билд вылетал на iOS, даже если в настройках стояло запекать текстуры при билде. В итоге пока убрал их.

#568
13:53, 10 окт 2014

> http://fogbugz.unity3d.com/default.asp?638445_7ml222c2813itb7s
> http://fogbugz.unity3d.com/default.asp?638459_72au4bulcoobsgm1

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

HeadZerg
> текстура генерировалась в два раза больше по каждой оси, чем было указано в
> настройках
Это только в iOS или всегда?

#569
14:22, 10 окт 2014

alexzzzz
Это в самом редакторе было, в билдах не проверял. Но в предыдущих версиях unity такой проблемы не было.

Страницы: 137 38 39 4044 Следующая »
UnityФорумОбщее

Тема в архиве.