Які основи розвитку гри? [зачинено]

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

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

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

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

1. буде закрито вашу програму, або
2. чи продовжуватиметься, поки користувач не натисне клавішу "Вихід"?

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

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

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

Під час гри в циклі, коли ви граєте, ходи - це зображення, намальовані на екрані за певними координатами. Коли користувач / плеєр натискає таку клавішу спрямування, як [Left], то ви змушуєте ваше зображення оновити його координати, зменшуючи його координату X, щоб ви створювали враження для руху вліво. Ви повинні отримати ці входи для того, щоб отримати, яку дію гравець хоче, щоб його персонаж / корабель здійснили далі. Потім ігровий цикл продовжує циклічно, поки ви не зможете отримати ще одну бажану дію від гравця, поки гра не закінчиться.

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

1. З чого почати писати ігри, будь-які підручники тощо?
2. Переміщення мого спрайту в XNA за допомогою класів .

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

Я сподіваюся, що це допомагає! =)

Під час створення консольних програм ви, швидше за все, використовуєте функції, що називаються print () або read () або write (). Замість них графічні ігри використовують інші функції, які можуть бути настільки ж низькими, як set_pixel (), щоб встановити колір окремого пікселя на екрані, на цілі рамки, які дозволяють малювати тривимірні моделі з безліччю ефектів.

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

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

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

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

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

Продовжуй гарно працювати!

Комп'ютерна гра - це нескінченний цикл:

• Оновлення: заздалегідь відіграйте в стані гри один невеликий проміжок часу (наприклад, 1/80 секунди).
• Пофарбуйте поточний стан гри.

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

Етап оновлення, який відбувається від 50 до 100 разів щосекунди (так це часто), робить це:

• Оновіть фізику ігор. Скажіть, що актор має швидкість. Оновлення повинно перемістити його на один крихітний біт у правильному напрямку. Крім того, якщо ви використовуєте двигун фізики, він повинен перевірити на зіткнення з іншими актосами чи перешкодами.
• Оновіть правила гри. Це те, що робить його грою, а не фізичним експериментом. Скажіть, що куля потрапила в актора гравця. Правила гри вказують гравцеві відняти X балів за здоров’ям, а куля не зникне.
• AI оновлення. Іноді актори, керовані комп'ютером, повинні вирішити, що робити. Йти вліво або вправо? Знайдіть шлях до приємного місця, де потрібно бути. Стріляйте зі зброї.
• Контроль введення. Оновіть актора програвача відповідно до кнопок, натиснутих на клавіатурі.
• Оновити графік сцени. Це може просунути анімацію на один крок або оновити графічний інтерфейс, щоб показати, що у гравця зараз на 10 очок менше здоров’я. Єдина мета - зробити так, щоб гра виглядала і відчувала себе приємно.

З чого ви починаєте?

Основна вимога до графічної гри - програмування графіки. Переконайтеся, що ви можете відкрити вікно і намалювати в ньому кулю.

Я припускаю, що ви можете зробити якісь заняття. Складіть бальний клас. У нього є такі члени: x, y, deltaX, deltaY. Усі цілі числа та в піксельній шкалі. Тепер напишіть цю петлю.

forever, do this {
  start measure time (in milliseconds)
  //physics part
  add deltaX to x
  add deltaY to y
  if x is bigger than the screen width, assign -deltaX to deltaX
  if y is bigger than the screen height, assign -deltaY to deltaY
  if x is less than 0, assign -deltaX to deltaX
  if y is less than 0, assign -deltaY to deltaY

  //paint
  paint the ball at x, y
  stop measuring time, assign this to workTime
  make the thread sleep for (25 - workTime) milliseconds
}

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

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

Навіщо спати протягом (25 - робочого часу) мілісекунд? Якщо ви зробите це так, симуляція буде працювати постійним темпом 40 оновлень і фарб в секунду. Це буде досить гладко. Якщо ви пропустили б сплячу частину, анімація буде хиткою і займає 100% процесора. Також швидкість кулі залежала б від швидкості роботи машини. Тепер вертикальна швидкість кулі становить 40 * дельта-пікселів в секунду.

Візьміть свою консольну програму, яка займається математикою, і тоді, коли ви вкажете правильну відповідь, змусьте її знімати конфетті ... Це стало грою (хтось, окрім мене, як дитина грає у Math Blaster? :)).

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

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

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

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

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

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