CGAleksey

CGAleksey

Делаю 3D - головоломку от первого лица, публикую результаты работы. Сайт: torshock.com Тележка: @CGAleksey -
Пикабушник
Дата рождения: 01 января 1990
поставил 1256 плюсов и 96 минусов
отредактировал 0 постов
проголосовал за 0 редактирований
5314 рейтинг 27 подписчиков 23 подписки 71 пост 23 в горячем

Опыт эксплуатации MacBook Pro

Есть у меня 15-и дюймовый бук 14-го года.
Как-то раз мне пришлось отнести его в авторизированный центр так как батарея барахлила, а он был на гарантии.

Отнес, батарею заменили. Заплатил много, в надежде что сделают все качественно.

Ноут начал греться и я стал думать как-бы его почистить. Нести снова в центр и платить гору золота?
При осмотре ноута обнаружил, что один из болтов свернут. В этом месте и крышка немного не держится (а раньше 100% держалась), совсем малость и видно было, что болт в общем свернут так как обычной отвёрткой можно его бесконечно вращать. Свернули они так как больше было некому.

Решил, что больше ни в какой центр его не понесу, нафиг надо такое.

Купил пертрабол отвёртку, открыл, почистил от пыли.

Недавно у ноута снова вышла из строя батарея. Вздулась. Хорошо, что вовремя заметил, что задняя крышка вздулась и ноут из тонкого и ровного стал похож на джери, сьевшего апельсин:

Опыт эксплуатации MacBook Pro Mac, Macbook, Osx, Запланированное устаревание, Ремонт техники, Ремонт компьютеров, Ремонт ноутбуков, Длиннопост

Вздутие произошло быстро, за ночь. Нет, у меня есть глаза и я заметил это сразу, а не когда ноут стал совсем круглым. Так что хорошо, что повезло, что я еще был дома.

Отлично роюсь в сети в поисках нужного аккумуоятора, заказываю найденный за 4500руб (кстати, он и сейчас работает).

Прихожу в точку выдачи онлайн заказов. Забираю. Продавец - П.
П: сами менять будете?
Я: да
П: ну вы даёте, мы вот знакомому меняли, там столько проблем было. Слава богу что что-то не сломали.

Подумал, что мы сами с усами и нефиг больше давать технику всяким безруким. Сам накосячу, сам и отвечать буду.

Прихожу домой, снимаю крышку, отключаю разъём питания от основной платы. И все! Делов-то! Осталось отклеить аккумуляторы. Ломать не строить, отклеил и весь клей вычистил спиртом.

Поставил новые, включил ноут в разобранном состоянии. Работает. Приклеили аккумуляторы, закрыл крышку. Вот и все.

Но это ещё не все проблемы с ноутом.

У ноута отклеились ножки. Вот не поверите. Он все 6 лет стоял на столе ровно. Так же ровно как сидят на попе некоторые чиновники. И что, ножки у него сломались. Сами по себе сломались, просто отвалились.

В итоге вырезал из кожи от старого ральфринглера кругляки, посадил на клей супер-резину.

Опыт эксплуатации MacBook Pro Mac, Macbook, Osx, Запланированное устаревание, Ремонт техники, Ремонт компьютеров, Ремонт ноутбуков, Длиннопост
Опыт эксплуатации MacBook Pro Mac, Macbook, Osx, Запланированное устаревание, Ремонт техники, Ремонт компьютеров, Ремонт ноутбуков, Длиннопост

Сейчас ножки выглядят так:

Опыт эксплуатации MacBook Pro Mac, Macbook, Osx, Запланированное устаревание, Ремонт техники, Ремонт компьютеров, Ремонт ноутбуков, Длиннопост

Держатся мертво, за $24 не стал заказывать аналогичные.

Но я ещё не заикнулся о кабеле питания. С ним всем известно что могло стать. Этот шлюха-провод вышел из строя за... 3 месяца? Где-то так.

Опыт эксплуатации MacBook Pro Mac, Macbook, Osx, Запланированное устаревание, Ремонт техники, Ремонт компьютеров, Ремонт ноутбуков, Длиннопост

Покопался в сети, хотел найти тонкую металлическую оболочку типа тех, что продаются для зарядников для телефонов. Нужно метра 2 такой оболочки, так и не нашёл. Видел как в сети некоторые умельцы учат ремонтировать кабель шерстяной ниткой. Чёт как-то покрывать шерстяной ниткой, которую обмазали клеем... Как-то не захотелось. Если кто знает где продаётся, отпишитесь. Эта проблема с кабелем волнует вообще всех владельцев тезники. Даже на HP заменил бы кабель на кабель в металлическом кожухе.

Ну и под конец. Экран немного покрылся какими-то пятнами. Нет, это не мухи нагадили. Это что-то стало с покрытием экрана. Конечно не так ужасно как у некоторых, когда у тебя экран в огромных пятнах, но все равно... Весь экран в таких мелких пятнах не айс, когда ноут стоит 150к:

Опыт эксплуатации MacBook Pro Mac, Macbook, Osx, Запланированное устаревание, Ремонт техники, Ремонт компьютеров, Ремонт ноутбуков, Длиннопост

И резинка на мониторе задеревенела, а в области камеры отвалилась из-за того, что за эту часть открывают крышку, а не из-за того, что у меня когти как у коршуна.

