Dev — Игра и на каком языке лучше сделать


Содержание

На каком языке делают игры и почему(С++, Java. )

Я не про в С++, но люблю этот язык за его мощность.

Есть игра GTA 4. Насколько мне известно она сделана на С++/DX.

Я знаю, что игры пишут не только на С++.

Есть друг, который утверждает что у С++ нет преимуществ перед Java. Спор зашел с ним о создании игрушек. Ведь DX можно использовать в связке с Java? Я не про и не смог ответить почему игры такого размаха как GTA 4 делают на С++ а не на Java.

Moby
Как ты думаешь, что главное в игре уровня GTA4, если не брать в расчет сюжет и геймплей?

Помеха
> Как ты думаешь, что главное в игре уровня GTA4, если не брать в расчет сюжет и
> геймплей?
главное чтоб продажи были как можно выше =)

Логическая цепочка.
С++ vs C#
C# vs Java
Ну и вот теперь долгожданная Java vs C++.

Moby
> Есть друг, который утверждает что у С++ нет преимуществ перед Java.
тебя нагло и жестоко обманули : )

> Есть друг, который утверждает что у С++ нет преимуществ перед Java.

Дык. пусть устраивается в рокстаргейм ) покажет как надо делать GTA и на чем

ответ кроется в понимании того что представляют из себя эти языки, c++ является не управляемым языком(в .net есть его управляемая версия), java и языки в ходящие в .net такие как C# наоборот генерируют управляемый код, просто вызвать неуправляемый код из управляемого нельзя(для этого есть специальные алгоритмы взаимодействия).
Следовательно чтобы вы могли работать с вашими графическими api такими как opengl и d3d вам необходимо реализовать этот процесс взаимодействия чем и являются такие продукты как managed directx(MDX(каторые больше не развивается)), XNA, SlimDX, TAO opengl binding это все что касается C# и тут несколько все лучше обстоит чем в java

к сожалению в java на данный момент нету поддерживаемых биндингов к библиотеке dx или d3d, однако есть таковые к opengl(jogl, lwjgl), которые однако также поддерживаться небольшой группой энтузиастов и для использования в коммерческий проектах несколько не подходят да и это всего лишь голое api(конечно на основе их есть реализации graphic engine(http://www.jmonkeyengine.com/screenshots.php)), также нельзя забывать и про работу с вводом, звуком для библиотек работы с которыми должны быть реализованы соответствующие привязки.

я думаю теперь становиться понятно почему разработчик коммерческих игр предпочитают использовать c/c++, не потому что на языках подобных java/С# нельзя написать игру уровня gta4 а потому что некто не будет переделывать существующую инфраструктуру и средства разработки в которые были вложены огромные деньги да и дополнительный уровень абстракции такой как net или java накладывает дополнительные ограничения(не только в техническом плане).

что касается c++ vs java ваш друг в чемто прав(если не считать написание игр), да и зависит все от задачи, есть такие где java просто нету альтернатив.

>Как ты думаешь, что главное в игре уровня GTA4, если не брать в расчет сюжет и геймплей?

>что касается c++ vs java ваш друг в чемто прав(если не считать написание игр), да и зависит все от задачи, есть такие где java просто нету альтернатив.

Не спорю и наверно даже примерно представляю о каких задачах идет речь.

Просто пытаясь хоть что то грамотное и обоснованное сказать про С++ я привел в пример GTA 4, на что получил ответ.

Так все таки есть такое, что Javе не под силу? Вот тот уровень абстракции, что приводит к некоторым ограничениям, может же привести к тупиковой задаче.

По моему скудному опыту я знаю, что С++ являясь низкоуровневым языком, дает больше свободы в прямой работе с железом. Как мне кажется, Java не справится с некоторыми задачами. И если брать GTA 4, то на Jave такую производительность\качество не получится реализовать. Поправьте меня.

Кстати, извините за тупой вопрос, но ведь сам Dx написан на С++, правильно?

Moby
> Вот тот уровень абстракции, что приводит к некоторым ограничениям, может же привести к тупиковой задаче.
К тупиковой точно не приведёт, возможно в некоторых случаях придётся писать больше кода.

Судя по статье в вики java особенно сильно С++ не проигрывает (но и не выигрывает). Наиболее заметный проигрыш, имхо, у неё в управлении памятью (для топовых игр наверняка критично) и шаблонах (generics в java). Плюс что бы поиграть в игру на java многим пользователям надо будет дополнительно скачать JRE из сети — это мало кому понравится. JRE весит около 16М, что может оказаться даже в несколько раз больше некоторых игр.

Правка: исправил ссылку на статью

Что бы там не говорили про то, что java сейчас шустрая, и по производительности догнала C++, это всё не так. Для десктоп-приложений она слишком тормозная (правильнее сказать, она не позволяет писать такой же быстрый код как С++). С++ позволяет писать быстрый код.(Конечно, если писать одинаковый код, то может и java и не проигрывает особо плюсам) Java позволяет быстро писать легко поддерживаемый код. Для игр гораздо критичнее производительность, нежели легкоподдерживаемость. А допустим в ынтырпрайзе наоборот, дешевле писать на Java и купить более мощный сервак для приложения, чем писать на C++.

Moby в общем подытожив что написал max333 ( я с ним всецело согласен ) можно сказать что требуется большая низкоуровневость — как в С++ — что позволяет через один уровень абстракции ( DirectX — например ) иметь доступ к железу. В java это делается хитровымудренно и как следствие — неудобно.
P.S.: между прочим С++ задумывался не только как «улучшенный С», но и как высокоуровневая замена Asm’у — а это говорит само за себя=)

Да, когда пишешь на С++, самопроизвольно в уме переводишь все на асм. С джавой и шарпом это раз в 20 сложнее и становится как-то неуютно.

Iskander
> Логическая цепочка.
> С++ vs C#
> C# vs Java
> Ну и вот теперь долгожданная Java vs C++.

осталось тока C#vs C# )))))))))))))) ЭТО СПАРТА. )))))))))1111

Moby
> Есть друг, который утверждает что у С++ нет преимуществ перед Java. Спор зашел
> с ним о создании игрушек.
Я с некоторых пор прогаю на C++ и Java. У каждого есть свои недостатки и преимущества. И как раз в игрушках Java уступает сильнее всего. Как уже было сказано, в ней пока нет стандартных средств работы с 3D графикой.

max333
> к сожалению в java на данный момент нету поддерживаемых биндингов к библиотеке
> dx или d3d, однако есть таковые к opengl(jogl, lwjgl), которые однако также
> поддерживаться небольшой группой энтузиастов
Ходят слухи, что JOGL войдёт в JDK 1.7. В любом случае, рано или поздно он или другой биндинг должен войти в базовую платформу Java. Я как-то использовал JOGL. Неудобно именно тем, что приходится поставлять всю библиотеку вместе с проектом, хоть она и не большая.

Tiendil
> многим пользователям надо будет дополнительно скачать JRE из сети — это мало
> кому понравится. JRE весит около 16М
Что в десять раз меньше нескольких одновременно установленных версий .NET Framework, так что тут никакой проблемы я не вижу.

Языки программирования, на которых были написаны популярные компьютерные игры — пять вдохновляющих примеров

Компьютерные игры — это большой бизнес. Суммарная выручка индустрии видеоигр в США достигла 23,5 миллиардов долларов в прошлом году, что на 5% больше, чем в 2014. За каждой великой игрой стоят программисты, которые вносят существенный вклад в конечный продукт. Конечно, для создания разных игр используются разные языки программирования. В данной статье мы представим вам несколько самых популярных.

Язык ассемблера

Многие игры для Sega и Dendy были написаны на различных диалектах языка ассемблера, включая Super Mario Brothers.

Игры серии Super Mario были проданы тиражом более 70 миллионов копий. IGN назвала третью часть Super Mario Brothers самой великой игрой всех времён.

Язык Си

Язык Си до сих пор остаётся одним из самых популярных языков программирования из-за своей относительной простоты и чёткой структуры. Компания id Software использовала Си для создания игры Doom, впервые выпущенной в 1993 году.

Doom была названа самой влиятельной FPS-игрой, став прообразом многих других игр от первого лица и 3D-игр в общем. По приблизительным оценкам Doom набрал около 10 миллионов установок в 1995 году.

Язык С++ использовался для создания многих современных операционных систем, софта, игр и игровых движков. Благодаря его гибкости, игры можно относительно несложно портировать с ПК на консоли и в обратном направлении. Одной из самых популярных игр, написанных на С++, является World of Warcraft.

С момента запуска было продано 14 миллионов копий. 48% подписчиков проживают в азиатском регионе, 22% из США. На вики по WoW содержится более 100 000 статей.

Разработанный компанией Microsoft в 2000 году, С# стал довольно популярен среди разработчиков игр. Движок Unity, широко используемый при создании игр для ПК, консолей и мобильных устройств, написан преимущественно на С#. Одна из самых заметных игр в данном классе — Angry Birds.

Angry Birds находится на третьем месте по популярности среди всех игры для iOS всех времён, сразу за Candy Crush Saga и Fruit Ninja. Стоимость разработки первой версии игры составила порядка $140 000, что является очень скромным числом в своём роде. Четыре человека работали над игрой суммарно порядка восьми месяцев.

Java является в некотором роде родственником C#. Они развиваются под влиянием друг друга, оба имеют сборщики мусора и объектно-ориентированы. Но Java изначально позиционируется как платформонезависимый язык, что означает, что он (по задумке) работает абсолютно одинаково на всех устройствах. Истории успешных игр, написанных на Java, включают в себя RuneScape и Minecraft.

Альфа-версия игры была создана всего за 6 дней. Minecraft — вторая самая продаваемая игра в мире. Изначально она называлась «Cave Game».

Хотите найти больше материалов по разработке игр и, может быть, даже разработать одну свою? Загляните в наш раздел по геймдеву.

«Студент правильно сделает, если возьмётся за изучение Scala». Руководитель Scala-разработки Evolution Gaming — о редком языке программирования

Два месяца назад разработчик игр для онлайн-казино Evolution Gaming открыл представительство в Минске. Минский офис стал четвёртым R&D-центром компании, наряду с Ригой, Таллином и Амстердамом. Несколько лет назад разработку в Evolution Gaming перевели на Scala.

О преимуществах и перспективах этого довольно редкого языка программирования dev.by поговорил с руководителем Scala-разработки компании Юрисом Крикисом.

«Изменять код можно уверенно»

Как вы изучали Scala и когда начали кодить на нём?

Примерно в 2012 году я начал искать для себя «улучшенную версию Java», который тогда слабо развивался. Начинал с Groovy — мне нравилось, но казалось, что можно лучше. И тогда я стал изучать Scala. Поначалу язык выглядел слишком сложным. В то время экосистема Scala не была такой зрелой, как сейчас: например, плохо работала подсветка кода в IDE. Но мне вовремя попались хорошие курсы Мартина Одерского на Coursera, они помогли понять язык. Scala мне понравился, и я начал активно его использовать.

Чем именно вам понравился язык?

Тем, насколько хорошо компилятор проверяет типы в коде. Это позволяет эффективно делать рефакторинг. Изменять код можно уверенно — компилятор подскажет, где ты ошибся в процессе правок. Scala даёт уверенность в том, что если компилируется, то и с большой вероятностью работает.

Насколько Scala популярен сегодня?

Мне кажется, он более популярен, чем многие другие языки, которые больше на слуху. Конечно, Scala-разработчиков меньше, чем программистов, работающих на Java, JavaScript или Python. Но Scala более распространён в индустрии, чем те же Go, Rust или Kotlin.

Для каких областей разработки Scala подходит лучше всего?

Scala — язык общего назначения (general purpose), который работает на платформе JVM, как и Java. На нём можно делать всё то же, что и на Java, плюс есть пара особых моментов. Во-первых, это фреймворк Akka, который используется и в Scala, и в Java, но в Scala удобнее. Фреймворк хорош для разработки распределённых приложений, которые обеспечивают transaction processing (обработку транзакций), например, в финансовой или банковской сфере, а также в приложениях со ставками на спорт и онлайн-казино — то, чем, собственно, и занимается Evolution Gaming. Во-вторых, Scala используют для Apache Spark — инструмента процессинга данных.

Для широкой публики Scala известен как язык разработки некоторых популярных соцсетей: Twitter, Linkedin, WhatsApp…

Думаю, что для соцсетей важен тот самый transaction processing. Фреймворк Akka подходит для быстрого отправления сообщений разным пользователям. Scala — это язык, который работает на JVM, что раскрывает возможности функционального программирования. Код, написанный на Scala, легче поддерживать. Кроме того, Scala «дружит» с Java-библиотеками и вашим существующим Java-кодом.

«Если разработчик знает Scala — это показатель того, что он улучшает своё умение писать код»

Можете назвать страны или регионы, где Scala знают и активно на нём кодят?

У меня нет статистики по географическому распределению таких компаний и программистов. Мы, например, успешно находим Scala-разработчиков в России, Беларуси, Украине и Латвии. Довольно много и эффективно Scala используют в Швейцарии, Нидерландах и Великобритании — в этих странах работают большие компании, которые используют Scala.

И всё же Scala — не самый распространенный язык программирования. Как считаете, почему?

А как определить уровень популярности? Есть разная статистика, но в топах сейчас, пожалуй, JavaScript и Java. У Java очень долгая история (язык появился в 1995 году), а чем старше язык, тем больше людей его знают и используют. На другой язык и платформу переключаться всегда сложно. Хотя, допустим, перейти с Java на Scala сравнительно просто, только это долгий процесс. В Evolution Gaming мы переводили классический Java-стэк на новый язык в течение нескольких лет.

А недостатки у Scala есть? Возможно, тот факт, что язык не очень популярен в среде разработчиков, накладывает какие-то ограничения?

Конечно, находить Java-разработчиков гораздо проще. Хотя бы потому, что их намного больше. Но если разработчик знает Scala — это своеобразный показатель того, что он развивает навыки функционального программирования, улучшает своё умение писать код и станет для нас предпочтительным кандидатом.

А так недостатков у языка два. Во-первых, чтобы писать Scala-код в стиле функционального программирования, нужно долго учиться. Возможностей много, и велик риск написать трудночитаемый код. Во-вторых, время компиляции в Scala в несколько раз медленнее, чем в Java, и это может стать проблемой при разработке больших проектов.

Scala позиционируется как язык, который объединяет в себе черты объектно-ориентированного и функционального программирования. Это действительно так?

В Scala есть возможности как объектно-ориентированного программирования, так и функционального. Но на практике вовсе не обязательно все эти возможности использовать в одном проекте. Всё зависит от задач и стиля Scala, в котором вы работаете. Вы можете использовать Scala в стиле «улучшенный Java», а можете и в стиле функционального программирования.

Реальная сила Scala — это поддержка платформы функционального программирования на базе виртуальной машины (JVM) с полным использованием Java-экосистемы. А сила Java-экосистемы в свою очередь в том, что она развивалась и проверялась в продакшне десятки лет.

Какие перспективы у Scala?

Scala — развивающийся язык, его популярность растёт. Например, скоро выйдет версия Scala 3.0, в которую будет добавлено много очень хороших фич, решающих важные проблемы. И сам язык, и его экосистема активно развиваются, появляются новые парадигмы. Так что перспективы очень хорошие.

Scala был разработан в швейцарской Федеральной политехнической школе в начале 2000-х. А кто сейчас занимается улучшением языка?

Тот, кто язык придумал, — Мартин Одерски. Он презентовал Scala 3.0 и продолжает активно работать над развитием и популяризацией языка. Кроме того, существует open-source-коммьюнити по разработке Scala, а также организации, которые работают над Scala-фреймворками: например, Typelevel Scala, Lightbend или Zio.

Вы уже несколько раз упомянули Akka-фреймворк…

Akka-фреймворк — это сочетание разных библиотек для написания распределённых сервисов (distributed services). Он включает в себя и Akka-кластер, и Akka Persistence. Мы используем Akka-кластер, например, для горизонтального скейлинга наших микросервисов и для коммуникации между ними. С помощью Akka Persistence мы храним данные о состоянии системы, используя Event Sourcing- и CQRS-подходы. Мы даже разработали свой Akka Persistence-плагин, который решает проблемы storage-ивентов.

«Код на Scala получается более качественным и с меньшим количеством багов, чем на Java»

В какой момент вы решили, что разработка в Evolution Gaming должна перейти на Scala?

В 2013 году мы начали использовать Scala в юнит-тестах. В компании были энтузиасты, которые хотели использовать наиболее эффективный и передовой способ разработки. Ведь код на Scala получается более качественным и с меньшим количеством багов, чем на Java, его проще поддерживать. Плюс Scala позволяет использовать Akka-систему естественнее, чем в случае с Java.

Scala понравилась разработчикам, и мы начали переводить свои приложения на новый язык и фреймворки: c Java и фреймворков Hazelcast, Hibernate, Spring и JSP на Scala и Akka, Akka Persistence. Разбили монолитное приложение на микросервисы, которые общаются между собой, используя Kafka. То есть изменения касались не только языка — изменялась вся экосистема. При этом интеграцию надо было провести постепенно, чтобы система не переставала успешно и безотказно работать в продакшне и обновляться.

В итоге все микросервисы, которые поддерживают наши игровые приложения, перешли с Java на Scala, и на этом языке разрабатывается бэкенд всех новых микросервисов. Ещё остались некоторые побочные системы, которые работают на Java, и одна система на Groovy, но мы и их переводим на новый язык.

Для игровой индустрии Scala — подходящий выбор?

В бэкенд-разработке — конечно. Фронтенд наших игр сделан на TypeScript, тоже типизированном языке, и React and Redux фреймворках. Scala.js используем для некоторых систем внутреннего пользования — например, системы планирования для наших сотрудников, которые ведут игры (их более 4600).

Насколько сложно найти хорошего Scala-разработчика в Беларуси и Латвии?

Понятно, что сложно найти человека с полным набором важных компетенций. Поэтому мы смотрим на желание учиться и правильное отношение к работе. Иногда удаётся найти хороших Java-разработчиков, которые могут и хотят программировать на Scala. Поиски идут довольно успешно — сейчас в Scala-чате компании более ста разработчиков.

Когда вы находите Java-разработчика, сколько времени уходит на его обучение новому языку?

Как правило, те, кто к нам приходит, уже имеют представление о Scala и его синтаксисе. У разработчиков может отсутствовать опыт работы на языке, но какие-то знания обычно есть. Многие пробуют кодить на новых языках для себя и своих проектов. Но знать синтаксис — это одно, совсем другое — знать все парадигмы и библиотеки. Поэтому обучение языку программирования — постоянный живой процесс.

По сравнению с другими языками, Scala овладеть сложнее?

Вопрос ведь не только про язык. Вопрос про парадигму, библиотеки. Начать не сложно, но чтобы стать экспертом в языке, придётся проделать очень большую работу. Скорее всего, это будет сложнее, чем овладеть Java на таком же уровне.

Имеет смысл начинающему разработчику, даже студенту, браться за изучение Scala или выгоднее овладеть более распространёнными языками?

Мы пару раз находили выпускников университетов, которым уже нравился Scala. Важным языком функционального программирования является Haskell, и в университетах его учат. Но вакансий Haskell-разработчиков меньше, и в продакшне его используют реже. Хотя язык прекрасный — Scala много позаимствовал у Haskell. Думаю, студент правильно сделает, если возьмётся за изучение Scala.

Владение не самым популярным языком программирования как-то отражается на зарплате разработчика?

Думаю, что на зарплату влияет умение писать хороший качественный код. Языки — всего лишь инструмент. Мир программного обеспечения (в масштабах планеты) расширяется, кому-то нужно обеспечивать его потребности. Поэтому нормально, что программист — очень востребованная профессия. Особенно, хороший программист. Ведь существуют задачи, которые может решить только очень хороший специалист.

Насколько сегодня Evolution Gaming испытывает потребность в Scala-разработчиках?

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

Познакомиться с компанией поближе можно 3 сентября на Open Doors Day в SPACE.

Язык программирования для разработки игр [закрыт]

Насколько мне известно, в gamedev сложилась традиция использовать C++. (Irrlicht, Ogre, Unreal Engine). (Хотя Quake Engine написан на C).

C++ это один из языков, где легко прострелить себе ногу (по большей части из-за того что он основан на Си), и чтобы писать код на нём нужно обладать большим опытом и профессионализмом. Нужно знать возможные грабли. (Отсутсвие модульной системы добавляет боли)

У меня есть подозрение, что использования C++ можно избежать. Теперь компьютеры стали быстрее.

C++ хвалят за возможность специализации (с помощью шаблонов) методов для конкретных типов данных. (Это позволяет выполнять код без лишних вызовов, хотя это и раздувает код).

Но ведь ту же специализацию можно сделать с помощью JIT. Или, например, весь быстрый код можно записывать с помощью eDSL, с компиляцией в рантайме (к примеру с помощью LLVM). Более того, этот подход может дать более быстрое выполнение чем специализированные методы C++, т.к. в рантайме доступно больше информации, и можно оптимизировать больше.

Наверняка кто-нибудь до этого уже додумался.

Собственно вопрос: Пишет ли кто-нибудь игры (или графические/игровые движки) не на C++? Какие есть проекты? Особенно интересуют проекты где необходимы быстрые вычисления.

Закрыт по причине того, что необходимо переформулировать вопрос так, чтобы можно было дать объективно верный ответ участниками Nick Volynkin ♦ , Peter Olson, aleksandr barakin, pavlofff, Regent 13 авг ’15 в 12:18 .

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

Заблокирован участником Nick Volynkin ♦ 20 мар ’17 в 5:00 .

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

Подробнее о заблокированных сообщениях здесь.

17 ответов 17

1) O’Caml или другой из ML-family. Бенчмарк, где кресты глотают пыль.

