Как се създават компютърни игри

[Avatara]

В този раздел мисля да пофоровим за това как се създават компютърни игри. Ще поговорим за "спрайтове", изометрия, псевдо и реална 3D и 4D анимация, за DirectX и OpenGL, за спецификата при създаване на gamе engine при използване на Delphi (RAD Studio), C# (Microsoft Visula Studio), Flash и др..

Ще поговорим за художници, 3D скенери, модели и manga. Към всяка статия ще има богат илюстрационен материал, както и конкретни примери.

И така да започнем ...

. . .

ВМЕСТО УВОД

I. DirectX – началото на всичко

Едва ли мнозина ще си спомнят времето, когато съществуването на DirectX беше поставяно под въпрос. В онези години никой не предполагаше, че ще се стигне до следваща версия, а още по-малко, че фирмите производителки на видеокарти ще се надпреварват да гарантират хардуерна подръжка на на подобно творение. Малцина специалисти познаваха компонентите поддържащи доста ограничен набор от Win32 функции, известни като DX3.0 и Direct Input. Но дори тогава беше налице тенденция към платформена независимост защото едва ли някой може да бъде убеден в непреходната същност на поредната SDK.

Ако на експертите вече им е станало досадно или ги е налегнала носталгия, могат да пропуснат следващите редове.

Нека се опитаме да формулираме какво представлява DirectX.

Най-общо това е набор от мултимедийни драйвери (не ги търсете в компютъра, все пак това са просто програми, написани от някой друг), които заобикаляйки стандартните функции на операционната система ни позволяват да работим директно с интерфейса (клавиатура, мишка, джойстик, монитор, звукова карта) като при това успяваме да използваме изцяло апаратните възможности, предоставени от производителя. Важно е да се знае, че съществува цял набор от Win32 сервизни приложения, които използват DirectX, като свое ядро. Или ако трябва да синтезираме казаното до тук то ще достигнем до следното

ОПРЕДЕЛЕНИЕ

DirectX е набор от мултимедийни драйвери на високо ниво.

Важно е да се знае, че между DirectX и интерфейсът (видео или аудио-карта например) стоят и драйверите, които са написани от производителя. Най-общо последователността на взаимодействие изглежда така:

DirectX се състои от няколко основни компоненти. Всяка една от тях обезпечава функционалност в определено направление както следва:

 DirectX Graphics - 2D/3D графични изображения и анимация.

 DirectShow – Поточно видео.

 DirectInput – Управление на входните устройства (мишка, клавиатура, джойстик).

 DirectSound и DirectMusic – Звук и звукови ефекти.

 DirectPlay – Стандартен интерфейс за създаване на мрежови приложения на база различни мрежови протоколи и провайдери (провайдерите са тези, които доставят internet услуги до домашния ви компютър и често са безпричинно ругани за това, че се опитват да бъдат нормални хора)

 DirectSetup – API чиято задача е да облекчи инсталирането на DirectX при крайния потребител

Голяма част от функционалността на DirectX се основава на използването на обектно-ориентирания COM модел, който ни позволява достъп и управление на отделните обекти посредством стандартен интерфейс. Изхождайки от казаното следва, че интерфейсът представлява клас, съдържащ в себе си указател към функции, които ни позволяват да взаимодействаме с обектите.

DirectX не е първият опит на Microsoft да превърне Windows в игрова платформа. Първият такъв опит се наричаше WinG API. Като цяло работеше основно с растерна графика и не успя да получи широко разпространение, макар с негова помощ да бяха създадени такива игри като първообраза на всички съвременни стратегии “Civilization”.

Ако следваме някаква хронология то още през 1995 година след появата на пазара на Windows 95, Microsoft пускат първата Game SDK – което е и прототип на DirectX. През 1996 година се появява Microsoft Developers Kit и DerectX 2, като към функциите за обработка на растерна графика са добавени и такива за работа със звук, мрежови и управление на входни устройства. Но истинското развитие на платформата настъпва с появата (обърнете внимание отново през 1996 година) на DirectX 3. За първи път се заговаря за Direct3D. Не може да не подчертаем изключителната функционалност на продукта (за сведение всички функции са достъпни дори при NT 4.0). Петата версия се появява през 1998 година. Не се учудвайте. Четвърта версия няма. Обновена е функцията DirectInput или ако трябва да бъдем конкретни тя става напълно независима от функциите за управление на входа, на операционната система. През същата година се появява и шеста версия Direct3D (DirectX 6), която поддържа мултитекстури, stencil и w-buffer-и. В края на 1999 година се появява революционната DirectX 7 и настъпва златното време на компютърната графика. За първи път става възможно използването на T&L (апаратни трансформации и засветяване на обектите). Производителите на видеокарти приемат безусловно DirectX.

С настъпването на 2000-та година на сцената се появява DirectX 8. Направена е поредната крачка към реалистичните изображения. DirectDraw прекратява своето съществуване. Новият продукт се нарича DirectX Graphics. Заедно с него се появяват и превърналите се в класика средства за разработка на софтуерни продукти на компанията “Pixar”. Следва версия 9 със всички предимства, които предлага.

Какво все пак налага да отделяме толкова място на развитието на една технология?

Преди всичко това е изконният стремеж на разработчиците да се абстрахират конкретен тип оборудване. Едва ли някой ще е готов да влага средства, усилия и време в разработка на игра, определен тип видео или звукова карта. Съществува ясна гранница между системното и приложно програмиране, за която си струва да поговорим. В първия случай става дума за разработчици на драйвери и съответстващите DDK (Driver Development Kit), а във втория – за тези, които пишат софтуер, използвайки вградените функции на DirectX SDK. Важно е първите никога да не забравят, че изискванията на COM стандарта повеляват да има приемственост между версиите, така, че всяка следваща да бъде в състояние да работи с програмите написани на предишната такава (след като веднъж е дефиниран COM интерфейсът не може да бъде променян по разбираеми причини).

Ако съществува алтернатива на DirectX то това е само OpenGL, тъй като редица негови компоненти са напълно самостоятелни. Независимо от бурното развитие на OpenAL и DirectSound, към момента те си остават просто надстройка на действаща операционна система. Независимо от подобренията, направени в девета версия на DirectX в частта D3DX, обработката на 3D графика, отстъпва чувствително на тази на OpenGL, но нека не забравяме, че още от момента на създаването си DirectX е ориентирана към растерни, а не векторни изображения.

Когато трябва да се направи избор между един или друг API компонент е нужно внимателно да се проучи неговата спесификация, както и възможностите за импортиране на DLL-библиотеките. Никога не забравяйте, че не винаги производителността е определяща.

Към момента съществува ясно изразена тенденция при разработката на игри програмистите да използват DX интерфейс или OpenGL, без допълнителни библиотеки за работа с графичните изображения и устройствата за вход. Що се отнася обаче до мрежовите и звукови функции все още се отдава предпочитание на това, което е заложено в самата операционна система. Това се диктува от факта, че независимо какво се твърди DirectPlay си остава тънка надстройка над системните функции. Единственото, което би предизвикало някакъв интерес е стандартизацията при работа с библиотеките. Още повече, че някои от ярко изразените лидери, като Miles Sound System и безплатните (за некомерсиални цели) OGG и OpenAL, налагат свои изисквания. Когато се говори за видео не бива да се пренебрегва SMK/BNK формата, както и библиотеките за работа с него.

Както сами може да се убедите, към момента не е предложена сериозна алтернатива за генериране на анимирани изображения и работа с растерна графика. От версия 9 на DirectX на разработчиците е предоставена възможност за работа с HLSL (High-Level Shader Language) – което е своеобразен език на високо ниво. Единствената алтернатива към момента е предложението на NVidia наречено Cg. Най-вероятно е езиковите платформи да продължат да съществуват успоредно във времето, подобно на D3D и OpenGL.

Много по-интересно е завръщането в деветата версия към взаимодействието с GDI, а също така и на функциите StretchRect() и ColorFill(). Това ни навежда на мисълта за предстоящото възраждане на DirectDraw.

Редица въпроси поставя и появата на MultiHead-функции, които позволяват извеждане на изображението на няколко отделни монитора (ако видеокартата е снабдена с няколко DAC преобразователя). Може би към момента използването на тази функция да е скъпо удоволствие, но в бъдеще, когато вероятно ще се наложи на мнозина да пишат софтуер за виртуална действителност, тези опции ще се превърнат в определящи при проектирането и изготвянето на цялостната стратегия на разработка на игри от ново поколение.

Повече информация за DirectX:

Microsoft DirectX - Официална странница