В целом ноут хороший, жёсткий корпус, ssd, суперпроу, стоит как состояние. Даже сейчас параметры у него достаточно высокие, но со свои i7 8 ядер по 2.7 вроде, но при всем при этом он напрягается чтобы открыть MicrosoftOfficeWord. Может микрософтевцы мстят, делают такой софт, что osx не тянет. Хрен знает, некогда разбираться, да и неинтересно.

Показать полностью 6

Как я боролся с запрограммированным устареванием

Году в 10-м купил Lenovo P780. Стоил дорого. Тысяч 16, вроде. Ну, кому-то и 116 тысяч недорого, но не суть. Относился к нему бережно, не ронял и так далее.

Прослужил он у меня в сумме лет 4.5, начал тормозить через год после покупки.

Физически разваливаться он начал так:

Сперва начал разваливаться корпус. Говорят пластик не разлагается, но мой леново разлагается ещё как. Сыпется, превращается в труху. Ну ладно, не обращал внимания на то, что рядом с некоторыми болтами образовались трещины и болты вырвали часть корпуса и он уже в этих местах не держался:

Как я боролся с запрограммированным устареванием Телефон, Личный опыт, Запланированное устаревание, Девайс, Поломка, Длиннопост

Потом сломалась кнопка питания. Питание залипало и аппарат бесконечно перезагружался.
Решение: купил новую, заменил.
Проработал ннеделю и сломалась кнопка уменьшения звука. Просто не работала.

Ну и фиг с ней, звонит и хорошо. Не стал менять.

Далее ааккумулятор внезапно поплохело. Вышла из строя кнопка и на след лень/два, телефон снова отказывался запускаться. Батарее поплохело так, что она просто не выдавала питания 🙄
Ну, оона уже и так на ладан дышала и вот, накрылась окончательно. Кстати, вот она:

Как я боролся с запрограммированным устареванием Телефон, Личный опыт, Запланированное устаревание, Девайс, Поломка, Длиннопост

Хорошо, не будем сдаваться, меняем аккумулятор на новый за 400р.

Телефон заработал. Проработал неделю и перестал включаться вообще.
Поковырявшись, я узнал, что скорее всего отслоился/отпаялся один из микроконтроллеров или модулей памяти.

Специальных устройств для пайки нет, в итоге бой проиграл. Пошёл и купил новый аппарат.

Показать полностью 2

Привет средам разработки

В этом посте речь пойдёт о моем опыте разработки игр. Здесь немного сравню среды в которых можно создавать игры.
Этот пост будет интересен больше тем, кто только начал разрабатывать игры.

Как программисту, мне доводилось разрабатывать игры в таких средах разработки:
- DragonFireSDK
- AndroidStudio (разработка под андроид)
- VisualStudio с использованием отдельных графических библиотек OpenGL/DirectX
- Unity

Начну с самого ужасного исчадия ада, которое даже в аду провалится ещё куда-то ниже, с DragonFireSDK.

Плюсы:
- без мака можно сбилдить хоть что-то для ios планшета / телефона
- код на С++ (думаю неплохо для кого-то, я был рад)
- будете знать свой код как свои пять пальцев (почему? Пояснено в минусах)
- знание C++ и простеньких API - вот и весь порог вхождения
Минусы:
- нет возможности дебажить код на девайсе, забудьте про отладчик, профайлер - все это для слабаков
- финальный билд для аппстора стоит отдельных денег
- билд происходит на сервере и иногда проект не билдится по непонятной причине. Можно выяснять детали посредством переписки с саппортом.
- нет поддержки кирилических символов. Мало того, проект с ними положит сервер и его хозяин начнёт грозить баном.
- нет 3D, а кому он нужен?
- ограниченный набор API
- от всего этого может развиться шизофрения

Итак да, повозившись достаточно, сделав один простенький проект, я понял, что моё здоровье мне важнее и выкинул это SDK подальше. Рекомендовал бы студентам-лентяям сдавать на нем лабы по C++, в качестве наказания.

AndroidStudio...
Вот я не знаю куда катился мир в то время, когда я решил научиться билдить на нем билды для мобильных устройств. Вроде у крупных фирм и требования к программистам заоблачные, но все равно бывает что-то, что не работает. И это не кнопка интерфейса, а что-то важное. Ну например, в этой среде мне пришлось ужом извиться чтобы сбилдить билд.
Вот что ожидает программист в 21м веке, когда нажимает кнопку билд? Наверно то, что все оптимизированно и сделано за него. Что ему не придётся самому генерировать всякие make-файлы, что среда сама найдёт все пути к либам, что сама все сгруппмрует, сделает промежуточный бин и откомпиллирует это все в итоговый файл. Не знаю как сейчас, но тогда я выполнял тестовое задание для одной из игрофирм, в общем собрал проект, но уфигачил больше времени на разбор того как там явовский файл билдится. Трупрогеры скажут: должен знать. И я скажу: должен знать. Но можно знать все это в теории, а можно столкнуться на практике. Всё же в теории знают как машинные коды работают, нет? Ну и что теперь, давайте ручками это все вместо компа сделаем. Надеюсь сейчас в этой студии все стало лучше.

