Чому розробник ігор пише власний движок замість того, щоб використовувати існуючі?


41

Я помітив, що багато великих і відомих розробників ігор часто розробляють власні двигуни. Приклади включають Valve, Crytek, Ubisoft, Epic Games та Square-Enix.

Чи може це бути просто тому, що вони можуть, чи ймовірно, що існуючі двигуни не відповідають достатній кількості вимог, тож ми розробимо власні? Я навряд чи уявляю гру, яка вимагає конкретного двигуна. Подобання Unity або Unreal досить просто, щоб зробити будь-яку гру; навіть якщо ні, вони мають вихідний код, який можна змінити для задоволення навіть деяких надзвичайних потреб.

Чому розробник ігор пише власний движок замість того, щоб використовувати існуючі?


1
Можливий дублікат: gamedev.stackexchange.com/questions/12488 / ... і пов'язаний з ними : gamedev.stackexchange.com/questions/859 / ...
MichaelHouse

1
Вони не хочуть ліцензувати ігрові двигуни інших компаній і платити їх.
János Turánszki

Я здогадуюсь, що це робиш, коли у тебе
трудяться

3
Існує кілька зустрічних прикладів великих студій, які створюють заголовки AAA за допомогою сторонніх двигунів, таких як Unreal або CryEngine .
Філіп

3
Valve почав користуватися двигуном Quake, а потім врешті написав своє для пізніших ігор. Часто справа в тому, щоб навчитися використовувати те, що є в наявності, а згодом хочеться досягти чогось іншого, ніж те, що пропонує існуючий двигун. У цей момент вам доведеться зробити важкі модифікації або прокатати свої власні.
Найру

Відповіді:


53

Є кілька причин, якими студія може обрати «будувати», а не «купувати» їхні технології:

  • Спадкові технології; Студія, можливо, почала створювати власну ланцюжок інструментів до того, як для неї існували життєздатні проміжні програми.
  • Конкретні вимоги; студія може мати певну колекцію вимог, яка не підходить до існуючого проміжного програмного забезпечення або
  • Проблеми з бюджетом; студія може не мати змоги дозволити собі витрати або договірні зобов’язання існуючих проміжних програм.
  • "Не побудований тут синдром;" технічне керівництво студій може бути обережним (розумно чи нерозумно) технологією, яку вони не побудували, і тому не повністю розуміють.

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

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

Для інших технологія може стати основою успіху. Наприклад, студії, які будують MMO, зазвичай потребують побудови цієї інфраструктури, оскільки це є критично важливим для їхнього успіху (а наявне проміжне програмне забезпечення, як правило, недоцільно, принаймні для більших назв "AAA").

Зауважте, що деякі з перерахованих вами студій (зокрема Crytek та Epic) в основному перестали намагатися домінувати сили безпосередньо на ринку ігор, і майже напевно роблять набагато більше як постачальників програмного забезпечення, ніж розробники ігор.


20
Я хотів би додати, що іноді є переваги технологій, які "побудовані тут". Одним із прикладів є те, як Unity3D змінює свої EULAs кожної версії та додає дивні обмеження, такі як відсутність «азартних ігор». Коли ви надаєте ліцензію на техніку, ви зобов'язані ліцензіата не повертатись та відкликати ліцензію без особливих причин (таке трапляється з правами IP для створення ліцензованих ігор) або вирішити стягнути з вас виправити їх помилки.
Скрилар

серйозно, Юніті каже: "немає азартних ігор"? Вони навіть мали певну сторінку про азартні ігри у розділі Спільноти свого веб-сайту!
поштовх

На сторінці Unity на сайті unit3d.com/industries/gambling написано, що ви можете придбати "ліцензію на азартні ігри Unity". Я не знайшов ціни за це, але звучить так, що вони все ще дозволяють вам робити ігри для азартних ігор, якщо ви платите за спеціальне ліцензування.
Олексій

