Най-подходящия (скриптов, динамичен?) език за програмиране на MMORPG?

Чудя се, донякъде абстрактно … седя, и си мисля … (по някое време осъзнавам, че само седя; оказва се обаче, че всъщност джуркам все пак някаква висша мисловна дейност, но на друго, различно от съзнателното ниво, егати изречението в скоби, както и да е) кой ли ще да е тоя най-подходящ за масова онлайн игра динамичен език за програмиране?

Искам да подчертая, че тук не визирам такива бездушни маркетингови машини за пари от сорта на УоУ, нито подобни собственически формати както тъпото диабло, примерно.

Имам в предвид игри от сорта на Ogame, Bulfleet, Omerta, Eve Online, Runescape, Ultima Online, Lineage 2, и т.н. в този дух.

В този вид игри има редица особености – който е имал повечко време вземане-даване с тях, знае. Като начало, имаме хиляди играчи на един сървър/свят/вселена или каквато е там мерната единица на съответната игра. В някои случаи десетки хиляди. За стотици хиляди не съм чувал, но нищо чудно просто да не съм достатъчно информиран. Дори и в момента да няма, в недалечно бъдеще тази цифра обаче си е съвсем реална. Проблеми се появяват, когато всичките се изсипят онлайн в кратък, много близък интервал от време, и започнат активно да цъкат по строежи, конструкции, изследвания, войни, бойни единици, търговии, разузнавания, организации и комуникации … Това генерира огромен, трудно компресиращ се и кофти за управляване и разпределяне трафик. Освен това, натоварва страшно и самият софтуер, както и машините, дето се грижат за игрите. И на последно място създава работа на хората, дето се предполага, че трябва да се грижат цялата галимация да не се смърънгяса тотално :).

Грубо опростяване и обобщение, но върши работа, май. Сега – за хардуера – не е голям проблем. Винаги може да се добавят още памет, процесори, клъстери, нови машини дори. За някои от дейностите хора също ще се намерят – дори и за без пари, буквално! Най-големи ядове обаче в един момент започва да създава софтуера. Избора на среда, скриптов/динамичен език за програмиране. Сървърна технология.

Какво става в най-натоварените часове? 5 000 потребителя, които са едновременно онлайн, и като цъкнат нещо, в зависимост от върнатия резултат пак цъкат, за да стане нещо друго, и това го правят по 20 пъти в минута. Ако данните са само текст – има си трикове. Ако има и изображения – тегаво, но все пак и там има заобиколни решения. А ако всичко това е свързано в динамична триизмерна координатна система? Бр-р-р- … не ми се мисли :).

Изброявам няколко по-популярни, без да се задълбочавам в достоверни изследвания.

PHP – върши работа, но не е подходящ за НАИСТИНА ГОЛЕМИ натоварвания. Колкото ще да е бърз хардуера, и да е фино тунинговано апачито, и оптимизиран самият код – при няколко хиляди човека издъхва.

Perl – по-добро, особено, що се отнася до текст. Но и той си има кусури, не знам как би се оправил в примерната ситуация … трудно ще е, вероятно.

Python – това не знам, може ли да се използва ефективно с такава цел?

JavaScript – не, не е шега – само че не смея да предвиждам резултатите при такива натоварвания …

Ruby (on Rails, or without them) – това веднъж като зареди, и ако не му се подават глупости, може и да се справи … или не?

Други?

Осъзнавам, че има прекалено други фактори, които влияят – много важен е избора на структурата и формата на база данните, чистотата и оптимизацията на самият писан код, конфигурацията на сървърите, платформите, много са. Разбира се, винаги го има фактора пари – даже е още по-важен на фона на световната финансова криза. Да приемем, че в случая няма чак такова значение. Нека все пак разходите да бъдат … разумни? Бива, разбрахме се. Много неща са навързани, отговора не може да бъде прост и елементарен … но все пак, може да се опита с нещо семпло.

Искам да попитам всички – седящите, четящите, мислещите, знаещите, можещите, предполагащите и съмняващите се – кой според вас е най-подходящият език за програмиране на масова онлайн игра и защо?