3) Object Pascal. Казуалка (с сервером на Haskell).

4) Любой другой, кроме крестов, если, разумеется, не стоит цель прострелить ногу всеми возможными способами и вдоволь насосаться леденца.

Хотя мощности и повысились, но и уровень игрушек повысился. Если вы хотите писать игры уровня 2000 года то да, можете хоть Java использовать.

Для современных же проектов лучше всё же C++ и даже ассемблерная оптимизация.

Если не хочется изучать С++ то советую посмотреть на игровой движек Unity 3D, где написание управляющего кода возможно на JavaScript, C#, Python(Boo) а вскоре обещают и ActionScript для компилирующихся во флеш проектов.

Кстати не стоит думать что вы пишете прямой исполняемый код на этих языках. Все скрипты написаные в редакторе будут скомпилированны. Например реализация JS в Unity почти в два раза быстрее оригинального.

Я бы разделил игровой проекта на отдельные крупные области и использовал в каждой из них приемлимые средства, выстраивая неких стек:

  1. Графический движок. Тут работа с нижележащими API (OpenGL, DirectX), работа с буферами памяти, шейдерами, процедурная генерация, жесткие оптимизации. Здесь C++ вне конкуренции.
  2. Игровая логика. Как правило в конечном счете это просчет взаимодействий объектов с объектами. Причем объекты вполне соответствуют объектам в традиционном ООП понимании.Действия одних объектов, могут вызывать реакции в других; объекты могут образовывать сложные иерархии. Удобно воспользоваться объектно-ориентированным языком с автоматической сборкой мусора, чтобы сосредоточиться на поведении игровой среды. Например, C#, Java, Python, Ruby.
  3. Алгоритмическая база. Различные варианты AI, работа с графами и сложными структурами данных, поиски и сортировки. Задачи, типичные для функциональных языков. F#, Scala, Lisp, Haskell, OCaml, Clojure.

Разумеется, не стоит разводить зоопарк трудносовместимых сред в одном проекте. Но некоторые комбинации могут быть вполне эффективными: C++/Java/Scala, C++/C#/F#, C++/Python