1
Крім того, простіше розпочати роботу з тим, що ви вже знаєте, і закінчити будівництво двигуна, навіть не знаючи, що це за двигун. Двигун - це не що інше, як сукупність випадків використання; якщо ви намагаєтесь зменшити надмірність, ви закінчуєте писати двигун, а якщо ви намагаєтеся просто створити гру, ви закінчите з монолітною системою. Дуже важко отримати ігровий движок і навчитися його змусити відображати піксель, а потім зрозуміти, що він не може цього зробити, оскільки він бачить усе як текстуру. Вам не доведеться з цим мати справу, коли ви пишете своє.
Дмитро

18

як сказав Джош Петрі :

" Не побудований тут синдром ;"

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

Я випробував різні типи ігрових двигунів, API рендерингу і таких, зокрема Ploobs, UNITY WaveEngine, XNAFinalEngine, Love, Ogre і т. Д. Багато іншого ... Я хотів почати писати ігри - завантажив багато чого, шукаючи гарного комфорту і добре задокументований пункт входу ...

Моя проблема, однак, була в той час, коли я не мав уявлення, що відбувається під двигуном. Я хотів хорошого контролю, і я хотів рамки, які я знаю, як тильна частина моєї руки. Я придумав ідею "Здравствуйте! Я думаю, що єдиний спосіб, коли я дізнаюся, як це працює, і зрозуміти це - спробувати створити власний двигун повністю і повністю з нуля". - це була абсолютно нова для мене гра з м'ячем.

Що я і закінчила.

Тому я вирішив створити XNA, оскільки я вже знав C #, і почав думати про те, як чи з чого мені почати. Мені була потрібна ідея.

Я вирішив, що, незважаючи ні на що, я б перейшов прямо в 3D .

Зниження основ було прохолодно - спрайтовий пакет, але, коли я прогресував, я виявив нові бар'єри та перешкоди - моїм першим справжнім було обмеження партії . Моєю метою було створити гру, яка могла б у будь-який час відобразити щонайменше 10000 об'єктів.

Я вирушив у нову дорогу впровадження Шедерного базування миттєвості (і навчився HLSL, коли я був на ньому), я викреслив вбудовані XNA в об'єкти Model і Effect, щоб замість цього написати свої власні заміни. Спочатку у мене виникли проблеми з розумінням потоків VBO; Я зламав речі - я зайшов до Інтернету, задаючи питання про інстанції, і тримався на ньому, поки нарешті не зрозумів, що робить GPU. Це окупилося; Тепер у мене було більше двадцяти тисяч тестових утворень, які збільшували масштаб мого огляду через пару днів налагодження мого VBO з PIX (dxsdk).

Тепер у мене було "деяке" уявлення про те, як працюють конвеєри рендерингу, але це ще не було зроблено - я в кінцевому підсумку створив власний ігровий стан, камеру, поштові ефекти та об'єкти сутності, відійшов від контентного конвеєра XNA, створивши свій власний Навантажувачі (особиста неприязнь до речі XNB), створили складну географічну ланцюг, відсортовану та змішану за станом, а також мали встановлені спрайти та текст, усе проектоване на ігрову сцену.

Я продовжував додавати, виправляти, змінювати та експериментувати з цим постійно протягом майже цілого року. Зрештою, вийшло досить непогано. Зараз у мене було розуміння того, що відбувається під кришкою, бо я створив це - моя дитина.

Зараз мій двигун був здебільшого стабільним і майже закінченим. Це не досконало: сценарій прискіпливий, а графічний інтерфейс зовсім не був чудовим. Але я все одно любив це. Тисячі рядків коду, активів та медіа - накопичились у приватному сховищі git 2 Гб, і всі головні болі, які мені довелося пережити, намагаючись зробити такий тип розвитку, який я ніколи раніше не робив. Кожна перешкода, яку я подолав, - це засвоєний урок - і полегшення.

Я зняв у ньому майже все, що хотів.