VisualStudio & OpenGL / DirectX.
Хорошее решение.
Плюсы:
- почти все делаешь сам. Сам на косячил - сам виноват. Не накосячил - очень вероятно, что сюрпризов не будет.
Минусы:
- высокий порог вхождения
- затратно по времени все делать самому. 21й век все таки на дворе. Интерактивная графика шагнула далеко. Придётся использовать какие-то внешние решения: библиотеки чтобы быть в ногу со временем.
- API библиотек (ну графических точно) не стоит на месте, придётся не отставать.

В целом этот вариант хороший, надёжный, а минусы незначительны по сравнению с плюсами. Ну, незначительны для программистов. Без знания основ тут ничего не сделаешь.


Unity
Кто-то сильно хвалит, кто-то сильно принижает Unity. В сети часто можно встретить сравнение графона Unity vs UE, где, как правило, графон анрила выглядит царски, а графон юньки показан нищебродски. Лично у меня нет опыта работы с анрилом, но у меня есть знакомые. Мы обсуждали технологии анрила и юнити и пришли к тому, что качество графона зависит от прямоты рук разработчиков. Вот и все.

Это все обман и надувательство
Когда-то давно, когда я был зеленее огурца, я считал, что максималка в настройках качества игрового графона на самом деле выжимает максимум из компа и видеокарты и в голове рисовалась такая идеалистическая картина: комп работает на полную, вентилятор на карте крутит сильнее так как качество картинки требует больше энергии. Данных подаётся больше обычного, но комп во-вот все же как-то справляется со всем с этим(потому что очевидно, что у меня хороший комп). Ну вы поняли.
Сейчас-то я в курсе, что можно нарисовать один треугольник так неоптимально, что на нем жахнется вся производительность. Другими словами: качество картинки зависит не только от мощности, но и от оптимизации. Я даже скажу так: от оптимизации зависит все.
Пусть комп - это процессор. Он за секунду может выполнить много операций. Как много бы он ни выполнял, максимум операций - это конкретное число N. Если число операций больше N, то все, комп ждёт пока все выполнится и число кадров в секунду будет меньше 60(напрммер).

Небольшое отступление.
Что интересно. Раньше я думал, что почти всем разработчикам это известно. Кроме тех, что ещё в детском саду или школе. А нет, оказалось, что есть и такие, которые закончили инсты, но не понимают этого, сам видел таких.

Ну и вот, очевидная вещь: максимальное качество картинки заложено не только в железе, но и в используемых алгоритмах.

Плюсы:
- низкий порог вхождения (создавать могут даже не программисты)
- кроссплатформеность
- встроенные либы, в т. ч. физика
- есть отладчик, можно дебажить как хочешь
- можно выбирать разные графические апи и билдить под них
Тут можно написать ещё много всякого, например поддержка сети, UNet, IJob, CloudWork.
Минусы:
- если есть баг, то он может быть юнитевским. И фиг поймёшь твой он или их, нужно искать. Например так у меня недавно вылетала среда. Просто закрывалась и все. Представляете какой трабл, если вы юбисофт, у вас там куча и даже больше кучи всякого кода и игра просто вылетает. Да-да, идём в логи эдитора и смотрим, исследуем что не так.
- повторю ещё раз. Везде есть баги. Просто смиритесь. У них всегда и везде есть баги.
- переключение graphic API - это непростое занятие. Думаете просто переключить код написанный под openGL на DirectX? Думаете unity за вас учтет особенности depth буфферов и нужно ли инвертировать текстуру на экране по оси Y... ? Хотя они и учитывают многое, но и вам придётся тоже учитывать многие нюансы. Так что если хотите собрать что-то во много раз сложнее крестиков-ноликов, то придётся знать специфики разных платформ.
- закрытость движка. Да, многое открыто, но многое и закрыто. Ну например, вам нужно без камеры определить какие объекты попали в область видимости и нужно отсечь невидимые объекты. Другими словами, доступ к octree вы не получите. Не беда, велосипеды никто не отменял.

Здесь приведены далеко не все плюсы и минусы, только мелкий кусочек.


Это все на сегодня.
Надеюсь кому-то было интересно и кто-то узнал что-то новое.
Спасибо за внимание!

Показать полностью

Начало разработки игры (команда. часть 2)

В предыдущем посте я бегло рассказал о том как пытался собрать команду разработчиков.

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


Не бывает так, что "человек-никто из ниоткуда и звать его непонятно как" идет-идет, бах, пришла идея игры, он пошел и нашел где-то команду, а потом и спонсора, а потом все сделал с ними и все жили долго и счастливо :)

Хотя вполне бывает, что человек(зародыш гейм-дизайнера) думает, что его идея гениальна, но на самом деле это вовсе не так...


Один из читателей подметил, что собрать команду - это уже достижение. Да, с этим можно частично согласиться. Я бы сказал так: собрать всегда можно что-то, если ты наделен возможностью коммуникации. То есть если ты говорящий, то уже можно чего-то добиться. Другое дело - это качество собранной команды, персональные особенности каждого члена команды. Вот это на самом деле важно. Можно набрать армию неумех и смотреть как эта армия расползается на глазах не делая ничего - это одна комнада, ее набрать достаточно просто. Можно найти пару специалистов, которые заменит армию неумех - это уже другая команда и найти их будет куда сложнее. На мой взгляд, если вы все же сумели уговорить специалистов, ну или хотябы не школьников, то в вашей идее возможно что-то и есть, хотя опять же не факт.