Лично я пишу с XNA Game Studio + Visual Studio Express (C# ).

  1. легко писать код
  2. много информации в интернете
  3. можно написать что-то типа такого: http://exdream.com/XnaRacingGame/
  4. и т. д.

Minecraft написан на Java. можете погуглить на эту тему

Цивилизация — движок ест-но на плюсах, а скриптование на Python

Ну а небольшие и 2D игры можно писать целиком на интерпретируемых языках, используя порты движков навроде Box2D.

На .Net вполне приличные игрушки можно делать, например есть игровой движок NeoAxis Engine ну и как писали ранее XNA, Unity 3D

Для начала надо определиться с несколькими вопросами, потому что ответить на вопрос в общей форме «На каком языке писать игру?» невозможно в принципе.

Цукерберг рекомендует:  Sql server - Подскажите пару книг по MS SQL + T-SQL

Во-первых, какую игру вы собираетесь писать? Варианты ответа:

Игру ААА-класса, чтоб убер-графика, убер-эффекты, всё реалистичное, чтоб у игрока челюсть отваливалась от одного скриншота.

Серединка-наполовинку: полу-инди с полу-убер-графикой.

Хлам для мобилок и браузеров: геймплей — ничто, монетизация — всё!

Тру-инди: из графики только пикселизованные монстрики. Вся суть — геймплей!

Во-вторых, кто вы по профессии? Варианты ответа:

Крутейший специалист по компьютерной графике, доктор по алгебре и дискретной математике, ассемблер — ваш родной язык, шейдеры пишете с закрытыми глазами.

Простой смертный программист.

Первый раз видите компьютер вживую. Про языки программирования что-то в последний раз слышали в школе.

В-третьих, кто вы по отношению к игре?

Автор, владелец, вдохновитель.

Шестерёнка в компании.

Только сейчас задумались о гейм-деве.

Теперь, когда вы держите в уме ответы на эти вопросы, можно заняться разбором вариантов.

*1* Если вы крутейший специалист, то вы не читаете этот вопрос. Пропускаем.

1*1 Если вы заправляете разработкой ААА-игр, то вы тоже не читаете этот вопрос.

**2 Если вы работаете на кого-то, то выбора у вас нет. Ха-ха-ха.

1** Если вы хотите заниматься разработкой игр AAA-класса, то есть некоторый выбор.

13* Если вы простой смертный, решивший приобщиться к разработке самых дорогих игр, то выбора особо нет.

На данный момент практически все игры ААА-класса пишутся на C++, как самом подходящем для этой цели: практически все существующие, актуальные и передовые средства разработки (библиотеки, программы, инструменты) поддерживают C++; это один из немногих языков, который позволяет опускаться так низко к железу, насколько надо (ближе только C); на C++ написано огромное количество кода во многих компаниях, у него огромное наследие — пожалуй, самое огромное из всех языков на данный момент.

Для мелких фиговин, типа скриптов для управления интерфейсом, могут использоваться другие языки — менее шустрые, но которые легко обновлять и писать: Lua и прочие. Обычно они составляют не самую большую часть логики.

Или вы уже разрабатываете, или только собираетесь — выбора у вас нет, C++ надо изучать, если хотите заниматься разработкой всерьёз, а не клепать скриптики.

Есть, конечно, вероятность, что через некоторое время будет создан «убийца плюсов», но пока дела на этом фронте продвигаются неважно. Если вдруг продвинутся, то вы будете об этом знать — всё-таки событие мирового масштаба.

22* Если ваша игра обойдётся без самой совершенной графики, и вы умеете программировать, то у вас уже есть выбор.

Чем меньше у вас сложной логики, тем свободнее выбор языка. Если у вас тьма тьмущая сложных алгоритмов, например, в вашей игре моделируются какие-то сложные процессы, то эти алгоритмы придётся писать на C++. Как вариант, можно посмотреть в сторону функциональных языков, но это на любителя: чем больше языков в программе, тем больше сложностей, особенно когда в команде вы не один.

Если нагрузка на CPU ограничена, то вы можете воспользоваться тем фактом, что CPU — отдельно, GPU — отдельно. Если вы даже из самого медленного языка отправите на отрисовку пучок графических операций, то они отработают быстро, потому что они будут выполняться отдельно от вашего тормозного кода. Сейчас, когда компьютеры стали достаточно быстрыми, часто ресурсов хватает на все дополнительные тормоза, которые возникают из-за управляемого кода (C#, Java и т.д.).

Отдельно надо упомянуть сборку мусора: чем сложнее логика, чем вы придирчевее к частоте кадров, тем менее доступным становится это удобство. Если логика разрастётся, то с большой вероятностью может оказаться, что от сборки мусора вообще придётся отказаться и повсеместно использовать пулы и прочие подобные средства. Дело в том, что сборка мусора, какой бы быстрой она ни была, на данный момент слишком медленная, чтобы не приводить к пропущенным кадрам. Мусор, генерируемый со скорость 60 кадров в секунду, разрастается слишком быстро.

23* Если вы ничего толком не умеете, то писать сложные игры в качестве первой попытки не стоит. Начните с чего-нибудь попроще.

42* Если графика у вас относительно простая, а сложных ресурсоёмких алгоритмов нет, то ваш выбор становится очень широк.

Вы можете писать абсолютно на чём угодно! Игру можно писать на любом интерпретируемом языке, который на порядки медленнее оптимизированого кода на C++. Какая разница, если игрок не заметит?

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

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

43* Если вы не умеете программировать, то вы на распутье: вам или надо научиться программировать, или воспользоваться более простыми средствами разработки игр.

Пугаться программирования не надо. Кто знает, может, у вас скрытый талант? Есть истории успеха, когда художник, впервые увидивший код, пишет успешную игру практически в одиночку и выигрывает кучу призов.

Но есть и путь проще: движки для игр, предназначенные для непрограммистов. Там вы будете рисовать нужное вам, расставлять свойства, копировать скриптики и смотреть, как оно всё шевелится. Но чем сложнее игра, тем больше нужно кода. Подобные движки часто сильно ограничивают свободу творчества, поэтому выбирайте сами, в каком направлении лучше двигаться.

3** И напоследок: если вы пишете для мобилок и браузеров, то вы имеете уникальную возможность настолько же быстро упираться в аппаратные ограничения, как и игры ААА-класса (которые для мобилок существуют с точки зрения денег, но не с точки зрения результата, но это так, лирическое отступление).

Здесь ваш выбор будет сильно ограничен платформой (или платформами). Для одной платформы «родной» один язык, для другой — другой. Выбор, на чём писать кросс-платформенные игры, невелик. Писать код на управляемых языках придётся немного по-другому, уделяя пристальное внимание сборке мусора. Здесь вы будете убиваться об стенку, чтобы ваша игра нормально работала на всех устройствах.

Так как ни одна платформа не доминирует, то сразу смотрите в сторону кросс-платформенных движков и библиотек. Псевдо-ААА тоже сплошником на нём пишется, и это никого не смущает. Так как разнообразие невелико, то в трёх соснах не заблудитесь.

Разработка игр

При создании качественной игры нужно учитывать множество факторов. Эта статья сориентирует Вас, каким образом этого достичь.

Как правило, цель разработки игры — получить высокую оценку (предпочтительно 9.5+). Однако, в ходе разработки ваши действия не влияют напрямую на эту оценку, больше на ваш игровой счет. Игровой счет (скрытое значение, которое вы не увидите. Не путайте его с т.н. игровыми отзывами) состоит из суммы Дизайна и Технологий, деленной на модификатор размера игры (это компенсирует тот факт, что бОльшая игра дольше разрабатывается и накапливает больше очков) и умноженной на несколько модификаторов качества. Все эти модификаторы, как правило, лежат в пределах от 0,6 до 1. Таким образом, снижение хотя бы одного фактора уменьшает суммарный игровой счет очень значительно. Игровой счет не влияет на игровую оценку напрямую, а сравнивается с предыдущим игровым счетом для расчета игровой оценки (подробности в следующем параграфе).

Вы можете повлиять на сумму очков Дизайна и Технологий вне разработки игр, исследуя новые сферы (позволяет вашим сотрудникам набрать больше очков, ведя разработки в области этих возможностей) и обучая сотрудников, либо нанимая новых (это увеличит вклад в общее дело), в то время как в процессе разработки игры вы можете повлиять на все модификаторы качества.

Хорошее качество ≠ Хороший обзор!

Во-первых, нужно понимать, что качественно сделанная игра не гарантирует хороший обзор (review score — она же таблица с обзорами изданий).

В этой игре вы соперничаете исключительно с собой, т.е. со своими предыдущими рекордами (за исключением самого начала игры, пока вы конкурируете с пресетами игры (базовые рекорды игры)). Ваш игровой счет сравнивается с вашим лучшим игровым счетом ( с учетом прироста около 10%-20%), и это ваш итоговый обзор игры (она же «review score») (прежде чем оценка обзора немного изменится случайным образом). Поэтому, для того чтобы получить хороший обзор, вам нужно немного повысить свой предыдущий игровой счет.

Это ОЧЕНЬ ВАЖНО понять:

Чтобы получить хорошие обзоры ЕДИНОЖДЫ, вам достаточно просто продолжать играть и, вне зависимости от ваших действий, вы когда-нибудь получите рейтинг игры 9.5+.

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

Зачем вам тогда заботиться о создании высококачественных игр? Затем, что проще сделать высококачественную игру (с максимальными проверками качества), чем делать игры не высшего качества одинаковой паршивости (из-за сравнения последующей игры с предыдущей, делать то хуже то лучше, не лучшее решение, — прим. ред.)

Например, для того, чтобы получить игру лучшего качества на основе работы с ползунками, вам нельзя ставить менее чем на 20% во время разработки (

3-6 за жанр), никогда не поднимать выше 20% (0-3 в жанре), и по крайней мере два раза применять более 40% (

Однако для того, чтобы сделать игру худшего качества, нужно сделать все наоборот, выставить менее 20% к определенным темам (

3-6 за жанр), более 20% к определенным темам (

0-3 в жанре). Поэтому если вы стремитесь к лучшему качеству, у вас есть 60% свободы (значение ползунка 60% от 100%, остальные нет) в 2 ползунках, 80% в

1-4 ползунках, 20% в

0-3 ползунка и 100% свободы в оставшихся

0-6 ползунках, а если вы стремитесь к худшему качеству, у вас есть 20% свободы в

3-6 ползунках, 80% в

0-3 ползунках и 100% свободы в оставшихся 0-6 ползунках. Таким образом, у вас есть 500%-800% (из общих 900%) свободы в первом случае и 360%-660% во втором случае. Поэтому, если вы придерживаетесь правил «лучшего качества», у вас больше творческой свободы, чем если вы будете придерживаться правил «худшего качества».

Для тех, кто ничего не понял из двух абзацев выше, поясню. У каждой игры есть три этапа разработки, где вы двигаете ползунки вверх/вниз. На каждом из этапов ВАЖНО выставлять ползунки в правильном процентном соотношении, т.к. это будущий модификатор получения ХОРОШЕГО ОБЗОРА. Так вот, например Экшен (Action) имеет приоритет во времени разработки у таких параметров как Движок и Геймплей (причем движок — самый важный из них). Параметр История/Квесты тут имеет «отрицательный» модификатор. Таким образом время, уделяемое Движку и Геймплею, ставится высокое (100 процентов на Движок, имеющий модификатор 1, и 80% Геймплею, т.к. он имеет модификатор 0.9), и 0% выставляем Истории/Квестам (т.к. модификатор 0.7). И видим снизу на прогресс баре, что у нас более 40% времени тратится на движок и геймплей, и менее 20% на Историю/Квесты — это именно то, о чем говорится в абзацах выше: «Плохим» модификатором мало времени на разработку, а «хорошим» (с коэффициентом >= 0.9) более 40% (именно по прогресс бару, а не по ползункам).

Еще более радикальные правила в комбинации жанр/тема. Есть Великие Комбинации (great combos) (у которых модификатор качества равен единице), а есть Странные Комбо (strange combos) (с ущербом для качества минимальным модификатором, равным 0,6). Поэтому, если вам нужно получить странное комбо, вы будете очень ограничены в том, какие жанр/тему вам стоит выбрать (не говоря уже о создании многожанровых игр). Тем не менее, если вы сосредоточены на создании Великих Комбинаций, у вас больше свободы.

Например, Подземелье (Dungeon), Самолет (Airplane), Фэнтези (Fantasy) и многие другие темы могут создать не только одно худшее Странное Комбо (смотрим таблицу с + и -, там только 2 минуса), но и 4 Великих Комбо (4 плюса). В общем, есть очень много тем, которые дают больше Странных Комбо чем Великих Комбо (Game Dev (разработка игр), Superheroes (Супергерои) с тремя Странными против одной Великой, Романтика, Стартапы, Больница и Хирургия со счетом 2 к 1), тогда как большинство из них дают больше Великих, чем Странных комбо.

Таким образом, эта страница не поможет вам в разработке игры, которая получит хороший игровой обзор (та самая страница с четырьмя цифрами от игровых журналов/изданий). Она расскажет вам, как сделать игры лучшего качества, что в свою очередь поможет получить хорошие обзоры. Если вы разрабатываете игры стабильного качества (Великие Комбо, баланс технологий/дизайна, отсутствие багов), ваш игровой счет будет основан почти полностью на сумме очков Дизайна/Технологий, очки которых вы видите в процессе разработки (оранжевые и синие шарики сверху), и, таким образом, вам будет легче судить насколько вы хорошо поработали (до того как вы увидите обзор).

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

Ошибки

Прежде всего избегайте следующих вещей:

О модификаторах

Это незавершенная статья
Она содержит неполную информацию
Вы можете помочь Game Dev Tycoon вики, дополнив её.
  • Разработка двух игр подряд с точно такой же темой/жанром/вторым жанром.
  • Разработка сиквела или аддона (расширения) менее чем через 40 недель после выхода предыдущей версии.
  • Разработка сиквела на том же движке (не относится к аддонам).
  • Разработка большой игры без использования 2D графики V4 (версия 4) или выше/3D графики V3 (версии 3) или выше.
  • Разработка ААА игры без использования 3D-графики V5 или выше
  • Разработка ААА игры без назначения как минимум трех специалистов соответствующих областей, которые считаются важными для жанра.

Как указано выше, качество игры рассчитывается как комбинация различных модификаторов, каждый из которых применяется в качестве множителя к сумме Дизайна и Технологий. Если оставить в стороне те, о которых сказано выше, то остаются следующие модификаторы, которые влияют на качество ваших игр:

  • Технология/Дизайн
  • Смещение ползунков (процент времени)
  • Комбинации жанра/Темы игры
  • Тенденции (тренд)
  • Ошибки (Баги)

Таким образом, чтобы гарантированно создать игру высокого качества (кроме тренда, который является в какой-то степени случайным модификатором), во время разработки вы должны:

  • Получить правильный окончательный баланс очков между Дизайном и Технологиями
  • Выбрать Великую Комбинацию (great combo) жанра и темы
  • Выбрать платформу, которая соответствует вашему жанру (или обоим жанрам в случае многожанровой игры)
  • Выявить и убрать ошибки (баги).

Процесс создания игры можно разделить на две основные части: подготовка к производству и разработка.

Подготовка к производству.

Во время подготовки к производству, когда решаются главные вопросы по игре, доступны следующие параметры:

  • Название игры
  • Размер. Он влияет на количество времени, потраченное на разработку, и на его стоимость. Малым играм тяжело набрать средние 10 баллов.
  • Целевая аудитория
  • Тема. Общая тема игры (Военные, Фэнтези, Научная фантастика и т.д.)
  • Жанр
  • Платформа.
  • Игровой движок.

Выбор жанра является наиболее важным в процессе подготовки. Жанр влияет на большинство решений, которые будут приняты в процессе разработки.

Комбинации Темы / Жанра

Важной частью подготовки к производству является выбор темы и жанра. Их сочетание может привести либо к Великой Комбинации (Great Combo), либо к Странной Комбинации (Strange Combo).

Одножанровые комбинации

Эта таблица основана на исходных данных игры.
Тематика Экшен Приключения РПГ Симулятор Стратегия Казуальные Возраст
Авиация + + + + 0+/6+/18+
Альтернативная история + + 6+/18+
Бизнес + + 6+/18+
Боевые искусства + + + + 0+/6+/18+
Больница + 6+/18+
Вампиры + + 6+/18+
Виртуальный питомец + + 0+
Военное + + + 6+/18+
Гонки + + 0+/6+/18+
Город + + 0+/6+/18+
Детектив + + 0+/6+/18+
Дикий Запад + 6+/18+
Жизнь + + 0+/6+/18+
Закон + 6+
История + + 6+/18+
Киберпанк + + 6+/18+
Комедия + + 0+/6+/18+
Космос + + + 0+/6+/18+
Мода + + + 0+/6+/18+
Музыка + + + 0+/6+/18+
Научная фантастика + + + + + 0+/6+/18+
Ниндзя + 0+/6+/18+
НЛО + + 0+/6+/18+
Оборотни + + 6+/18+
Охота + + 0+/6+/18+
Пираты + 0+/6+/18+
Подземелья + + + + 6+/18+
Постапокалипсис + + 6+/18+
Тематика Экшен Приключения РПГ Симулятор Стратегия Казуальные Возраст
Правительство + + 6+/18+
Путешествия во времени + + 0+/6+/18+
Разработка игр + 6+
Ритм + + + 0+/6+/18+
Романтика + 6+/18+
Словари + + + 6+
Спорт + + + 0+/6+/18+
Средневековье + + + + 0+/6+/18+
Стартапы + 6+/18+
Супергерои + + 0+/6+/18+
Тайна + + 0+/6+/18+
Танцы + + 6+/18+
Транспорт + + 0+/6+/18+
Тюрьма + + + 6+/18+
Фильмы + + 0+/6+/18+
Фэнтези + + + + 0+/6+/18+
Хакинг + + 6+/18+
Хирургия + 6+/18+
Хоррор + 6+/18+
Чужие + + 6+/18+
Школа + + + + 0+/6+/18+
Шпионаж + + + 0+/6+/18+
Эволюция + + 0+/6+
Тематика Экшен Приключения РПГ Симулятор Стратегия Казуальные Возраст

Многожанровая комбинация

Единственный способ получить Великую Комбинацию (Great Combo) для многожанровых игр заключается в использовании двух жанров, каждый из которых в соответствии с темой получит «Великую Комбинацию». Это значит, что такая тема как Хирургия (Surgery) не может получить «Великую комбинацию» на разножанровых играх (см. таблицу выше, у хирургии только одна комбинация великого комбо).

Комбинация Жанра / Платформы

Каждый жанр имеет свою популярность на каждой платформе. Ваш выбор жанра по отношению к платформе слабо влияет на игровые отзывы. Он больше влияет на продажи игры. Чем выше модификатор продажи выбранной платформы, тем больше вы заработаете.

(+++) — Отлично подходит,(++) — Хорошо подходит, (+) — Нормально подходит, (-) — Не очень подходит, (—) — Плохо подходит, (—) — Ужасно плохо подходит.

Платформа Экшен Приключения РПГ Симулятор Стратегия Казуальные
PC ++ +++ ++ +++ +++
Govodore 64 (G64) ++ ++ + ++ + +
TES +
Master V +
Gameling + ++ +
Vena Gear + ++
Vena Oasis + ++
Super TES +
Playsystem + ++
TES 64 +
DreamVast + ++
Playsystem 2 + ++ +
mBox ++ +
Game Sphere +
GS + ++ ++ ++
PPS + ++
mBox 360 + + ++
Nuu + +
Playsystem 3 + +
grPhone + ++ ++ ++
grPad + ++ ++ ++
mPad ++ + ++
Wuu ++ +
mBox Next(mBox One с 1.4.3) ++ + ++
Playsystem 4 + +
Своя консоль ++ + ++
Платформа Экшен Приключения РПГ Симулятор Стратегия Аркада

Комбинации платформы и целевой аудитории.

Вы будете время от времени получать сообщения о соответствии/несоответствии целевой аудитории и выбранной платформы. Ваш выбор аудитории имеет незначительное влияние на Игровые Отзывы. В первую очередь он влияет на количество продаж вашей игры. Чем выше модификатор продаж данной платформы, тем больше вы заработаете с этой аудитории.

Основано на исходных данных игры.

— Избегайте таких комбинаций

Платформа Юные 0+ Все 6+ Взрослые 18+
PC + ++ +++
Govodore 64 (G64) + ++ +
TES +
Master V +
Gameling +
Vena Gear +
Vena Oasis +
Super TES +
PlaySystem +
TES 64 +
DreamVast +
PlaySystem 2 +
mBox +
Game Sphere +
GS +
PPS +
mBox 360 + ++ ++
Nuu +
PlaySystem 3 + ++ ++
grPhone +
grPad +
mPad + +
Wuu +
mBox Next(mBox One) + ++ ++
PlaySystem 4 + ++ ++
Своя консоль + ++ ++
Платформа Юные 0+ Все 6+ Взрослые 18+

Этап разработки.

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

Смещение ползунков имеет два основных последствия:

  • Выделение отведенного времени влияет на качество игры
  • Количество очков Дизайна и Технологий добавляется в игру в процессе разработки пропорционально времени, отведенному на соответствующую часть (например, выделяя больше времени на Движок, вы получите больше очков Технологий, а время, отведенное на Историю/Квесты, даст больше очков Дизайна).

Качество игры и правильный баланс Технологий/Дизайна (точное значение, к которому вы должны стремиться, основано на выбранном жанре) очень важны во время подсчета рейтинга. Итак, подведем итоги — как выставлять ползунки:

  • Посмотрите на таблицу ниже и обратите внимание на соотношение задач и полей с плюсами/минусами для вашего жанра (или комбинаций).
  • Убедитесь, что вы выставили ползунок выше 40% от отведенного времени на поля с плюсами по крайней мере дважды в течение всего процесса разработки.
  • Убедитесь, что выделили не меньше 20% полям с плюсами и не более 40% полям с минусами.
  • Соответственно, выставьте ползунки так, чтобы уложиться в рамки 25-процентного соотношения Технологии/Дизайна в соответствии с целями вашего жанра (или комбо).
  • Помните, что нижняя панель состоит из трех частей (размещена под ползунками), и что важно не то, сколько процентов вы назначите каждому ползунку. Все эти значения (40% и 20%) относятся к приблизительным размерам части поля на нижней панели.

Основано на исходных данных игры.

Жанр (Соотношение Т/Д) Этап 1 Этап 2 Этап 3
Движок Геймплей Сюжет/Квесты Диалоги Дизайн уровней ИИ Дизайн мира Графика Звук
Экшен (1.8) + + + + + +
Приключения (0.4) + + + +
РПГ (0.6) + + + + + +
Симулятор (1.6) + + + + + +
Стратегия (1.6) + + + + + +
Казуальные (0.5) + + + +

Для многожанровых комбо значения рассчитаны с учетом того, что первый выбранный жанр в два раза менее важен, чем второй.

Жанр Комбо (Соотношение Т/Д)

Экшен/ Стратегия (1,73)

Приключения/ Экшен (0,68)

Этап 1 Этап 2 Этап 3
Движок Геймплей Сюжет/Квесты Диалоги Дизайн уровней ИИ Дизайн мира Графика Звук
Экшен/ Приключения (1,10) + + +
+ (чёрная) + + +
Экшен/ Симулятор (1,73) + + + + + +
+ + + + + +
Экшен/ Казуальные (1,24) + + + +
+ + +
Приключения/ РПГ (0,46) + + + +
Приключения/ Симулятор (0,65) + + + +
Приключения/ Стратегия (0,65) + + + +
Приключения/ Аркада (0,46) + + + +
+ + + + +
РПГ/ Приключения (0,53) + + + +
РПГ/ Симулятор (0,84) + + + + + +
РПГ/ Стратегия (0,84) + + + + + +
+ + + + + +
Симулятор/ Экшен (1,66) + + + + + +
Симулятор/ Приключения (1,02) + + +
Симулятор/ РПГ (1,15) + + + +
Симулятор/ Стратегия (1,60) + + + + + +
Симулятор/ Аркада (1,15) + + + +
Стратегия/ Экшен (1,66) + + + + + +
Стратегия/ Приключения (1,02) + + +
Стратегия/ РПГ (1,15) + + +
Стратегия/ Симулятор (1,60) + + + + + +
Стратегия/ Аркада (1,15) + + + +
Аркада/ Экшен (0,87) + + + +
Аркада/ Приключения (0,53) + + +
+ + +
Аркада/ Симулятор (0,84) + + + +
Аркада/ Стратегия (0,84) + + + +

Основной момент многожанровости состоит в устранении жанровых требований, — это дает вам большую гибкость в использовании различных возможностей. Например, жанры Стратегия/Приключения и Стратегия/РПГ имеют только 3 поля с «+», а остальные не имеют значения, — следовательно, если вы будете делать Стратегию или РПГ (как одножанровую игру), у вас будет 6 полей с «+» и одно поле для беспокойства с «-«. Поэтому многожанровость дает вам больше творческой свободы, когда вы объединяете жанры должным образом. Лучше всего оставить её для больших и ААА игр, так как на более низких уровнях свобода не дает больших возможностей.

Разработка для чайников

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

Прочтите это, прежде чем пользоваться таблицей, приведённой ниже.

Ползунки не являются основным способом получить хорошие оценки, — они представляют собой сочетание многих факторов. Некоторые из них учитывают предыдущие отзывы, ваш персонал, нынешний год, жанр на платформу и т. д., и основной из них — ваш коэффициент Технологии/Дизайна. Я не утверждаю, что таблица бесполезна, но если вы будете следовать этой таблице и ваши очки Технологии/Дизайна будут недотягивать до желаемых значений, то вы то и дело будете получать ужасные отзывы, поскольку качество ваших игр будет нестабильно — иногда вы будете попадать в точку с этой таблицей, иногда будете далеко от высокого качества, ибо нестабильность ведет к плохим отзывам. Так что, пожалуйста, изучите остальные страницы и читайте их во время игры, или просто получайте удовольствие и делайте игры такими, какими вы бы хотели их видеть.Таблица выше со способом «+» и «-» является лучшим справочным материалом если вы понимаете, что делаете. Допустим, у вашего персонажа 300 очков Технологии, 300 Дизайна, 300 Скорости и 300 Исследований. Ваш 2-ой работник имеет 500 очков Технологии, 100 Дизайна, 150 Скорости и 200 Исследований. 3ий работник имеет 400 очков Технологии, 200 Дизайна, Скорость 200 и 100 очков Исследований. Ваш коэффициент Технологии/Дизайна не будет работать. Ваши технологии будут достаточно высоки для игр большинства жанров. Игры жанров РПГ, Приключения и т.д. будут выходить в плохом качестве (из-за плохого соотношения Технологии/Дизайна), в то время как Симуляторы, Стратегии будут обладать хорошим качеством (из-за хорошего баланса в их сторону). Если ваши сотрудники будут иметь очков дизайна больше чем технологий, то будет наоборот. Поэтому если вы будете следовать приведенной ниже таблице, у вас будут получаться качественные игры того или иного жанра, но некачественные другого, что означает, что вы будете получать плохие отзывы и непостоянство игрового счета. Вы никогда не получите стабильно хорошее качество игр с этой таблицей после своего первого гаража/офиса. У вас есть два варианта, получать удовольствие и наслаждаться игрой в таком виде, в каком её сделали Greenheart (прим. ред. — разработчики), или же проверять оптимальное соотношение Технологии / Дизайна на странице исходных данных игры, проверять Алгоритм Отзывов, использовать таблицы с «+» и «-«, использовать хорошие комбинации (Good Combos), всегда следить за правильной аудиторией и убедиться, что коэффициент Технологии/Дизайна правилен, разделив между этапами разработки ваших работников.

Этап 2 Этап 3 Движок Геймплей Сюжет/Квесты Диалоги Дизайн уровней ИИ Дизайн мира Графика Звук Экшен 100 80 80 100 100 80 Приключения 80 75 100

100 25 100 80 25 РПГ 25 80 100 100 80 100 80 25 Симулятор 100 100 25 100 100 50 100 80 Стратегия 80 100 100 80 100 80 Аркада 100 100 100 80

Будьте осторожны — в то время как это БУДЕТ работать в НАЧАЛЕ игры, пока у вас один сотрудник и мало возможностей, в конце игры, когда у вас будет несколько сотрудников и множество возможностей, эта таблица не даст вам максимального качества производимых игр, — она лишь будет приблизительным ориентиром.

Специализация обучения

Специализация на конкретном ползунке требует от вас удовлетворения требований уровней технологии и дизайна. Можно также обучить отдельного специалиста на каждый из ползунков. Отличным играм требуются сотрудники, сосредоточенные на дизайне или технологии, или сбалансированные и на том, и на другом. Оставьте ваших универсальных сотрудников для конечной фазы разработки. Специализация стоит 200 очков Исследования (research point) и 5 миллионов кредитов за одного специалиста.

GameDev — какой язык выбрать,

Сейчас активно занимаюсь разработкой игр, но в силу дизайнероско-программистского диплома, знаю и использую пока в основном (ногами не бить) ActionScript 3.0. И даже вроде бы неплохо. Там есть и Unit-тесты, и легко использовать паттерны, есть отличный FD и т.д. Так что не такая уж и мракобесия.
Но тормозит, естественно, при больших задачах.
А я сейчас как раз плавно ухожу в область разработки десктопных вещей.
Внимание, вопрос:
какой язык выбрать для изучения в данной области применения? C? Python? А ведь хотелось бы еще и сохранить возможность визуального редактирования элементов, но это, судя по всему, мечты.
/* Точно, абсолютно точно, не Java. Просто нет. Знаю, что синтаксис похожий. Но нет */
Помогите пожалуйста выбрать или хотя бы осознать, что что дает.
Еще было бы здорово, если б можно было оптимизировать работу приложений, и при этом, чтобы код оставался читабельным. Но это уже лирика.

Очевидно, что для десктопа нужно брать C#. Либо C++, но только если есть для этого веские причины. И никак иначе.

Для флеша же куда удобнее haXe, чем ActionScript.

afaik все игрушки пишуться на сиплюсплюс.

советую начать с википедии

Я вот тут писал простенькую игрушку на C#. Сорцы и скрины прилагаются.

> Для флеша же куда удобнее haXe, чем ActionScript А что, прям быстрее бегает? Когда-то стукнуло в голову почитать, посмотреть, но до проекта дело не дошло — как-то AS3 был роднее, а необходимость применения HaXe непонятной.

Но если и правда быстрее обработка пойдет, то было бы просто прекрасно. А то у меня TaskManager от 10 зомби еще не надрывается, а вот с 4мя, но с A*, уже все — пошаговая стратегия, вместо шутера. (Хотя, тут A* и правда избыточен, но пример прям под руку попался)

Там перенос строки, конечно же. Прошу прощения

Но если и правда быстрее обработка пойдет, то было бы просто прекрасно.

Я не знаю. Но люди говорят.

Кстати, вот в этой теме я на haXe выкладывал сорцы софтверного 3D рендерера. Вроде на ActionScript это делать проблемнее ввиду того, что в нём нет дефолтных либ для полноценной быстрой работы с памятью.

Впрочем, во флеше я нуб, потому могу быть неправ.

Есть же Super Tux, зачем оно, да ещё на шарпе

область разработки десктопных вещей

C в обязательном порядке. Плюсов добавить по вкусу. Когда плюсы окончательно осточертеют — Lua. Для разнообразия потом можно посмотреть Guile. Главное, не наступить по дороге в Python, TCL или что-то подобное. Это всё хорошо, но не для геймдева.

хотелось бы еще и сохранить возможность визуального редактирования элементов, но это, судя по всему, мечты..

Никакие не мечты — данные можно редактировать визуально сколько хочешь. Вот поведение уже надо программировать.

Есть же Super Tux, зачем оно, да ещё на шарпе

Мне просто интересно было попробывать это сделать. Картинки я натырил из Super Tux’а. Сделал. Выложил. Хотите — пользуйтесь, не хотите — проходите мимо. До играбельного состояния не доработал, потому что стало неинтересно.

Впрочем, во флеше я нуб, потому могу быть неправ.

Кстати, недавно допилили одну игрушку match-3 — NatureBubbles. Я программил, жена рисовала и ещё один парень музыку наколбасил. :)

Изучать тему лучше по C++ или, на худой конец, C#, потому что документация и семплы в основном на них, но вот когда уже войдешь в тему, то для реальных проектов лучше брать нормальные языки — и я бы тут посоветовал CL(ну хотя даже тот же C# в принципе не так уж и плох). С++ это легаси, его для новых проектов даже в геймдеве использовать смысла нет вообще никакого, не ведись на форумных аналитиков(от слова «анал») на всяких gamedev.ru и прочих.

Кстати, Си смысла использовать тоже нет.

Равно как и Python и прочую скриптоту(как C#, так и CL, посоветованные мной выше — намного гибче и удобнее в использовании, чем любая скриптота, ну а уж про скорость работы программ, на них написанных, я даже и не говорю)

C++ вкупе с Qt. У Qt хорошая документация, детальные примеры и туториал. Уровень входа низкий, а продукт качественный.

к этому хорошие(интересные лично тебе) книги по С++ и ООП.

> С++ это легаси, его для новых проектов даже в геймдеве использовать смысла нет

форумный аналитик(от слова «анал») рассказывает какие современные игроделы непонятливые, выпускают Fallout 3, Rage, Skyrim и пр. и пр. на С++ ( что легко можно увидеть по бинарникам, даже отладочная информация зачастую есть ), а вот он, нихрена не написавший, понял жизнь и советует всем, что надо делать ^_^

>Когда плюсы окончательно осточертеют — Lua.

выпускают Fallout 3, Rage, Skyrim и пр. и пр. на С++ ( что легко можно увидеть по бинарникам, даже отладочная информация зачастую есть )

это по причине инертности индустрии, не более
ладно хрен с ним с лиспом, но вот C# уже сто лет как может в геймдеве на десктопах заменить C++ полностью и окончательно.

C# + XNA
Я серьезно.

Казуальщину небось на нем уже давно пишут.

Python используют для игр достаточно часто. Обычно движок на C++, логика верхнего уровня на пистоне.

Библиотек для него много, можно начинать писать чисто на нем, потом тормозящие части переписывать на плюсах.

С++ + Qt
или
C++ + SDL
или
C# + XNA

Первые 2 варианта — православные. Третий, наверное, если верить мелкомягким, с низким уровнем вхождения, но без намеков на кроссплатформенность и переносимость.

C++ отраслевой стандарт. Когда игры пишут на C# получаются опять же тормоза, новый Ил-Штурмовик как ярчайший пример. Python в геймдеве тоже не нужен.

> C# уже сто лет как может в геймдеве на десктопах заменить C++ полностью и окончательно.

Уже сто лет как никто не геморроиться только ради десктопов. А как обстоят дела с C# для XBox 360/PS3/Wii ты знаешь и без меня.

Battlefield 2:
. Some of the lower scores were reactions to the large amount of bugs and glitches in the initial release, including crash to desktop bugs and network problems.

The Temple of Elemental Evil:
. The release was criticized for stability issues and other bugs.

Civilization IV:
The version of Python present in the Windows version of the game differs from the version in Mac OS X up to and including version 10.4.7, and as a result, while most Python files for the Windows version will work on the Macintosh version, not all will. The reverse is also true.

Eve Online:
Both the server and the client software for Eve Online are developed in Stackless Python, a variant of the Python programming language. Stackless Python allows a relatively large number of players to perform tasks without the overhead of using the call stack used in the standard Python distribution. This frees the game developers from performing some routine work and allows them to apply changes to the game universe without resetting the server. However, the Eve cluster is taken offline daily for database and server maintenance.

Какие языки выбрать для локализации игры

Итак, вы решили, что локализация – это отличная идея, позволяющая привлечь больше игроков и повысить продажи. Но какие именно языки она должна включать? И в каком порядке? Есть ряд факторов, которые определяют эти решения.

Ваш вопрос «Какова будет окупаемость локализации на язык X?» должен делиться на два вопроса:

  • Во сколько обойдётся локализация на язык X?
  • Ждёт ли игру успех/хорошие продажи среди игроков, говорящих на языке X?

Сколько стоит локализация?

Если вы прежде не сталкивались с локализацией, понять её стоимость будет непросто. Поговорив с поставщиками услуги или порывшись в интернете, вы наткнётесь на самые разные цифры. Почему так? Всё дело просто в чьей-то излишней жадности? Это может быть одной из причин, но давайте посмотрим, что формирует итоговый ценник. Во-первых, локализация, это не что-то конкретное. Проще говоря, это перевод текста плюс «всё остальное».

Что такое «перевод»?

Ну вот, всё не совсем ясно уже с самого начала, но перевод – это тоже не что-то конкретное! Есть бесплатные варианты, тот же Google Translate (не рекомендуется) или фанатский/краудсорсинговый перевод (если фанатская база позволяет). Можно нанять независимых переводчиков или же работать с агентством. Агентства, кстати, могут подразумевать разные услуги под словом «перевод», и не всегда чётко ясно, за что именно вы платите. Самые распространённые варианты могут включать:

  • Только перевод: текст переводится одним человеком и на этом всё;
  • Перевод с вычиткой: текст проверяется другим человеком, который не знает языка оригинала;
  • Перевод с редактурой: проверяющий тоже является переводчиком и сверяет текст с оригиналом;
  • Автоматизированная проверка качества: большинство агентств используют машинную проверку на двойные пробелы, правильность пунктуации и т.п.;
  • может добавляться или не добавляться к вышеперечисленному.

Выбранный вариант влияет на цену и на результат, так что, прицениваясь к разным поставщикам услуги, убедитесь, что сравниваете сопоставимые вещи.

Другой важный фактор – целевой язык. Ниже представлены сравнительные расценки по переводу на разные языки. График основан на ценах компании Andovar, но в целом разница в стоимости языков остаётся таковой у всех.

Как видите, перевод на один язык может обойтись вчетверо дороже, чем на другой. Почему? Это свободный рынок, и цены определяются спросом и предложением, а также запросами переводчиков. Для некоторых языков (или языковых пар, если точнее) есть много квалифицированных переводчиков, конкуренция между которыми сбивает цену. Для других же профессионалов, знакомых с игровой тематикой, найти непросто, и просят они втридорога. Вдобавок, на некоторых языках говорят в странах с высоким уровнем жизни, так что переводчики просто вынуждены требовать больше.

Так, с «переводом» разобрались, переходим ко «всему остальному».

Что такое «всё остальное»?

Если бы локализация заканчивалась на переводе текста, жизнь была бы простой и непринуждённой, а половина переводческих агентств по всему миру обанкротились. Но на самом деле, есть и другие задачи, которые могут включать:

Что представляет из себя локализация?

  • Анализ исходных файлов
  • Стилизация руководства
  • Глоссарий
  • Освоение игры
  • Память переводов
  • Дистрибуция
  • Лингвистическая проверка
  • Функциональная проверка
  • Обеспечение поддержки языка
  • Ограничение длины символов
  • Локальный маркетинг
  • Адаптация изображений
  • Перезапись звуков
  • Инжиниринг локализации
  • Интернационализация
  • Адаптация к локальным законам
  • Подготовка региональных серверов
  • Добавление субтитров
  • Инструментарий локализации

Этого «всего остального» оказывается, немало! Каждый термин заслуживает отдельной статьи, и здесь мы их разобрать не сможем. Достаточно сказать, что перевод, это не всё, что входит в стоимость локализации. Если вы не уверены, что из перечисленного необходимо вашему проекту, обсудите вопрос с поставщиком услуги. Если он пытается убедить вас, что достаточно только перевода текста, пожалуй, стоит поискать других людей.

Локальный маркетинг может обойтись дороже, чем сама локализация. Вот, что полезно знать:

  • Поисковые движки: Google не везде занимает передовые позиции. В Китае лидирует Baidu, в России Yandex, а в Южной Корее Naver.
  • Маркетинг – В разных странах работают разные стратегии. Например, в Тайване очень важна реклама игр по телевидению.
  • Магазины приложений – Во Вьетнаме и Китае Google Play занимает очень малую долю рынка, там популярнее местные альтернативы.
  • Социальные медиа – Во многих странах доминирует Facebook, но в Китае это Wechat, Sina Weibo и Qzone, в России ВКонтакте и Одноклассники, а в Японии и Южной Корее сильные позиции удерживает LINE.

Ждёт ли локализованную игру успех?

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

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

  1. Понравится ли игра говорящим на дополнительном языке? Если игра обрела успех на своём главном рынке, это сигнал о том, что локализованные версии тоже могут быть успешными. Но не всё так просто. Если новый рынок заметно отличается в плане культуры, игровых предпочтений и ожидаемых цен, нужно исследовать его внимательнее. Чем больше различий, тем больше усилий потребует локализация и тем выше вероятность неудачи. Это особенно важно в случае с комплексными сюжетными играми и при переходе с западного на восточный рынок или обратно.
  2. Сколько их там? Говорящие на дополнительном языке могут жить в одной стране (японский) или же по всему миру (испанский). Во втором случае встаёт вопрос: делать одну версию или разные, например, для Испании и Латинской Америки? Первый вариант дешевле, но игроки могут почувствовать, что игру локализовали не специально для них.
  3. Есть ли у них деньги? На китайском или хинди говорит множество людей, но среди них немного игроков, готовых потратиться на покупку игры или на внутриигровые платежи. Будет ли низкая средняя платёжеспособность компенсирована количеством?
  4. Действительно ли им нужна версия на их языке или хватит и английского? Вопрос непростой. Есть страны с высоким уровнем знания английского, особенно среди геймеров. Там могут даже не пользоваться локализованными версиями операционных систем, потому что слова «file» или «desktop» непривычно звучат на их языке. Если они откажутся покупать локализованную игру, то не из-за проблем с английским, а купят они её в том случае, если высокое качество локализации позволит получить больше удовольствия. На глобальном уровне можно ознакомиться с индексом владения английским языком.

Посмотрим на статистику

История локализации игр началась, когда японцы начали переводить свои продукты на английский, чтобы выйти на американский рынок, а американские компании стали выпускать свои игры на FIGS (французский, итальянский, немецкий, испанский) в Европе. Вторая устоявшаяся аббревиатура – это CJK, то есть китайский, японский и корейский, обозначающие минимальный набор языков для локализации на азиатском рынке. Сохраняются ли подобные нормы в свете результатов недавних исследований? Давайте взглянем на данные от компании Newzoo, изучающей рынок игровой индустрии:

Топ-20 рынков с крупнейшей доходностью игр за 2014:

Страны, где больше всего тратили на мобильные игры в 2014:

Показатели игрового рынка в каждом регионе и динамика их роста за апрель 2015:

Судя по этим цифрам, EFIGS и CJK покрывают большинство важнейших рынков, но не стоит забывать и о других языках, набирающих свою значимость. Существует много разнообразной статистики, но ни одна модель не является однозначно лучшей. Давайте кратко рассмотрим самые популярные языки.

EFIGS

Английский – это либо основной язык вашей игры, либо первый, на который она должна быть переведена. Он открывает доступ не только к США – по-прежнему крупнейшему игровому рынку в мире (хотя уже скоро лидировать будет Китай) – и другим англоговорящим странам, но и к немалой доле остального западного мира. Игроки могут предпочесть версию на своём родном языке, но если игра хороша, будут играть и на английском. Даже про самые лучшие игры на китайском или корейском такого не скажешь, эти языки не сильно распространены за пределами своих стран. Можно рассмотреть отдельные варианты с британским и американским английским, особенно, если в игре есть озвученные реплики. Английский открывает вам доступ ко множеству стран, так что не забывайте о дистрибуции и локализации серверов и поддержки.

Французский даёт вам пропуск не только во Францию, но и, в определённой степени, в Бельгию, Швейцарию, Канаду и бывшие французские колонии. Французы известны тем, что предпочитают родной язык и будет сложно завоевать их внимание без надлежащего качества локализации. К тому же, они и сами мастера делать игры, так что нужно учитывать фактор местной конкуренции.

Итальянский всегда был частью сокращения FIGS и сегодня остаётся немаловажным языком, хоть и немного сдал позиции из-за экономических проблем Италии. За пределами своей страны итальянский мало распространён, так что восстановление экономики скажется и на восстановлении его значимости. Рассматриваете ли вы Италию как выгодный рынок или нет, важно помнить, что итальянцы привыкли к качественным локализациям от крупнейших издателей и на компромиссы не согласятся.

Немецкий – беспроигрышный вариант: Германия занимает 4 позицию по доходности, а Австрия 20. С лингвистической точки зрения немецкий ближе к английскому, чем любой другой язык FIGS, и в Германии хорошо знают английский (только взгляните на индекс владения языком!). Делать вам немецкую локализацию или нет, зависит от ваших приоритетов.

Испанский – это особый случай среди языков FIGS. Изначально испанская локализация предназначалась только для Испании, но сегодня нужно всерьёз рассматривать растущий рынок Латинской Америки с её населением в сотни миллионов. Это делает испанский вторым или третьим по распространённости языком в мире, в зависимости от методологии подсчётов. Доход от латиноамериканского рынка незначителен по сравнению с Европой, но развивается он быстрее любого другого.

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

Японский должен занимать особенное место в сердцах всех любителей игр. Наряду с США Япония была колыбелью современной игровой индустрии, взрастившая таких гигантов, как Nintendo, SEGA и Sony, и любимые многими бренды – Pacman, Sonic и Mario. Она занимает третье место по доходности после США и Китая и славится преданными фанатами, не стесняющимися тратиться на любимые игры. Несмотря на обильный обмен играми, длящийся ещё с 80-х, Япония остаётся частью «загадочного Востока», когда дело касается иностранной продукции. Формула безупречной локализации западной игры на японском рынке или японской на западном до сих пор не найдена, и на этом спотыкались даже крупные компании. Будьте внимательнее.

Корейский – последний язык из большой тройки азиатского минимума. Несмотря на относительно скромное население в 50 миллионов, Южная Корея занимает 6 строчку в рейтинге Newzoo, а корейская культура гейминга соперничает с японской. Хотя страна и начинала импортировать оборудование и софт из Японии и США, собственные игры, вроде MapleStory и Ragnarok, положили начало местной игровой индустрии больше десяти лет назад. В настоящий момент она создаёт мощную конкуренцию, западным играм для успеха требуется глубокая адаптация, продуманная стратегия и, в идеале, локальный партнёр. Южная Корея известна как крупное средоточие киберспорта, где прямые трансляции различных событий привлекают миллионы зрителей.

Другие языки

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

Россия занимает нишу, отличающуюся от развитых рынков Европы и Азии. Страна располагается на 12 месте по доходности, но имеет максимальную долю PC-игроков – свыше 90 %. Рынок мобильных игр сравнительно молод, так что у предприимчивых разработчиков есть хорошие шансы на успех. Местные компании составят достойную конкуренцию любому, кто появится на российском рынке, пусть некоторые из них и практически не известны за пределами страны. Следует учитывать, что российская экономика нестабильна, и высокие розничные цены вкупе с недостаточно жёстким соблюдением авторских прав делают пиратство серьёзной проблемой.

Индия не намного отстаёт от Китая по численности населения. Несмотря на низкий уровень развития, малую распространённость Интернета и только зарождающуюся культуру гейминга, Индия уже скоро может стать силой, с которой придётся считаться, благодаря одному лишь её размеру. Конечно, главный вопрос здесь – на каком же языке говорят в Индии? В стране 22 официальных языка, при этом большинство игроков играют на английском, хоть и говорит на нём очень малый процент населения. Демонстрируя траты на игры на уровне $90 млн в год, Индия представляет собой развивающийся рынок с безграничным потенциалом, но ВВП на душу населения настолько мал, что мобильные игры можно продавать лишь по 2 цента.

Цифровой рынок игр в Бразилии в 2014 достиг $1,4 млрд. В целом Латинская Америка не является крупным рынком в сравнении с остальными, но она демонстрирует самый быстрый рост. Это добавляет бразильский португальский к латиноамериканскому испанскому в качестве самых перспективных языков локализации. Однако, если испанский в Латинской Америке и Испании различается не очень сильно, для бразильского португальского потребуется делать отдельную версию.

Юго-Восточная Азия – один из наиболее быстро развивающихся рынков, особенно в мобильном секторе. Там меньше местных компаний и конкуренции, чем в Китае, Японии и Южной Корее. С другой стороны, этот регион сильнее отличается в культурном и языковом плане, и каждая страна требует индивидуального подхода. Среди 11 стран 99 % игровых доходов приходится только на 6: Индонезию, Малайзию, Филиппины, Сингапур, Тайланд и Вьетнам.

Подведение итогов

Итак, безопасной ставкой являются главные европейские языки. Все обычно начинают с английского, французского, немецкого, испанского, португальского и итальянского. В Азии массивными рынками являются Китай, Япония и Южная Корея, но тут вам потребуется делать гораздо больше, чем просто перевод. Латинская Америка, Юго-Восточная Азия, Россия и Индия показывают быстрый рост, но размеры рынков и низкая средняя доходность на пользователя здесь намного меньше. Определяясь с языком локализации, принимайте во внимание не только стоимость перевода, но и все сопутствующие расходы.

Языки программирования для создания игр

Языки программирования для создания игр являются одними из самых развитых и востребованных в современном обществе. Большая популярность игр на ПК, на андроид и другие системы делают их очень ценным товаром, который при грамотной рекламной компании и хорошей реализации в целом способен принести немалые деньги и возможности для дальнейшего развития.

Компьютерные игры появились почти сразу же с самим началом развития ИТ отрасли. Извечной мечтой любителей ЭВМ было создание программ, способных играть в шахматы и при более менее нормальном развитии техники эту задачу быстро удалось решить. Особый расцвет игровой индустрии пришелся на начало 2000-х годов, когда у многих людей начали появляться мощные и относительно недорогие персональные комптометры. Сейчас игры все так же популярны и у детей и у многих взрослых людей.

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

Самые ходовые языки в GameDev

Существует очень большое количество языков программирования и многие из них можно приспособить под задачу создания игр. Но наибольшее распространение и популярность в этом направлении получили следующие языки:

  • С++. Очень многообразный и функциональный язык, изучение которого требует немалых усилий, усидчивости и реальной заинтересованности. Это статически типизированный компилируемый язык программирования, поддерживающий основные парадигмы: объектно-ориентированное, обобщенное, процедурное программирование. Важным плюсом С++ выступает наличие у него очень объемной стандартной библиотеки, включающей массу полезных функций: ввод/вывод, многопоточность, удобные алгоритмы и контейнеры. Язык способен функционировать на самых разных платформах, он отлично сочетается с другими средствами разработки, что делает его универсальным и беспроигрышным вариантом для создания игр;
  • C#. Си Шарп также отлично подходит для разработки игр. Как игровой язык он имеет много важных характеристик и преимуществ. Это полностью объектно-ориентированный язык, разработанный в недрах компании Microsoft. Синтаксис Си Шарп очень близок к синтаксису всего семейства языков С, а также Java. В основном на нем разрабатываются игры на ПК, а если более конкретно – то на платформу .NET Framework. Язык поддерживает полиморфизм, перегрузку операторов и имеет статическую типизацию. Возможностей C# вполне достаточно, чтобы разработать полноценную игру: ее логику, архитектуру и другие важные элементы. Языки си для программирования игр используются уже давно и в целом очень успешно;
  • Что касается разработки игр под мобильные, в особенности на операционную системы Android, то здесь придется изучить такой язык, как Java. Именно он способен справиться с созданием логики игр, ее механики и других важных нюансов. Java помогает работать с многими потоками, что очень важно для игр и для самого Андроид. Также это язык дает возможность легко взаимодействовать с памятью устройств, что в играх тоже немаловажно.

Почему именно эти языки программирования нужны для создания игр? Потому, что они способны дать максимально эффективный набор инструментов для разработки игр и при этом реализация идей программиста здесь будет наиболее полной. Можно использовать и другие языки, но они чаще работают в других областях или только на некоторых участках в деле создания игры. Также указанные языки хорошо взаимодействуют с другими программами, которые обязательно придется использовать для создания игры. Это и графическое оформление, и использование движка и аудио сопровождение, и многие другие нюансы.

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

Писать все с нуля или использовать игровой движок?

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

Игровым движком называется основной программный участок будущей игры, в котором уже заложены особенности анимации, звуков, физический движок (особенности игровой механики, движение персонажей и т.п.), искусственный интеллект, особенности управления памятью и многопоточность. Благодаря использованию игрового движка можно существенно сэкономить время и усилия.

Вот только некоторые популярные игровые движки:

  • Отличный инструмент для создания как 3D, так и 2D развлекательных приложений, способный работать на Linux, Windows и OS X. Игры созданные на Unity могут одинаково успешно работать на самых разных платформах: ПК, игровых приставках, мольных устройствах на Android, iOS или Windows Phone. Игры на этом движке поддерживают популярные технологии DirectX и OpenGL, что только увеличивает их функционал и качество. На Unity созданы Wasteland 2, Prime World, Shadowgun, Gone Home, некоторые части Need for Speed и другие популярные игры;
  • Unreal Engine. Очень популярный игровой движок, на котором создается львиная доля всех современных игр. Созданный в уже далеком 1998 год он все еще является одним из самых лучших и функциональных движков, чем привлекает внимание многих компаний разработчиков игр. Именно на Unreal Engine разных версий создавались Blade & Soul, Mass Effect 3, Medal of Honor, BioShock 2, Life is Strange и огромное множество других культовых игр;
  • Frostbite Engine. Еще один отличный движок от компании EA Digital Illusions CE, который при относительно небольшой требовательности к игровым устройствам предоставляет очень качественную и графику, поддерживает технологию DirectX, способен дать возможность разработчику создавать в игре очень красивые и интересные спецэффекты (например, разрушение объектов игровой среды, более реалистичный вид рельефа и многое другое).

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

7 лучших языков программирования для создания приложений на Andro >

Возраст ОС Android приближается к десятилетнему юбилею. Хотя с момента первого релиза этой операционной системы прошло уже столько времени, это вовсе не означает, что поезд ушёл, а учиться разработке Android-приложений уже поздно. На самом деле, именно сейчас самое время научиться: ещё никогда не существовало так много эффективных способов создания потрясающих приложений для Android.

А ещё все новые Хромбуки отныне и навсегда обзавелись поддержкой Android-приложений: их можно скачивать, устанавливать и запускать, как в родной среде. Рынок Android-программ лишь растёт. Не следует думать, что время ушло – ещё совсем не поздно начать. Всё, что нужно для старта: приготовиться, сделать глубокий вдох, подобрать подходящий язык программирования – и начать свое путешествие.

Но какой язык программирования будет лучшим именно для вас? Выбор подходящего инструмента разработки – первая задача, с которой никто не справится лучше вас. Многое зависит от опыта в программировании (либо от отсутствия опыта в конкретных средах разработки), от личного комфорта при использовании того или иного языка. К счастью, выбор приличный. В данной статье рассмотрена подборка лучших языков программирования для Android.

Когда дело касается приложений для Android, язык Java никак не может стать неверным выбором. Помимо того, что это официальный язык программирования данной ОС, он ещё и второй по распространённости на ресурсе GitHub, и столь популярен он уже более 20 лет. Это значит, что инструкций и учебников по Java существует великое множество, да и беспокоиться об устаревании этого языка в ближайшем будущем совершенно не следует.

Так как язык Java широко распространился по десяткам отраслей программирования, мы рекомендуем начать его изучение с книг, посвящённых Java в контексте экосистемы Android. Разумеется, Java один и тот же во всех средах, но отдельные парадигмы и выражения помогут пытливому уму быстрее вникнуть в суть разработки Android-приложений. Именно такую задачу и ставят перед собой большинство книг на эту тему.

Стоит отметить, что из-за почтенного возраста Java ему не хватает некоторых характерных особенностей, присущих более молодым языкам. Новичкам это не столь важно, однако для более опытных программистов, переходящих на этот язык, скажем, со Swift, Java может поначалу вызывать приступы клаустрофобии.

Kotlin

Язык программирования Kotlin был создан специально для работы на виртуальных машинах Java. Это означает, что приложения Kotlin компилируются в код Java, что позволяет им запускаться на любых машинах с поддержкой Java-среды. А так как поддержкой Java обладает большинство машин, то использование Kotlin – сравнительно простой способ разработки кросс-платформенного ПО.

Использование Kotlin – это применение в программном продукте всех лучших сторон Java, без его недостатков. Синтаксис и другие особенности программирования на Kotlin современны, понятны, быстры. Это действительно удобная среда для разработки. Там, где Java кажется громоздким, неуклюжим и староватым языком, Kotlin выглядит комфортно, свежо и даже красиво. В какой-то степени можно считать, что Kotlin был специально создан для разработки приложений Android.

Обратная сторона медали? Kotlin – очень молодой язык. Его первые версии были выпущены в 2011 году, а официальный релиз состоялся лишь в 2020. Есть и хорошие новости: Kotlin – бесплатный и с открытым исходным кодом. Стоит ожидать, что он будет развиваться семимильными шагами. Но в любом случае должно пройти несколько лет, прежде чем этот язык зарекомендует себя по-настоящему надёжным выбором.

C# — невероятный язык программирования! Он взял от Java всё самое лучшее, оставив за бортом худшие особенности этого языка. И развивался он в том же правильном русле. Похоже, что в Microsoft некогда разглядели потенциал Java и решили разработать собственную, лучшую версию.

Долгое время серьёзным недостатком использования C# было то, что он работал лишь в системах Windows: этот язык основывается на .NET Framework. Но в 2014 году это обстоятельство изменилось: Microsoft открыла исходные коды .NET Framework. Более того, в 2020 году корпорация приобрела компанию Xamarin – разработчика Mono (проект, позволяющий программам C# работать на различных платформах).

Итогом этих славных дел стало то, что сегодня можно использовать среды Xamarin.Android и Xamarin.iOS для создания мобильных приложений в Visual Studio или Xamarin Studio. Отличный способ для начала разработки, ведь в дальнейшем можно будет использовать средства этого языка в других областях – скажем, создание сложных игр при помощи Unity и C#. Наглядные примеры приложений, созданных в Xamarin? MarketWatch – ни больше, ни меньше.

Наконец, отметим, что ещё недавно за работу в Xamarin требовалась плата. Но Microsoft сделала эту среду бесплатной!

Python

Хотя Android не обладает нативной поддержкой Python, существуют инструменты, позволяющие писать приложения на Python, а затем конвертировать их в «родные» для Android приложения APK. Великолепный пример жизнеспособности Python в качестве действительно эффективного языка. Почитатели языка Python, желающие попробовать себя в разработке Android-приложений, обязательно оценят эту возможность – не вникая при этом в дебри Java.

Среди наиболее популярных решений для конвертации кода Python в APK – проект Kivy. И дело даже не в его природе open source, и не только в поддержке Windows, Mac, Linux и iOS вдобавок к Android. Kivy спроектирован таким образом, чтобы действительно ускоряет разработку приложений. Во всяком случае, можно использовать его в качестве инструмента для прототипирования. Сколько всего можно сделать при помощи лишь нескольких строк кода!

Впрочем, в отсутствии у Python нативной поддержки, не получится воспользоваться и преимуществами родной для Android среды. Приложения, написанные с Kivy, как правило, компилируются в более объёмные APK, медленный старт и, в целом, производительность ниже среднего. Однако каждый вновь выпущенный релиз по-настоящему лучше предыдущего, а мобильные устройства сегодняшнего дня настолько мощны, что неоптимальная производительность приложений значит не столь уж много. Пусть этот фактор не будет препятствием.

Пара примеров приложений на Android, написанных в Kivy: Kognitivo и Barly.

HTML5 + CSS + JavaScript

Эта тройка языков, когда-то созданных для разработки фронт-энд приложений в веб-среде, с тех пор переросла в нечто большее. Теперь инструментов HTML5, CSS и JavaScript вполне достаточно для создания самых разных приложений и для мобильных устройств, и для классических ПК. По сути, программист создаёт веб-приложение, способное использовать всю мощь и магию оффлайн-платформ.

Для создания Android-приложений этим способом можно использовать возможности Adobe Cordova – это фреймворк с открытым исходным кодом, который также поддерживает операционные системы iOS, Windows 10 Mobile, Blackberry, Firefox, и многие другие. Однако, какой бы полезной ни была Cordova, для создания в ней сколь-нибудь приличного приложения требуется серьёзная работа. Поэтому многие программисты отдают предпочтение проекту Ionic Framework (который использует «Кордову» для развертывания на различных платформах).

Примеры приложений для Android, написанные на HTML5, JavaScript и CSS: Untappd и TripCase.

Есть и другая возможность: использование библиотеки React Native. Её можно развернуть на Android, iOS и платформе «Универсальных приложений Windows». Эту библиотеку используют специалисты Facebook, Instagram и других крупных компаний, поэтому можно положиться на её надёжность. Обучение не самое простое, но когда оно подойдёт к финалу, в ваших руках будет вся мощь, гибкость и удобство, которые только можно пожелать.

Lua – старый скриптовый язык, который изначально создавался в качестве дополнения для программ, написанных на более сложных языках: C, VB.NET и т.д. В этом языке есть некоторые особенности, которые выделяют Lua из ряда подобных ему – к примеру, начало массивов с 1 вместо 0, или отсутствие нативных классов.

Таким образом, для определённых задач Lua можно использовать в качестве основного языка программирования. Лучший тому пример – SDK Corona. При помощи Corona можно создавать мощные, богатые по функциональности приложения с возможностью развёртывания на Windows, Mac, Android, iOS, и даже Apple TV + Android TV. В Corona также встроены возможности для монетизации, плюс – это приличный по объёмам рынок, где можно отыскать полезные в работе плагины.

Чаще всего Corona используют для создания игр (среди примеров – Fun Run 2 и HoPiko), однако есть и образцы утилит, а также бизнес-приложений (My Days и Quebec Tourism).

Для создания приложений Android, Google официально предоставляет две среды разработки:

  • SDK (использует Java);
  • и NDK (использует нативные языки, наподобие C и C++).

Отметим, что для создания приложения целиком, использовать C, C++ и «голый» Java не получится. Вместо этого NDK позволяет создавать библиотеки, к функциям которых могут обращаться части Java-кода из приложения.

Как правило, нет необходимости использовать NDK. Эту среду не стоит использовать в качестве основной хотя бы потому, что придётся больше заниматься кодингом на C/C++, а не на Java. Существование NDK оправдано в тех задачах, когда требуется выжать как можно больше производительности при выполнении сложных вычислительных задач. Также NDK позволяет внедрять в приложение библиотеки C и C++.

Но в других случаях стоит придерживаться Java везде, где возможно. Разработка Android-приложений на C/C++ в разы сложнее, чем на Java. И чаще всего выигрыш в производительности слишком незначителен.

Какими приложениями вы хотели бы заняться?

Мессенджеры, игры, калькуляторы, блокноты, проигрыватели. Возможности безграничны! Во многом они безграничны благодаря перечисленным выше языкам программирования и фреймворкам. Не нужно изучать их всех подряд – лишь те, которые пригодятся именно в решении вашей задачи. Если в будущем потребуется расширить собственные знания, то можно заняться самообразованием, когда настанет время.

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

Языки сценариев и Game Dev/Программирование

Хорошо, поэтому я занимаюсь разработкой/программированием 2D-игр, и многие игры, которые я видел, используют какой-то язык сценариев. Поэтому мне интересно — Какая цель использования скриптов в играх? Я знаю, что нет простой одной причины ответа, и я пытался рассмотреть все возможности. Вот что я думаю: «Я знаю до сих пор:

1) Скрипты позволяют изменять игру без повторной компиляции.

2) Скрипты легче использовать не программистам.

3) Сценарии позволяют мне отделить движок от самой игры, что позволяет мне быстрее делать другие игры с теми же компонентами?