Але врешті - я вирішив, що прийшов час її відкласти. Настільки, наскільки я задоволений написанням такого величезного двигуна сам, порадившись із мережі та інших приятелів gamedev, я вирішив, що буду це робити все заново - і робити це краще - тому що цього разу я здебільшого знаю що я роблю.

Цей проект все ще знаходиться в моєму репортажі GIT.

Мій другий пропуск при написанні нового двигуна (цього разу на MonoGame) просувається добре. Коли щось ламається, це виправити легше. Менше безладу. Я сподіваюся публічно показати свою гру десь цього року, тому що я, як правило, трохи 'занадто' прикріплений до свого коду.

Врешті-решт написання власного двигуна - це те, як я навчився це робити, при цьому, можу сказати, що я точно знаю і розумію, що робить кожен компонент, і як вони повинні працювати. Я насправді НЕЙТЕ читати код інших людей, особливо для великих незадокументованих проектів. Я хочу, щоб все, що я використовую, будувалося мною.

Це тільки я. Я сумніваюся, що коли-небудь використовувати заздалегідь зроблений двигун, напевно, тому що я думаю, що мені просто цікавіше написати власні рамки, ніж сидіти і мати справу з чиїмсь кодом - повний контроль.


13
Це читається набагато більше, як химерний особистий анекдот; Ви можете, ймовірно, відредагувати це, щоб зробити його набагато більш стислим, і це дозволило б отримати кращу відповідь.
Джош

2
Це, безумовно, чудово підходить для навчання, а також для створення своєї гри, коли у вас є час на все. Коли це справді лише ти. Але що робити, якщо ви хочете колись співпрацювати з кимось? Або працювати в компанії з іншими програмістами? Якщо хтось хотів би приєднатися до вашого проекту, хіба це не дивно, що тоді вони повинні були б прочитати ваш код - для них код інших людей .. саме те, чого ви ненавидите. Я вважаю, що читання коду теж дуже важливий навик. Без образи, я впевнений, що ви багато чого навчилися і написали крутий двигун - лише зауважте, що це не все є.
антон

Я усвідомлюю це, що будь-яка робота, в якій я брав участь будь-яким кодом будь-якою мовою, завжди була сольною для мене D;
Коді Морган

Треба сказати, я точно знаю , з яких причин людина розгортає власний двигун / інструмент / що завгодно. Але у нього є ціна (як і всі речі) ... У мене таке відчуття, що всі начальники просто ненавиджу це, коли ви не можете прочитати / зрозуміти найрозумніший код там, тому, будь ласка, продовжуйте і кидайте себе як ** * тонну неправильно написаного неправильно підтримуваного коду без документації, просто відчуйте це ("реальний" світ). Без образ.
Quonux

Ось чому ми, програмісти, не можемо мати приємних речей. Тому що ми завжди хочемо все зробити самостійно, а не використовувати працюючі та довірені методи. У мене є компульсивна необхідність писати все сама, але я повільно вчуся довіряти іншим, і поки це робить мені більше користі, ніж поганому :)
Maurycy

15

Абсолютна ключова причина написання власного двигуна (і мене дивує, що поки ніхто цього не викликав) - це налагодження .

Якщо ви написали велику, складну гру, і в ній є помилка аварійного завершення, і у вас є вихідний код (і тісно знайомий з цим вихідним кодом в силу написаного ним), ви можете просто приєднати налагоджувач до процес і знайти те, що викликає збій. Зроблено.

Якщо ви використовуєте чужий доступний у продажу двигун, і у вас немає вихідного коду для цього двигуна (як правило, немає), то налагодження будь-яких проблем, які виникають - навіть усередині вашого власного коду, - відбувається. бути монументально складніше. І якщо ви натрапите на помилку всередині самого двигуна, ви не зможете їх вирішити самостійно. Як би ви хотіли, щоб вийшов тиждень від дати випуску і хтось виявив помилку аварії в двигуні, який ви використовуєте - помилку аварії, яку ви не можете виправити, оскільки це всередині власного двигуна, до якого ви не працюєте є вихідний код? Я бачив, як це трапляється - у вас немає іншого вибору, як подати терміновий дзвінок підтримки у постачальника і сподіваєтесь, що вони зможуть (і зацікавлені в) вирішити проблему за вас, поки ви перебираєте,