Еще немного о команде.

Очень часто, начинающие команды, начинают делать одно, а получается у них что-то другое. Такое часто бывает. Ну, например, обычный случай: начинают создавать MMORPG, а на выходе получается тетрис, ну или в лучшем случай рогьюлайк какой-нибудь.


В чем тут может быть дело? А дело может быть вообще в чем угодно. Но в основном разбор полетов нужно начинать с главного гейм-дизайнера. Кто он, есть ли у него опыт разработки подобного? И куда он/они смотрели при разработке если вдруг что-то пошло не так...

И да, какую команду он набрал? Дальше идем по всем специалистам и по тому что они реально умеют делать.

Часто диванные критики говорят что-то типа: "игра это совместное детище, все принимают участие в разработке, все вкладывают частичку себя" ни и прочее бла-бла-бла.


Да-да, это все так, но не на 100%. Во-первых команда - это организованная структура. Это, так сказать, машина настроенная под определенные задачи. Условно, в настоящей команде есть разные специалисты и каждый специалист решает свои задачи. Этому каждому специалисту есть что решать и над чем работать и он не лезет изо всех сил не в свою сферу пытаясь внести что-то свое. Например, очень часто встречается такое, что программист пытается научить дизайнера как и что делать. Это не его задача вооообще. Максимум он может посоветовать, но так, слегка намекнув, очень отдаленно и не более. На то у команды есть главный гейм-дизайнер или другой человек, который следит за общей картиной, делегирует часть своих полномочий другим членам команды, работает с разными частями проекта.


То, что я описал выше, это такой идеализированный случай (типа сферического коня в вакуме), который на практике не учитывает ничего и такого в реальной жизни не встретишь потому, что один человек не может быть специалистом во всем. Для того чтобы все же учесть максимум, приходится общаться со всеми вместе, чтобы все делились своими взглядами/мнениями. Это в общем-то неплохо, потому что в этом случае информация о проекте синхронизируется и команда лучше понимает детали.


Игры - это достаточно сложные вещи и быть специалистом во всем невозможно. Почему так?

С одной строны пока вы разрабатываете игру, выходит Vukan/DirectX12,15,25,125 и так далее. То есть технологии не стоят на месте. Все согласны?

C другой строны очень маловероятно, что один человек настолько разносторонне развит, что совмещает в себе программиста, художника, дизайнера(а вернее кучу направлений игрового дизайна), звукодизайнера и да, немаоважная деталь -> все это у него на конкурентноспособном уровне.


Скажу так: очень здорово, если вы будете специалистом хотябы в чем-то одном...

Да, специалистов на все руки нынче не ценят. Еще студентом, я пробовал устроиться в одну очень крупную игровую фирму и понял, что чтобы туда попасть я должен был к тому времени знать все что только можно было знать по С++11.

Что еще немаловажно, знать это нужно было еще пол года назад, а лучше год назад, а лучше до выхода стандарта. Это как старый мем со Swift: язык только вышел, а в сети уже требуют спецов с опытом работы от 4-х лет.


Вернемся к команде, которую я пытался собрать.


После краха с Васей мои руки не опустились. Как говорится: "Все, что нас не убивает, делает нас калеками".

Я сразу же приступил к разработке другого проекта. Товарищей было найти труднее. Особенно, когда у тебя уже есть небольшое понимание того, что вам предстоит делать. А еще, когда у тебя есть опыт, то тяжело смотреть, как человек забивает гвоздь в стену задом на перед, да еще и не соглашается с этим.

Итак, благодаря моим знакомым мне удалось найти вроде как более-менее нормальных ребят. Ну, скажем так: дареному коню в зубы не смотрят.

Что получилось в результате? В результате кто-то работал, а кто-то не знал что делать. Тут я понял, что невозможно работать, когда ты живешь в общежитии, другие ребята еще где-то и вы делаете что-то общее. Не буду ходить вокруг, да около. Скажу прямо: важна сплоченность команды. А у нас этого не было. В команде был я(мастер на все что надо сделать), программист, левел-дизайнер и 2 графических дизайнера (которые должны были игрыгать арты, скетчи и прочие идеи так, как вулкан изрыгает лаву).

Программист был достаточно толковый, пытался как-то нас обьединить, в общем парень что надо. Да и все пытались как-то дружить... Но все же не пошло. Оказалось, что команда как и дружба - это дело тонкое.

Через какое-то время все распалось. Причину распада могу выделить такую: собрались некомандные игроки. Ребята, конечно, хорошие, но они не под такие задачи.

Что произошло далее. Далее я случайно пересекся с парнем, которого слабовато знал: знал что он существует и учится в параллельной группе. 100 лет назад вроде как я кинул ему идею разработки игры( хотя может он сам до нее дошел, а может все же я помог дойти. Спрашивать как-то неудобно). В общем парень оказался трудолюбивым, упоным. С ним вроде как все клеится и мы до сих пор работаем. Главное что дело движется :)


На сегодня все,

Спасибо за внимание!

Показать полностью

Начало разработки игры (команда. часть 1)

Как и обещал. В этом посте будет часть опыта, которую я приобрел в процессе поиска святого грааля/команды.

Плохая команда на дороге не валяется, а хорошая и подавно.

Итак, поехали!


Команда разработчиков.