Что обо всем, что я знаю. Мой следующий вопрос: если я собираюсь быть Dev/программированием одной игры, мне действительно нужно использовать скрипты? Или я мог бы прототип игры с использованием чего-то вроде python или ruby, чтобы можно было быстро протестировать, а затем переписать код в С++ сэкономить время и ошибки компилятора и т.д.

Еще одна вещь, о которой мне интересно: мне лучше использовать Ruby или Python, так как я с ними больше всего знаком? Или я должен использовать Lua, Perl или что-то еще, если он лучше подходит для достижения цели? Говоря по этому поводу, для чего я должен использовать сценарии? следует ли использовать их для позиционирования и моделирования пользовательского интерфейса меню игры, записи/чтения файлов сохранения, уровней загрузки карт, хранения массивов или структур игровой терминологии, таких как «Новая игра» или «Выход», все вышеперечисленное, ни один из вышеперечисленных

Если я использую скрипты, не разрешит ли игровой механик редактировать конечный пользователь? Или есть способ упаковать скрипты в один сжатый файл, который может читать движок?

В основном, мне интересно:

Для чего я должен использовать скрипты в своей игре? И почему?

Нужно ли мне использовать языки сценариев, если я работаю один или с программистами, а не с Devs?

Какой язык сценариев должен использовать, если я буду создавать платформеры, ролевые игры или что-нибудь еще?