Розробка ігор складна, але налагодження на порядок складніше. У моїй книзі все, що робить розвиток ігор складнішим, але налагодження простішим - величезний чистий виграш.


3
Це одна велика перевага, яку ми відчували при використанні двигуна з відкритим кодом (cocos2d-iphone). Ми можемо налагодити його точно так само, як написаний нами код. Я фактично вважаю, що спосіб думати про відкритий код - це ваш код. Якщо є помилки, нам доведеться їх виправляти, як і в будь-якій іншій частині нашого коду ..
antont

1
Це можна сказати про будь-яке посередництво. Налагодження коду - це 80% роботи програміста, а обробка проміжного програмного забезпечення - це поширена проблема з технологією, на якій ми сьогодні працюємо, з більшою кількістю проміжного програмного забезпечення, ніж ми можемо порахувати. Навчитися долати це - лише частина роботи. Якщо двигун не працює, щось інше ви не маєте під контролем волі. Менше рухомих деталей - хороша ідея, але коли це ускладнюється, як ігровий розробник, тоді вам доведеться мати справу з багатьма з них.
Тім

@ Тим я категорично не згоден - що одна зовнішня річ може погано поводитись у важкому для налагодження способі, це не означає, що нам слід просто знизати плечима і відмовитись від того, щоб все не так поводилось у важких для налагодження способах. Очевидно, потрібно приймати речі в кожному конкретному випадку, але двигун - це велика система, де часто ховаються хитрі помилки . Чому б вам не хотілося, щоб це було під вашим контролем, якщо ви, можливо, можете дозволити собі зробити це самостійно?
Тревор Пауелл

@TrevorPowell Очевидно, це зводиться до складності проекту, і, як ви кажете, до конкретного випадку, але просто винаходити колесо (особливо, якщо це велике колесо), слід серйозно розглянути питання щодо заощадженого часу, не роблячи це. Посереднє програмне забезпечення полегшує справи. Ми вважаємо, що ми завжди можемо винаходити рішення, щоб покращити його, не враховуючи, наскільки добре це рішення укладено разом. Кілька ударів> винахідлення> Неправильне рішення цілком
Тім

2
@Tim RE: "Програмне забезпечення полегшує справи", я мав зовсім інший досвід, ніж ви, мабуть.
Тревор Пауелл

9

Тут є дуже хороші відповіді, але вони пропускають один важливий додатковий момент.

Багато сучасних ліцензованих двигунів стартували як спеціалізовані двигуни .

Візьмемо Unreal як приклад, тому що він настільки всюдисущий.

Сьогодні, коли ви думаєте про Unreal, ви схильні думати про двигун, який ви ліцензуєте і який можете використовувати замість того, щоб створювати свій власний, але це не завжди було так, і колись двигун Unreal навіть не існував як окрема сутність.

Колись там була гра під назвою Unreal . Його розробники вирішили створити власний двигун, а не ліцензувати існуючий . Швидкий рух вперед через кілька ітерацій, і цей двигун стає двигуном Unreal, про який ми знаємо сьогодні.

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


2
Варто зазначити, що ще в той час, коли вперше були побудовані такі ігри, як Unreal, просто не було іншого вибору, як писати все з нуля. Лише за останні кілька років у нас є вибір N двигунів ...
joltmode

3

