Програмиране на игра
Програмирането на игра, част от разработването на видео игри, е разработването на софтуер за видео игри.
Програмирането на игра изисква значителни умения в софтуерното инженерство, както и специализация в една от следните области, които се припокриват до голяма степен, за да се създаде игра: симулация, компютърна графика, изкуствен интелект, физика, звуково програмиране и въвеждане. За масови мултиплеър онлайн игри са нужни умения в още няколко области, като например мрежово програмиране и работа с база данни. Въпреки че често хората, които са ангажирани с тази дейност са професионални разработчици на игри, много новаци могат да разработват игри като хоби.
Процес на разработване редактиране
Професионалното разработване на игра обикновено започва с дизайна на играта, който сам по себе си може да започне по няколко възможни начина. Понякога процесът на разработване на игра започва без ясна концепция за дизайна, а като серия от експерименти. Например, дизайнерът на игри Уил Райт започва разработването на Симс като събира програмисти да експериментират с няколко идеи.
Изработване на прототипи редактиране
Често се изисква от програмистите да създават прототипи с идеи и функционалности за геймплея. Голяма част от изработването на прототипи може да се проведе преди стартирането на производство, преди да е завършен плана за дизайн и може да помогне да се определи това, какви възможности има дизайна.
Прототипите се разработват бързо, отделя се много малко време за първоначален дизайн и служат основно за доказване на концепция или за тестване на идеи. Те не се очаква да работят безпогрешно, но са разработени, за да изпробват нови, понякога екзотични идеи.
Дизайн на играта редактиране
Въпреки че основната работа на програмиста не е да развие дизайна на играта, програмистите често допринасят за проектирането му. Дизайнерът на играта ще изисква съвети както от продуцента така и от водещия програмист за идеи и стратегии за дизайна на играта. Често хора които не са в ръководни позиции също допринасят, като например копирайтърите.
Програмистите често плътно следват плана за дизайн на играта. Докато развитието на играта тече, планът се променя, след като са открити ограничения за програмиране или нови възможности.
Реализация редактиране
По време на реализацията, програмистите могат да напишат огромно количество програмен код за да създадат играта, описана в проекта за играта. В процеса на разработка, проектът може да бъде променян вследствие на обективни ограничения или да бъде разширен, включвайки нови характеристики. Проектният документ е до голяма степен „жив“ и голяма част от живота му се подчинява на графика, таланта и находчивостта на програмиста. Въпреки че много програмисти имат известно влияние върху съдържанието на играта, повечето продуценти на игри търсят мнението на водещия програмист по отношение на статуса на разработването на играта. Отговорност на водещия програмист е да е запознат с всички аспекти/етапи от разработването на играта и да посочи евентуални ограничения. Водещият програмист може също да предава към продуцента предложения от програмистите за възможни функционалности, които да бъдат включени в играта.
Предвид богатото визуално съдържание на игрите днес, програмистът трябва често да работи с дизайнерите на играта. Това разбира се до голяма степен зависи от ролята на програмиста. Например, за програмиста на 3D графиките може да е необходимо да работи рамо до рамо с 3D дизайнера, за да могат да обсъждат стратегии и конструктивни съображения, докато програмистът, занимаващ се с изкуствения интелект би имал малка или никаква нужда да взаимодейства с дизайнерите. За да подпомогнат дизайнерите на отделните нива на играта в техните задачи, програмистите могат да участват доброволно или да бъдат потърсени да разработят инструменти и приложения за разработване на игра. Много от тези инструменти могат да служат за постигането на конкретни цели и е възможно да съдържат програмни грешки поради ограниченото време (времето за разработването на такива инструменти често не е предвидено в графика за разработването на играта), както и поради факта, че често са предвидени само за вътрешна употреба. Много от инструментите за игри се разработват на езици за скоростно разработване на приложения (от английски: Rapid application development (RAD)) за ускоряване на процеса на разработка и може да не се използват след завършване на играта.
Тестване редактиране
Процесът на тестване за осигуряване на качеството, който се осъществява от професионални тестери на компютърни игри, започва още в процеса на разработка на играта. Тестването при високо-бюджетните игри може да започне още на етап Алфа тест, докато при ниско-бюджетните и развлекателните игри може да не се започне тестване до завършване на версията предшестваща финалната версия на играта. Задачата на програмистите е да коригират програмните и други грешки, открити от екипите за осигуряване на качеството(QA).
Финални етапи редактиране
Последните етапи включват „изглаждането“ на играта, като например коригиране на случайни програмни грешки – от малки до катастрофални – които биха могли да възникнат по време на последните фази на тестването. Разработването на играта може да премине през период на бета тест, като дефиницията за този тест варира от разработчик до разработчик. Често бета тестът обхваща всички функционалности на играта, но е възможно все още да има програмни грешки или съдържанието да е непълно. Малко игри имат публична бета версия, например за стрес-тестване на сървърите. Когато се прецени, че играта е завършена, се приема, че тя е готова за пускане в производство и се изпраща на издателя. В зависимост от обстоятелствата, издателят може да я подложи на собствено тестване за осигуряване на качеството или може директно да я пусне в производство.
Поддръжка редактиране
След като играта е пусната за производство, започва фазата на поддръжката. Програмистите изчакват известен период от време, за да съберат възможно най-много информация за програмни грешки. Когато разработчиците преценят, че са събрали достатъчно обратна връзка, програмистите започват да работят върху обновяването. Разработването на обновяванията може да отнеме седмици или месеци. Понякога обновяването може да включва допълнителни функции или съдържание или може дори да промени геймплея.
Продължителност редактиране
Завършването на повечето съвременни игри отнема между 2 и 3 години. Продължителността на разработването зависи от редица фактори, но всички фази на разработването изискват програмиране, с изключение на най-ранните етапи на изготвянето на архитектура и дизайн.
Инструменти редактиране
Както всеки друг софтуер, програмите за разработване на игри се генерират от програмен код до действителната програма (наречена изпълним файл) чрез компилатор. Програмният код може да бъде разработен с почти всеки текстов редактор, но повечето професионални програмисти на игри използват интегрирана среда за разработка (Integrated development environment - IDE). Коя среда ще бъде използвана, зависи от това за каква платформа се разработва конкретната игра. Популярни среди за разработка на игри за Xbox и Windows са Microsoft Visual Studio и CodeWarrior.
Програмни езици редактиране
| Език | Характеристики |
|---|---|
| Assembly | Минимално натоварване на процесора |
| C | Широко познаваем, широко приложим, множество APIs, компилира се до машинен код |
| C++ | Обектно-ориентиран, широко познаваем, множество APIs, компилира се до машинен код |
| Java | Обектно-ориентиран, система за почистване на паметта, широко приложим (чрез виртуална машина) |
| C#, Visual Basic .NET | Обектно-ориентирани, система за почистване на паметта, съвместими с продуктите на Microsoft |
| Objective-C, Swift | Обектно-ориентирани, съвместими с продуктите на Apple |
| Lua, Python, JavaScript, Tcl | Подобен синтаксис, лесно вградими един в друг, често се използват като скриптинг |
След като е уговорен първоначалният дизайн на играта, се избира и програмен език. Изборът зависи от много фактори, като например възможностите на екипа, целевите платформи, изискванията за скорост на изпълнение на гейм енджините, приложно-програмния интерфейс(APIs) или използваните библиотеки.
Най-популярните езици са процедурни/обектно-ориентирани и изпълнявани чрез компилатор, като С, C++[1][2] и Java[3]. Въпреки това, разработчиците могат да вземат предвид специфичните за домейна функции, като например взаимодействие с операционната система и възможностите за обратно инженерство за онлайн видео игрите.[4] Много от игрите са написани на повече от един език. Например Unity, популярен гейм енджин, който е написан на С, С++ и С#.
За конзолите най-важният фактор е поддръжката на платформата. В миналото видео игрите са били писани само на Асемблерен език поради ограничените ресурси откъм съхранение и скорост на обработка[5]. С напредването на технологията има повече възможности за развитие на конзолите. Nintendo, Microsoft и Sony[6] имат различни инструменти за разработване на конзолите си, съответно Wii U, Xbox One и PlayStation 4.
Скриптовите езици от високо ниво все повече се използват като вградени разширения в основата на играта написани в компилиран език, за удобство на разработчиците на играта и всеки друг, който иска да модифицира играта. Lua e много популярен избор защото неговото API е написано на ANSI C и е проектиран за вграждане в други приложения[2][7]. Много разработчици са създали персонални езици специално за своите игри, като например QuakeC на Id Software и Unreal Engine na Epic Games
Приложно-програмен интерфейс (API) и библиотеки редактиране
Ключово решение в програмирането на игри е какви APIs и библиотеки да се използват. Съществуват много библиотеки, които се грижат за основните задачи в програмирането на игри. Някои от библиотеките обработват звук, вход или графиките. Други могат да се справят със задачи тип изкуствен интелект, като например намирането на най-прекия път между две точки. SDL[8] и Allegro[9] sa популярни библиотеки, тъй като са съвместими с повечето модерни езици и по отношение на ефективност няма значителна разлика. Съществуват гейм енджини, които могат да обработват повечето задачи в програмирането на игри и изискват само написването на игровата логика.
Кои APIs и библиотеки ще бъдат избрани зависи от платформата. Например библиотеките за разработка на PlayStation 2 може да не са достъпни за Microsoft Windows и обратно. Въпреки това съществуват фреймуърци (библиотеки от класове), които позволяват или улесняват мултиплатформено разработване, за да могат разработчиците да програмират на един език и играта да се използва на различни платформи като Wii, PlayStation 3, Xbox 360, PSP и Microsoft Windows.
Графични API-та редактиране
В днешно време графиката е ключово определящ фактор за повечето игри. Докато до средата на 90-те години 2D графиката е била стандарт при видео игрите, повечето игри използват изцяло 3D графика. Като това се отнася и за игри, чиито корени са залегнали до голяма степен в 2D, като например "Civilization III".
При видео игрите за персонални компютри, разработчиците разработват продукта си главно за Microsoft Windows, тъй като той е инсталиран на около 90% процента от продадените настолни компютри и има изключително голяма потребителска база. Двете най-известни 3D графични API-та за Microsoft Windows са Direct3D и OpenGL. Предимствата и недостатъците на всяко едно от тях са горещо дискутирани измежду разработчиците на видео игри за Windows.
DirectX е колекция от API-та за видео игри. Direct3D е API за DirectX. Direct3D се разпространява безплатно от Microsoft, както и останалите API-та за DirectX. Microsoft са разработили DirectX за програмистите на видео игри и продължават да добавят разширения към API-то. Спецификацията на DirectX не е контролирана от отворена арбитражна комисия и Microsoft са свободни да добавят, премахват или променят разширенията към DirectX. Direct3D не е портативен; Той е предназначен изцяло и само единствено за Microsoft Windows (въпреки че подобия на Direct3D се използват на Xbox, мобилните устройства с Windows Phone 7.5 и мобилни устройства, които използват Pocket PC операционна система).
OpenGL е портативна API спецификация. Кодът написан с OpenGL се „портва“ лесно между платформите със съвместима имплементация. Например Quake II, който използва OpenGL е бил „портнат“ от Windows към Linux от фен на играта. OpenGL е стандарт установен от Съвета за рецензия на архитектурата на OpenGL - OpenGL Architecture Review Board (ARB). ARB се свиква периодично, за да обнови стандарта чрез добавяне на належаща поддръжка за характеристиките на ново-излезлите 3D хардуери. Вземайки предвид това, че е базирано на стандарт и се е задържало най-дълго, OpenGL се използва и изучава в колежи и университети в целия свят. В допълнение, инструментите за разработка предоставени от производителите на някои конзоли за видео игри(Nintendo Game Cube, Nintendo DS и PSP) използват графични API-та, които наподобяват OpenGL. OpenGL често изостава откъм актуализация на функции поради липса на постоянен екип от разработчици и изискването имплементациите на актуализациите да започват чак след, като се обяви стандарта. Програмистите, които решат да го използват, могат да получат достъп до най-новите 3D функции на някои хардуери, но само чрез не стандартизирани разширения. Ситуацията може да се промени в близкото бъдеще тъй като ARB са прехвърлили контрола над спецификацията към Khronos Group в опит да преодолеят проблема.[10]
Други API-та редактиране
За разработката на игри за Microsoft Windows, могат да се използват различните API-та на DirectX за входни сигнали от потребителя, звукови ефекти, музика, работа в мрежа, възпроизвеждане на видео. Има налични много комерсиални библиотеки с помощта на които да се постигне изпълнението на тези задачи, но тъй като DirectX е безплатен е и най-използван.
За разработка на конзолни игри, производителите на конзоли осигуряват апаратури за графично „рендиране“ и другите задачи от разработката на видео игри. Производителите на конзоли също така осигуряват цялостни системи за разработка, без които не могат да бъдат пуснати легално игри на пазара или изобщо да бъдат разработвани такива за техните системи. Разработчиците, които са трета страна в разработката също продават библиотеки или инструменти, които да улеснят разработката на една или повече от задачите или да осигурят специални предимства, като възможност за мултиплатформена разработка.
Структура на видео игра редактиране
Централния компонент на всяка игра от програмна гледна точка е игровият цикъл. Игровият цикъл позволява играта да върви гладко независимо от входния сигнал подаден от потребителя или липсата на такъв.
Повечето традиционни софтуерни програми реагират на входните сигнали на потребителя и не правят нищо докато не получат такива. Например текстообработваща програма форматира думи и текст докато потребителя пише. Ако потребителят не пише, текстообработващата програма не прави нищо. Някои функции могат да отнемат повече време да се изпълнят, но всяка от тях се инициира от потребителя казвайки на програмата да направи нещо.
Игрите от друга страна трябва да продължават да функционират независимо от входните сигнали подадени от потребителя. Игровият цикъл позволява това. Опростен псевдокод на игрови цикъл представлява нещо подобно:
while(user doesn't exit) check for user input run AI move enemies resolve collisions draw graphics play sounds end while
Цикълът може да бъде прецизиран и модифициран докато разработката на игра прогресира, но повечето игри са базирани на тази базисна идея.
Игровите цикли се различават в зависимост от платформата за която се разработва играта. Например игри писани за DOS и много конзоли може да използват наличните ресурси за обработка без ограничение. Въпреки това игрите за модерните операционни системи за персонални компютри, като Microsoft Windows трябва да функционират в рамките на ограниченията от планировчика на задачите. Някои от модерните игри използват многонишкова реализация, за да може изчисляването на изкуствения интелект да бъде отделно от генерирането на плавно движение в играта. Тук идва недостатъка от (значително) прегравяне, но играта може да върви по-гладко и ефективно на хипер нишкови или мулти процесорни платформи. Поради тази причина фокуса на компютърната индустрия е върху процесори с повече ядра, които могат да изпълняват повече нишки. Конзоли като Xbox 360 и PlayStation 3 вече имат повече от едно ядро на процесор и изпълняват повече от една нишка на ядро.
Любителско програмиране редактиране
Единствените платформи позволяващи на любители да програмират са операционни системи предназначени за обикновения потребител. Това е защото разработването на игри върху игрови конзоли изисква специални системи за разработка струващи хиляди долари. Често такива могат да бъдат набавени от производителите на конзоли и биват продавани или давани под наем само на професионални студия за разработки на видео игри. Въпреки това Microsoft разпространи фреймуърк за разработка на игри – XNA, който работи както на Microsoft Windows така и на Xbox 360. XNA е бил прекратен, но други проекти като MonoGame и SharpDX се опитват да позволят същия достъп за програмиране на игри. Игри написани за Windows често могат да бъдат „портнати“ и за Xbox с минимални промени. Това позволява на малки екипи или индивидуални разработчици да създават игри за конзоли. Някои любители също така разработват самоделни игри, особено за преносими системи или остарели конзоли.
Някои студенти по софтуерно инженерство програмират игри с цел упражнение при учене на програмни езици или операционни системи. Някои любители могат да използват помощни софтуерни пакети като Adobe Flash, Unity, pygame, Adventure Game Studio, GameMaker: Studio, Godot, UDK или Construct, при разработването на видео игри.
Източници редактиране
- ↑ Corlan, Alexandru-Dan. Game Programming in C and C++ // 2011. Посетен на 8 ноември 2015.
- ↑ а б DeLoura, Mark. The Engine Survey: General results // 5 март 2009. Посетен на 8 ноември 2015.
- ↑ Corlan, Alexandru-Dan. LWJGL – Projects // Архивиран от оригинала на 2015-11-10. Посетен на 8 ноември 2015.
- ↑ 'No Bugs' Hare. Chapter V(b) from "Development&Deployment of MMOG"
- ↑ Hyde, Randy. Using 6502 Assembly Language. 1985. Посетен на 8 ноември 2015.
- ↑ [Phoronix] Why Sony Is Using LLVM/Clang On The PlayStation 4 // Phoronix.com. Посетен на 17 ноември 2014.
- ↑ Corlan, Alexandru-Dan. Lua: Uses // 24 март 2015. Посетен на 8 ноември 2015.
- ↑ SDL Language Bindings // Посетен на 8 ноември 2015.
- ↑ Allegro - Language bindings // Посетен на 8 ноември 2015.
- ↑ "OpenGL ARB to Pass Control of OpenGL Specification to Khronos Group" press release Архив на оригинала от 2008-05-03 в Wayback Machine. from The Khronos Group
 
|
Тази страница частично или изцяло представлява превод на страницата Game programming в Уикипедия на английски. Оригиналният текст, както и този превод, са защитени от Лиценза „Криейтив Комънс – Признание – Споделяне на споделеното“, а за съдържание, създадено преди юни 2009 година – от Лиценза за свободна документация на ГНУ. Прегледайте историята на редакциите на оригиналната страница, както и на преводната страница, за да видите списъка на съавторите.
ВАЖНО: Този шаблон се отнася единствено до авторските права върху съдържанието на статията. Добавянето му не отменя изискването да се посочват конкретни източници на твърденията, които да бъдат благонадеждни. |