Команда - это сердце игры. От качества команды зависит буквально все. Крупные фирмы старательно выпестывают свою команду, организуют всякие корпоративы, встречи, собрания и так далее. Все это делается не просто так, все это показывает насколько важны "шестеренки", которые производят продукт.


Какие есть требования к членам команды?

Требования ко всему предьявляются исходя из того, что вы хотите сделать. Разумно? А как же иначе. И это нужно держать в голове.

Если вы разрабатываете космический корабль, не будете же вы искать членов команды среди поваров, даже если последние готовят на самом деле очень вкусно XD


Я инди, комнада нужна была для разработок инди-игр... Опустим вопрос зачем вам вообще что-то разрабатывать (хотя это большая тема).

Все же какие требования предьявляются к инди-разработчикам? Давайте разбираться, это очень непростой вопрос.


Во-первых зададим себе вопрос: что я могу? Далее берем абстрактную инди-команду, которая состоит из "вас" и еще 10 "вас", которые в вашем лице все сделают.


Что вы планируете создать? Нет-нет, давайте поставим вопрос так: "что вы можете создать?" GTA6, Crysis, Portal4, TeamFortress? Нужно отталкиваться от того что вы можете, а не от того что только что сверкнуло в голове или от того что вы нафантазировали.


Вы можете создать все что придумали/запланировали? Да? Тогда почему до сих пор не создали? На создание всего нужно время? Если вы на самом деле можете все сами создать, то вы золотой человек и мастер на все руки, молодец, таких людей очень-очень и оень мало. Надеюсь вас очень ценят.


Если вы не можете создать все, что придумали, то зачем вам инди? Для души?


<<По волнам моего опыта>>


Школа


С 10 класса я уже пробовал работать в команде. Но что-то никак ничего не удавалось. Школьники они знаете... они такие... в общем-то обычные.

Итак. 10-й класс, середина учебного года. У меня на руках план игры и товарищи, которым я его предлагаю. Набирается кучка товарищей, которая хочет начать делать. Эта кучка сразу же и отваливается.

Мотивы этой команды:

- попробовать что-то новое

- похвастаться "я делаю игру"

- опыт (может в будущем поможет)


Смотрите, среди мотивов не было:

- желание заработать

- желание совместно работать далше

- даже желания закончить, самоутвердиться, сделать свой продукт


Гоним в шею такую команду и себя вместе с ней, если вы хотите просто получить опыт и куда-то утечь, возможно на "сторону врага".

Итог: игру допилил сам.



Институт


Итак, теперь я уже знал людей немного больше. Ищем людей, которые имеют:

- огромное желание заработать

- хотят посвятить себя разработке игр

- беспокоятся о качестве продукта


Я уже набрал горку книжек  понял, что на первом курсе точно нужно либу учиться, либо вылетать вверх тормашками. Пришлось выбрать учебу.

Итак, первым, кто захотел что-то делать был мой сосед. Назовем его Вася. Парень он был хороший, но я его тогда еще хорошо не знал. Мы зарядили проект, параллельно работали. Но что-то пошло не так.

Что пошло не так как планировалось. Поначалу я не придавал значения тому, что Вася имеет свое собственное "чувство прекрасного" и оно никак не коррелирует с тем, чему учат дизайнеров. Ну и еще была такая особенность Васи: сделать по правилам дизайна (или хотябы учесть их) - это значит пойти на компромисс. То есть сделать так как я говорю ссылаясь на что-то там неважное, на какую-то книжку. Да тьфу там на все книжки, мы сами с усами, все знаем.

Это все смешно звучит, на деле это совсем не смешно. Это просто дырнь в команде.

Кстати, я закончил школу с дизайнским уклоном, поступил в технический вуз. Вот такие чудеса бывают.


Итак, до меня дошло, что что-то у нас не так. Если честно, то "не так" у нас было с самого начала, а именно: мы с Васей не договорились о том, за кем будет последнее решение. Это я понял достаточно быстро, поехали дальше.

Что делать, когда молодой программист не считается с твоим мнением (а ты, допустим, прав. Но нужно не исключать, что ты можеim быть и не прав) и пытается показать: всякие цветопалитры, габариты обьектов и прочее - все это для новичком, а мы и сами с усами?


Следующий шаг был таким: мы нашли дизайнера.

Ход моих мыслей был таким: нужно уравновесить Васю и его стремление учиться быть дизайнером на нашем проекте. Если Вася не доверяет мне, то дизайнеру-то он точно доверится. В итоге молодая девушка дизайнер (она была не из нашего института) посмотрела на идеи Васи и плавно отмела их. Так сказать неявно встала на мою сторону. Ну а как не встать, когда Вася не понимает, что чем больше обьект занимает экранного пространства, тем он значимей. Не всегда так, но этот базовый принцип работает везде. Это основа. Такая же очевидная как и: на белом листе должны быть буквы, которые контрастируют с белым (черные), но никак не белые и даже не светло-серые.


Итак, мы уконтрапупили Васю, вроде все хорошо, работаем дальше. 75% игры завершено. Сценарий у нас был, игра проходила тесты. Но тут Васе снова сверкнула мысль и он решил стать сценаристом. Сценарий у нас уже был, все готово для тестов, но нет... Вася придумывает нововведение, которое наносит удар по core-механике игры. Убедить его ни в чем не удается.

Потом было нанесено еще пару ударов.