Є й інші причини, від яких студія може обрати «будувати», а не «купувати» їхні технології:

  • Нові платформи : нова мобільна ОС, консоль або контролери. Подумайте про стрибок, гугле скло тощо. Підтримка крос-платформ є важкою
  • Нова механіка гри та / або ігрові редактори : подумайте про FEZ кілька років тому (2D проти 3D)
  • Відсутність хороших безкоштовних редакторів ігор з відкритим кодом . Відсутність хорошої документації щодо існуючих джерел старих ігор
  • Еволюція інструментів у студії інструментів (або додавання нових)
  • Ціноутворення двигунів та ліцензійні війни

Я також погоджуюся з конкретними запитами / потребами, а цінові двигуни та війни за ліцензії змушують деякі студії випускати деякі двигуни.

Хорошими мотивами "купувати" або "використовувати" інші двигуни є:

  • Повторне використання коду : двигун, який вже використовується в інших іграх, більш випробуваний, стабільніший і може мати більшість необхідних функцій, починаючи з першого дня.
  • Розширення : ви можете розширити деякі двигуни з відкритим кодом.
  • Безкоштовно : або майже безкоштовно, оскільки навіть безкоштовні двигуни з відкритим кодом потребують певного часу для розробника, щоб навчитися.

2

Історична причина (в основному).
Що пов’язано з ціноутворенням.

За кожну гру, яку ви бачили під керуванням Unreal або CryEngine в минулі роки, довелося платити величезні гроші. Особливо, якщо ви хочете отримати вихідний код (тобто: ви хотіли UE, а не лише UDK.)

Але це змінилося. Тепер кожен може дозволити собі ще більші двигуни, оскільки почалася цінова гонка.
Що це означає...

  • Ви побачите набагато більше ігор, використовуючи і UE4, і CryEngine.
    Хоча вони не будуть іграми AAA, як раніше.
  • Спеціальні вимоги та потреби для кожного проекту не зникнуть.
    Дивіться двигун Warhammer40k / COH в компанії Relic або той, який використовували генерали в EA.
    Тож навіть якщо хтось може дозволити собі більші двигуни, він не обов'язково пропонує кращий вибір.
  • На ринку є й інші. Як Єдність.
    Люди люблять це за простоту використання, швидку продуктивність та величезний запас активів.
    Звичайно, Unity здатний розгорнутись майже на будь-якій платформі.

Так що так. Потреби, ціноутворення в минулому і таке.


1
Я б не назвав Хавок «сильно модифікованим».
Джош

Хіба Хавок не просто двигун фізики?
Філіп

Так, і GW2 не звертав на це великої уваги, яку я можу пригадати.
Джош

Ви не маєте на увазі (ie.: you want UE, not UDK only.)?
Keavon

#JoshPetrie: Вибачте, якщо чесно, я не маю досвіду в Havok / ніколи з ним не грав. Тож я натрапив на файл LICENSE GW2, а потім кілька днів тому відвідав сторінку вікі і побачив Havok. Тоді у мене була якась стара пам’ять про те, щоб побачити "Havok" на початку гри, де я подумав, що це ДВС. Але тоді я теж підняв погляд на Хавок, і я знав, що це двигун фізики. tl; dr: я перемішав речі про Хавок. || #Philipp: Це трохи більше, ніж це, але насправді це не ігровий движок, моя погана. || # Кевон: Правильно, виправлено. Дякую!
Apache

0

А як щодо організації команди?

За матеріалами налагодження стоїть документація та підтримка, а не код, тому що в кінці я не хотів, щоб моя будівельна група торкнулася коду мого власного двигуна. Це може бути безлад.

Отже, мені потрібна група підтримки для цього. Але це збільшує витрати: більше людей, більше місць, більше телефонного зв’язку, більше адміністрації ...

Одним з варіантів цього рішення може бути аутсорсинг ... компанії середнього програмного забезпечення, вивільняючи ресурси для мого бізнесу з створення ігор, тобто для творчої групи та письменників.

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


0

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

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


0

Моя відповідь відрізняється від існуючої, тому я додаю її, хоча пізно:

