Введение в проблему
Здравствуйте, дорогие читатели!
Мысли о создании серии простых уроков «концептуальные идеи для новичков игродева» появились у меня спонтанно, где-то в 2:00 по Московскому времени во время создания своего нынешнего проекта. Ну нет, это так мне кажется, что спонтанно, но, наверное, это мое подсознание так среагировало. Среагировало потому, что все больше юных (коим я и сам являюсь) и очень юных программистов решают заняться созданием игр. Как мне кажется, общая тенденция молодежи-программистов (и людей, интересующихся сферой программирования) плавно перешла от создания сайтов и модных блогов к созданию развлекательных продуктов. Я начинаю замечать это и среди своих знакомых, которые одно время говорили, что, мол игры — это не серьезное программирование, но теперь уже проявляют настоящий интерес к этой среде.
Я объясняю это для себя следующим, очевидным образом. Любые информационные направления приобретает массовые тенденции к изучению при выполнении двух условий: наличие простого и адекватного инструмента осуществления конкретных задач в выбранной информационной сфере и легкость получения прибыли при продаже ваших выполненных задач. В пример же опять можно привести сферу веб-технологий (когда-то сайты было создавать ультра-хардкорно, а сейчас, наверное, даже моя мама сможет поставить блог на WordPress или его аналогах. Опять же почему? Потому что WordPress открыл возможность создавать свои блоги всем мамам вокруг света, и потому что веб-сайты открыли доступ к быстрой популярности, славе, деньгам и рому).
Но пришла эра развлечений – я не буду упоминать с каким трудом делались первые игры, но прошли десятилетия, стали появляться платные игровые движки, через какое-то время они стали практически бесплатные (Unity, Unreal Engine4), причем не движки от Васи с соседнего подъезда в которых можно только сделать “грабеж корованов ”, а движки мастодонты который представляют из себя комплексные среды разработки, способные реализовать ваши проекты мечты. Однако есть и обратная сторона этих популярных технологий. А именно большое количество некачественных продуктов. Обленились придумывать что-то свое… “Лучше сделаю флеппи берд!” – подумал Вася.
И я решил, что надо сделать серию уроков состоящих из простых идей, которые могут использовать люди в своих самых первых проектах, люди, которые, может быть, не так давно начали изучать программирование вообще.
Случайная генерация 2D моделей (Unity)
Когда вы делаете игру в одиночку, не всегда бывает возможно нарисовать большое количество спрайтов для ваших персонажей, кораблей или зданий, вообще объектов.
Тут и приходит на помощь процедурная(случайная) генерация. Что значит этот термин в двух (шести) словах? «Модельку создает компьютер, а не вы».
На просторах интернета вы можете найти миллионы алгоритмов процедурной генерации в сфере геймдева (может быть, один из них даже описан моей мамой в собственном блоге). Одни из них будут просто сложные (как например генерация водной поверхности с использованием Nvidia Physics), другие из них будут экстремально сложные, как например сегментация рельефа с использованием нечеткой логики и нечетких множеств (Fuzzy Sets).
И что? Не думаю, что человек, который второй раз открывает юнити начнет думать, как ему понять, как реализовать и в какое место игры применить найденный алгоритм.
Проще реализовать свой! Пусть он будет простой, зато понятный вам. А это самый важный шаг во всем программировании.
Предлагаю вам свой вариант процедурной генерации модельки (применим к любой 2D игре). Предупреждаю, код экстремально простой! Две строчки! Но сначала, то, что вы должны подготовить перед осуществлением кода:
1. Понять какую модель (или объект) вы хотите создавать процедурно – это может быть ваш рыцарь, здание, космический корабль и тд.
2. Разбить на столько элементарных частей сколько вы хотите (например, для рыцаря это могут быть шлем, меч, щит, нагрудник).
Примечание: чем меньше отдельные элементы (например, меч вы разобьете на рукоять и лезвие), тем очевидно, что ваша сгенерированная модель будет выглядеть более натурально и уникально.
3. Нарисовать на каждый элемент столько различных спрайтов сколько считаете нужным.
4. Соберите свою модель в редакторе Unity, так, как она должна выглядеть. Я буду использовать в виде примера модельку корабля из своего нынешнего проекта.
Вот мои детали-спрайты разбросаны на сцене, из них я соберу модель геометрически нужную мне.
И настает время кода!
Функция ChangeTextureFunc() содержит всего две строчки кода, как и обещал.
Навесьте скрипт на каждый элемент вашего объекта как показано на скрине. Закиньте спрайты каждого элемента в массив прямо в эдиторе, и радуйтесь результату.
Эффектный результат:
P.S Старайтесь спрайты для вашей модели делать одного размера чтобы не было смещений в модели, однако если вы все же хотите сделать какой-нибудь особо изысканный спрайт, который кардинально отличен по размерам от основного множества, то просто передвиньте в sprite editor'e точку вращения (Pivot point), которая будет определять центр спрайта, на столько сколько вам нужно. Иногда в Unity забывают про эту возможность.
Вывод:
Конечно я вас немного обманул сказав, что вы получите процедурную генерацию моделей, скорее это можно назвать быстрым комбинированием модели из заданных спрайтов. Но тут же хочу сказать в защиту этого подхода:
1) Ну кода нет, ты рисуешь три кораблика делишь каждый на три одинаковых элемента и на выходе получаешь 27 моделек кораблей. Ура.
2) Вы скажете, что вы крутой мозг и сможете написать алгоритм, который будет сам и контуры кораблей выбирать и расцветку подставлять свою и у вас будет 1000000 комбинаций, ну а я вам отвечу, что каждая ваша модель будет крякозяброй потому что не забывайте, что разработка игр в том числе и искусство. И 10000 ваших безвкусных кракозябр никому не запомнятся.
3) Для новичков это будет впечатляющим результатом, который может подтолкнуть их к развитию этой идеи вширь и вглубь.
Идеи:
Вот кстати примеры, которые я придумал прямо во время написания этой статьи, как это можно интересно использовать:
1) Навесьте на каждый элемент скрипт содержащий параметры, которые вписываются в сеттинг вашей игры, например для космического корабля это могут быть параметры: скорости движение корабля, его урона, кол-во хп или даже способности которые будут приобретаться только у данного вида детали. Далее вы кидаете на главный родительский объект, который держит в себе все детали, скрипт, который будет собирать параметры с каждой детали, и, например, суммировать их и таким образом будет получатся общая характеристика кораблика.
2) Идею из пункта 1 можно использовать геймплейно еще глубже, например, в какой-нибудь RPG игре, где вы сможете оценивать противника издалека не по надписи «моб 80 уровня» а по его одежке, потому что до этого вы уже видели, схожие элементы доспехов на предыдущем мобе, который имел иммунитет к огню и молнии. То есть, не используя никаких текстовых подсказок игрок будет опытным путем выяснять влияние определенных вещей на характеристики.
Так, о чем это я? В создании игры не главное гнаться за суперсложным кодом, реализующим миллион возможностей, в создании игры главное выудить новую и интересную идею при минимально возможной затрате сил. Во-первых, это прокачает вашу находчивость и смекалку, а во-вторых вы сэкономите силы для реализации дальнейших новых идей. И тогда вы может сможете изменить современный рынок однообразных поделок… Может быть приобрести славу, деньги или просто самоудовлетворенность. Вы ведь для этого начали делать игры?
Здравствуйте, дорогие читатели!
Мысли о создании серии простых уроков «концептуальные идеи для новичков игродева» появились у меня спонтанно, где-то в 2:00 по Московскому времени во время создания своего нынешнего проекта. Ну нет, это так мне кажется, что спонтанно, но, наверное, это мое подсознание так среагировало. Среагировало потому, что все больше юных (коим я и сам являюсь) и очень юных программистов решают заняться созданием игр. Как мне кажется, общая тенденция молодежи-программистов (и людей, интересующихся сферой программирования) плавно перешла от создания сайтов и модных блогов к созданию развлекательных продуктов. Я начинаю замечать это и среди своих знакомых, которые одно время говорили, что, мол игры — это не серьезное программирование, но теперь уже проявляют настоящий интерес к этой среде.
Я объясняю это для себя следующим, очевидным образом. Любые информационные направления приобретает массовые тенденции к изучению при выполнении двух условий: наличие простого и адекватного инструмента осуществления конкретных задач в выбранной информационной сфере и легкость получения прибыли при продаже ваших выполненных задач. В пример же опять можно привести сферу веб-технологий (когда-то сайты было создавать ультра-хардкорно, а сейчас, наверное, даже моя мама сможет поставить блог на WordPress или его аналогах. Опять же почему? Потому что WordPress открыл возможность создавать свои блоги всем мамам вокруг света, и потому что веб-сайты открыли доступ к быстрой популярности, славе, деньгам и рому).
Но пришла эра развлечений – я не буду упоминать с каким трудом делались первые игры, но прошли десятилетия, стали появляться платные игровые движки, через какое-то время они стали практически бесплатные (Unity, Unreal Engine4), причем не движки от Васи с соседнего подъезда в которых можно только сделать “грабеж корованов ”, а движки мастодонты который представляют из себя комплексные среды разработки, способные реализовать ваши проекты мечты. Однако есть и обратная сторона этих популярных технологий. А именно большое количество некачественных продуктов. Обленились придумывать что-то свое… “Лучше сделаю флеппи берд!” – подумал Вася.
И я решил, что надо сделать серию уроков состоящих из простых идей, которые могут использовать люди в своих самых первых проектах, люди, которые, может быть, не так давно начали изучать программирование вообще.
Случайная генерация 2D моделей (Unity)
Когда вы делаете игру в одиночку, не всегда бывает возможно нарисовать большое количество спрайтов для ваших персонажей, кораблей или зданий, вообще объектов.
Тут и приходит на помощь процедурная(случайная) генерация. Что значит этот термин в двух (шести) словах? «Модельку создает компьютер, а не вы».
На просторах интернета вы можете найти миллионы алгоритмов процедурной генерации в сфере геймдева (может быть, один из них даже описан моей мамой в собственном блоге). Одни из них будут просто сложные (как например генерация водной поверхности с использованием Nvidia Physics), другие из них будут экстремально сложные, как например сегментация рельефа с использованием нечеткой логики и нечетких множеств (Fuzzy Sets).
И что? Не думаю, что человек, который второй раз открывает юнити начнет думать, как ему понять, как реализовать и в какое место игры применить найденный алгоритм.
Проще реализовать свой! Пусть он будет простой, зато понятный вам. А это самый важный шаг во всем программировании.
Предлагаю вам свой вариант процедурной генерации модельки (применим к любой 2D игре). Предупреждаю, код экстремально простой! Две строчки! Но сначала, то, что вы должны подготовить перед осуществлением кода:
1. Понять какую модель (или объект) вы хотите создавать процедурно – это может быть ваш рыцарь, здание, космический корабль и тд.
2. Разбить на столько элементарных частей сколько вы хотите (например, для рыцаря это могут быть шлем, меч, щит, нагрудник).
Примечание: чем меньше отдельные элементы (например, меч вы разобьете на рукоять и лезвие), тем очевидно, что ваша сгенерированная модель будет выглядеть более натурально и уникально.
3. Нарисовать на каждый элемент столько различных спрайтов сколько считаете нужным.
4. Соберите свою модель в редакторе Unity, так, как она должна выглядеть. Я буду использовать в виде примера модельку корабля из своего нынешнего проекта.
Вот мои детали-спрайты разбросаны на сцене, из них я соберу модель геометрически нужную мне.
И настает время кода!
using UnityEngine;
using System.Collections;
public class ChangeTextureF : MonoBehaviour {
// в массиве Sprites будут находиться спрайты для каждой отдельной детали
public Sprite[] Sprites;
void Start()
{
// вызываем функцию сразу после создания объекта
ChangeTextureFunc();
}
public void ChangeTextureFunc()
{
// Подбрасываем псевдокубик в диапазоне от 0 до
// длины нашего массива, причем Random.Range
// не включает последний элемент
int ChooseForTexture = Random.Range (0, Sprites.Length);
// обращение к компоненту SpriteRenderer, и передача ему
// спрайта из массива наших заготовленных спрайтов по индексу,
// определенному рандомно строкой выше.
GetComponent<SpriteRenderer> ().sprite = Sprites[ChooseForTexture];
}
}
Функция ChangeTextureFunc() содержит всего две строчки кода, как и обещал.
Навесьте скрипт на каждый элемент вашего объекта как показано на скрине. Закиньте спрайты каждого элемента в массив прямо в эдиторе, и радуйтесь результату.
Эффектный результат:
P.S Старайтесь спрайты для вашей модели делать одного размера чтобы не было смещений в модели, однако если вы все же хотите сделать какой-нибудь особо изысканный спрайт, который кардинально отличен по размерам от основного множества, то просто передвиньте в sprite editor'e точку вращения (Pivot point), которая будет определять центр спрайта, на столько сколько вам нужно. Иногда в Unity забывают про эту возможность.
Вывод:
Конечно я вас немного обманул сказав, что вы получите процедурную генерацию моделей, скорее это можно назвать быстрым комбинированием модели из заданных спрайтов. Но тут же хочу сказать в защиту этого подхода:
1) Ну кода нет, ты рисуешь три кораблика делишь каждый на три одинаковых элемента и на выходе получаешь 27 моделек кораблей. Ура.
2) Вы скажете, что вы крутой мозг и сможете написать алгоритм, который будет сам и контуры кораблей выбирать и расцветку подставлять свою и у вас будет 1000000 комбинаций, ну а я вам отвечу, что каждая ваша модель будет крякозяброй потому что не забывайте, что разработка игр в том числе и искусство. И 10000 ваших безвкусных кракозябр никому не запомнятся.
3) Для новичков это будет впечатляющим результатом, который может подтолкнуть их к развитию этой идеи вширь и вглубь.
Идеи:
Вот кстати примеры, которые я придумал прямо во время написания этой статьи, как это можно интересно использовать:
1) Навесьте на каждый элемент скрипт содержащий параметры, которые вписываются в сеттинг вашей игры, например для космического корабля это могут быть параметры: скорости движение корабля, его урона, кол-во хп или даже способности которые будут приобретаться только у данного вида детали. Далее вы кидаете на главный родительский объект, который держит в себе все детали, скрипт, который будет собирать параметры с каждой детали, и, например, суммировать их и таким образом будет получатся общая характеристика кораблика.
2) Идею из пункта 1 можно использовать геймплейно еще глубже, например, в какой-нибудь RPG игре, где вы сможете оценивать противника издалека не по надписи «моб 80 уровня» а по его одежке, потому что до этого вы уже видели, схожие элементы доспехов на предыдущем мобе, который имел иммунитет к огню и молнии. То есть, не используя никаких текстовых подсказок игрок будет опытным путем выяснять влияние определенных вещей на характеристики.
Так, о чем это я? В создании игры не главное гнаться за суперсложным кодом, реализующим миллион возможностей, в создании игры главное выудить новую и интересную идею при минимально возможной затрате сил. Во-первых, это прокачает вашу находчивость и смекалку, а во-вторых вы сэкономите силы для реализации дальнейших новых идей. И тогда вы может сможете изменить современный рынок однообразных поделок… Может быть приобрести славу, деньги или просто самоудовлетворенность. Вы ведь для этого начали делать игры?
seokirill
За пришедшие во время поста идеи плюсик. Ато было уж за обман огорчился)