10 ответов

11 Решение Garviel [2011-09-15 19:51:00]

ваши лучшие 3 причины все на 100% правильны и являются основными причинами использования языков сценариев вместе с движком вашей игры.

Лично у меня только был опыт работы с Lua через Luabind. Это немного сложно настроить, но это того стоило. Что вы можете делать с языками сценариев, так это раскрывать структуры данных и/или функциональные возможности, которые вы хотите, чтобы пользователь был в этом случае сам, чтобы иметь возможность использовать. Вообще говоря, единственная игровая механика и т.д., Которые можно редактировать, — это те, которые вы им разрешили.

Для чего я должен использовать скрипты в своей игре? И почему? Загрузка активов, экспонирование функций/типов, т.е. Для нашего игрового движка (написанного на С++), у нас был базовый уровень, а затем много разных типов наследования уровня от него, такие как уровень волны, соответствие смерти и т.д. Пользователь просто заявляет в script, какой тип уровня им нужен, а затем зажимает здесь активы. В моей демонстрации мы:

— Уровень Начальное число врагов

— Уровень Общее количество волн

волновых чисел = «4»

Не беспокойтесь о цифрах и обо всем этом.

Как вы можете видеть, какая-то загрузка актива, а также определение типа уровня

Мы также дали большой контроль над ИИ сценариями, на самом деле структуры данных были почти полностью открыты для Lua.