Итак, как быть с Васей, когда тот плохо понимает, что делает?


Ну что, искать сценариста, гейм-дизайнера и всю команду чтобы уравнять Васю во всем? Подвернулась отличная идея: предложить инвестору сделать игру-аркаду, продать ее и на ней мы с Васей оценим наши промахи и попадания. В 2-х словах: находим инвестора, делаем игру.


В процессе разработки я не бьюсь как рыба об лед чтобы убедить Васю, что он делает ошибки, снимаю с себя эти полномочия и оставляю за ним последнее слово.
Игру завершили, ее созданием руководил Вася. Мы провалились в маркетинге и во всем что только можно было. В процессе разработки с нами работала дизайнер, она работала так же как и я под руководством Васи. Честно говоря, этой девушке было по барабану что рисовать и вообще все до фанаря. Ну вы понимаете что бывает с игрой при таком отношении.

Игра "не пошла" так как ног у нее не было. Я начинаю разбор полетов и перебор ошибок, критику всего. Так же я говорю Васе прямо в каких местах он допустил очевидные ошибки. Понятное дело, ошибок было столько, что Васе моя критика не понравилась. Ну а кому понравится, когда говорят, что твоя игра буквально полностью кака? Так же пришлось подчеркнуть, что я намеренно дал полную свободу Васе, чтобы он видел во что он может привести наш проект.


Итог работы над игрой с инвестором: Вася меня не понял, а только обиделся. Его мнение относительно всего так и не изменилось.

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


Итог: в общем на этом этапе я покинул Васю. Совместная с ним игра была завершена на 75%. Я бы сказал она была классная до того как Вася начал лезть туда куда ему не следует.
Почему я больше не стал работать с Васей? Иногда надо принять то, что лучше остановиться сейчас, чем потратить кучу времени впустую и прийти к разбирому корыту. В мире есть куда более талантливые и опытные ребята с которыми силы будут уходить на "создание результата", а не на войну в команде.


Какие я сделал выводы:

1) конечное решение принимается всегда одним человеком и его нужно выбрать в самом начале формирования команды.


В семье один глава, как правило, - это мужчина (последнее решение за ним).

В государстве тоже один глава - президент, он принимает окончательное решение.

У человека одна голова на плечах и она принимает решение за все тело.


2) члены команды должны быть гибкими


3) члены команды должны иметь представление о том как "это делается".


В следующей статье будет продолжение.


На сегодня все.

До встречи!

Показать полностью

Начало разработки игры (продолжение 1)

В прошлом посте я взялся рассказывать о своем личном опыте разработки игр (и нетолько игр).

Итак, моя первая игра была: СУ27, горы, облака, враг-точка (враг не работал).

Игра работала очень просто. Настолько просто, что даже я смог заставить самолет лететь невникая в векторную арифметику: сложение вектров, скалярное произведение и так далее.

Я вырезал картинку СУ27, фон закрасил розовым так как почему-то именно этот цвет распознавался моей средой разработки как прозрачный.

Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост

Итак, здесь все просто, картинка выводится в определенном месте экрана с координатами (x,y).

Добавил обработчик нажатия клавиш и так у меня появилась возможность перемещать картинку. В обработчике все просто: в зависимости от нажатой клавиши нужно прибавлять/выяитать текущую позицию картинки самолета.

Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост
Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост

Таким образом самолет у нас будет летать. Думаю мои посты будут полезны самым юным читателям-пикабушникам :)

Самолет летает и это круто. Но как-то он летал как "кирпич". Пришлось добавить анимации наклона при наборе / сбросе высоты. Дополнительные картинки анимаций приложил к посту. Картинок было больше, но все равно это все смотрелось немного бедно, но не для меня в то время XD

Потом я слепил облака и горы из... пластилина. Магия паинта, цветокоррекция и ничего более. Хотя гору я все же вырезал откуда-то. Моя была слеплена из коричневого пластилина и вы сами понимаете на что это было похоже. Такую пластилиновую гору хоть как обрабатывай и фотошопь XD

Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост
Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост

Горы/облака шли все время в стороу самолета. То есть координата "x" у них уменьшалась (декрементилась). Облака проходили сквозь самолет и не задевали его. А вот с горами пришлось повозиться. Но все равно не удалось добиться того чтобы гора идеально сталкивалась с самолетом. Гору описал квадратом: то есть если нижняя координата самолета ниже верхней координаты горы И координата начала или конца самолета(это х самолета) находятся между координатами начала и конца горы(х горы), то наш самолет врезался в гору.

Этого было достаточно для того чтобы порадовать и себя и родителей самым простой версией игры.

Ну что там с тестами этой игры на сестре?

Это был кошмар потому, что ей нельзя было угодить. Приходилось много думать над : почему моя игра ей не нравится, а вот другая нравится. Мало того, мне и самому начало приходить озарение, что с моей игрой не все так гладко, как мне казалось в самом начале.

У меня было много предположений. Ну знаете как это бывает когда у тебя кривые руки настолько, что просто ты не имеешь представления о прямых руках. Так и я винил все время сестру в том, что это ее проблемы, что она не может в это играть и ей неинтересно. Итак, мы не сдаемся и пошли в бой. В первую очередь я решил заменить самолет на супермена. Не помогло. А супермен был таким классным, сами зацените.