[Avatara]

II. DelphiX или правото на избор

И така стигнахме до момента, в който колкото и да не желая ще се наложи да поговорим за избора на език за програмиране.

Както вече упоменахме съществува два вида програмиране, а именно системно и приложно.

Създаването на игри или програмирането на тяхното ядро (което занапред ще наричаме “game engine”) се отнася към приложното, а не към системното програмиране. Игрите са предимно пазарен продукт и като такъв те трябва да гарантират максимална печалба при минимум вложени средства за първоначална инвестиция. Когато работите по голям проект е от изключителна важност да документирате всичко извършено на всеки етап от проекта. Още по-важно е обаче да гарантирате, че това, което сте създали ще работи.

Преди години се наложи да участваме в колектив, чиято задача беше да изготви примери към учебник по компютърна графика. Всички примери бяха написани на C++ и работеха прекрасно. Получихме добра оценка за своята работа, но един внимателен анализ ни доведе до твърде нелицеприятни изводи. В процеса на отпечатване бяха допуснати редица технически грешки, останали незабелязани за редакторите. Макар алгоритмите да бяха издържани във всяко едно отношение, самите програми не бяха достатъчно разбираеми за начинаещите програмисти въпреки коментарите към тях. Кодовете бяха написани с цел да впечатлят, а не да научат.

При избора на език, на който да бъдат съставени базовите примерите, изхождахме от необходимостта да се демонстрират предимствата на обектно ориентираният модел (COM - Component Object Model) на програмиране, без да се налагат излишни и в редица случаи объркани пояснения. Важно за нас бе и да се избегне в максимална степен обвързаността с конкретна операционна система или набор от апаратни средства.

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

