Създаде игра, игра дизайнери, игрови двигатели
Начинаещи Ръководство за създателите на MMORPG игри.
Необходими са знания:
1. Познаване на поне един език за програмиране. Кой сред разработчиците на най-популярния език C ++, заради своите предимства за ефикасността и бързината. Visual Basic, Java или C # може да се използва и в това си качество.
2. Необходимо е да се запознае с графичен библиотеката. А популярен избор е SDL, OpenGL или DirectX / Direct3D.
3. Взема решение за библиотеката мрежа. Можете да избирате WinSock, SDL_net или DirectPlay.
4. Имате опит в игра за програмиране. Например, за да имате представа за това, което е: опашката за събитие, многонишково, развитието на потребителски интерфейс (GUI) и т.н.
Тя е силно препоръчително е да знаете:
1. клиент-сървър комуникация архитектурата и строителството на такива системи.
2. Създаване на междуплатформени приложения. Доста вероятно искате да създадете вашата игра, и най-вече на клиента, така че да може да работи с различни операционни системи. За тази функция, аз препоръчваме да използвате SDL, OpenGL и SDL_net.
3. Разработване на Web (Интернет). Това е необходимо, ако искате да се даде възможност да видите статистиката на играчите, информация на сървъра, или всяка друга информация на интернет страницата на заинтересованите лица.
4. Защита и управление. Вие не искате някой хакнат сървъра си?
5. Работа в екип, управление на екип. Трябва да сте екип, който ще бъде в състояние да управлява успешно.
Стъпка 2. Създаване на проект скица
Данни на Guide-Bulgaria.com
предимства:
• лесно може да добавите или промените на терена.
• Промяна на статистиката за играча (не игра) е много по-лесно
• Можете да получите различни статистически данни бързо и ефективно използване на SQL заявки
• Не е необходимо да се създаде една операция за I / O, за да файл, база данни, всичко това ще направя за вас
• Лесно е да се актуализира и да се възстанови
недостатъци:
• Лесно е да се правят грешки. Например, за заявки забравен ", където" изявление. Това може да има катастрофални последици, особено ако имате само старите (или изобщо) архиви
• Работа с базата данни може да бъде по-бавно, отколкото да работи с файл играч директно. Може да загубите няколко милисекунди, когато получите данните, особено ако голям брой играчи в същото време, влизане / излизане от играта
• Трябва да се напише допълнителен код, за да конвертирате вашите данни до / от базата данни
• Изисква опит с бази данни и SQL езикови запитвания. Също така са необходими библиотеки за организацията на взаимодействие между приложението и базата
• Ако по някаква причина са повредени файлове на бази данни, вие сте изложени на късмет. Вие можете да изгубите всички играчи (особено ако няма прясно архивиране)
файлове
предимства:
• Много бърз достъп (четене / запис)
• Лесен за прилагане
• В момента няма допълнителни библиотеки
• Няма връзка със сървъра на база данни. Поради това, че не е нужно да се притеснявате за получаване на актуализации и кръпки за базата данни
недостатъци:
• Това може да бъде доста предизвикателна за добавяне на нови полета, ако преди това не мисля за структурата на формат и файл
• Не можете да направите заявка за голям брой играчи (този проблем може да бъде решен с помощта на програма, която всяка вечер добавя важни данни на сървъра за база данни)
• Трябва да се напише специален код, за да се позволи актуализиране / проверка на състоянието на играчите
• Малко по-трудно да се извършва операции обновяване и възстановяване
Сега, след като сте решили как да съхранява информация за героите, трябва да решите какъв тип мрежов протокол, който ще използвате за клиент-сървър комуникация: TCP или UDP? TCP е известен като по-бавен, но по-точно, тя се нуждае от повече трафик. На практика, не забелязах никакви проблеми при използването на TCP. Ако сте предоставили достатъчно пропускателна способност на мрежата, TCP - това е добър избор, поне като за начало. UDP може да бъде много неприятно, особено за начинаещи. Не забравяйте, че първоначалните тестове на двигателя и играта ще бъдат направени в локалната ви мрежа, така че всички пакети ще пристигнат на местоназначението си в същия ред, както това отиде. Но това не може да бъде гарантирана, когато използвате интернет, т.е. в реална среда. По това време, тъй като пристигат обичайните пакети в определен ред, някои от тях може да се загуби, а това е постоянен проблем за интернет. Разбира се, можете да развиете своя протокол, така че клиент / сървър може да се възстановят загубени пакети. Но това е труден процес, който не се препоръчва за начинаещи.
Стъпка 3. Разработване на вътрешен протокол за предаване на данните от игра
Тази задача също изглежда просто, но отново, това не е така. Не може просто да изпратите низ в символ на Терминал нула '# 92; 0 ". Ще ви е необходим съвместен протокол, за да бъде в състояние да предава струни, така и двоични данни. Неразумно в този случай, използвайте 0 (или всеки друг комплект) като терминатор елемент, тъй като терминатор може да бъде част от потока от данни, който изпращате. Също така, ако искате да изпратите 20 байта, а след това още 20 байта, най-вероятно на сървъра не получава пакет с 20 байта, следван от друг пакет с останалите 20 байта. Вместо това, той ще получи 40 байта наведнъж, тъй като това намалява натоварването на мрежата, поради заглавието на пакет (изпратен един, не два заглавия). По същия начин, можете да изпратите пакет с размерите на 1 KB, но сървърът ще получи две по-малки пакети. Така, че е необходимо да се знае, когато опаковката започва и къде свършва. Вечните земи в проекта да използват следния метод:
• Изместване 0: 1 байт, който определя командата предава.
• 1 Изместване 2 байта, дължината на предаваните данни.
• Изместване 3: променлива дължина на основния текст на съобщението.
Този метод има предимството, че всички данни се предават, съответно, определен стандарт. Недостатък - някои отбори са фиксирани, предварително известни на размера, така че трафикът се губи. В крайна сметка, ние са преминали към използване на хибридни решения.
Следващият въпрос е да се реши - ". Блокирани контакти, многонишкова" какъв модел да се използва от сървъра ", без блокиране на контакти, единична резба молба" или И двата метода (мулти и еднонишкови) имат своите предимства и недостатъци.
Multithreading:
1. По-точен отговор от сървъра, в момент, когато играчите се нуждаят от много време (например, четене на данни от база данни), тя ще върви по свой собствен конец, без да докосвате други играчи.
2. Много е трудно да се трасира усетят: Вие ще трябва да се създаде много синхронизация, и най-малката грешка може да доведе до сериозни последствия (катастрофа на сървъра, припокриващи се обекти, и т.н.)
един вход:
1. Тя е много по-лесно за изпълнение и след отстраняване на грешки
2. голямо време за реакция
В моята компания, ние избра една резба приложение, защото аз просто не разполагат с достатъчно ресурси, за да се справят със създаването на многонишковите решения.
Стъпка 4. Клиент
1. Не може да се направи MMORPG, отнема голяма компания.
Не съм съгласен с това. Докато създаването на игри света на Warcraft, Ever Quest 2, Asheron призива 2, на Lineage 2, а другият е непосилна задача за малки независими екипи за разработка, създаване на една скромна игра е напълно възможно, и зависи само от нивото на вашия опит, мотивация и свободно време. Вие ще трябва най-малко 1000 часа в режим на програмиране, за да се създаде проста техническа демонстрация, а вероятно и 10-15000 часа, за да завършите създаването на сървъра и клиента. Но тъй като ръководителят на екипа, с който ще трябва да се направи много повече от просто програмиране. Пазете отбора заедно, за разрешаване на конфликти, да се направи публични изявления (PR), техническа поддръжка, конфигурацията на сървъра, проблеми с блокиране на играчи, "мозъчна атака", и т.н. ще ви съпътстват през цялото време. Тези притеснения ви zasosut напълно. Най-вероятно, ще трябва да ходи на работа / училище, което допълнително ще намали времето, което може да бъде посветена на проекта. Ние бяхме много щастлив, че нито един член на отбора не излезе от него, но ако това се случи, то може да се превърне в голям проблем. Само си представете, че си художник отива в средата на даден проект. И това, което е по-лошо, той не оставя правото да използва работата му върху. Разбира се, този проблем може да бъде решен в зависимост от наличието на договора, но търсенето на нов изпълнител ще бъде досадно. Използването на две различни художествени стилове в един проект ще бъде проблем.
2. Това отнема голямо количество (4-6 цифри) за поддържане на сървъри.
Това не е вярно. Видях много сървъри с лимит от 1000 GB / месец
3. Създаване на MMORPG много вълнуващо.
Това също не е вярно. Може би си мислите, че всичко ще бъде симпатизират на вас, играчите ще ви помогнат да бъдете в състояние да направи иновативни куестове, и няма да има много играчи в играта си. Играчите могат да бъдат досадни. Дори ако това е напълно безплатна игра, те все още се намери причина да се оплачете. И най-неприятните - хората често се оплакват от абсолютно противоположни неща. Войниците не обичат, че е необходимо да се получи ново ниво дълго време, докато търговците ще бъдат разочаровани от факта, че войниците получават много пари с трофеи. Ако се намали недостигът на чудовища трофеи, някои хора ще заплашват заминаването му от игра. Ако увеличението - същите хора ще са недоволни от факта, че сега дори и начинаещите могат лесно да се правят пари. Но за да го оставите като това е - не е най-добрата идея. Тук е необходимо да се използват нови идеи и подобрения. Ако решите да промените нещо, например, са добавили нови предизвикателства за тези, които произвеждат предмети, някои ще кажат, че е твърде трудно. Ако не направите това - те казват, че е много лесно или скучно. Трябва да се помни, че повечето от играчите, обикновено не се казва нищо и сте напълно доволни от всичко, а някои част винаги ще се оплакват.
Икономиката в MMORPG е много по-трудно да се балансира, отколкото в играта за един играч. В един играч може постепенно да се подобри оръжията, така че играчът е постепенно да се движим напред, може да получи най-доброто оборудване, хвърлянето (или продажба) на старото. В мултиплейър игра, този подход се провали, тъй като всеки ще се опитва да получи по-добри оръжия, като се игнорира най-лошото. Много от играчите предпочитат да не първо да използват оръжията, и да запази финанси за покупка веднага след най-доброто от възможните оръжия в играта. Развитието на икономиката заслужава своя собствена статия писмена форма.
Всичко, което имам изброени до този момент, заедно с допълнителна работа и предизвикателства трябва да ви накара да мислите най-малко два пъти, преди да предпочитат такъв сериозен проект. Трябва да се разбере всички последици по Ваш избор.
Заключение.