Якщо взяти приклад Valve із запитання, чи серії Witcher, процес був таким:

  • Ліцензувати двигун
  • Змініть / адаптуйте двигун до свого призначення
  • Випустіть гру та генеруйте гроші
  • Створіть власний движок для наступної гри

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


-2

мій вчитель програмування нам сказав, використовуйте лише API / методи / класи / функції, які ви вмієте будувати

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

Вивчення простих речей може призвести до виникнення дивних проблем, не кажучи вже про щось складне, як ігровий движок, особливо коли ви повинні використовувати цей ігровий движок для запуску своєї гри, що може призвести до багатьох несподіваних результатів і проблем

і ігровий движок не дотримується логічного коду чи будь-якої іншої логіки, коли вони побудовані, впевнені, що можна очікувати, але насправді все буде побудовано на основі розуміння чи знання мови програмування, чи того, як працює якась система

наприклад, якщо я вирішу написати математичне рівняння, я можу написати його так багато способів, я можу представити його поліномами, або диференціальним численням, базовою геометрією чи алгеброю, або що мені підходить, але іноді я б писав у певній формі / форматі, тому що я хочу щоб мати можливість маніпулювати тим, що легко доступно, наприклад, якби я планував робити багато вершинних маніпуляцій, я міг би написати цю математичну модель за допомогою базової геометрії, однак, якби я хотів змінити криву за допомогою градієнтів, я міг би зосередитись на диференційному обчисленні, щоб мати можливість легко маніпулювати градієнтами тощо. Це ж стосується будь-якого, я планую мати легший доступ

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

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


6
-1 Якщо ви працюєте над будь-яким проектом, що має великі розміри, від вас очікується використання функцій / класів, які ви не знаєте, як це було написано, і ви, можливо, не зможете самостійно написати його, не вивчаючи кількість книг на тема. Я не говорю про те, що повинен знати кожен програміст, але ігровий движок - це величезний проект, і очікується, що спеціаліст X спеціалізованої теми X не має знань з теми Y, а значить, і повинен використовувати цю функцію, я також не маючи на увазі, що ви не повинні знати, як використовувати API, який слід, але у вас може бути недостатньо знань, щоб написати його.
concept3d

2
Чи знає ваш вчитель, як з нуля створити повний автомобіль з хімічних елементів? Або він веде його, припускаючи, що це просто працює ;-)
Кромстер каже, що підтримує Моніку

1
@ concept3d є різниця між роботою над проектом, де хтось інший розробляє ті функції / класи, які ви використовуєте, тому що зазвичай, якщо ви щось не розумієте, це можна легко пояснити, програмістом, який переходить до використання класів коду / функцій / бібліотек, він / вона не знає, що це нерозумна людина, навіть класи та API, які доступні публічно, мають посібники та вікі, які пояснюють, що ці API чи функції роблять, щоб просто розраховувати використовувати його, не знаючи, що він робить, як спробувати заплисти в глибокі води, не знаючи, як плавати, і справді неосвічені та схильні до помилок
thingybingytie

@ hopjoppe5 Якщо ви перевірите прийняту відповідь, це єдині причини, через які люди будують власні технології. Багато реальних бібліотек / кодів передаються в реальному світі, і вам доведеться ним користуватися. Читання посібників відрізняється від знань про реалізацію, оскільки деякі алгоритми вам навіть не доводиться самостійно їх реалізовувати, і їх слід впроваджувати фахівці з цього питання, якщо у вас був досвід реального світу, ви це зрозумієте. Знати все неможливо.
concept3d

Однією з головних причин абстракції є написання коду, щоб люди, які не знають, як він працює, все ще могли ним користуватися. Працюючи над грою, більшим за понг, малоймовірно, що ви знайомі з кожним фрагментом коду. І в більшості випадків це добре, адже це означає, що ви можете зосередити свою увагу на тому, над чим працюєте зараз, а не турбуватися про те, як система введення може поводитись із вашим запитом на подію "Увімкнути клавішу дій".
Айдіакапі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.