Предполагаме, че мнозина биха ни опонирали, застъпвайки тези, като тази за бързодействието при използване на един или друг компилатор (C++, C#, VB и др.).

Подобни твърдения отдавна са лишени от каквото и да било основание. Целта ни е да анализираме различни подходи от чисто приложен характер. Това изисква да се придържаме към определена линия на изложение, доказала своята ефективност.

Освен изграждане на добър стил Delphi формира и своеобразна дисциплина в мисленето, което може да се окаже изключително полезно, особенно ако сте решили да се занимавате професионално с програмиране. Мисля, че така изложените аргументи ще помогнат да бъдем разбрани правилно.

И така след като сме приключили с избора на език за базовите примери е време да пристъпим към изучаването на DelphiX. Макар мнозина да приемат, че DelphiX е своеобразна надстройка на DirectX, на практика, това не е така. Всички компоненти в една или друга степен притежават относителна самостоятелност. Въпреки това в началото ще се придържаме стриктно към класическото определение, а всички допълнителни пояснения ще илюстрираме с примери.

ОПРЕДЕЛЕНИЕ:

DelphiX представлява набор от визуални компоненти, чиято задача е да позволят максимално лесно и удобно използване на цялата мощ на DirectX, при разработката на графични приложения.

Основните компоненти в DelphiX са:

• 
  
  
• DXDraw - Позволява бърз и удобен достъп до до повърхността на DirectDraw (всъщност това е просто DirectDraw)
  
• DXDib - Съхраняване на изображения в DIB (Device Independent Bitmap)
  
• DXImageList - Позволява съхраняване под формата на списък на DIB, JPG, BMP-файлове, което е безкрайно удобно при работа със спрайтове. Позволява също така зареждането на DIB, от диск по време на изпълнение на програмата
  
• DX3D - Direct3D компонент. Използва се основно при работа с тримерна графика.
  
• DXSound - Позволява възпроизвеждане на звукови файлове в wav формат
  
• DXWave - “Контейнер” за wav-файлове
  
• DXWaveList - Позволява съхраняване под формата на списък на серия от wav-файлове
  
• DXInput - Директен достъп до входните устройства (мишка, клавиатура, джойстик). Използва DirectInput
  
• DXPlay - Използва се основно за MyltiPlayer приложения. Позволява обмен между различни компютри при използване на стандартни, мрежови протоколи.
  
• DXSpriteEngine - Анимираща машина. Използва се основно при работа със спрайтове.
  
• DXTimer - Системен часовник
  
• DXPaintBox - Алтернатива на TImage но в DIB вариант
  

В DelphiX съществуват както самостоятелни така и спомагателни компоненти. Например компонента DXSpriteEngine не може да бъде използвана самостоятелно, а само с DXDraw.

Познаването на DelphiX ще ни помогне да усвоим един специфичен подход на програмиране. Това е важно когато пристъпим разглеждане на методологията за създаване на определени групи игри (стратегии в реално време, логически игри, игри от първо лице и др.).

Забележка: Към момента изучаването на DelphiX е залегнало като основен предмет в редица престижни училища в Япония, САЩ, Европа, Русия и др.. За съжаление в България, поради наложени стериотипи (или неразбиране), това си остава една доста непопулярна тема.

[Avatara]

Днес ще си позволим да излезем извън темата.

Една от причините за това е приключилата в петък 23.04.2010 год. конференцуя "Software people 2010".

Заедно с появата на т.н. "четвърта вълна" в IT все по-често ще говорим за ролята на "човешкия фактор".

Та в този ред на мисли ето една информация, която би дала повод за размисъл на мнозина.

В началото на месец март 2010 год. ръководството на Activision буквално изхвърли на улицата Джейсон Уест (Jason West) и Винс Зампела (Vince Zampella), които успешно ръководеха студиото Infinity Ward през последните години (няма как да не сте чували за Modern Warfare 2.В EA). Именно те донесоха милиарди пречалби на своите инвеститори.

Какво се случи след това?

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

За анализаторите си оставаше пълна загадка какво се случваше с Тод Алдерман (Todd Alderman) и Майки Маккандлиш (Mackey McCandlish), едни от най-великите аниматори на нашето съвремие - Марк Гризби (Mark Grisby) и Джон Пол Мезерли (John Paul Messerly), водещият ландшафтен художник Крис Черубини (Chris Cherubini), инженера по разработките Рейм Винсон (Rayme Vinson) и програмиста Джон Ширинг (Jon Shiring).

Днес обаче тази загадка е разрешена.

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

Според официални публикации Respawn Entertainment ще започне да функционира от месец май. Имайки в предвид какво направи този екип до момента може само да предполагаме какво ни очаква.

На практика това е пореден случай, в който алчни инвеститори заклаха кокошката, която снасяше златни яйца. За пореден път някои са забравили, че годината е 2010, а не 1980, но ... за това има една доста неприлична фраза, която не е редно да споменаваме на обществени места.

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

Георги и Павел Герасимов

P.S. Kакто нееднократно сме казвали:

"Разработчици от всички страни ... забавлявайте се."

След като не ви оценяват, просто направете по някой милиард за самите себе си. Парите няма да ви навредят съществено.

А тези, които все още вярват в оутсорсинга ги забравете. Нямаме време да връщаме заблудените в правия път, а и не сме чак такива светци.

[Galahad]

Много интересна тема. Надявам се, че някъде ще има "примерче" на български език как се прави някоя игричка (за примерчето се предполага елементарна). То има доста напътствия, ама са все енглизирани, даже и визуализираните и качени в YouTube. Тъй че и едно съвсем простичко примерче на български език ми се вижда много полезно.

Редактирано Април 26, 2010 от Galahad

[Eньо]

  On 26.04.2010 г. at 17:59, Galahad said:

Много интересна тема. Надявам се, че някъде ще има "примерче" на български език как се прави някоя игричка (за примерчето се предполага елементарна). То има доста напътствия, ама са все енглизирани, даже и визуализираните и качени в YouTube. Тъй че и едно съвсем простичко примерче на български език ми се вижда много полезно.

Има си сайтове, на които с няколко кликвания си правиш игричка.

Ето една флаш онлайн в която можеш да стреляш до насита по бате Бойко, която направих пробно.

Като зареди натискаш Play. Survival и стреляш...

http://www.pictogame.com/en/play/game/eH0mexTeoFAp_sniper

[Avatara]

Здравейте,

Ще има примери и то какви. Искам все пак да подчертая нещо много важно:

Темата е за това как се разработват комерсиални игри, които носят печалби от няколко милиарда (не е грешка, а точен анализ).

Преди много години, когато посетих за първи път в живота си Прага, бях очарован от този прекрасен град. Тогава нямах и най-малка представа, че живота ми ще бъде свързан с тесните улички на Мала Страна и красотата на Вацлавски намести. Бях млад и се наслаждавах на сладникавия вкус на бехеровката в някоя уютните малки кръчми в дъждовните нощи.

Сега много от тях не съществуват. Бяха заменени от модерни бутици.

Защо пиша всичко това ли?

Защото ние българите много обичаме да казваме колко велики програмисти сме, но опре ли да покажем нещо "конвертируемо" не сме в състояние. Оутсорсинга е като проституцията - продаваш се на дребно, а и няма никакво достойнство в цялата работа. Чиста проба слугинаж и самочувствие без покритие, водещо само до упадък.

Днес ще ви запозная с една група разработчици от Чехия (макар това да е относително, тъй като и Моравия е в гранниците на тази държава).

Не знам колко от вас са чували за Bohemia Interactiv. Игрите, които те правят, не могат да бъдат направени с "едно кликване на мишката". Тук се използват воксели и много линейни уравнения, приложени за първи път в Stalker. За всичко това ще говорим на един по-късен етап, както и ще разгледаме различни аспекти на създаването на компютърните игри. В конкретния случай става дума за един малко познат в Българи жанр, а именно "тактически симулатор".

Това е доста по-сложно от обикновенна стрелба от първо лице. В ARMA 2 се налага да решавате задачи, максимално близки до реалните. Забавно е, че във версията, която предстои да излезе на пазара на 29 юни 2010 година действието се развива в държава, наричана Такистан, като пейзажите силно наподобяват тези в Афганистан. Забавно е, че събитията в първата версия на играта се случват не къде да е, а в Чернорусия, която пък напомняше на Чечня.

Но да се върнем на темата.

Преди да бъдем в състояние да създадем игра, поне малко наподобяваща тази на чешките ни или американски колеги е нужно да се запознаем с основни елементи "от кухнята" на игрите.

Ако сте чели внимателно, написаното, ние започнахме от DirectX. Посочихме, че друга технология е OpenGL. Разликата между двете е повече от определяща за избора на стратегия на разработка. В единия случай ползваме векторна, а в другия растерна графика.

За да може да създаваме игри, които да бъдат конкурентни на този динамичен пазар е нужно да познаваме и двата подхода. Не си мислете, че това, което намирате тук и там в мрежата ще ви научи как точно се правят игри. Всичко се крие в малките трикове, и принципите на анимацията (класическа или кинематична), които се пазат ревниво. Друг момент са елементи като изкуственият интелект на играта. Проблемът там е, че технологиите са същите, като тези които се използват за управлението на високоточните ракети в съвременните войни и за това сме отделили специална тема.

Играта, която Еньо е дал като пример е Flash-игра, която използва технологията на "спрайтовете".

И ако си мислите, че "спрайт" е безалкохолна напитка, която прави много мехурчета, то не грешите. Наименованието "спрайт" идва именно от нея.

Какво всъщност представляват спрайтовете?

Спрайтовете са последователност от кадри.

На практика те по нищо не се различават от кадрите върху една филмова лента и при тях се използват принципите на класическата анимация.

Следващата тема (специално се посвещава на Еньо и Galahad) е за спрайтовете и как се използват.

За да експериментирате обаче е нужно да разполагаме със среда за разработка.

Както вече съм писал, аз лично предлагам да се научите да го правите на Delphi, ако се отнасяте сериозно към игрите. Като начало може да изтеглите Turbo Delphi от официалният им сайт:

Turbo Delphi

Следващата стъпка е да инсталирате DelphiX. Вижте и това, което Марко Канту е написал по темата в официалния си блог. Ако имате проблеми с Delphi, може да вземете от библиотеката, прекрасните книги на този удивителен човек. Всичко е на български език и има много добри примери и обяснения, които ще ви научат на невероятни неща.

Официалният му блог се намира на адрес:

(Marco's Tech World).

Ще остането безкрайно изненадани, когато разберете, че на практика няма разлика между писането на програми (игри) за Windows, Linux, PS3, XBox, за различните модели на GSM или дори за iPad когато ползвате Delphi.

Забавно е, а и спестява много проблеми, свързани с видеокарти, монитори, аудиосистеми, различни периферни устройства и т.н.. Там материалите са на английски, но ... имаме много добри статии на български, писани през годините за различни издания, които ще публикуваме.

Все пак ако сега започвате и имате затруднения с инсталирането на Delphi X, най-добре е да го направите автоматично. Ето адреса, откъдето може да свалите програма, която ще добави всички нужни визуални компоненти към Turbo Delphi:

Delphi X Instalation

Защо предлагаме точно този подход?

За да ви спестим редица сериозни юридически неприятности и много, много пари, които просто няма от къде да вземете.

Дори при Linux се заплащат лицензионни такси (и то не малки), а за тестване и други необходими неща (като специални знаци, стикери и пр.), без които няма да можете да продадете и едно копие ще се наложи да се бръкнете доста дълбоко. Причината за това е ЕС и безумното законодателство, което бюрократите в Брюксел са приели. Все пак разработчиците и софтуерните гиганти еднакво мразят политиците и за това се подкрепяме и си помагаме с каквото можем. В този бранш няма "големи" и "малки". Има "кадърни" и "некадърни". Само от самите нас зависи, къде да бъдем.

Парите сами идват, когато има какво да покажете. За голи обещания сериозни пари няма да получите, а и е нужно да се докажете и да положите усилия (в България точно тази част от работата най я мразят).

Компании като Microsoft (виж BizSpark), IBM (виж Develop&deploy), Embarkadero (тези направо купиха cNet i Jedy) и др. са достатъчно предвидливи, за да ви дадат шанс да започнете. Те ви предоставят безплатно всичко необходимо за да работите. Дали ще го направите е друг въпрос.

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

Ние сме извървели много дълъг път и искренно желаем да помогнем. Ние не искаме нищо, а само да споделим опит и малкото знания, които са ни били предоставени. С нас са се отнесли човешки и ние се отнасяме човешки с вас. Ако обаче решите да ни плюете в лицето, то най-лесно е да предадем опита си на някой, който няма да го захвърли без преди това да помисли. Главата (освен за перископ на други наши органи) служи и за взимане на решения, когато се налага.

Kогато сте готови ще започнем нашето забавно приключение в магическия свят на компютърните игри. Както казваше един мой колега:

"По забавно от това да играеш на една игра е само това да я направиш ..."

А историята на България може да даде основа на много интересни стратегически игри. Има над какво да помислим.

Това е за сега. Обещавам да продължим по темата.

С уважение

Г.Т.Герасимов

G-System Development Group

P.S. Павел е на училище. Каквото и да ви казват големи пари се правят само и единствено с много, ама много учене и труд. Дори в наркобизнеса не печелят толкова, колкото се печели в IT-бранша (лични наблюдения), а и е конвертируем и с висока степен на принадена стойност (да ме прощават господата финансисти, аз имам малко по прагматични възгледи и не вярвам, че със селско стопанство и туризъм може да просперираме).

Усмихвайте се и не прощавайте на глупоста и злобата.

А преди години учехме чехите на програмиране.

После доморасли "експерти" им се подиграваха на образователната система. Били се спрели на Delphi и го изучавали детайлно в средния курс. Горките чехи. Чак ми идва да се разплача от съжаление ... Друго си е да си "велик програмист" в държава, в която думата на ЕС е закон.

[Avatara]

Време е за следобедното кафе и поредната порция разсъждения.

Ето още малко аргументи, касаещи избора на Delphi, като среда за разработка.

Нямам представа, защо масово битува заблудата, че програмите написани на Delphi са с по-ниско бързодействие от тези на C, C++, C# или друг език. Въпреки, че многократно съм изисквал да ми бъдат представени конкретни доказателства, основаващи се на резултати от тестове, такива никога не съм получавал, а и няма как да получа.

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

Защо това е нужно?

При разработката на игри работим основно с обекти.

Обектите се създават. Те имат живот. Те се развиват или биват унищожавани.

Пример:

Имаме герой, който ще ни представлява в един виртуален свят.

Той притежава определени свойства: сила, издържливост, скорост и т.н.

С нашия герой се случват определени събития: атакува враговете, правио магия, храни се, търси съкровища, язди кон, обучава се и пр..

Нашият герой е типичен пример за обект.

Той притежава всички елементи на един обект (свойства, събития, параметри).

Едно от често срещаните изисквания в съвременните игри е възможността да можем да правим героя такъв, какъвто ни харесва на нас. Да го обличаме с дрехи, които ни допадат. Да му задаваме едни или други качества. За едни той може да бъде по-бърз, но друг би пожелал да бъде по-силен или доруи по-умен (в редица игри това е голямо предимство).

Всичко това има непосредствена връзка с обектите.

Преди обаче да говорим за обекти ще поговорим за класове (class) и записи (records)

Класовете, се появяват цяло деситилети по-късно от появата на записите и това е разбираемо, ако проследим развитието на езиците за програмиране и развититто на Обектно Ориентираното Програмиране (ООП).

В Delphi може да ползвате както класове така и записи, защото на практика по своята същност става дума за едно и също нещо. Класовете са взаимствани от биологията, а записите от лингвистиката. И в двата случая е налице наследяване на предстви.

Нека илюстрираме думите си с пример.

Пример:

Ние създаваме Герой.

Нашият Герой има Име (Name). Името на героя е "Иван" (примерно).

Името се състои от символи.

Това се нарича символен низ.

Забележка: В Delphi обаче се ползва още едно понятие и то е стринг (String), за да се прави разлика между низ, състоящ се от PChar или AnsiPChar символи. Последното може просто да пропуснете.

Нашият герой има Сила (Power), която ще измерваме в интервал от 0 до 100. Сами виждате, че силата е цяло число с положителен знак. Ще прииемем, че силата е от целочислен тип или integer (цяло число със знак + или -).

Освен сила, нашият герой има и Живот (Vitally). Живота на героят ни се измерва също в цели единици от 0 до 100. Когато живота на героя стане равен на нула, той ще бъде мъртъв. Тук пак имаме цяло число.

До тук нашият живот има следните неща:

Герой:

1. Име (Name) - String

2. Сила (Power) - Integer

3. Живот (Vitally) - Integer

На практика ние създадохме запис "Герой", който съдържа три свойства.

Най-общо групирахме различни неща (променливи) в един общ блок.

Сега нека видим какво се случва когато ползваме запис (record) и когато ползваме клас (class).

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

Преди да преминем към окончателните анализи обаче се налага да погледнем и една друга страна на тестовете - какво се случва след стартиране?

Интересен въпрос. Съществуват разлчични форми на разпределение и използване на паметта на компютъра (забравете за операционни системи, тук говорим за основополагащи принципи). Темата е доста дълга и изисква една отделна дискусия, така, че за момента ще забравим за нея. Но не това е важно. Важно е, че една програма може да бъде пусната няколко пъти без да изключваме компютъра (нищо необичайно, нали). И тъй като всеки знае, че това е очевидна истина ние ще направим следното:

За да бъде коректен теста ще извършим не еднократен запуск на програмата, а десет такива, като всеки път ще отчитаме времето в ms, необходимо за изпълнение на програмния код.

Тук също се налага пояснение.

Не отчитаме времето за компилация, а времето за извършване на операциите в изпълнимите програми, т.е. тези, които вече са компилирани (готови за ползване от крайния потребител).

И така да видим какво се получава ...

Пример 1:

// Тук използваме клас

type

TTest = class

A, B, C: Integer;

end;

var

ArrT: Array [1 .. 1000000] Of TTest;

begin

for I:= low (ArrT) to high (ArrT) do

begin

ArrT:=TTest.Create;

ArrT.A:= 2;

ArrT.B:= 3;

ArrT.C:= 4;

end;

end;

При тестове на локална машина този код (при първо пускане) се изпълнява за средно 161 ms. При последващи пускания, времето се редуцира до 91 ms.

Следващият кода обаче се изпълнява за 9 ms:

begin

C:=0;

for I:= low(ArrT) to high(ArrT) do

begin

C:= C + ArrT.A + ArrT.B - ArrT.C;

end;

end;

Ако пренапишем кода, но използваме масив, състоящ се от записи, ще се получи нещо подобно:

// Тук вече използваме запис (record)

type

Rtest = record

A, B, C: Integer;

end;

var

ArrR: Array[1..1000000] of RTest;

begin

for I:= low(ArrR) to high(ArrR) do

begin

ArrR.A:= 2;

ArrR.B:= 3;

ArrR.C:= 5;

end;

end;

На пръв поглед няма, кой знае каква разлика, но проверката на производителността показва, че за изпълнението на кода във втория случай при първи пуск са нужни 17 ms и 9 ms за всяко следващо изпълнение. Обхождането и задаването на стойност на всеки един от елементите на масива, отнема 6 ms.

begin

for I:= low(ArrR) to high(ArrR) do

begin

ArrR.A:= 2;

ArrR.B:= 3;

ArrR.C:= 5;

end;

end;

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

Мдааааа ...

Ще премълча, че нормалната човешка реакция е от порядъка на 0,1 sek. След това на подсъзнателно ниво се появява леко раздразнение.

Какво показват така направените разсъждения:

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

И за да бъда разбран правилно нека си послужа със следния пример:

Пример:

Запознавате се в сайт за запознанства с прекрасна, млада жена (мъж или каквото ви допада). Снимките са главозамайващи. Видът ви кара да виете като изгладняло куче. Интелект, разговори и закачки, до момента на реалната среща ...

Тук настъпва ужасно разочарование. Жената-мечта (мъжът или каквото там се случи) е на годините на моята (не вашата, а моята) баба и с вид на кръстоска между Кощей Безсмъртни и шампион по сумо. Не стига това, ами и ви нарича "любими" ("любима" или каквото там се казва в подобен случай), а на вас ви идва да и наденете чувал на главата и да избягате в дън гори Тилилейски (доста приятно за обитаване място между впрочем).

Е ... И с програмирането понякога е така.

Съветът ми е никога да не приемате нещо за чиста монета, ако не сте го проверили.

Що се отнася до това как трябва да се пише програма, то тук темата е доста забавна и няма нищо общо с компютрите.

Такаааа ... Кафето е изпито. Беседата - проведена. Време е да продължим с рутинните задължения.

Приятен ден.

[Ventseslav]

Много интересна тема! Има ли продължение или някакви подобни теми за хора които се интересуват по задълбочено?

И коя е тази книга за която се пише?

[Avatara]

Здравейте,

Не знам дали Ventseslav ще прочете този пост, но все пак ще отговоря (с огромно закъснение от две години).

За огромно мое съжаление много от нещата вече са недостъпни за "гражданска употреба".

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

И още един пример - растерната градика се използва в системите за геолокация. Не знам дали си запознат, но ГЛОСАД си е доста сериозна военна система.

Или да поговорим с игрите с "морска тематика"?

Опитай се да се запишеш за студент в катедрата по океанология в някой от големите университети в Австралия. Никога няма да те допуснат до там.

Нямаш и най-малка представа, колко специалности в Русия (примерно) вече са абсолютно забранени за българи. Но така не е само там. Така е и във Франция, Германия, Япония (лични наблюдения).

Да не говорим за литературата.

Тезата, че "в internet има всичко" е не просто грешна, но и вредна.

Няма. Няма и няма да има.

За българското кногоиздаване да не говорим. Погледни само каква и с какво качество техническа литература е издадена през последните години.

Та питаш "Къде е книгата?", откъси от която съм цитирал.

Няма я вече. Засекретена е, защото написаното се оказа доста по-сериозно, отколкото сме мислели.

Така е и с "Изкустрово на кибернетичната война", Така е и с BS-технологиите.

За разлика от "експертите" в България в чужбина има хора, които внимателно следят къде какво излиза и кой какви ги пише и повярвай правят всичко възможно да ви се остави само онова, което за нищо не става.

Това се нарича "политика за сигурност".

Новите военни доктрини са добре забравените стари описани подробно в У-Дзин (седем секретни учения) в раздел "Гражданска война".

Сега ще ти дам само един пример, а ти сам ще си направиш изводите:

Пример:

В училища, университети и къде ли не не се изучава Delphi и как се разботи с RAD Studio XE8 (примерно).

Никъде не се учи как се работи в FireMonkey (FMX - гальовно наричана "Маймуняка"), Tethering технологиите (а това е бъдещето на мобилните комуникации и internet), BAAS, REST и пр. и пр. и пр..

Виж за Java, C# (който Delphi със синтаксис на C), Perl и пр. се пише много, че и непрекъснато се търсят такива "програмисти" (да се чете - "кодери").

Да ама кодерът не е и никога няма да бъде "програмист", а още по-малко "архитект". За там се изисква друга логика и други познания.

Въпросът е, че това, което може да се напише на Delphi от един човек за 79 минути се пише от десет високоплатени "програмисти" (да се чете - "кодери") за три месеца. Факт.

И след три месеца може и да не рабити както трябва. Това се нарича икономика.

И знаеш ли защо?

Защото цената на RAD Studio XE8 е 5 596 EUR без ДДС. И това е само за основния пакет.

Гроздето е високо, значи е кисело. Я да си караме на "безплатния" софт. Това е като да се сравнява Porche със селкса каруца.

Ето за това в България мразят Delphi.

Мразят го защото са бедни и никой не може да си позволи лукса да ползва професионални средства за разработка.

Ако обаче имахме политика, нямаше да е така.

Съвсем друга тема е доколко "академичната" общност е готова да използва това, което Embarcadero предоставя.

Тази общност бе заета да мрази и да организира протести, вместо да седне и да се заеме да върши това, което трябва.

И там става дума за "икономика".

Истината обаче е, че този вид "икономика" не допада на тези, които в момента държат "големите пари" (а те не са в Европа и САЩ). Никак, ама никак не им допада. Те за разлика от нас имат държавна политика в образованието и като учат нещо го учат както трябва. Там като се пише учебник той преминава през трима рецензенти. Така беше и в България, но на новите "академични деятели" това не им допада.

Искаш ли да ти споделя какво се случи когато обявихме конкусрс за обучение при нас?

Три въпроса, свързани с използване на.... Google. И при трите пълен провал. десетгодично момче в Чехия се справи по-добре от нашите "експерти". А иначе печелим олимпиади.

Когато обаче на учасниците им се плати за първи път (за участие по 1000 лева на човек), знаеш ли какво ми каза едно момче, което не пожела да се включи? Цитирам: "Ама Вие защо не казахте, че ще се плаща?".

Извини ме, но това е безумна логика.

Аз считам, че програмирането е занаят. В занаята има майстор, чирак и калфа.

най-голямата идиотщина е специалността КСТ. не може да си програмист, а да не познаваш елементарни дизични процеси при различните апаратни платформи. не може да си програмист за мобилни приложения, а да не познават TAPI. Не може да не знаеш защо трябва да се използват специализирани видеокарти при разработка на мултиплатформени приложения, а да си печелил олимпиада по "програмиране". Не може

Не се сърди на стареца. Аз си отивам. Аз бях от едно друго поколение. Сега пишем софт за устройства, които се управляват с мозъчни вълни, но няма кой да ни наследи.

Друго си е да пишеш нещо по-социално.

Извини ме още веднъж.

Ако наистина имаш интерес ще ме намериш. Ако имаш желание ще получиш копия на книгите. Ако си упорит ще се научиш.

С най-добри пожелания

Avatara

[kall]

Аватар, имаш интересни мнения и доста информативни, виждам, че може доста да се научи от теб, така че ако можеш, пиши по-често... Само ще питам за коя книга пишеш, че си цитирал и не била достъпна, нещо заглавие, подобни неща. Нали сега е модерно да говорят за Deep Web, Tor и подобни, не може да няма хептен нищо по тези въпроси там, ще ми е интересно мнението ти като специалист за този тип технологии.

[Avatara]

Здравейте Kall,

Книгите, които визирам са две:

"Въведение в програмирането на игри" - Всъщност това са три книги всяка с обем над 500 странници, в които може да се намерят много интересни практически примери, които не са описани никъде другаде. Части от тази книга може да прочетете в този раздел на форума, но това са много малки прашинки от цялото. В третата част има огромен раздел за изграждането на надплатформени приложения (Multi Device Application*), които в момента са абсолютен хит (все пак всичко е полудяло по мобилни устройства).

Другата книга, която споменах носи заглавие "Изкуството на кибернетичната война". Там определено нещата са много тежки и доста сериоани. За да добиете някаква представа може да прочетете доклада ми от конференцията по виртуалистика "Философия на кибернетичната война - теоретични аспекти на съвременните военни доктрини". За мое огромно съжаление дори след това все още има "експерти", които считат, че кибернетичната война е свързана със социални мрежи, компютри и пр.. Това е поредното доказателство за ширешщото се невежество и ще поясня защо. Не си спомням по времето на аристотел да са се използвали микропроцесорни системи, таблети или GSM устройства. Ако е имало "социална мрежа" то вероятно това е била кварталната кръчма.

Кибернетиката е наука за управление на процесите. Има огромна разлика между това "да контролираш" и това "да управляваш".

Още по болно ми стана, когато използваха термина "хибридна война". Това, че името ми никъде не бе спомената (а само преди две години ни се подиграваха, когато говорехме за "хибридни системи от четвърто поколение").

Хиобридната война има отношение към военните системи с изкуствен инстинкт, а не към пропагандните и дезинформационни методи. Тя няма нищо общо с internet, но това няма как да го докажете на тези, които просто използват един термин, без да имат и най-малка представа какво се крие зад него.

Тези две книги няма да намерите никъде, така както едв ли ще намерите един мой стар доклад, който е съвместтна разработка с доц.Пандов и др.Иванов, касаещ in-vivo взаимодействията на лекарствени средства.

В момента тези изсания се ползват само при "строго регламентирани процедури" (да се разбира гриф "само за служебно ползване" бр.екземпляри и пр.) и най-лошото е, че това се решава от хора, които не са българи.

А иначе аз си живея в България и се занимавам с фикалийни канали.

В internet няма да намерите много неща. Истински важните неща никога, ама никога не се допускат до мрежата.

Повярвайте ми не може и да си ги купите. Има редица неща, които едно, че не се продават, второ, че ако попитате някой дали ги има ще ви отговорят: "Какво? Това ли? А, а, а. а, не. Няма такова нещо.".

Все пак ще видя какво мога да направя.

С най-добри пожелания

Avatara**

* - Имаме си много хубави български термини за всяко нещо и е редно да си ги ползваме.

** - Avatara е почетна титла, а не псевдоним (alias). Аз лично си се гордея с нея, за разлика от титлата "д-р", която бе дискредитирана.

Редактирано Май 29, 2015 от Avatara

[Joro-01]

Ще ти отговоря после, че имам работа сега

[Joro-01]

Какво те кара да мислиш, че в нета няма книги за програмиране, даже достъпни?

Извън БГ торент сайтовете (не съм гледал там), аз мога да намеря много. Но на английски. Което обаче не е проблем за мен. Има на BG въведение или програмиране в C#. В тази книга се започва с концепциите - идеята да се схване. Namirat se za C++..., Питон Делфи, Java мисля видях..

И какъв старец си ако си 1961 г, извини, че оповестявам? Всеки влязъл в профила ти може да го види...

Добре дошъл отново! Бях забравил да ти кажа

[insighting]

Нелепо е при вече създадена технология да откриваме отново топлата вода. Съществуват геймдизайнерски платформи. Техният код (open source) предоставя възможност за силна модификация. Сами моделираме героите и ги текстурираме. Анимирането не е сложно. За озвучаването ползваме готови файлове. Кътсцените се рендерират в отделни филмчета и след компилация се получава един завършен продукт. И не се изискват умения по програмиране на Си шарп и Делфи, например.

[Avatara]

Здравейте Insighting,

Съгласен съм с Вас. Съществуват дори цели програми. Съществуват и специализирани системи за моделиране на физични процеси, които се използват в игрите.

Анимирането съще не е сложно, ако се използват съвременните редактори. Но ....

Тази логика ми е до болка позната, така както и логиката за "многото" достъпни описанив в internet.

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

Лично аз мога да Ви посоча поне три неща, които няма да може да направите със споменатите системи с отворен код (open source*).

Като най-елементарното бих Ви помолил да създадете игра при която обектите да притежават всички възможни степени на свобода (транслации и ротации по трите оси) и да съществува възможност за паралелно взаимодействие между повече от пет обекта в нееднородна среда.

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

Друг въпрос е, че в една игра освен кинематика, изкуствен интелект, графика и пр. има и сценарий и някаква логика. Повярвайте потребителите не са глупаци и определено са капризни.

Или да си поговорим за мултиплатформените игри?

Или за съвременните протоколи използвани в internet?

Моля да бъда извинен, но в момента (най-вече във връзка с мобилните приложения) цветовото кодиране е във формат RGBA, където A е алфа каналът. Има и нещо, което се нарича "апаратна съвместимост". Не случайно в професионалната сфера се използват монитори като Eizo. Да, но такъв монитор струва около 4600 лева. Така е и с RAD Studio. За да работите ще ви трябват около 6800 EUR.

Или да си поговорим за Apple?

За iOS ще са ви нужни 99 USD за регистрация, след което ще се наложи да си закупите поне дре устройства. Няма да коментирам какви други "забавни моменти" Ви очакват.

Що се отнася до Google Play ще ми е адски забавно да ми обясните как с геймдизайнерска платформа ще заобиколите проблемите пред Kit Kat 4.4.4 и LoliPop. Дори в системните инструменти на Android SDK (който е напълно безплатен) няма да намерите решение).

Що се отнася до т.н. "монетаризация" на игрите то там мога да Ви обяснявам с часове, но отдавна съм се отказал.

Има една прекрасна реклама. Та в тази реклама един известен радиоводещ казва следното: "Ако Ви кажа, че съм зъболекар ще ми позволите ли да ви оправя зъбите?"

Аз не съм дизайнер. Много уважавам дизайна (все пак втората ми специалност е "Ергономия").

В съвременните средства за разработка и най-вече във FireMonkey дизайнът е превърнатъ в елемент на функционалността на обектите. Терминът "стил" (style) там няма нищо общо с CSS използвани в web. така е и с термина "анимация" в който е вложен много интересен смисъл (и тук се връщаме към литературата).

Всичко, което написах е резултат от това, което се определя като "информационен излишък". Имаме много информация и на пръв поглед богат избор, но ... крайните резултати са отчайващи.

Що се отнася до "откриването на топлата вода" то тук определено не сте прав.

Водата е най-малко изученият обект в момента, а топлата вода си е цяла загадка. До момента на науката са известни едва около 200 макромолекули, които могат да бъдат наблюдавани във водата. Ако поставите в чаша с вода парчета кехлибар ще получите преподреждане на водните диполи. Този ефект се използва в микроелектрониката. Водата е много, ама много сложно нещо. Програмирането - също.

И в закюченив.

Аз мога да Ви взема нещо насила, но не мога да Ви дам нещо, ако нямате желание.

Аз няма на какво да Ви науча. Дискусията не е ползотворна, защото няма сериозни аргументи, а клишета, а клишетата няма да помогнат да направим каквото и да било.

Моля да ме извините. Исках да видя дали нещо се е променило за последните две години, но определено всичко си е по-старому.

С уважение

Avatara

* open source - най-сигурният начин една компания да бъде доведена до фалит.

Редактирано Май 29, 2015 от Avatara

[kall]

Аватара, това за кибернетиката е много вярно, това е наука за управлението на процесите, като такава е изключителен интерес приложението и към икономиката, не знам ти какво можеш да кажеш по-въпроса, но аз лично се изприщвам от онези десни либертарианци, които искат пълно раздържавяване на всичко, абсолютен свободен пазар и подобни от глупостите на Айн Ранд. Т.е. качествено държавно управление на процесите в пазара би следвало да е напълно възможно, не говорим за социализъм, а за управление на процесите въз основа на научните достижения. Няма да споменавам, че съм изключително разочарован не от днес от това, че за тази идея не се говори и не се намира нищо( говоря от собствен опит), а тук има поле за изследователска и приложна работа... Да не говорим за човешкото поведение... Прочее, пак да си задам въпроса за Deep Web и Tor browser( Файърфокс с едни "леки" настройки), представлява известен интерес за мен, спокойно, няма да свалям правителството:-)

