Які типові щоденні завдання програміста ігор початкового рівня? [зачинено]

Що я хотів би знати: це щоденні обов'язки випускника-програміста на робочому місці ігрової індустрії? Це здебільшого кодування, аналіз, проектування чи що?

Дякую.

PS На даний момент я перебуваю на своєму другому курсі університету і працюю над спеціалізацією в програмуванні ігор, зокрема геймплея, інструментів або програмування інтерфейсу користувача.

Виходячи з мого досвіду (у США, найнятого з коледжу за проектом, який щойно вийшов з прототипу та був близько 50-ти командою, потім було скасовано, потім ми продовжували робити ще дві ігри за чотири роки. був там із загальною базою розробників близько 200),

• Ви, ймовірно, витратите близько 50-70% свого часу на програмування. Цього разу я включаю "забавні речі", як зробити так, щоб зробити дійсно розумну функцію, а також час, коли ви дивитесь на звал пам’яті протягом 8 годин, намагаючись зрозуміти, що сталося. Можливо, 25-50% від цього - це фактичне програмування довгої форми "сидячи за клавіатурою" та "отримуй в зоні".
• Ще 15-25% під час зустрічей та адміністративних завдань, таких як триггер помилок, зустрічі з приводу триггеру помилок, планування, документації на високому рівні для інших програмістів та виробників, електронна пошта, оновлення статусу всього проекту / компанії тощо. Це залежить від того, скільки автономії у вас є - якщо у вас немає автономії, тоді ви витратите більше часу на програмування, тому що витратите менше часу, встановлюючи власний графік. Якщо ви більше контролюєте свій графік, ви можете взяти на себе роботу над більш цікавими речами, але тоді вам потрібно витратити час на цю справу.
• Ще 15-25% допомагають дизайнерам / художникам, відвідуючи творчі зустрічі, фактично щодо гри, в курсі документів щодо дизайну гри тощо.

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

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

Окрім питань дискусії на високому рівні, які підняв Джо, є ще кілька речей, про які слід пам’ятати.

• Зазвичай ви використовуєте якийсь інструмент відстеження помилок або інструмент відстеження завдань, який ваш потенційний клієнт буде використовувати для призначення завдань. Іноді вони однакові (тобто FogBugz). Іноді ваш список помилок буде здійснюватися через видавця, а ваш список завдань знаходиться на внутрішній вікі. Ви не просто сідаєте і починаєте робити все , що завгодно , ваші завдання будуть спрямовані.
• Іноді вас попросять оцінити свої завдання. Це неявно під час використання таких систем, як FogBugz. Частина ваших обов'язків буде / повинна / може полягати в тому, щоб розподілити функцію вищого рівня на частини, які ви можете використовувати, щоб правильно оцінити, скільки часу знадобиться для того, щоб побачити, як ви рухаєтесь до завершення етапів тощо.
• Дуже багато студій перейшли до більш гнучких / стильових методологій. Оновлення діаграм згоряння (тобто, кажучи, що ви витратили X годин на завдання Y і очікуєте, що буде виконано за Z-час) є досить поширеним явищем. Щоденні зустрічі з standup, мабуть, трохи частіше. У будь-якому випадку ви будете надавати певну видимість того, над чим працюєте.
• Ви будете використовувати версію / джерело управління. Чим більше студія, тим більше шансів використовувати Perforce. Ви повинні знати про основи цього (перевірка файлів, введення файлів, можливість вирішення локальних конфліктів злиття). Вас також можуть попросити зрозуміти розгалуження та об'єднання гілок. Деякі студії працюють там, де всі розробники отримують свою локальну філію, і ви можете зареєструватися скільки завгодно та об’єднати, коли ваш філія. В інших студіях (у нас) просто діє "не порушувати основну" політику, тому вам потрібно обов’язково оновити, зробити швидкий тест, щоб переконатися, що ви нічого не зламали, а потім зареєструйтесь. У деяких студіях немає що політика і люди постійно ламають лайно, і це дуже прикро, і вам доведеться навчитися працювати над цим.
• Огляди коду досить поширені. Іноді вони широко-кодові. Наша команда використовує код-підхід, коли це більше один на один для оглядів на реєстраціях. У будь-якому випадку слід очікувати, що вас попросять надати критичний аналіз коду інших людей.

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

Багато з того, що я робив, також було пов'язано з ІТ. Розробка внутрішніх інструментів була великою справою - деякі безпосередньо допомагали в розробці ігор, а інші - для автоматизації речей, які раніше робилися вручну. І звичайно, виправлення помилок для інших інструментів, включаючи Ігри Microsoft для інсталятора Windows Live.

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

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

Мій підсумковий рік - це елемент полотна HTML5. Зараз я працюю над стажуванням протягом останніх двох місяців, де мені потрібно перенести наявну флеш-гру до полотна HMTL5.

З того, що я можу вам розповісти про своє життя тут, добре, що його важко. Колектив вимог пред'являє дуже специфічні вимоги. Який натискання миші повинен робити, як впливати на гру. Як би це не було важко для програміста навіть для найрозумнішого запиту, його потрібно вирішити, і після того, як всі вимоги будуть виконані. Початок повідомлення про помилки. Бог це дратує. Це справді починає набирати собі нерви. Зсув 1px за клік може зробити ваше життя пекло, повірте! Це може означати нове структурування всього вашого простору для позиціонування та взаємодії, для чого ви можете підлаштовуватися під їх примхи та вигадки.

Але це також весело! :) Велика радість від написання цієї по-справжньому розумної функції, взаємодіючи із спільнотою про те, як ви могли відтворити функцію, яку спалах виконує автоматично. Все це. Такі часи, що ти не пошкодуєш, що працюєш. Створює це як найкраща робота у світі, а мої племінники - найкрутіша у світі.

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

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