Скажите насколько часто пользуются этим пакетом профессиональные аниматоры, дизайнеры ?Сообщение от superregistr
Просто среди них что-то многие выбирают и покупают лицензионные продукты иных названий, чем пользуются этим. Почему ?
Когда я брался за изучение питона, тогда о нем почти никто не знал даже, помню в ручную все приемы и ходы изучали... У кого что получится... потому как даже литературы не было обучающей. Только описательная и все.
Но уже тогда везде потчевали и уверяли начинающих программеров питонистов вот этим самым:
А прошло уже более пяти лет с того времени...Питон -- это гибкий, удобный, быстрый и быстро развивающийся язык. За ним будущее, так как он развивается быстрее чем Си++.
Да питон стал больше использоваться как скриптовый язык, но заменить Си он так и не способен...
Не важно... что было сказано или написано... все это от незнания и неумения выбрать верное среди многого...
Мои взгляды на то какой должна быть глобальная стратегия
\\Java давно уже не чистый интерпретатор, там компиляция на лету используется наподобие как в .NET
вообще-то он с самого начала не чистый интерпритатор.
и с .NET все наоброт -- это в дотнете используется JIT как в жабе.
\\По поводу java, знаю, но стабильнее пока этот язык не становится...
Странное мнение о языке, который уже давно используется как в бизнес-логике, так и во всяких встраиваемых системах.
Конечно, жаба имеет много своих гитек, постоянно вылазят те или иные грабли в зависимости от версии, сборки.
Но тем не менее, сама языковая среда достаточно стабильна.
\\С питон API в виндовсе знаком, но на практике применял только для корректирования отдельных моментов в тех или иных программах.
Не понимаю... с какого это тебе нужно использовать в Питоне биндинги к виндовому API?
Ну, то есть, есть такие момент где без этого не обойтись.
Но ведь все остальное можно делать вполне через его же собственные кросс-платформенные библиотеки.
http://www.dtf.ru/articles/read.php?id=58185
оттуда, из комментов
""Нет "рецепта" успеха - и он не только в мотивации или "огне". Хотя, признаюсь, не так давно я бы тоже говорил о мотивации... Может, перешел на новую ступень понимания? Или спустился ниже?
Есть опыт, знания, общее "умение соображать", здравый сысл, желание успеха, возможность тратить на работу достаточно времени и усилий, умение ладить с разными людьми, здоровье, некая "политическая" (в хорошем смысле) мудрость и/или знание психологии. Все это "транслируется" в те сотни решений, от которых зависит успех проекта. И еще - удача
""Вероятно будет полезным, список неформальных показателей от Сергея Архипенкова (серьезный дядька, пм в люксофте, проекты для боинга), за что премировать людей, как развивать команду:
1. Занимает активную позицию, стремится расширить свою ответственность и увеличить личный вклад в общее дело.
2. Постоянно приобретает новые профессиональные знания и опыт, выдвигает новые идеи, направленные на повышение эффективности достижения общих целей, добивается распространения своих знаний, опыта и идей среди коллег.
3. Получает удовольствие от своей работы, гордится ее результатами и стремится, чтобы эти же чувства испытывали все коллеги.
4. Четко осознает свои личные и общие цели, понимает их взаимообусловленность, настойчиво стремится к их достижению.
5. Уверен в себе и в своих коллегах, объективно оценивает их достижения и успехи, внимательно относится к их интересам и мнениям, активно ищет взаимовыгодное решение в конфликтах.
6. Является оптимистом, при этом твердо знает, что окружающий мир несовершенен; воспринимает каждую новую проблему, как дополнительную возможность подтвердить собственный профессионализм в своих глазах и во мнении коллег.
Отсюда - http://www.happy-pm.com/blog/?p=2761""
http://www.dtf.ru/blog/read.php?id=54278
1.1 Вижен-документ - документ на одну страницу, коротко описывающий будущий проект.
1.2 Переговоры с издателем, определение ключевых фич проекта.
1.3 По итогам обсуждений - концепт-документ (приблизительно 5-7 страниц), раскрывающий ключевые фичи проекта. Дальше я не буду уже упоминать, но каждый этап из этого списка в той или иной форме апрувился издателем, хотя по своим обязательствам он должен был принять более локальное участие. Разработчикам хинт - издателя (т.е. продюсера проекта как только он определился) на этом этапе надо абузить как можно более активно - dual hardcore mind penetration вполне подойдет.
1.4 Адаптация GDD "Агрессии" к проекту, как результат - "расширенный концепт" (~15 страниц), частично описывающий дизайн игры. На этом этапе более точно определились игровая хронология, страны-участницы и проч. реалии игрового мира.
1.5 Создание "фейкового эталонного" скриншота художником (не могу найти сейчас - выложу позже). Картинка призвана демонстрировать общее мнение издатель+разработчик КАК ДОЛЖНА ВЫГЛЯДЕТЬ игра. В нашем случае, как должна выглядеть стратегическая карта, поскольку визуальная составляющая "Империи" это трехмерная карта + двухмерный интерфейс.
1.6 Создание "схемы геймплейных модулей", отображение core game mechanics в виде блок-схемы, делалось без излишней детализации, но в целом демонстрировало какие действия может совершать игрок и как на это игра реагирует.
1.7 Дальнейшая проработка документации, имплементация в механику игры новых фич (которых не было в "Агрессии"). То есть мы в данном случае сначала определили костяк геймплея, который оставляем от "Агрессии" (на этом этапе были отрезаны все фичи, которые мы посчитали лишними, которые были не приняты игроками, которые не соответствовали сеттингу), а затем начали наращивать на него "мясо" в виде новых фич, необходимых для "Империи".
1.8 Подбор core team (кадровые вопросы), составление штатного расписания рабочей группы по проекту с определением полномочий и пр. формальностями. Наученные печальным опытом "Агрессии" мы подбирали команду по принципу психологической совместимости, что в итоге стало залогом продолжительной работы без скандалов и прочих ахтунгов. Но тут еще ситуация уникально удачно сложилась, что как раз на тот момент в Студии оказались свободны обладающие нужными знаниями и психологически совместимые люди.
1.9 Работа с "фичамером", все связанные с проектом предлагали свои фичи и выставляли им оценки в табличку по 5-ти балльной шкале. После коллективного обсуждения дополнительных фич часть из них пошла в документацию. Надо отметить что на этом этапе добавлялись уже мелочи, ничего из корневых механик старались не трогать.
1.10 Подключение программиста, выделение отдельной ветки движка под проект, настройка основных технологических процессов (где будем хранить версию, как будем работать с базой и т.д. и т.п.). По сути к моменту появления на проекте первых программерских рук (а это в нашем случае будущий главный программист проекта, то есть почетный Хранитель Рабочего Билда, от которого зависит чуть ли не успех всего предприятия) все основные вопросы дизайна закрыты и он может понять технологический масштаб проекта и подобрать нужные ему решения.
1.11 Дизайн-документ версии 1.1 одобренный издателем (а также заранее оговоренный договором комплект документации по результатам препродакшена).
1.12 Как этап, совмещающий препродакшен с производством - Тотальная Викификация всей накопленной информации по проекту (да, мы не работаем с громоздкими .doc как только они становятся такими, wiki гибче и мобильней).
Вот такие 12 шагов.
хочу высказатсья по поводу выбора языка и поводу вот таких вещей.
ИМХО.
игру надо изначально реализовывать в виде независимых модулей (DLL) которые можно писать на рызных языках.
Моя версия:
1. ядро игры. оно осуществляет основную деятельность по обработке игры. при этом ей совершенно по барабану кто играет и где он находится. она просто вызывает функции которые отвечают за ходы игроков.
2. прослойка отвечающая за сетевую игру. она получая данные/сигналы от ядра игры отправляет данные игрокам и получает их ходы. именно этот модуль отвечает за сетевое соединение. при этом ей опять же по барабану кто играет (ИИ или человек)
3. уровень игрока. часть отвечающая за ИИ и человека. при этом при взаимодействии с ядром игры совершенно нет разницы кто играет: ИИ или человек. Отличие состоит лишь в том что когда играет человек, происходит вывод графики и ожидание его действий.
при использовании вышеприведённой модели можно будет в начале разработки игры использовать 2D, а потом в случае необходимости внедрить движок аля "суперпуппер3D" при этом даже не затрагивая ядро игры.
Да, это все красиво звучит. Какраз в русле нынешних паттерн-кодеров.
Но проблема в том, что игра -- это одноразовый продукт.
А такая детальная проработка: разделение на (независимые) модули, программирование в рассчете на слудующую версию и т.п.
тупо усложняет разработку здесь и сейчас в 2-3 раза.
А если программист(ы) не понимают сути выше указаного, то и вообще ведет разработку к краху.
мы тут обсуждаем разработку альтерцивы, и ты говоришь что это одноразовый продукт. обижаешь
я уже начал так делать и особых проблем и тормозов не вижу. при использовании этой схемы реально возникает возможность РЕАЛЬНО разделить работу программистов, один делает ядро, другой делает интерфейс. если изначально всё правильно сделать всё будет хорошо.
ффффНовичкам я бы посоветовал (и советую при каждом удобном случае, вот как сейчас) начинать с проекта в стиле total conversion на чужом движке, и в этот чужой движок влезать очень осторожно. К сожалению, у них, за редким исключением, извините, амбиции, и очевидную мысль, что первую свою хорошую игру сделать на чужом движке совершенно нормально, они не догоняют.
поддерживаю ahilles
модульность, объектность не спроста придумали.
дело не только и не столько в реюзинге сколько в улучшении понимания собственной программы и простоты ориентирования в ней.
то что структурированный код писать в 3 раза дольше - это не соответствует действительности. возможно по началу только.
а экономия времени наоборот огромная - на отладке прежде всего, а отладка львиную долю составляет процесса разработки.
если мы говорим конечно не про hello world а про большую программу на десятки тысяч строк
Ваши права
Ответить с цитированием