И един послепис за водата и отворения код- за водата все пак имам известни предубеждения, защото никак не съм убеден, че теориите за памет на водата са верни: http://bgchaos.com/851/polemics/unintelligent-design/%D0%BF%D0%B0%D0%BC%D0%B5%D1%82-%D0%BD%D0%B0-%D0%B2%D0%BE%D0%B4%D0%B0%D1%82%D0%B0-%D0%B8%D0%BB%D0%B8-%D0%BA%D0%B0%D0%BA-%D0%BD%D0%B8-%D0%BF%D1%80%D0%BE%D0%BC%D0%B8%D0%B2%D0%B0%D1%82-%D0%BC%D0%BE%D0%B7/

Та оттук и останалите твърдения за водата :-)

Дяволски си прав за опен-сорса, моята работа е свързана с Линукси и такива мизерии, дори сега пиша от служебен компютър с Убунту 12.04... Но все пак има и полезни неща в тази област де.

Сега гледам, то имало тука и тема за "информационния боклук"- http://nauka.bg/forum/index.php?showtopic=17313

[Avatara]

Здравейте Kall,

За водата имам наблюдения от микроелектрониката и хидролизните процеси на етилсиликатите.

И докато за миктроелектрониката все пак се знае, то за етилсиликатите и тяхното приложение се знае (от широката публика) твърде малко.

