Я не согласен. Большинство графики я нарезаю чем-то вроде:
1. Duplicate Layer/Group
2. В меню выбрать New document
3. Потом выбрать Image Trim
4. Save To PNG
Дизайнер потратит на это не сильно меньше времени чем я. В сложном случае я сам к нему пойду. Зато не тратится время на вот эти коммуникации.
Может быть конечно если дизайнер уже заранее натренирован и сразу знает в каком именно виде графику нужно отдать, то это действительно проще сделать дизайнеру.
При этом я приветствую структурированный подход конечно вроде выдачи таблицы цветов или шрифтов. Это очень помогает. У меня были случаи, когда я подходил к дизайнеру и говорил «А у тебя вот на этом экране шрифт 56 пикселей, а вот тут 60. Это ты специально так задумал или скосячил?». Таблички должны эти проблемы убирать в корне.
Задача дизайнера — дизайнить. А это уже верстка.
Версткой может заниматься как разработчик, так и дизайнер. Обычно занимаются дизайнеры, потому что фотошоп это их инструмент.
Но почему бы не делать это программистам? Это чисто технический скилл. Не нужно бояться фотошопа.
А я вот стараюсь дизайны резать сам и прошу от дизайнеров только PSD. Если не справляюсь, потому что не знаю Photoshop так хорошо, то уже прошу мне там пару картинок дорезать.
Мне так нравится куда больше, чем объяснять дизайнеру что именно и как мне нужно нарезать. Да и не отвлекаю его лишний раз.
Кстати в довольно используемом в последнее время языке Objective-C приблизительно та же ситуация с исключениями. Они как бы в языке есть, но используются исключительно для runtime error ситуаций, когда нужно записать что-то в лог и умереть.
Все фреймворки построены вокруг возвращения ошибки через возвращаемое значение или параметр-указатель.
При этом я не могу сказать, что за несколько лет написания кода под iOS мне это как-то сильно мешало.
На практике в большинстве мультитач интерфейсов сейчас используется протокол TUIO, потому что почти все тач-устройства его поддерживают в первую очередь
Почти все правда, кроме «наплевать на лояльность». Я работаю в похожей компании, только делаем мы оффлайновые инсталляции (мультитач столы, кинекты, мэппинги и все в таком духе).
Вся эта тусовка маркетологов (считай заказчиков) на нормальном уровне уже не очень большая. Скосячишь с одним, об этом обязательно узнают остальные.
В первую очередь ценится стабильность результата — сроки как всегда действительно «вчера» и важно, чтобы к сроку что-то работало. Оно может быть не самым красивым, но оно должно выглядеть как что-то законченное и по возможности не валиться каждые 5 минут с exception'ом :)
Тут скорее все-таки недостаток квалификации программиста. Большая часть флешеров это всегда были аниматоры, которые как-то научились чуть-чуть кодить. Порой они не знают, что такое Linked List или зачем нужна эта вертикальная палочка | и чем она отличается от ||, как недавно проскакивало на hacker news.
Грабли всего лишь состоят в том, что система типов C# не настолько мощная, чтобы указать требование о неизменяемости типа для ключа для Hashset.
Поэтому это требование приходится держать в голове.
В Java, C++ и еще паре десятков языков примерно та же реализация Hashset/Hashmap и ровно та же проблема.
Если в 3DSMax ландшафт делать боль, то возможно какой-нибудь 3д-редактор с хорошими процедурными средствами (Houdini или уже умерший к сожалению XSI) вполне могли бы справиться с задачей. Там можно за весьма короткий срок (прототип можно и за час сделать) собрать какой-то ассет, который на вход будет принимать любую кривую (например безье), которую можно просто нарисовать руками или заимпортить откуда-то вроде Illustrator'а и строить по ней дорогу с любой детализацией, которая только захочется. При этом можно сделать логику, вроде «если дорога слишком высоко над землей, то построить подпорки, а если дорога уходит в землю, то выкопать туннель».
У того же Houdini есть пока экспериментальная, но уже поддержка Unity3D, которая позволяет прямо внутри Unity на этапе редактирования проекта как-то менять процедурный ассет.
У вас всего одна проблема: Дизайнер и Верстальщик патологически не могут общаться между собой
Большинство этих вещей вполне рабочие вопросы, которые решаются за несколько минут в процессе работы, а не когда ее уже нужно сдавать.
www.arcsynthesis.org/gltut/ — лучше сразу начать читать вот это. Там про современный быстрый и куда более мощный pipeline. Фактически нет никакого смысла учить то, что уже сейчас устарело и никаких вообще знаний про то, как работают видеокарты не дает.
1. Duplicate Layer/Group
2. В меню выбрать New document
3. Потом выбрать Image Trim
4. Save To PNG
Дизайнер потратит на это не сильно меньше времени чем я. В сложном случае я сам к нему пойду. Зато не тратится время на вот эти коммуникации.
Может быть конечно если дизайнер уже заранее натренирован и сразу знает в каком именно виде графику нужно отдать, то это действительно проще сделать дизайнеру.
При этом я приветствую структурированный подход конечно вроде выдачи таблицы цветов или шрифтов. Это очень помогает. У меня были случаи, когда я подходил к дизайнеру и говорил «А у тебя вот на этом экране шрифт 56 пикселей, а вот тут 60. Это ты специально так задумал или скосячил?». Таблички должны эти проблемы убирать в корне.
Версткой может заниматься как разработчик, так и дизайнер. Обычно занимаются дизайнеры, потому что фотошоп это их инструмент.
Но почему бы не делать это программистам? Это чисто технический скилл. Не нужно бояться фотошопа.
Мне так нравится куда больше, чем объяснять дизайнеру что именно и как мне нужно нарезать. Да и не отвлекаю его лишний раз.
www.kimchiandchips.com/#littree
www.kimchiandchips.com/#LSS
Все фреймворки построены вокруг возвращения ошибки через возвращаемое значение или параметр-указатель.
При этом я не могу сказать, что за несколько лет написания кода под iOS мне это как-то сильно мешало.
www.tuio.org/
Кстати 3 года назад мы тоже делали Pong для мультитач-стола
выглядел он вот так: vimeo.com/24002921
приватным сообщением, если не ок в комментах
Вся эта тусовка маркетологов (считай заказчиков) на нормальном уровне уже не очень большая. Скосячишь с одним, об этом обязательно узнают остальные.
В первую очередь ценится стабильность результата — сроки как всегда действительно «вчера» и важно, чтобы к сроку что-то работало. Оно может быть не самым красивым, но оно должно выглядеть как что-то законченное и по возможности не валиться каждые 5 минут с exception'ом :)
Тут скорее все-таки недостаток квалификации программиста. Большая часть флешеров это всегда были аниматоры, которые как-то научились чуть-чуть кодить. Порой они не знают, что такое Linked List или зачем нужна эта вертикальная палочка | и чем она отличается от ||, как недавно проскакивало на hacker news.
Поэтому это требование приходится держать в голове.
В Java, C++ и еще паре десятков языков примерно та же реализация Hashset/Hashmap и ровно та же проблема.
У того же Houdini есть пока экспериментальная, но уже поддержка Unity3D, которая позволяет прямо внутри Unity на этапе редактирования проекта как-то менять процедурный ассет.
vimeo.com/86457532 — вот что-то похожее с их канала Vimeo.
Решилось: поменял на «Fixed crash» :)
Большинство этих вещей вполне рабочие вопросы, которые решаются за несколько минут в процессе работы, а не когда ее уже нужно сдавать.