Хорошо, супермен-спайдермен не прокатил. Может улучшим графон? Заменил шоры на другие и самолет прокачал. Теперь все стало смотреться... ну... скажем "иначе". И это меня не спасло. А еще и не спасло то, что мои знакоме опускали мою игру не хуже моей сестры и мое чсв / эго или как это назвать было просто растоптано.

Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост
Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост

Итак. Главное не сдаваться.

Сравнительный анализ существующих игр и моей показал:

- графон бедный

- музыки и звуков нет

- анимации настолько бедные, что даже сложно достичь моего дна

- нет сюжета


Я понял важную вещь. Вообще я заметил, что многим новичкам свойственно находить какую-то одну проблему и свято верить, что все дело в ней. Они верят, что вот если они исправят эту проблему, то все "выстрелит". Итак, я в свои 15-16 лет заключил то же самое. А конкретно мое заключение было таким:

"Я являюсь творческим человеком, с неимоверным фантаном таланта и морем фантазии. Но, к сожалению, данный тип игр наименее подходит для реализации мной. Приняв это, я заключаю, что другие типы игр у меня бы получились лучше". Хорошее заключение, неправда?


После краха с самолетиком я взялся за реализацию супер-пупер мега игры "Пианино". Название говорит само за себя. В общем я собрал пианино для компа и управление сделал мышкой. Ну вы поняли, что у компа одна мышка, а нажатий у пианино может быть больше одного и все переделал под кнопки. Игра получилась так себе.

Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост
Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост

Тут я понял, что и с "Пианино" у меня не особо все гладко. Игра есть, а играть неинтресно. Не, такие игры не для меня. Нет, ну я знаю что могу созать шедевр, но вот вся проблема в среде разработки. Это она во всем виновата и сковывает мои возможности. А еще и программы падают от переполнения памяти. Потом я понял, что память имеет свойство заканчиваться и потому нужно освобождать массивы. Попыжившись с пианино и точно поняв, что игру не исправить заменой картинок фона и приветствия, я пошел дальше.

Начало разработки игры (продолжение 1) Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост

Интернета у меня не было, но было много товарищей для проведения на них тестов. А это, кстати, ой как полезно. Наверно, кто не тестировал тот не поймет. Я как-то читал в книге про гейм-дизайн про бла-бла-бла важные качества гейм-дизайнера. И в этой книге автор сказал, что самым важным качеством гейм-дизайнера является "умение слушать". Ну что, это так, да, правда.


Это очень важно. Но это не все и далеко не все. Есть еще куда более важное качество, которое я пока умышленно утаю от читателей. Все же дам толстенный намек: нет такого одного спец-качества, которое поможет вам преуспеть в гейм-дизайне. Нет и не существует такого скрытого одного "чего-то", такого, что когда ты это понял, то сразу добился успеха ;D Если кто-то предлагает вам ключ к успеху или к счастью, то не ведитесь.



Подытожим. До поступления в инст мне удалось сделать пару игр и взяться за С++ / assembler. В это время я мог ковырять/ломать программы (дизассемблером). Немного освоил DirectX9(не уверен что 9), OpenGL какой-то, всякие windowsForms apps (да-да, те самые в которых чтобы создать окно нужно было передать в функцию столько переменных, что и жизни не хватит все туда записать).

Кстати, в инсте я удивился, когда обнаружил как все быстро меняется. Мои познания в DirectX каком-то уже были непригодны для DirectX12. Да и шейдеры там какие-то появились, световые модели и вообще что-то офигенное. В общем было над чем работать.


В инсте(хотя еще в школе) я понял, что нужна команда. Команда разработчиков. Одному игры делать можно, но долговато. После пианино и самолетика я сделал кучу других игр и они были достаточно играбельны. В общем я как человек из подполья делал игры в подполье XD


В следующей статье я поделюсь опытом относительно того как пошло дело с командой и что из этого вышло.



Кстати, здесь я выкладываю пока наброски процесса разработки своей игры:

https://twitter.com/CGAleksey

https://www.instagram.com/cgaleksey/

https://www.reddit.com/user/CGAleksey



А на сегодня все,

До встречи!

Показать полностью 7

Начало разработки игры

Имея некий опыт в разработке игр, а именно опыт в разработке:

- программного кода

- алгоритмов

- арта

- немого нарратива (преподнесения игровой истории)

- интерфейса

- игровых механик

- и еще в чем-то, что сейчас не приходит на ум...


В своих постах я хотел бы поделиться тем как я пришел к разработке игр и рассказывать о процессе разработки своей собственной игры.


Заранее извиняюсь за все неточности, которые вы встретите в моих постах. В оправдание могу сказать, что написание постов - это не моя задача, а что-то типа "может кому-то будет интересно".

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

Начало:


Итак, далекий 1997 год, мне тогда было лет 6 и я яростно штудировал журнал "МК". До сих пор помню, классный был журнал. Понятно, что я мало чего в нем понимал, но изучать все это было на самом деле круто. Настящий чертеж самолета или корабля и все это в одном журнале. Журналов было штук 450. Точно не скажу, но мой отец собирал все так как ему тоже было интересено.


Годам к 10 я понял, что буду разработчиком. Неважно кем, да я и не понимал, что разработчиков былвает 100500 видов, но главное разработчиком.