Това е основното свързващо вещество за изготвяне формите в които изкристализирват лопатките за турбините на двигателите на съвременните самолети.

Тази "свръхмодерна" технология е била много добре позната на древните египтяни.

Така е и с навигационните системи. Реално по точност на позициониране астролабът по нищо не отстъпва на съвременният GPS.

Така е и с кибернетиката и игрите.

Игрите са сериозна наука добре позната на източните цивилизации много преди Христа.

Факт е, че игрите са решавали изхода на войни.

Но да поговорим за кибернетиката.

Абсолютно си прав.

Истината е, че сериозни анализтори и политици внимателно са изучавали тази наука.

Също така е вярно, че неуки (но титуловани личности) попаднали случайно и неизвестно как на някойе място, отричайки основни принципи на кибернетиката са водили не една държава до крах.

Да си спомним Клеопатра. Или Голда Мейрл. Или Индира Ганди или Маргарет Татчър.

Последствията от техните действия са ужасни и в редица случаи - непоправими.

Корените на кибернетиката са много древни. Аз лично започнах да се занимавам с тази наука, когато работех по проекти свързани с медицинската информатика.

Визирам специфична обработка на НЧС, а не бази данни. Работата ми бе свързана с миографски и други нискочестотни сигнали.

С голямо учудване трябваше да разбера, че три века преди Христа в Сиам са знаели че сърцето изписва пространствена фигура (японската думата е "cocoro", за виетнамската нямам представа, а аз визирам EKG сигналът, който е 3D - тридименсионен).

