Category: дизайн

Category was added automatically. Read all entries about "дизайн".

nyaload

эргономика

У стилуса N900 есть два конца. Один для того что бы писать/рисовать мелко на экране или нажимать мелкие кнопки, второй конец - по форме корпуса, что бы корпус был плавным и без дырок когда стилус убран в корпус.

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

Предупреждая насмешки "зачем стилус вообще" - пальцами кнопки жмутся не хуже чем на двух других моих андроидах, и не сильно хуже чем на айфоне.

nyaload

«....ааа что, вы и есть за меня будете?! - Ага!!»

Игрушка на http://godville.net укрепила меня во мнении, что борьба с ботами - это от слабости геймдизайна. Зачем игрокам писать ботов, если конфеты интересней есть самому?

PS. фраза заголовка - из «Вовка в тридевятом царстве», можно на ютубе глянуть, если прошло мимо детства.
nyaload

ignore-on-commit для TSVN

У нас редакторы постоянно меняют некоторые файл настроек под svn. Коммит этого файла от одного дизайнера ломает работу остальным. Исправить это в чужом редакторе ммм сложно. Игнорировать файл тоже нельзя (он должен быть в репозитории, заигнорить то что в репозитории - не влияет на работу TSVN).

Вот как можно сделать, что бы изменённый файл не отмечался автоматом галочкой в TortoiseSVN:

rem add options.xml to *local* ignore changelist, if not was already here
(svn stat %1 | findstr ignore-on-commit > NUL) || svn changelist ignore-on-commit %1

Увы, это влияет только на локальные настройки TSVN. Что бы распространить эти настройки у всех, я засунул эти общие настройки в батники запуска редактора и игры.
nyaload

Paranormal Agency

Недавно шипнулась моя казуальная игрушка, Paranormal Agency, в которой я очень много сделал, как по программированию, так и по организации. Запросом в гугль можно найти и другие инсталляторы, более привычные (не онлайновые) чем у БигФиша.

Выводы:
1) Не делать игру про сюжет и диалоги, на чужом языке. Игру блеймят за плохую грамматику и орфографию, не смотря на то было потрачено масса сил на вычитку, перевод текста, организацию вычитки и перевода скриптов диалогов. И всё равно никто не читает. Я взял на себя ответственность зафичекатить некоторые текстовые фишки игры, вроде "энциклопедии привидений", "журнала про паранормальные явления" со статьями выдраными из википедии, считаю что я прав. Сколько-то сил это сэкономило. Игры должны быть без текста, если это не про Гарри Поттера и Звёздные Войны, иначе это просто ненужная и неблагодарная работа. Или это Visual Novell, которая только про текст, и в которой текст это суть "геймплея".

2) В фичи надо тыкать пользователей носом, а лучше что бы их было много, так что не наткнуться нельзя. Во всех обзорах и отзывах написано "скушно, нет изюминки". Изюминка - это миниигры в офисе по левой нижней кнопки, НО С ПЯТОГО УРОВНЯ в маленькой незаметной коробочке внутри офиса. Так же миниигры должны быть с самого начала, а не с 9-го уровня. И они не должны быть мозгодробительным перебором вслепую (гирьки). Увы, этот дизайнерский недочёт я не исправил. На этот офис было потрачено 2/3 усилий, но только 10% игроков туда попало, и только 10% от этих 10% заметило коробочку с минииграми с 5-го уровня. В этом же офисе есть всякие секретки...

3) Не делать перспективное деление в казуальных играх. Не смотря на мои усилия, объекты уровней отрисованные с делением на W на каких-то редких видеокартах или не рисуются, или рисуются некорректно.

4) Не выпускать клон удачной игры (Mystery Case Files) спустя год.

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

<Zeux> CEMEH, рассказывай
<Zeux> как матерый профессионал бы решил проблему теней
<CEMEH> Сказал бы - солнцу не двигаться.
nyaload

JPEG Chroma subsampling

Часто слышу жалобы от художников и дизайнеров "JPEG портит красный цвет при любом качестве" или "JPEG блюрит картинку"

Collapse )

1) можно использовать Save For Web из фотошопа (качество >= 51).
2) можно в консольном стандартном из LibJPEG cjpeg.exe указать параметр chroma subsampling как -sample 1x1,1x1,1x1
3) Ищите же его в других программах! Collapse )

Вот статья с няшными иллюстрациями и подробными объяснениями: http://www.impulseadventure.com/photo/chroma-subsampling.html

Вот не вырожденый пример, а реальная графика: http://stream.ifolder.ru/8764652 (перещёлкивать два jpg в какой нибудь графической смотрелке)
nyaload

Скрипты на С++

<UPDATED>:
длинное обсуждение, что можно и нельзя на плюсах - http://www.gamedev.ru/forum/?group=0&topic=20087 - резюме такое: можно всё, что можно и в скриптах.
ищо ссылка - http://www.gamedev.ru/forum/?group=0&topic=20683

Тезис:

Единственное преимущество "скриптовых" языков - это то, что для них не надо писать пуленепробиваемые reference-counted copy-on-write контейнеры и прочий безопасный пушыстый стафф для дизайнеров уровней, которые не должны знать что такое "память", "байт", "malloc", "конструктор копирования". Еще можно из преимуществ можно назвать реальный, а не эмулируемый microthreading. Для некоторых приложений так же важно, что бы скрипт их скачаного из интернета уровня не мог отформатировать винчестер и послать всем твоим друзьям по почте. Но на это разработчики обычно забивают - некорректно записаный SaveGame может сделать тоже самое. Уязвимости были даже в mp3 и jpeg-файлах.

Мудрый пост Семёна:


Я все-таки хочу подчеркнуть всякие причины, по которым мне не хотелось бы использовать С++ как скрипт.
1) Таки медленно пишется код по сравнению со скриптовыми решениями. GC, принципиальна невозможность выхода за пределы массивов, проблемы с указателями и т.д. - это на самом деле неоценимо. _Winnie, ты же чувствуешь себя умным, когда на С++ пишешь? Я устал повторять, что это плохо. Нужно быть совсем тупым. Тупеть от каждой строчки. Ну и традиционно упомяну рефакторинг ;)
2) Скрипты достигают очень приличных объемов кода. Мегабайт, скажем. Приличных модулей кода, на которых компиляция С++ совсем не мгновенна.
3) Пуленепробиваемая безопасность - это таки аргумент. Потому что логика "если все равно бывают баги, то давайте вообще о них не думать" - она порочна.


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

</UPDATED>


aruslan как-то жаловался, что его за####ает "мгновенная природа С++"

В споре скриты vs С++ я привел такой код:
Collapse )


Вот тут интересное развитие/альтернатива:
http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html