11 thoughts on “Най-подходящия (скриптов, динамичен?) език за програмиране на MMORPG?

  1. Струва ми се, че задаваш въпроса си неправилно. За целта, която поставяш – писане на MMORPG игра няма подходящи и неподхоящи езици. Всичките изброени (както и много други) биха свършили чудесна работа. Всъщност, ако започнеш да пишеш подобно нещо, най-последния ти проблем бъде езика. От гледна точка на сървърите, тези игри не са нищо повече от една натоварена, web базирана информационна система. За да можеш да имплементираш една такава игра, на какъвто и да било език, трябва да седнеш и да направиш модел на данните. Трябва да имаш точно определени правила на играта и да успееш да съобразиш къде са критичните места. После избираш подходящите алгоритми, структури от данни и почваш да пишеш – на любимия ти език. До колкото съм чувал игрите на Blizzard се движат на огромни ферми от сървъри и наистина много народ се грижи за да работи всичко както трябва. Принципите обаче са тези и не мисля, че езикът е от някакво особено значение в случая.

  2. Езикът не ти е проблем, и аз съм съгласен с Кирил. Коментарите към езиците, които даваш, са неважни ;) Всеки език ще ти свърши работа — за такива натоварвания, каквито имаш предвид, по-важното е какви са железата отзад. Повечето игри, които споменаваш, са уеб-игри. Значи важно е и каква е операционната система и какъв е уеб-сървърът. Доколко всички тия три неща, желязо, ОС и сървис, могат да се надстройват, scale-ват и т.н.
    Езикът ти е най-малката грижа. Ако наистина става дума за сериозни натоварвания. Съмнява ме мен, че в една уеб-игра има големи (ама наистина големи) натоварвания. По-скоро е средна работа, особена ако е на български език ;)
    Най-добрият език е този, на който можеш да пишеш, другото са подробности ;)

  3. Ботълнека на подобни системи не е скриптовия език, а базата данни. Кеширането е близко до невъзможното. Вероятно бих избрал онзи език, който владея най-добре – а именно PHP.

    Предвид простотата на заявките, с много начинаещите ми познания по RoR, мисля че Rails е чудесен избор за MMORPG.

  4. Ех, пустите бази данни … така не обичам да се занимавам с тях, там ми е мътна история. Още от времето на дибейс, фокспро … Като опра до SQL и всякаква съобразителност и креативност се изпаряват. В някакъв момент се занимавах и с информикс, където също нямах особен успех.
    Затова и не го правя :).

  5. Да не си решил да създаваш подобна игра?

  6. Критична е както бройкта на сървърите, така и тяхната организация …
    не на последно място и езика …
    а кеширането е въпрос на RAM ;-)

  7. Аз мога да кажа две думи само и единствено за ММОРПГ игрите тип World Of Warcraft, Warhammer Online или Eve Online.

    Това са си пълноценни игри, всички без изключение написани на C/C++ и ползващи отчасти скрипт език за вътрешната си логика (но не и за предаване на данни по мрежата или подобно – там всичко е C/C++). Обикновено скрипт езика е Lua, но както казах, той се ползва предимно за вътрешни цели като например за потребителския интерфейс в World Of Warcraft.

    Всичко това до момента е клиентската част. Тази, която аз и ти си пускаме на компютрите. Тя се връзва обикновено с така наречения backend. Въпросния backend всъщност е набор от програми и бози от данни движени от купчина съвръри. В случая с WoW говорим за над 15000 сървъра разпоожени физически в Щатите, Франция и някъде в Азия. Има си сървъри за клиентския профил, за самия игрови свят, за auction house-a, за дънджън инстанциите и за какво ли още не. И то не точно сървър, а клъстер от сървъри. Обикновено въпросния backend е също C/C++ програма, която движи под Linux. Ако и да се ползва скрипт език, той определено не е основен за нея и е по-скоро допълнение.

    Може и да бъркам малко някои от горните факти, но доколкото знам така стоят нещата.

  8. Определено езика има значение от гледна точка, гъвкавост на изграждане на системата. В една такава игра най-ценното нещо е разпределянето на натоварването върху съществуващите сървъри и поддържането на някакво кеширане.
    Играта е проста – Имаме Web приложение което не е много натоварващо и имаме база данни която е проблематичната част. Едно разпределено приложение с поддръжка на кеширане на данни от базата данни е най-подходящо ако ще има голямо натоварване от гледна точка брой потребители едновременно. Правилно планиране и използване на сървър сайд скриптове комбинирани с поставени на място AJAX допълнения правят изключително мощен и гъвкав интерфейс, което би направило играта много гъвкава и приятна за игра за потребителите.
    Аз бих заложил на използване на по-мощен и модерен език от сорта на Java или C# за сървър сайд часта, и съответно JavaScript или C#Script за интерфейса. Базата данни е ботълнека на такива системи. За това ако се спра на Java най-малкото бих ползвал Postgrey. MySQL или SQLLite не са подходящи. Ако се прави сайта на C#, SQLExpress е добро решение като скорост на достъпа, но има ограничение на броя конекции и размера на файла.
    Използването на частично кеширане на данните от базата би разтоварило натоварването от базата, но означава че тънкостта ще се пренесе във връзката между Web приложението и базата данни. Индексиране на страниците с въвеждане на timestamp и флагове би позволило на една гъвкава система да определя колко скоро дадена страница е била създадена и колко време да се запази в кеша. С въвеждане на флагове може да се индикира кога и дали една страница има нужда да се презареди от базата данни. Всичко е въпрос на хардуерен ресурс в такъв момент.

  9. Брей, колко много коментари по темата. Езици, бази, кеширане, сървъри, клиенти, ама никой за алгоритми и думичка не казва. Ще дам едно просто примерче – да кажем, че поради незнание решите да ползвате алгоритъм със сложност O(n) на едно критично място в системата. При n = 1000, ще изпълните 1000 операции вместо 1. Защото на такива места се използват само O(1) алгоритми. Казано по друг начин, на вас ще ви трябват 1000 сървъра, за да можете да свършите работата на 1 сървър, при добре написана система. Толкова за хардуерните ресурси и езиците за програмиране. На freeico искам да му кажа, че до момента не съм чувал за „Postgrey“ или „SQLLite“. Момчета, стягайте се и четете, защото сега само си чешете езиците, но утре може да ви се наложи да напишете някоя сериозна система и тогава не ми се мисли…

  10. Относно забележката ти за JavaScript, не мисли прибързано :)
    За пример виж на Гугъл проекта V8 или другите подобни неща на WebKit за компилиране на JavaScript -> byte code. Това е теорията, а практиката бих те насочил към Аptana.org, където можеш да намериш сървър (Jaxer) за подобни приложения + лесен за използване метод за клъстерване на този сървър. Всичкото това звучи великолепно на _теория_, но си има и куп минуси – идеята ми беше, че JavaScript не е бавен, броусърите са :)

    Относно до езика, говорейки за сложности и прочие, за да си проектираш всичко като сериозна система бих ти препоръчал един единствен език: Java (нещо го нямаше в списъка). Тук ще каже някой, че и тя е много тежка, но не е точно така :)
    Ако сложиш цял application server + 12 000 чудеса и библиотеки да. Но ако си вдигнеш едно приложение за играта на jetty с чиста Java + го клъстернеш и пуснеш само отпред едно прокси действащо като лоуд балансър, с 2-3 сървъра за самия уеб ще имаш доста добри резултати, а системата ти ще е лесна за „доразработване“ (каква дума измислих)

    От някаква си..така да я нареча „трета“ страна, в днешно време има ли смисъл от езика, можеш да помислиш как да изградиш цялостна SOA архитектура и така да работиш с 30 езика, всеки които за каквото ти е удобен :)

    По базата, да тя е много важна и лично според мен е най-големия проблем на всички large scale web applications. Това да подържа голям read/write паралелно го няма никъде, а реално е най-важното нещо при база данни за уеб. Ровил съм доста из нета и единственото, което мога да препоръчам е ако пък имаш чак толкова голямо натоварване, по добре си дръж нещата в рам (клъстер) и си пази query log-овете. Звучи много трудно..но не е чак толкова :)

    Това е от мен, надявам се да съм спомогнал с нещо за теорията ти :)

Вашият коментар

Вашият имейл адрес няма да бъде публикуван. Задължителните полета са отбелязани с *

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните ви за коментари.