Също така в Сиам са знаели, че съществува трети кръг на кръвообращение. Едва преди няколко години открито се заговори за т.н. "миокарден кръг".

Но нешата не спираха до тук. Някои все още се чудят над т.н. Т-вълна и нейната роля в диагностиката, а онези там са я използвали и то как.

От тук - Гърция. А Гърция бе Херодот, Платон Аристотел, а Аристотел бе кибернетиката. И се започна. Ампер, Винер, Коуфигнал, Зоувен ... та в този порядък до наши съвременници, които ме изумиха с познанията си.

И знаеш ли до какъв извод стигнах?

Ние сме загубили мечтите си.

Ние сме забравили какво е да си дете и да си любопитен за това, което става.

Ние повтаряме заучени неща и следваме тенденции. Нивно вярваме, в това, в което някои упорито ни убеждават.

Ето само един пример:

Теорията на относителността на Анщайн се основава на един много забавен постулат: етер няма защото не е доказано, че има. Точка.

Пррррррекрасно. Ноооооо ...

Към момента няма нито едно експериментално фдоказателство от страна на експерименталната физика, което да доказва, че Айнщайн е прав. Виж за етера не е съвсем така.

Да добавим към рова и нещо още по забавно.

Пак според Айнщайн скоростта на светлината във вакум е не само константа, но и не може да бъде преодоляна.

Хайде, бе. Я да разгледаме въпроса от гледна точка на доказалата се теоретична механика и да видим дали това е така.

От теоретичната механика се знае, че линейната скорост на материална точка, движеща се по окръжност е рвана на ъгловата скорост умножена по радиуса на окръжността или:

V = Omega * R * R

където:

Omega е ъгловата скорост, а R радиуса на окръжността.

И сега внимавай много, ама много добре.

Нека имаме няколко кръга като всеки един от тях се върти в посока обратна на съседните.

Относителната линейна скорост на всеки следващ кръг (диск или каквото се сетиш) ще бъде сума от линейните скорости на предхождащите го. Или:

Vn = V1 + V2 + ... + Vi + ... + Vn-1.

При радиус R = 10 m (десет линейни метра) и Omega = 30 000 оборота/секунда линейната ще бъде:

Vi = 30 000 * 100 = 3 000 000 метра/секунда

Нека сега да си представим, че имаме 100 диска, т.е. N = 100 и да видом какво се получава.

Vn= 3 000 000 + 3 000 000 + ... + 3 000 000 = 100 * 3 000 000 = 300 000 000 метра/секунда

От тук:

300 000 000 > 299 792 458 (а това са последните данни за скоростта на светлината).

На практика доказахме въз основа на приемането на относителността (и утвърдени постулати от класическата механика), че може да се реализира скорост много по-голяма от тази на светлината по механичен път.

Яко, а?

Хайде сега някой да дойде и да обори теоретично твърденията ми.

Макар това да е доста популярна шега в нашите среди, тя си е доста сериозна.