Нужно ли мне использовать языки сценариев, если я работаю один или с программистами, а не с Devs?

Да нет? Конечно, мы все предпочитаем «реальное» кодирование. Если вы можете сделать свой игровой движок достаточно абстрактным, чтобы создавать совершенно разные игры только с Lua, значит, вы отлично поработали и разработали его очень хорошо.

Другая вещь, о которой вам нужно подумать, особенно если вы играете с движком игры, довольно велика и позволяет ей смотреть на нее, на самом деле не будет маленького, каждый раз, когда вы компилируете, это может занять несколько минут! Это линкер, который занимает здесь время.

Какой язык сценариев должен использовать, если я буду создавать платформеры, ролевые игры или что-нибудь еще?

Я только использовал Lua, так что единственный совет, который я могу здесь дать.

Надеюсь, это полезная информация для вас.

Честно говоря, поскольку это звучит как ваша первая попытка в игре, вы не должны даже беспокоиться об этом. Вместо этого я буду больше беспокоиться о том, чтобы свести объем вашего проекта до уровня, на котором у вас есть шанс снежного шара на самом деле что-то сделать. Если вы еще не сделали что-то на уровне Tic-Tac-Toe или Pong, сделайте это первым. То, что вы узнаете там, будет более ценным, чем беспокоиться о языке сценариев.

