| Гость |
Вы не зарегистрированны? Нажмите здесь для регистрации.
Забыли пароль? Запросите новый здесь.
|
|
| Сейчас на сайте |
Гостей: 25
На сайте нет зарегистрированных пользователей
Пользователей: 1,790
новичок: Durved
|
|
|
| Обсуждение «Альманах грабель» |
|
| Опубликовано 04.07.2013 11:22 (11 лет назад) # |
Из своего опыта знаю, что в каждой отросли программирования есть различные типичные грабли, на которые новички уверенно и закономерно наступают.
Так сложилось, что до этого момента не очень сильно углублялся в разработку игр (лишь небольшие игрушки типа змейки, арканойда и т.д.), но сейчас выдалось свободное время (после защиты диплома есть пару месяцев, вечера которых можно потратить на хобби) и решил изучить это безусловно интересную тему.
Так вот, вернёмся к нашим баранам, т.е. граблям. Уверен, что многие из вас смогут поделиться какими-то интересными наблюдениями, опытом и советами, дабы моё вливание в дружные коллектив геймдевелоперов прошло максимально приятно и безболезненно.
Конечно, я ни коим образом не отменяю значимость обучения на собственных ошибках, но знание потенциальных опасностей и сложностей помогает лучше подготовится.
Надеюсь на ваши интересные отзывы и советы.
P.S. Являюсь Java-разработчиком, так что сейчас смотрю в сторону lwjgl (а следовательно и openGL и прочее) |
|
|
|
|
| Опубликовано 04.07.2013 13:14 (11 лет назад) # |
по своему небольшому опыту могу сказать только это:
не бойся пробовать новое,
не думай что лучше нет (редактор, яп, движек),
не бойся что-то спрашивать и лишний раз показаться "нубом"
|
|
|
|
|
| Опубликовано 04.07.2013 13:47 (11 лет назад) # |
ObelardO написал:
не бойся что-то спрашивать
Признаться честно, один из моих главных недостатков, с которым пытаюсь бороться. Воспитан так, что со всеми проблемами нужно справляться самому. Но понимаю, что порой перегибаю палку. Недавно на работе 2 дня собирал проект (недавно перевёлся в новую компанию) - хоть убей, фейлился во всевозможных местах. Не выдержав подошёл к тимлиду разбираться - оказалась, мне скинули старую инструкцию и нынче проект собирается совсем иначе.
Буду вытравливать из себя этот недостаток. |
|
|
|
|
| Опубликовано 04.07.2013 15:34 (11 лет назад) # |
На java я бы посмотрел на libgdx. lwjgl в нем используется как бэкенд для PC-платформ, поэтому все чуть более высокоуровневое + Android.
Ии стандартных грабель, которые вполне можно пенесести из других отраслей:
1. Не кидайся писать ммо.
2. Не пытайся собрать команду в качестве лида.
3. Четко знай свою цель при разработке игры. Если цель - получить знания, то можно хоть сто раз переписывать под идеальную архитектуру, если цель - доделать игру, то костыли оправданы.
4. Перед 3D лучше попробовать 2D. |
|
|
|
|
| Опубликовано 04.07.2013 20:26 (11 лет назад) # |
| Свои, немного локальные грабли, а скорее совет: как можно раньше все визуализировать или в принципе получать какой-то результат. А то был опыт сборки довольно сложной и вроде бы логичной ООП-модели, которая в итоге, когда начал визуализировать, не фига не работала в самых простейших местах. |
|
|
|
|
| Опубликовано 04.07.2013 20:59 (11 лет назад) # |
От простого к сложному. Всегда, везде. Сразу прыгать на 100500 метров не получится, как не старайся.
Чем быстрее получится видимый результат, тем лучше (уже замеченно Xneg-ом).
Меленькие по изменениям иттерации "сделал - посмотрел результат" предпочтительнее иттераций с массой изменений. Несмотря на то, что возникает ощущение медленного течения разработки, результат получается более стабильный и предсказуемый. В иттерациях с большой массой изменений иногда сложнее выловить баг (потому что не сразу понятно, что именно его вызвало. А при малых изменениях искать легче)
Поставить в среде разработки автозапись. Если есть возможность - запись перд компиляцией.
(я как-то раз потерял что-то около двух третей готового кода игры на 64й конкурс из-за крэша среды. С тех пор эти грабли обхожу сильно стороной)
Чисто игростройные:
Геймплей превыше всего. Есть игры без звука, без цвета, без 3D, без шейдеров, без графики, без джойстика, без геймпада, даже без сюжета есть и еще кучи всего остального, но без геймплея игр не существует, никак, вообще.
Игрок должен получать удовольствие от игры, а не бороться с ней. Т.е. игра должна предоставлять игроку челендж, но не в плане кривого управления, вырвиглазной графики, непонятного поведения и пр. Игрок превыше всего.
Мелочи роляют. Внимание к мелочам (удобное меню, дружелюбный интерфейс, вменяемое "место для ошибки"во всём, что делает игрок) оставит от игры намного более лучшее впечатление, чем потраченный день на фотореалистичный рендер коробки, на котору запрыгивает персонаж.
Самое главное - целью нужно ставить создание игры, в которую можно играть.
(Технодемы играми не являются и хороши для выбивания финансирования из издателей под будущую игру, но полностью выпадают из местных реалий)
|
|
|
|
|
| Опубликовано 05.07.2013 05:40 (11 лет назад) # |
| Игрок - это целая философия) этому посвящено много статей и даже книг. и все это тесно переплетено с психологией. |
|
|
|
|
| Опубликовано 05.07.2013 20:07 (11 лет назад) # |
Спасибо за советы.
Насколько смог заметить, шибко разительных отличий от разработки не игрового ПО не так уж и много, и в большинстве своём главные сложности одинаковы. |
|
|
|
|
| Опубликовано 05.07.2013 22:38 (11 лет назад) # |
GromHoll написал:
Спасибо за советы.
Насколько смог заметить, шибко разительных отличий от разработки не игрового ПО не так уж и много, и в большинстве своём главные сложности одинаковы.
Тут еще вот какой момент, в случае с разработкой неигрового ПО, например на работе, есть какое-то из или хотя бы общее представление о том, что пользователи хотят от программы. В случае с собственной игрой обычно никакого из нет, поэтому возникает проблема с тем, когда остановиться в реализации собственных идей.
И еще, довольно очевидная проблема, однако, все ее пропустили: обычно автору игра кажется недостаточно сложной. В силу того, что в процессе разработки ты все играешь и играешь в свою игру, ты все больше в ней совершенствуешься. А для стороннего игрока итоговая сложность может оказаться запредельной. |
|
|
|
|
| Опубликовано 05.07.2013 22:38 (11 лет назад) # |
GromHoll написал:
Спасибо за советы.
Насколько смог заметить, шибко разительных отличий от разработки не игрового ПО не так уж и много, и в большинстве своём главные сложности одинаковы.
Тут еще вот какой момент, в случае с разработкой неигрового ПО, например на работе, есть какое-то из или хотя бы общее представление о том, что пользователи хотят от программы. В случае с собственной игрой обычно никакого из нет, поэтому возникает проблема с тем, когда остановиться в реализации собственных идей.
И еще, довольно очевидная проблема, однако, все ее пропустили: обычно автору игра кажется недостаточно сложной. В силу того, что в процессе разработки ты все играешь и играешь в свою игру, ты все больше в ней совершенствуешься. А для стороннего игрока итоговая сложность может оказаться запредельной. |
|
|
|
|
| Опубликовано 09.07.2013 09:31 (11 лет назад) # |
Самая главная проблема - это отсутствие мотивации. Вот начнёшь что-нибудь делать, провозишься неделю и бросишь. А всё потому, что чем дольше возишься, тем больше видишь, что предстоит сделать ещё больше. И всё это занятие короче превращается в зря потраченное время, если, конечно, это не коммерческий проект за который тебе платят. А пилить что-то для себя - очень сомнительное занятие потому, что: для себя ты уже всё и так придумал, как в твоей игре и что должно быть, а всем остальным это не не нужно, т.к они скорее скачают Mass Effect №3 и поиграют в него, чем в твои подделки, сколько бы времени ты ни убил. Таким образом мотивация получить некий готовый продукт отсутствует изначально, (т.к ни другим людям - они найдут что поинтереснее, ни тибе самому он не нужен), остаётся только наслаждаться процессом, но это скучно, как я уже сказал, максимум на неделю
А ещё Java - это тоже такие большие грабли. Потому, что она тормозит |
|
|
|
|
| Опубликовано 10.07.2013 10:11 (11 лет назад) # |
| Удивлён, что этот древний миф про медленную Java всё ещё жив. Есть достаточно примеров коммерческих игр, которые имеют хорошую производительность (линейка игр Titan Atack или spirit knight). |
|
|
|
|
| Опубликовано 10.07.2013 10:18 (11 лет назад) # |
| Попеременно пишу на Java, C#, Delphi. Delphi быстрее всего, C# чуть отстает, Java отстает больше всех. Отстает по всему - по времени "компиляции", по времени запуска, по общей скорости работы и отзывчивости. Особенно, когда дело доходит до OpenGL. Честно говоря, даже tao framework на C# работает лучше, чем lwjgl. |
|
|
|
|
| Опубликовано 10.07.2013 11:56 (11 лет назад) # |
Daemon написал:
Попеременно пишу на Java, C#, Delphi. Delphi быстрее всего, C# чуть отстает, Java отстает больше всех. Отстает по всему - по времени "компиляции", по времени запуска, по общей скорости работы и отзывчивости. Особенно, когда дело доходит до OpenGL. Честно говоря, даже tao framework на C# работает лучше, чем lwjgl.
Старый добрый холливор. =)
Я имею достаточно опыта с Java и никогда не сталкивался с проблемами её производительности (быть может просто не видел как справляются другие языки (C/С++ - не в счёт)).
Быть может она и медленней C# или Delphi - но неужели разница будет настолько велика, что её заметит конечный пользователь? Не уверен. Сотни игр под Android доказывают, что всё решаемо.
Java лично мне нравится своей лаконичностью, некой красотой и наличием готовых стандартных решений для огромного количества задач.
Хочу ещё раз отметить - я не новичок в программировании, лишь только в "игропроме". |
|
|
|
|
| Опубликовано 10.07.2013 13:28 (11 лет назад) # |
GromHoll написал:
Старый добрый холливор. =)
Я имею достаточно опыта с Java и никогда не сталкивался с проблемами её производительности (быть может просто не видел как справляются другие языки (C/С++ - не в счёт)).
Быть может она и медленней C# или Delphi - но неужели разница будет настолько велика, что её заметит конечный пользователь? Не уверен. Сотни игр под Android доказывают, что всё решаемо.
Java лично мне нравится своей лаконичностью, некой красотой и наличием готовых стандартных решений для огромного количества задач.
Хочу ещё раз отметить - я не новичок в программировании, лишь только в "игропроме".
Твой опыт в программировании никто не оспаривает, я это заметил еще в первом сообщении, так что можно еще раз не отмечать :)
"Игропром" довольно специфичен в плане требований производительности. Практически ни в одной другой прикладной задаче тебе не требуется не менее 60 кадров в секунду что-то рисовать, выполнять серьезные и критичные для процессора математические операции (вроде расчета видимости, банальный перевод из modelview в projection и прочее), а еще не менее 30 раз за секунду считать довольно сложную логику.
У Java есть преимущество, которое одновременно является ее недостатком - отсутствие деструкторов и наличие garbage collector. И с его непредсказуемым поведением (и как следствие - со скачком фпс) сталкивается практически каждый девелопер на java. Да, очень удобно писать на нем сервер для мультиплеерной игры (опять же, исходя из наличия garbage collector), можно что-то случайно "забыть" удалить и оно удалится, если (подчеркиваю если) подсчет ссылок будет верным. Ситуацию с взаимоблокировкой ссылок (не помню, как это правильнее называется) когда у объекта А есть ссылка на объект Б и наоборот, GC не разруливает, ее надо рулить ручками.
Нет, я не рассказываю вам, человеку знающему Java, что такое GC. Я рассказываю о том, как он мешается в "игропроме".
Нет, я не пытаюсь развести holywar. Для меня уже год как ЯП - просто средство, которое надо выбирать в зависимости от задачи, бюджета, сроков ее решения и личных предпочтений. Именно в таком порядке.
И кстати об Android-играх. Из 100 едва ли 10 будет написано на чистой Java. Чаще всего пишут полупустую обертку на java, которое общается с написанной на C++/FreePascal и скомпилированном в *.so(или как там обозначается dll в *nix?) библиотекой, через Android NDK.
И даже несмотря на такую структуру с посредниками, это работает быстрее, чем код на Java, что для меня вообще полный секрет, но что является фактом.
Я не пытаюсь убедить вас в том, что бросайте Java, пишите на плюсах. Просто я рассказываю вам о том, во что вы рано или поздно упретесь :)
Посылаю лучи бобра и все такое =) |
|
|
|
|
| Опубликовано 10.07.2013 13:54 (11 лет назад) # |
| Кстати против проблемы явы (да и C#) связанной с GC есть одно верное средство - кеширование. Кеширование всего и вся в игре позволяет добится очень хорошей производительности (близкой к Сям). Только написать правильную архитектуру при этом может оказаться сложнее, чем просто написать все на тех же Сях)) Именно благодаря кешированию мне удалось с горем опполам закончить когда-то пару игрушек под заказ под J2ME и свой OpenGL валлпейпер https://play.google.com/store/apps/details?id=com.phlox.electrowp под андроид (правда память в нем все-равно мал-по малу где-то текла - я, когда разобрался с производительностью вообщем на память забил).
редакция от FedeX, 10.07.2013 13:59 |
|
|
|
|
| Опубликовано 10.07.2013 14:20 (11 лет назад) # |
Во-первых сравнивать Delphi с C#/Java довольно странно, ведь Delphi компилируется в нативный код для конкретной выбранной архитектуры процессора (с применением различных оптимизаций для конкретных архитектур), а java и c# компилируются в байт-код, который выполняется в среде выполнения, которая выполняется на процессоре с архитектурой, для которой эта среда была скомпилирована (хотя есть варианты, в которых и сама среда выполнения тоже выполняется в среде выполнения которая выполняется... [картинка с леонардо дикаприо.jpg]). Так что без использования JIT приложения на java/c# как не крути будут работать медленнее нативных. Зато будут работать на любой платформе, на которой есть нужная среда выполнения.
Во-вторых java и .net используют JIT так что скорость их выполнения может приближаться к нативному коду.
В-третьих внезапно все эти тормоза в 99% случаев являются следствием искривления рук автора кода. Если GC вызывает тормоза до ощутимого падения FPS, то скорее всего это следствие плохого дизайна приложения и/или непонимания принципа работы GC (читай говнокод). Кстати, могу ошибаться, но кажется в приложениях собранных из Delphi тоже есть сборщик мусора не смотря на конструкторы/деструкторы.
В-четверых про Android утверждение бездоказательное, однако даже если бы это и было так, то это не был бы камень в огород java, а скорее комплимент в сторону архитектуры Android. Программы написанные на C/C++ довольно легко переносятся на Android так что нет никаких причин для того, чтобы переписывать их с нуля на java. Например как по вашему появились порты Max Payne и GTA III на андройд? Они не стали переписывать их целиком на java же, это было бы просто экономически нецелесообразно, достаточно было скомпилировать код для android и написать тонкую оболочку на java. Во-вторых существует огромное количество кросс-платформенных библиотек и движков которые созданы по тому-же принципу. Ядро написано на языке, который можно компилировать в нативный код для разных платформ, а логику самой игры можно писать уже на языке принятом для платформы, например на java или Objective-C или C# или даже JavaScript или Python.
Вот кстати в копилку граблей навеяло:
не существует самого лучшего ЯП(платформы/ос/по...) на котором нужно писать все и всегда и не существует самого плохого и ужасного ЯП(платформы/ос/по...) который никому и никогда не нужно даже трогать. Если инструмент существует и о нем говорят (холиварят), значит его используют, он приносит пользу и прибыль и занял свою нишу и следовательно нужен. Так что не нужно холиварить :) Лучше изучить по лучше то, с чем борешься и понять в чем его сильные и слабые стороны, в чем их суть, когда его следует использовать а когда нет и т.д. И тогда наступит гармония :) |
|
|
|
|
| Опубликовано 10.07.2013 15:09 (11 лет назад) # |
Daemon написал:
И с его непредсказуемым поведением (и как следствие - со скачком фпс) сталкивается практически каждый девелопер на java.
Поведение как раз таки предсказуемо. Проблема тут для игр в том, что это предсказуемое поведение не real-time.
Бегает игрок в 3D-action, захотел нажать гашетку и прибить супостата, а тут пришел сборщик мусора.
Поэтому в серьезных проектах ответственные за real-time модули придется делать на чем-то другом. Но если например игра это текстовый квест, то ей никакие требования по real-time не нужны.
Ещё Java более далека от железа, чем C/C++.
редакция от bsivko, 10.07.2013 15:09 |
|
|
|
|
| Опубликовано 10.07.2013 15:34 (11 лет назад) # |
AFAIK, JIT-компилятор у java не компилит приложение целиком при запуске, верно? Только необходимый кусок. Вот если бы он компилил бы его полностью, да еще и кэшировал результат компиляции (как делает .NET)
в приложениях собранных из Delphi тоже есть сборщик мусора не смотря на конструкторы/деструкторы
Нету. Из подобного можно забацать классы, реализующие интерфейс IInterface и использующие его стандартную реализацию через наследование TInterfacedObject. Только в этом случае при использовании интерфейсных ссылок идет их подсчет, за которым следит ... сам объект. При обнулении счетчика объект вызывает свой деструктор. Сразу. Безо всяких, "не, я еще пару десятков тактов подожду, а то че я, как лох, буду один объект чистить" =)
А вообще, ребятушки, черт с ними с языками, каждому свое.
ТС - пиши на чем хочешь :)
Айда лучше конкурс обсуждать :) |
|
|
|
|
| Опубликовано 10.07.2013 16:03 (11 лет назад) # |
Daemon написал:
AFAIK, JIT-компилятор у java не компилит приложение целиком при запуске, верно? Только необходимый кусок. Вот если бы он компилил бы его полностью, да еще и кэшировал результат компиляции (как делает .NET)
Значит на то была объективная причина, которая дает преимущества в чем-то либо это издержки в пользу чего-то еще. Дело же не в том что Sun/Oracle просто такие лохи что не смогли сделать так круто как MS, иначе бы с появлением .net новые проекты на java просто перестали бы появляться
Daemon написал:
А вообще, ребятушки, черт с ними с языками, каждому свое.
ТС - пиши на чем хочешь :)
Естественно :) Просто нужно подвергать сомнению богоизбранность выбранного инструмента и понимать что другие тоже не просто для количества существуют а возможно даже в будущем помогут решить некоторые задачи меньшими усилиями :) |
|
|
|
Перейти на форум:
|
|
|
|
| Конкурсы |
Открытые конкурсы:
Bullet HeavenСтарт: 23 ноября 2024г.
Финиш: 4 декабря 2024г. Участники: 4 Недавние конкурсы:
|
|
|