Преди време често се казваше: "Няма нужда да откриваме колелото".

Хайде, бе. В момента най-големите изобретения са свързани точно с велосипедите.

Наскоро в Германия имаше невероятна конференциа по темата.

Така е и с "топлата вода".

Топлата вода е като "бобената чорба". Просто нещо, но е е за прости хора (диалектика).

Получаването на топла вода е доста сериозно занимание, което е било основна задача за нашите далечни праотци живели в каменната ера (за справка неолитното селище край Хоталич).

Древните са имали постоянно течаща топла вода и жилища със застроена площ над 140 квадратни метра.

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

Но (както казваш ти) така е и с политиката.

Демокрацията като строй може да съществува само и единствено в условията на робство.

Всички демократични държави са ползвали робство под една или друга форма.

И сега най-интересното:

"Демокрацията е за една отминала епоха. Днес светът е прекалено сложен, за да дискутираме единствено всеобщото страдание и други подобни. Тези безкрайни парламентарни дебати не водят до нищо друго освен до застой."

Казуро Ишигуро (Kazuro Ishiguro) "Остатъкът от деня"

Най-добрият британски писател (Ишигуро е англичанин макар да е роден в Япония) го е казал с три изречения.

Сега си помисли колко думи се използват в медиите за да се говори за демокрация, реформи, ценности и пр.. Какво разхищение на енергия.

А какъви са резултатите?

Мдааааа ...

Linux, Linux, Linux ... любимо дете на Novell.

Ех какви времена бяха. Towa Java, това C++ това Oracle ... Мдааа ...

Но Linux определено са си печалбари. Поискаха ми 37 200 USD за нещо, което принадлежи на Microsoft и се предоставя безплатно.

Но пък като се замисля и Android, че и още маса ОС са си Linux ...

Но ... Хляб и зрелища, както е казал някой.

Хляб няма, но имаме "суратлъ тефтер" и "сеир суратлъ" (социални мрежи и селфене). Зрелищата са налице ...

Да, ама словоблудство стомах не пълни, а гладът е сериозен учител.

Извинявай. Сериозно иозлязохме извън темата, но пък от години не съм си комункирал с никого.

С най-добри пожелания

Avatara

[kall]

Имаш интересно виждане за теорията на относителността, тъй че бих искал леко да се поразсъждава на тази тема... Формулата за ъгловата скорост и линейната е Omega*R, леко си се объркал... Не е Omega*R*R!

Сега, първо да почнем от кръговете...

Ето тук е изведена сгрешената формула впрочем, за да не съм голословен: http://phys.tu-sofia.bg/ef/Phys%201/Lektzii/Mehanika/10%20vupros.pdf

Та на кръговете: "Нека имаме няколко кръга като всеки един от тях се върти в посока обратна на съседните." Това ми е бая зор да си го представя:-) Но да кажем, че ще е нещо като зъбчатките на часовников механизъм...

Редактирано Май 29, 2015 от kall

[kall]

И тук опираме до събиране на скорости, много е важно да се има в предвид, че скоростта е векторна величина! Това означава, че отделните линейни скорости, наблюдавани от нас, ще имат различни стойности спрямо различни отправни системи.

[kall]

А линейната скорост е просто модулът на векторната. Т.е. ако сме върху една от зъбчатките, за съседните ще ни се струва, че едната "бяга", а другата се приближава. Това ще важи и за по-далечните и тъй като това за различните скорости е казано само за съседните, то при всички случаи ще наблюдаваме съпосочни на нас сред далечните, тях ще ги виждаме неподвижни( не е задължително, но да приемем, че линейните скорости са еднакви).

Т.е. от гледната точка на наблюдател върху зъбчатките, дадената формула за сумиране на скоростите е некоректна. Но какво е положението спрямо външен наблюдател. Според външния наблюдател просто всички точки върху ръба на зъбчатките ще се движат с еднаква скорост, просто в различни посоки... И тук това сумиране на скорости е некоректно( все пак класическата механика не ми е сила, затуй са ми така накъсани и постовете, защото сега ровя в студентските си записки:-), моля да бъда извинен за което).

Дотук всичко разсъждавано е класическа механика, като навлезем в релативистичната( няма да го правя, нека и друг, по-знаещ да се помъчи), нещата загрубяват, там не е само скоростта на светлината, но и времето не е едно и също в различните отправни системи, което си изпуснал, а е солта на нещата. Така че в заключение- верни са и ОТО и СТО, даже са и експериментално доказани, но тук ще трябва да се поровя за конкретните експерименти...

http://en.wikipedia.org/wiki/Tests_of_special_relativity

http://en.wikipedia.org/wiki/Tests_of_general_relativity

И да отбележа, щото съм се напатил вече: преглеждайте линковете, дето давам, келеши!

Редактирано Май 29, 2015 от kall

[kall]

Бахти, следващият път предварително ще си направя чернова, та да не става като тая грозотия с постовете сега, тва няма и как да го редактирам...

[В.Павлов]

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

  On 29.05.2015 г. at 6:49, insighting said:

Нелепо е при вече създадена технология да откриваме отново топлата вода. Съществуват геймдизайнерски платформи. Техният код (open source) предоставя възможност за силна модификация. Сами моделираме героите и ги текстурираме. Анимирането не е сложно. За озвучаването ползваме готови файлове. Кътсцените се рендерират в отделни филмчета и след компилация се получава един завършен продукт. И не се изискват умения по програмиране на Си шарп и Делфи, например.

Не съм съгласен. Защо да е нелепо? Създадената технология е просто набор от инструменти, които ползваме. Ако разработката на тези инструменти прекъсне, нещата спират развитието си. Юнити например е сравнително нова технология, която в голяма степен направи тези инструменти достъпни за разработчици и то на съвсем прилични цени, а при слаби продажби (на изработения продукт) дори безплатно. Преди него беше доста скъпо да се закупи подобна среда за разработка на игри.Колкото до уменията за програмиране, няма как да стане. Има разни инструменти, като Adventure creator, които са по същество шаблони, но когато трябва да се вмъкне елемент, който преди това не е разработен или ако играта върви бавно и трябва да се оптимизира, просто няма как да се мине без програмиране.

За озвучаване не може да се ползват готови файлове. Трябва да има лиценз за тях, ако искаш да продаваш продукта. За създаването на визуалното съдържание на играта, отново се изисква набор от платени софтуери, където средата е доста динамична и съвсем не става лесно, трябва поне специалист-художник. За анимацията също. Дори да се ползват (абсурдно скъпите) MOCAB системи, се иска специалист-аниматор да пипне и да го направи истински добро. Да не говорим, че ако героят не е спрайт а 3D то до анимация въобще не може да се стигне, без на героят да му бъде построена костна система. Нещо което е доста трудно да се случи качествено. Процесът се нарича ригване. Има интернет страници които предлагат автоматично ригване, но цената е висока, а качеството съмнително.

Кътсцените вече не се рендерират в друг софтуер, а се правят направо в гейм-енжините. Това е така, понеже резултатите на рендерите, в реално време, стават все по-добри. Интересен факт е че Юнити иска про (платената) версия за да може да пуска видеа. За да се случат тези кътсцени в гейменжина (не се сещам за алтернатива на български език) се иска много добро владеене на Java или C#.

Ако Avatara има намерение да пише за начините за създаване на инструменти, то аз бих могъл да се включа със скромните си знания по начините на тяхното използване в художествената област на играта. По същество обаче много рядко в гейменжините имаме инструменти за създаване на художествената част на приложението. От друга страна съществува огромен набор от софтуери правени точно с цел създаване на изобразителна продукция. Поради тази причина обикновенно се ползва специализиран софтуер, като Фотошоп, З-бръш, Модо, 3дС Макс, Мая, Топогън, дори Скечъп и много други, в по-голяма или по-малка степен познати.

Бих искал да направя един кратък обзор на процесът по който се създава триизмерен герой, или съдържание в игра. Ще вмъквам някои бележки и за 2D героите.