О, и если вы делаете RPG в качестве первой попытки игры. Не. Они, безусловно, являются самыми трудными типами игр, которые можно сделать даже для профессиональных разработчиков, много раз предоставляющих им ресурсы. Держите его простым и используйте его как опыт обучения.

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

Да/нет/зависит от вашего второго. Если объем вашей игры невелик, скрипты не так важны. Если вы делаете это самостоятельно, сценарии не так важны.

Ваш выбор того, что вы знаете или что ваш движок будет поддерживать (или какие инструменты для двигателей вы купите для поддержки). Lua популярен, но даже ручные скрипты будут работать. Это больше касается развязки данных из кода и типа дизайна с работы типа инженера.

Ваши первоначальные пункты выше применяются. Сценарии не содержат кодировщиков и позволяют любому человеку в команде легко изменять данные, связанные с данными, которые должны быть в коде в любом случае. Скрипты также выступают в качестве языка с очень высоким уровнем, позволяя контролировать количество уровней игры контролируемыми способами, которые будут/будут выглядеть уродливыми, если они будут помещены в код. Я лично работал над играми, которые делались в обоих направлениях. Сценарий игры был немного легче поддерживать в конце игрового цикла — ЕСЛИ ЕСЛИ код поддержки script был зрелым и выполнялся через некоторые циклы отладки. Новый script код поддержки сложнее отлаживать, чем кодирование вещей прямо, потому что есть более возможные точки отказа. Игры, которые были закодированы без скриптов, как правило, делались быстрее, но требовали гораздо больше времени программиста/инженера, что означает, что общий объем вещей должен был быть ограничен, чтобы оставаться в бюджете.

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