Микросхем и прочего у меня не было. Их вообще нигде не было в моей "деревеньке". Часто приходилось выпаивать/распаивать и так далее. Толком ничего не работало потому, что сделать все 1:1, как написано в книжке, не удавалось.


Ну и ладно подумал я, по телеку шла передача "Позвоните Кузе" и это стало моим новым увлечением. Нет, не игра, а само устройсвто - компьютер! Что в 12 лет можно знать о компьютерах, когда их никогда не видел? В общем поговорив с отцом я собрал коробку из бумаги и сделал что-то, что явно не компьютер. Быстро пришло понимание, что компы это что-то сложнее бумаги, веревки и того кто за это все тянет. Да и игра еще как-то не такая как в телеке, совсем... Что-то не то.

Порывшись в журналах, я нашел печатную плату какого-то старого компа "Электроника". Запустить его не удаось так как от электроники была одна лишь плата XD

Вскоре отец купил комп. Совпадение ли эти или еще что-то??? На компе была WindowsXP, которую я быстро освоил, знал чуть ли не все файлики в папке System32.
Что произошло дальше? Я начал изучать то как все работает. Комп с операционкой был для меня настоящим черным ящиком. Как исследуют черные ящики? Впрочем тогда я не знал как их исследуют, но исследовал примерно правильно. То есть я подавал на вход ящика значение и смотрел что будет на выходе.


Итак, я брал приложение "блокнот", открывал в нем dll, exe и все прочее и думал, что читаю настоящие машинные коды. Частично это было так. Потом я вносил изменения в файл, сохранял файл в папке System32 вместо того что там был. Ну и... Ну и я долго не мог понять что блокнотом бинарные файлы нельзя изменять. Так как блокнот сохраняет файл в другой кодировке и, даже, если его не менять, то файл становится испорченным.

Сколько раз я грохал систему таким образом... Часто она падала сама, но там даже не разберешь я ли это был или она сама падала... Но однозначно могу сказать, что доля вины была на мне.

Так я разбирался с тем как работает все класса до 7-го. Узнал про #Assembler, @Ida и прочее.
В школе на уроках информатики нам не могли толком ничего рассказать кроме какой-то черепашки, которая, вместо привития интереса к программированию, лично у меня вызвала отвражение :/


И вот как-то однажды при обмене дисками с товарищами я нашел какую-то среду разработки. Это не была VisualStudio и это не был BorlandC++. Даже не знаю что это было. Сейчас думаю, что эт была чья-то крутая курсовая или что-то типа того.


В общем, у меня была среда и она выводила "Hello World!".  Более того, она имела набор примеров вывода картинок, работы с памятью и вообще кучу всего о чем я даже не имел представления. Язык был похож на язык С++. Но это не был ни С++ ни C#.

Итак, делать было нечего, нужно было разбираться с тем, что было. Повозившись с месяц я все же смог собрать без учебников о геймразработке и вообще без всего что-то типа Platupus. Что там было: картинка Су27, облака, горы и враг, который не работал. Самолет летел вверх-вниз, а горы шли на него. Горы рандомно генерировались, убого сбивали самоле, если он касался их.

И да, через какое-то время программа вылетала и я не мог понять В ЧЕМ ДЕЛО. Кажется эта среда разработки не имела отладчика вообще. Код просто компилировался и работал или (чаще) не работал и указывал где есть ошибка.


Несмотря на все это я ликовал и чуть ли не ходил на руках от того что собрал игру. Надо же, ОНО РАБОТАЕТ! Если кому-то интересно, я могу позже опубликовать что-то из игры так как я сохранил ее части на память. Много чего потерялось, но что-то осталось.


Радостный я побежал к сестре и решил посмотреть что она скажет о моей игре. Получить, так сказать, первый отзыв. Ну что, отзыв был нелстный. Даже скажу больше, мою работу конкретно опустили XD

Печально видеть как твою работу критикуют, да еще и чесно. Но, скажу по секрету всему свету, честная критика (даже просто негативная) - это то, что делает разработчика лучше.


На этом этапе тестирования я выявил очень много интересных моментов для себя. Таких, о которых многие гейм-дизайнеры (в основном) не знают.
Ну например:

- человек будет играть в твою игру именно так как он захочет. Не так как разработчик запланировал, а так как ОН захочет. И никто не заставит его играть неудобным для него способом.

Мастерство гейм-дизайнера (не все мастерство, часть) заключается в том, что игрок играет в игру по разработанным гейм-дизайнером правилам.

- ощущение пространства. Игровое пространство ощущается. Это незаметно игрокам, но они это чувствуют. Например стоя на выступе ты имеешь превосходство, больше выбора. А вот спрыгнув с него ты уже можеim и не запрыгнуть назад.

- и многие другие...


Все эти особенность сложно (да и бессмысленно) описать в целом. Их нужно рассматривать в контексте игры. Одни особенности важны в одной игре, а в другой они вообще бесполезны.


(На фотке Trello и документация к игре)

Здесь я выкладываю пока наброски процесса разработки:

https://twitter.com/CGAleksey

https://www.instagram.com/cgaleksey/

https://www.reddit.com/user/CGAleksey



Думаю на сегодня все.

Спасибо за внимание!

Начало разработки игры Игры, Gamedev, Инди, Инди игра, Компьютерные игры, Длиннопост
Показать полностью 1
Отличная работа, все прочитано!