Очевидно първо трябва да се създаде идеята. Принципно героят може и да се случи без нея (някои художници започват работата си просто с няколко щрихи, от които построяват целия герой, без предварителен умисъл), но преминаването през тази стъпка може да направи разликата между истински дробрият, запомнящ се герой и посредствената работа. Задачата на този етап е да се създаде идентичност, която после да бъде визуализирана, по такъв начин, че още от първ поглед, наблюдателят да може дори подсъзнателно, да асоцира този герой с нещо познато и да добие представа за личността. Звучи странно но стереотипните облекло и обща визия могат да бъдат добър подход. Отплеснах се малко, за последното трябва да говорим когато стигнем до рисуването. На този етап ние просто трябва да построим героят, не като визия, а като характер. Ако играта има сценарист, то тази работа ще бъде в голяма степен свършена за нас. Ако не, то бихме могли да започнем с някаква история. Къде е живял, какво детство е имал, какво е работил, какво е учил. С измислянето на миналото му можем да изведем някой по-преки характеристики, дали е прилежен, или по-разхвърлян, на каква позиция е в работата, умен ли е, темпераментен или малко по-сприхав, семейно положение и др. Бихме могли да наблегнем и дори пеувеличим някои негови качества, така че когато ги визуализираме те да бъдат веднага схванати.

Втората стъпка е нарисуваме героят. Имайки идеята ние вече знаем какво правим. Нужно е просто да пуснем Google и да намерим подходящи референции за облекло, лице и телосложение. Както вече писах стереотипната визия може много да помогне. Хората изграждат мисловно шаблони и често си съставят мнение за друг индивид, само от пръв поглед с който категоризират външната му визия. Така е добре да проучим "униформите" на различните професии. Например бихме могли успешно да изобразим учен с бяла престилка и слабо телосложение. Ако към тези добавим хирургическа маска, веднага получаваме лекар. Късо подстриганата коса подсказва за полицай или военен. Археолози и различни изследователи носят дрехи с много джобове и т.н.

Особеностите на характера можем да подчертаем отново с дрехи (например вдигната назад към темето шапка, показва разпуснатост, накривена на страни елегантност, а ниско захлупена сериозност). Тук обаче трябва да добавим и лицето. Ококорения поглед може да бъде подходящ за учения, добавяйки известна налудничавост. Отпуснатите клепачи говорят за спокойствие и увереност. С рошава коса може да се подчертае разпуснат характер. Вероятно не е добра идея да се комбинират противоречащи си белези, например рошава коса с безупречно чисти обувки. Героят трябва да "излъчва" характера си за да бъде мигновенно "прочитан". Именно възможноста за асоциация ще привлече вниманието на зрителя и ще го направи запомнящ се.

Няма голямо значение как ще бъде създадена рисунката на героя, може дори да бъде на лист хартия. Като част от планирането тази рисунка няма да бъде директно използвана в продукцията на играта. Нейната цел е да подпомогне процеса по създаване на героя. Тук трябва да отбележа, че тези две първи стъпки бележат създаването, както на триизмерни, така и на двуизмерни герой.

В следващия етап навлизаме директно в създаването на героя. Обикновенно героят се оформя в T поза, това означава че не само ръцете но всички крайници (които ще бъдат анимирани) се поставят раздалечени един от друг и от тялто. Най-често се прави за ръцете, краката и пръстите, срещат се и такива с широко отворена уста. Тази поза е наложена от необходимоста от поставяне на костна система, с чиято помощ героят се анимира. За да станат по-ясни нещата се налага да навлезем в малко по-подробно в техническата част, което с удоволствие ще направя утре или друг ден. Днес вече стана много късно, или по-скоро рано.

Редактирано Май 29, 2015 от В.Павлов

[Avatara]

Здравейте,

Благодаря на -n Павлов за написаното. Напълно съм съгласен, че сериозно сме се отклонили от темата и вината е изцяло моя.

Все пак ако ми позволите искам да се извиня на Kall. Ако трябва да бъда коректен би следвало да запиша:

v=(2*Pi*R)/T,

където Т е периода на въртене.

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

За Анщайн мога само да повторя, че (както съм написал) това е шега, защото самата мисъл, че се изключва съществуването на нещо, което не се познава, като основа на една теория изглежда леко нелогично.

А сега е време да се върнем на основната тема и да поговорим сериозно за това какви са проблемите при създаването на една игра.

С уважение

Avatara

P.S. Не бях забелязал, че insighting е жена.

[В.Павлов]

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

Бях стигнал до технически въпроси. Нужно е да влезем малко в тях, за да добием по-добра представа за процесите и как те афектират на работния подход.

Триизмерните модели в компютрите се създават с помоща на геометрия, която условно наричаме мрежа или wireframe. Тук има няколко примери за такава. Самата мрежа има няколко съставни елемента. Винаги присъстващи са vertex. По същество това са точки (или може би е по-точно да се каже вектори) с точно местоположение в триизмерното пространство. Така вертексът винаги съдържа координати по трите оси X, Y и Z. При някой видове мрежи (каквито са NURBS или Spline) вертексите могат да оказват влияние на свързващите ги ръбове. Получават се криви на Безие, които могат да бъдат контролирани от "рамената" на вертексите (виж тук). На следното изображение можете да видите вертексите. Тяхното местоположение е означено с червени точки. На същата картинка виждаме и друга съставна част на мрежата, означена с бяло. Това са ръбовете или edges. Обикновенно представляват прави линии свързващи два вертекса. Ако се използват кривите на Безие, тези линии може и да не бъдат прави (вижте отново тук). Друга съставна част на мрежата е затворената между три вертекса и свързващите ги ръбове площ. Този съставен елемент наричаме лице или face. Неговата основна характеристика която ще ползваме, наричаме нормала. Това е линия или вектор, който е перпендикулярен на даден обект. Обикновенно нормалите се използват за да означат от коя страна лицето (face) e видима и следователно трябва да се вижда при рендерирането. Интерес представляват нормалите на ветексите, чиято посока може да бъде променяна. С тяхна помощ може да се имитира заобленост на ръбовете (вижте тук). Тъй като нормалата се използва за ориентир при визуализацията на мрежата (рендериране), съществува способ за нейното мултиплициране и манипулиране. По този начин бихме могли да добавим към мрежата си геометрия, без фактически да увеличаваме гъстотата на мрежата. По-подробно внимание на normal maps, начините на тяхното генериране и използване, ще обърна на друг етап от настоящата дискусия. За сега е важно да се подчертае какво е това мрежа и от какво се състои. В следващия пост ще опитам обесня как се използва.

Редактирано Май 30, 2015 от В.Павлов

[В.Павлов]

Пропуснах да добавя един съществен елемент - полигон(polygon). Подобно на face полигонът е равнината между ръбовете, които свързват вертексите, за разлика от фейса обаче полигонът не е ограничен до триъгълник, а може да бъде съставен от n на брой прави ръбове - edges. Гейм енжините работят само с фейсове, където има полигони методологията е последните да бъдат разделени на триъгълници. Полигоните и най-вече четириъгълните такива са широко използвани в софтуерите за създаване на геометрия. Когато дадена мрежа се манипулира така че да работи добре в гейм енжин, трябва да бъде направена така, че да съдържа само четириъгълни и триъгълни полигони. Би трябвало (след като работят с фейсове) гейм енжините да допускат триъгълни полигони, но някои като например Unreal, не импортват геометрия с триъгълници. Петоъгълници или такива с повече ъгли мисля че въобще не са допускани в гейм енжините. Изключение мисля че правеше Lumion, за който имам мътен спомен, че импортваше разни странни мрежи. Полигоните и фейсовете са единосъщни когато става въпрос за триъгълни площи.

Това кратко разяснение на основни неща е нужно, за да стане ясно защо героят се моделира (създаването и манипулирането на мрежата се нарича моделиране) в Т-позата, с която завърших един от горните постове. За да бъде по-удобно анимиран, на героя се поставя костна система. Изгражда се своеобразен скелет, който деформира мрежата. Така вместо да се анимира обемът се анимира хуманоидният скелет. Скелетът от своя страна движи и манипулира мрежата, като влияе на вертексите (пример, пример и отново пример ), чрез зони на влияние, наричани Envelope. Ако пръстите са близо или ръката е в отпуснато положение или направо долепена до тялото, зоните на влияние ще обхващат и вертекси, които не бихме искали да движим, така при движене на ръката ще движим и част от вертексите, които оформят тялото. Тъкмо тази особеност, налага използването на Т-поза, която улеснява работата на този, който ще се занимава с ригването и анимирането на дадения герой.

Въоръжени с тези основни знания, бихме могли да преминем към създаването на мрежата или обемът на героя. Обясненията за който процес обаче, остават за друг път. Днес бих завършил с това, че ще бъде голямо улеснение ако се създаде втора рисунка на героя, тъкмо в тази Т-поза. Не че е задължително, но ще помогне много. В наши дни тези които проектират героите, тези които създават мрежата и тези които анимират и ригват, са различни специалисти, които често не могат да вършат работата на другия.

Редактирано Май 30, 2015 от В.Павлов