4 Klaim [2011-09-15 19:36:00]

Для чего я должен использовать скрипты в своей игре? И почему?

Причины, которые вы указали, хороши. Одна вещь, которую вам, возможно, потребуется понять, это то, что большинство профессиональных игр по-прежнему построены на С++, и это далеко не гибкое, чтобы изменить, если база кода большая. Поэтому, если вы используете С++, вам понадобятся языки сценариев, чтобы быстро вносить изменения, когда им было позволено делать это в соответствии с приведенными вами причинами.

Если вы не используете С++, возможно, вы используете язык, который может быстро впитывать изменения, делая основной смысл сценариев не столь очевидным. Например, я не использовал бы скриптовый язык в игре Flash или Python.

Нужно ли мне использовать языки сценариев, если я работаю один или с программисты в отличие от Devs?

Как мой предыдущий ответ: это зависит от времени изменений. Подумайте, что основные правила игр редко меняются, но все, что касается дизайна уровней, будет и должно быть легко проверено. Если вы можете это сделать на языке программирования игр, зачем беспокоиться? Если вы не можете, то любой способ ускорить интеграцию изменений будет платить.

Какой язык сценариев должен «использовать», если я буду делать платформеры, ролевые игры или что-то-вы?

Честно говоря, нет ни одного решения каких-либо проблем. Я лично использую Falcon и ChaiScript, Lua хорошо известен, но любой язык сценариев, который может использоваться с вашим программированием игры, будет делать. Этот вопрос уже задан, и если у вас есть сомнения, просто выберите Lua, поскольку он наиболее распространен в играх.

2 [2011-09-15 19:42:00]

Я дам вам быстрый и короткий ответ. Сценарии в основном для изменения вещей, пока игра все еще работает, и вы можете редактировать вещи быстрее. Это намного лучше, чем перекомпилировать, перезагрузить активы, перейти к определенному моменту игры, активировать определенные условные обозначения (элементы, разговаривать с людьми в определенном порядке и т.д.) И т.д.

Вещи, выполненные в script, — это речь персонажа, взаимодействие с NPC с триггерами (например, ходьба где-то останавливается, чтобы поговорить с другим NPC, затем бежать куда-нибудь, скрипты используются для синхронизации), триггеры или события в целом и статистика противника (здоровье, скорость, точность, иногда логика для указанного символа).

Приведенные вами причины являются обоснованными причинами использования языков сценариев в играх. Я также добавил бы еще одну причину: разные языки лучше подходят для различных задач программирования, а язык сценариев высокого уровня позволяет вам писать части вашей игры на языке, который может быть лучше, чем С++.

Основными причинами, по которым С++ широко используется в играх, являются производительность, легкий доступ к низкоуровневым родным API или аппаратным средствам (на консолях) и инерции — большинство игр написаны на С++, поэтому большинство сторонних библиотек и промежуточного программного обеспечения для игр написаны на С++ и наиболее легко сопряжен с С++. Для многих задач, однако языки более высокого уровня, такие как Python, С# или Ruby, имеют преимущества производительности программистов над С++, которые могут перевесить преимущества С++ для кода, который не критичен по производительности или ему не нужно взаимодействовать с родными API.

Хорошо разработанный игровой движок С++ с языком сценариев высокого уровня может дать вам лучшее из обоих миров — производительность и низкий уровень доступа на С++, где это наиболее необходимо, и преимущества производительности на высоком уровне, где они наиболее необходимы.

Я нашел бесполезным использование скриптов, как в тех случаях, когда я работал в большой игровой студии, так и в моей работе как инди-разработчик. С другой стороны, у меня есть друзья, которые успешно использовали профессиональные, современные двигатели со сценарием. Поскольку вы делаете самостоятельную разработку игр самостоятельно (или в небольшой команде), я думаю, вам следует избегать этого. Основные причины:

  • Он добавляет накладные расходы почти везде: еще один язык для освоения (для каждого разработчика в команде), производительность медленнее, чем native, а API — самая слабая ссылка, что означает, что вам часто приходится перестраивать двоичный файл.
  • Единственный реальный выигрыш с языком более высокого уровня — это меньше времени на разработку (если вы используете зрелый движок), но, по моему опыту, время съедается из-за трудоемких ошибок в конце.
  • Многие языки сценариев игр используют динамическую типизацию (Lua, Stackless Python, Pawn), которые я считаю уязвимыми по сравнению со статически типизированными языками. Если вы тоже чувствуете, что это только хорошо для простых вещей, вы также можете сделать это вместо этого.

В качестве примечания я считаю, что игры для сценариев игр исключительно полезны, но только для приложений с быстрым взломом/прототипом, а не для огромных компонентов в играх. См. Мой ответ здесь.

На самом деле, почти все игровые серверы MMORPG запрограммированы в script.

Все С++-engin будут внедрять язык script для логической обработки, lua — подходящий для него язык script.

В bigworld, python является встроенным языком по умолчанию.

И node.js также является хорошим кандидатом на программирование игрового сервера. Потому что его сетевая способность выше. В node.js есть среда с открытым исходным кодом: https://github.com/NetEase/pomelo/

Для чего я должен использовать скрипты в своей игре? И почему?

Как сказали все (включая вас), скрипты упрощают редактирование вашей игры. На больших командных сценариях также есть очень хороший эффект производительности: люди с техническими навыками могут продолжать полировать движок, в то время как творческие люди могут работать над реальной игрой, и обеим командам не нужно входить друг в друга.

Нужно ли мне использовать языки сценариев, если я работаю один или с программистами, а не с Devs?

Вам это не нужно, и в зависимости от конечной цели, на самом деле, это пустая трата времени для реализации сценариев. Я также разрабатываю 2D-скриптовую игру atm; Я один, но я делаю его сценарием также как личный вызов, а также потому, что хочу, чтобы игра была легко модифицируемой.

Какой язык сценариев должен использовать «я», если бы я создавал платформеры, ролевые игры или что-то еще?

Двумя наиболее популярными опциями являются Lua и Python. Большинство людей рекомендуют Lua, потому что это немного быстрее. Я пошел с Python, потому что он имеет (родную) поддержку для классов — который хорошо работает с моей существующей архитектурой С++ -— а также потому, что я считаю, что это гораздо более приятный язык для работы.

0 Tsaku [2013-11-22 10:47:00]

Хорошо, я знаю, что это немного мертво, но я должен сказать это. В буквальном смысле нет такой вещи, как программирование без скриптов. Честно говоря, неважно, напишите ли вы сами в себе или нет, факт, кто-то написал эти сценарии. Как и ruby, для его использования вам нужна программа, например, «блокнот +», чтобы настроить ее, или какой-либо компьютерный RPG Maker от enterbrain использует форму рубина для работы. нравится это или нет, при использовании компьютеров для разработки игры узнайте script. Теперь, что касается языка, посмотрите немного и попробуйте разные. Не дешево с использованием предварительно скомпилированного движка, просто работайте с нуля. поверь мне, тебе будет лучше. Я все еще пытаюсь решить, что мне больше нравится, Lua (С++) или Ruby. Я могу просто использовать чистый С++

0 Raedwald [2011-09-15 19:50:00]

Я не уверен, что интерфейсы сценариев для игр, которые вы пишете, настолько полезны. Однажды я немного поработал над Freeciv, и огромные усилия пошли на включение «modding», используя интерфейс сценариев. Функция, которая показалась малоиспользуемой. Я думаю, что существует опасность внутреннего эффекта платформы. Для настройки игры вам не нужен язык сценариев: у вас уже есть отличный язык программирования (С++, в вашем случае) для этого. Это WTF.

Цукерберг рекомендует:  Набираем студентов на факультет Java-разработки
Понравилась статья? Поделиться с друзьями:
Все языки программирования для начинающих