Не пишите просто движок, он скорее всего никому нужен не будет. Потому что, если вы не писали , то не знаете тонкостей использования движка в игре, и ваш движок будет неподходящим ни для какой игры.
Делайте игру, а не движок для неё, тем более не пишите движок для игры таким, чтобы его можно было исользовать в других играх. Пишите только игру и необходимые ей минимальные базовые системы. Если в игре вы обрабатываете только 2 кнопки, то не пишите модуль ввода на DirectInput, обрабатывающий все кнопки и мышь. Используйте минимальные и простейшие средства необходимые для решения задачи. Если нашли простой чужой компонент то используйте. Потому что сложность даже маленькой игры очень большая, и вам нельзя отвлекаться на лишнее.
Применяйте планирование. Оно нужно даже для маленькой игры, которую делает один человек. Оно состоит из этапов, и чем на более раннем этапе будет ошибка, тем дороже она будет, так как проходит по следующим этапам и обрастает работой. Если не хотите работать в 2 или 20 раз больше, то очень уважительно относитесь к планированию. Например, если вы запланируете делать плохую игру или вообще не игру а движок, то вы год проработаете над этим проектом и бросите, так как поймёте что это никому не нужно, то есть год уйдёт в пустую из-за ошибки планирования цели. Если вы вообще не планируете, то это не означает, что вы избавляетесь от ошибок планирования, а наоборот, у вас они будут на самых ранних этапах, в следствие чего вы проработаете значительную часть времени зря, и повышается риск провала проекта.
Под планированием понимается:
1. Цель. Выберите какую стоит делать игру, чтобы она была полулярной, изучите рынок. Даже если вы не предполагаете продавать игру, всё равно выполните этот пункт, вам тогда будет приятнее делать игру которая имеет спрос.
2. Требования. Это может быть простота. Не пытайтесь сделать игру с абсолютной свободой действий и абсолютно реалистичной графикой. Или, например, требования к производительности, количеству персонажей, особенностям сюжета. Полезно, чтобы требования вам выставили другие. Таким образом вы будете делать игру для других, что увеличит вашу мотивацию. Их требования могут быть лучше чем ваши, что обеспечит лучшую игру. Отсеивайте невыполнимые требования.
3. Архитектура. Это логика. Применяя нисходящий подход, сделайте иерархию функций. На каком-то этапе вы не сможете делать далее нисходящую архитектуру, не из-за того, что уже всё сделали, а из-за того, что тонкости реализации задают вам свои правила, тогда вам надо продолжить создание архитектуры восходящим способом, то есть исходя из особенностей API подкорректировать интерфейс более высокого уровня.
4. Проектирование. Более высшие функции состоят из вызовов более нижних, то есть они почти реализованы на этапе создания архитектуры. Спроектируйте реализацию самых нижних функций на псевдокоде. Псевдокод не должен быть кодом на С только на русском языке. Он должен быть короче минимум в 2 раза и описательно реализовывать алгоритм, отвечать не на вопрос как, а что, должен позволить сосредоточиться на самых сложных вещах. Из хорошего псевдокода получаются хорошие комментарии, не дублирующие код, а поясняющие его. Создайте тесты для нижних функций. Попытайтесь доказать правильность программы.
5. Конструирование. Только сейчас пришёл этап кодирования. Вы должны реализовать нижние функции и тесты и получить работающую программу. Используйте псевдокод для комментариев. Придерживайтесь определённого стиля форматирования.
На тестировании и отладке останавливаться не будем.
Хорошо производить планирование публично, так как другие помогут вам выявить ошибки, которые вы сами бы не выявили и уменьшить ваше время работы и улучшить результат.
1. Планирование.
2. Немного трёхмерной математики в случае использования трёхмерной грфики. Досконально вам знать её не надо благодаря инкапсуляции. Она описана во многих книгах и справках о
Я определил, какие у движка должны быть библиотеки. Но то была больше теория. Сегодня я создал проект и применил теорию на практике. Вот что у меня получилось:
Вот так вот я организовал структуру своего движка. Давайте я рассмотрю подробней. Начну с папок. Всего создано шесть папок. Первая - _Doc, будет содержать ссылки на используемую документацию по движку (история, лист задач и т.д.). Фишка: обратили внимание на подчеркивание? Так вот, это сделано специально чтобы папка была в самом вверху и не смешивалась с папками движка (папки сортируются по имени).
Application - это уровень приложения. Как вы видите в ней всего один проект с тем же именем. Данный проект - это динамическая библиотека (подробнее о видах библиотек можете прочитать http://ru.wikipedia.org/wiki/Библиотека_(программирование)). Пользователь в идеале должен будет работать только с этой библиотекой.
Папка Core - это основа из схемы. Она содержит 4 проекта. Каждый проект - это статическая библиотека.
Папка Engine - это ядро из схемы. Все проекты из папки, также являются статическими библиотеками.
Папка Framework пуста, потому что пока нет смысла в ней что-то делать.
И папка Test будет хранить приложения для тестирования частей движка.
То есть в итоге у нас одна динамическая библиотека, одинадцать статических которые будут линковаться к динамической. И проект.
Я не стану пояснять как я создал такой проект, так как это долго. Да и не расчитанно на новичков.
На этом подготовка завершена. Продолжим.
Любое приложение должно с чего-то начинаться. Это называется точкой старта (или входа) приложения. Обычно это или main() или WinMain(), а также все их производные... Но в движке нет точки старта, потому что движок не запускается сам по себе. Точку старта задает пользователь при создании приложения. Но я начну именно с нее проектировать и писать код. Наша точка старта будет в приложении test.
Пользователь должен при старте, создать наследника от класса Application, полиморфировать нужные методы, инициализировать наследник, запустить его на выполнение и затем очистить ресурсы.
То есть получается так:
Поясню. Start - это условный момент запуска приложения. End - это условный момент завершения приложения. WinMain и MyApplication - это уровень приложения. Данные сущности пишутся пользователем. iApplication - это интерфейс из библиотеки Application. Как вы видите, я выделил их цветом согласно схемы из предыдущей статьи. Я так буду поступать и дальше чтобы вам было легче ориентироваться.
Начнем писать код. Для начала создадим класс приложения. Находим Application и пишем:
Application.h
200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once
#include "export.h"
Class ENGINE_DLL Application
{
public:
Application();
virtual ~Application();
// Инициализация приложения.
bool Create();
// выполнение одного кадра
bool RunOneFrame();
// Выполнение приложения.
void Run();
// Завершение приложения.
void Shutdown();
Bool IsInit(){return _isinit;}
bool IsExit() {return _exit;}
Protected:
virtual bool _init() = 0;
// пользовательский кадр
virtual bool _frame() = 0;
// пользовательская очистка
virtual void _close() = 0;
Private:
bool _isinit;
bool _exit;
};
Application.cpp
200?"200px":""+(this.scrollHeight+5)+"px");">
#include "Application.h"
Application::Application() :
_isinit(false),
_exit(false)
{
}
Application::~Application()
{
// чистим за нерадивым программистом
if (_isinit==true)
Shutdown();
}
Bool Application::Create()
{
/*
Инициализация всех систем движка
*/
// пользовательская инициализация
if (_init() == false)
return false;
// сообщаем что приложение инициализировано
_isinit=true;
// сбрасываем флаг сообщающий о выходе
_exit = false;
return true;
}
Bool Application::RunOneFrame()
{
// следим чтобы не было попытки рисовать при неудачно инициализации
if (_isinit == false)
return false;
Return _frame();
}
Void Application::Run()
{
// Инициализируем
if(_isinit == false)
Create();
// выполняем бесконечный цикл
while (_exit==false && _isinit==true)
{
_exit = !(RunOneFrame());
}
// очищаем ресурсы
Shutdown();
}
Void Application::Shutdown()
{
_isinit = false;
}
Если вам нужен файл export.h, то он такой:
200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once
#ifdef WIN32
#ifdef _BUILD_ENGINE
#define ENGINE_DLL __declspec(dllexport)
#else
#define ENGINE_DLL __declspec(dllimport)
#endif
#else
#define ENGINE_DLL
#endif
При этом, где-то в Application должен быть объявлен _BUILD_ENGINE. В проекте на который я дал ссылку выше, все это уже есть.
Теперь вернемся к приложению:
main.cpp
200?"200px":""+(this.scrollHeight+5)+"px");">
#include
#include "../Application/Application.h"
Class MyApp: public Application
{
private:
protected:
// пишем пользовательские классы
virtual bool _init() { return true; }
virtual bool _frame() { return true; }
virtual void _close() {}
};
Int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pScmdline, int iCmdshow)
{
MyApp app;
Return 0;
}
Собственно вы уже можете собрать (но не забудьте прилинковать Application). Но запускать не советую - уйдет в бесконечность:) Мы ведь еще условий выхода не написали.
Так, теперь двигаемся дальше. Вспомним для чего нам был нужен Application - для обертывания остальных сущностей. Среди которых главной была Engine. Значит теперь ее нужно создать. Далее, по текущей задаче мы должны создать окно и инициализировать рендер. Значит в модуле рендера появляются два класса - Window и Render. Но так как мы решили что сущность рендера абстрактна, то тогда нужен еще один класс RenderDX11 и WindowWin32, которые будут выполнять реализацию использования в рендере DirectX 11 в окне операционной системы Windows.
Схема усложняется:).
Начнем выполнение с конца. Находим библиотеку рендера и пишем код:
Window.h
200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once
#include
Class Window
{
public:
Window();
virtual ~Window();
/// Создать окно
virtual bool createWindow(const std::wstring &caption, unsigned int width, unsigned int height)=0;
/// Закрыть окно.
virtual void closeWindow()=0;
/** Показать/Скрыть окно.
@param
value определяет, показывать ли окно (при true) или не показывать.
*/
virtual void showWindow(bool value)=0;
/// Вернуть заголовок окна
virtual const std::wstring& getWindowName() const {return _caption;}
/// Изменить заголовок окна.
virtual void setWindowCaption(const std::wstring& _caption)=0;
Protected:
std::wstring _caption; ///< заголовок окна
unsigned int _width; ///< ширина клиентской части окна
unsigned int _height; ///< высота клиентской части окна
};
Window.cpp
200?"200px":""+(this.scrollHeight+5)+"px");">
#include "Window.h"
Window::Window()
{
_width = 800;
_height= 600;
_caption = L"Engine";
}
Window::~Window()
{
}
Теперь нам нужен класс Render. Но тут я хочу сказать вот что - наш рендер должен быть единственным. Реализуем мы это через паттерн синглтон (погуглите, кому интересны подробности, прям по запросу "паттерн синглтон"). Так что сначала надо написать сам паттерн. Переходим к библиотеке Common. и пишем:
macros.h
200?"200px":""+(this.scrollHeight+5)+"px");">#pragma once
#include
#define Assert(a, b) assert(a && b)
Singleton.h
200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once
#include "macros.h"
/** Singleton pattern implemented using templates.
@remarks
Using singleton is useful for objects such as engine
or managers which should have no more than a single
instance in the whole application.
@remarks
If you want to make object of some class singleton you
have to derive this class from Singleton class.
@remarks
If something goes wrong during singleton object creation,
deletion or on attempt to access it, assertion arises.
By "something going wrong" I also mean attempts to create
more than single object of class marked singleton.
*/
template
class Singleton
{
public:
/** Creates singleton of type T.
*/
Singleton()
{
Assert(!s_pSingleton, "Singleton class already instantiated.");
#if defined(_MSC_VER) && _MSC_VER < 1200
int offset=(int)(T*)1-(int)(Singleton
s_pSingleton=(T*)((int)this+offset);
#else
s_pSingleton=static_cast
#endif
}
Virtual ~Singleton()
{
s_pSingleton=0;
}
/** Returns reference to a singleton.
*/
static T& getSingleton()
{
Assert(s_pSingleton, "Singleton class not instantiated.");
return(*s_pSingleton);
}
/** Returns pointer to a singleton.
*/
static T* getSingletonPtr()
{
return s_pSingleton;
}
/// A static pointer to an object of T type.
/// This is the core member of the singleton.
/// As it is declared as static no more than
/// one object of this type can exist at the time.
static T* s_pSingleton;
};
Template
Паттерн не мой, поэтому сохранен язык оригинала:-D
Вообщем, я к сожалением на сегодня на этом завершаю:-(Хотел бы написать дальше, но 12 часов - пора спать. Ждите до завтра, будет продолжение. Мы наконец-то создадим окно и инициализируем движок.
Приветствую. Хотите узнать как создать игру самому и какие бывают этапы создания игры? В наше время чтобы создать простую игру на PC или телефон не обязательно нужно быть в этом большим специалистом, существуют специальные программы, которые позволяют создавать игры с нуля в одиночку.
В этой статье весь мой личный опыт
Конечно, качество такой игры, если у вас нет опыта и знаний, может быть очень низким, но все с чего-то начинали. В этой статье вы узнаете что вам нужно чтобы создать игру и какие есть основные этапы создания игры.
Куда больше материалов вы можете найти на специальной странице в этом блоге:
Я выделил 7 основных этапов создания игры.
Как создать игру самому?
Для создания игры вам нужно знать язык программирования, а сейчас все они на английском, да и они сложные, там есть свой, так называемый синтаксис, который тоже нужно знать. Так вы себе представляете создание игры, верно?
Не совсем.
Конечно, почти все высоко бюджетные игры делаются с помощью одного из ключевых языков, однако для новичка даже этого знать не обязательно.
Существуют специальные программы для создания игр, одной из которых является Game Maker. Они были созданы специально для создания игр (программа так и называется - создатель игр). Лично я работаю в Game Maker и он позволяет делать вполне качественные игры под любые платформы, от андроида, до ios.
Так-же можно посоветовать Unity или Construct 2 , в качестве хороших альтернатив.
Лично моё мнение, Game Maker - одна из самых удобных программ для создания игр именно для новичков, тогда как освоение Unity с нуля может занять куда больше времени.
Если вы выбираете Game Maker - то мой блог и канал вам существенно помогут в его освоении, ну а если вам выбор остановится на Unity или чем-то еще, тотам тоже существует огромное количество бесплатных обучающих материалов высокого качества на Русском.
В любом случае, первый (нулевой:) этап - это выбор программы для создания игр.
Первый этап - дизайн документ
Далее вам нужно создать дизайн документ для новой игры. Другими словами - вам нужна идея игры. О чём будет игра? Что там будет происходить? Какой это будет жанр? Сколько времени и денег займёт разработка? Таких вопросов очень много и перед началом создания игры очень полезно составить какой-то примерный план.
Базовые вещи о том, как написать дизайн документ для игры, вы можете найти тут:
Ну не прям вот ужас, да? Плохо конечно, но не прям вот?
Ну вот, это я рисовал компьютерной мышкой в очень простом графическом редакторе, а учился рисовать я 1-2 месяца, рисуя по 1 картинке в неделю, максимум.
Я думаю за год можно выйти на очень неплохой уровень, если выделять по 1-3 часа в день на рисование и на изучение теоретической базы.
У меня есть видео (16 минут)
:
Там я рассказываю свои мысли о том как учиться рисовать и зачем это нужно.
Четвертый этап - звук
Звук и саундтрек в играх - очень важная часть, которая, однако, очень часто игнорируется начинающими разработчиками. Подумайте, у игрока, как и у любого человека, есть всего несколько основных органов чувств, а чем больше органов чувств в игре задействовано, тем лучше погружение игрока в процесс.
Сколько органов чувств задействовано у игрока?
Обоняние? Нет. Осязание? Иногда, что связанно с некоторыми системами управления в играх. Зрение? Вот на зрении всё и строиться, это основа.
Поэтому такая высокая важность графики и визуальных элементов. И по сути дела кроме зрения в играх можно задействовать еще только одно чувство - слух.
Если вы раньше играли в компьютерные игры, то у вас наверняка есть любимые, а так-же есть какой-то любимый OST (Музыка из игр). И игра вам могла запомниться именно за счёт музыки. Про мой любимый OST я писал вот тут:
Звуки - это еще один удар по органам чувств, звук сопровождающий действие может как-бы усиливать эффект от этого действия. Просто выстрел и вылет пули - скучно. Верный звук перезарядки, выстрела, столкновения пули с поверхностью (разные для разной поверхности), падение гильзы на пол и прочее существенно усиливают погружение игрока в процесс.
Вы же знаете про всякие специальные звуки и фразы в таких играх как Unreal Tournament и насколько сильно они увеличивают фан от игры.
Другими словами - верные звуки и музыка делают игру атмосферной, эмоциональной, человечной и куда более интересной.
У меня был небольшой опыт когда я делал игру Lonely Dude.
Тогда для этой игры мой знакомый написал уникальный OST, а остальные звуки я просто взял из бесплатных источников.
Что я хочу сказать? Для простой игры совершенно необязательно сильно заморачиваться со звуком, достаточно просто поместить в игру звуки для основных действий (выстрел, взятие бонуса, завершение уровня, прыжок и т.п.) и это уже существенно усилит общее впечатление от игры. Музыку написать конечно существенно сложнее, но иногда можно купить трек за каких-то $1-5, ну или посидеть с такими программами как FL Studio, дабы написать пару простых треков для своей игры.
Чем больше вы тестируйте (вы сами и ваши друзья, если вы инди разработчик), тем лучше игра получиться в момент релиза. Всего один баг где-то вначале игрового процесса способен испортить всё впечатление от игры, заставив игроков писать негативные отзывы.
Поэтому игру нужно допиливать напильником как можно более тщательно и делать это нужно до релиза. Как нужно тестировать игру?
Просто играйте в ней как можно больше и пробуйте разные варианты. Думайте как думал-бы игрок, а не как думает разработчик, который всё знает. Сажайте за игру вашу девушку и пусть играет она, записывайте какие у неё проблемы возникают и как она их решает, если вообще решает. Где затыки, где дисбаланс и где баги. Всё нужно поправить.
Седьмой этап - продажа игры и распространение
В любом случае, рано или поздно, вы свою игру доделайте, если вам хватит сил и упорства. Ну а дальше вы её продаёте, либо распространяете бесплатно, в любом случае вам-же хочется чтобы люди в ней поиграли?
Как это можно делать я уже писал в своей старой статье:
Общие принципы сохраняются практически для любой игры.
Паблики ВК, свой ютуб канал, трейлер, базовое понимание продвижения и поисковой оптимизации и всё такое прочее.
Всё это (как и каждый этап тут) - совершенно отдельная и большая тема, но задача данной статьи это ознакомление с процессом создания игр, не более того.
На этом всё. Надеюсь я ответил на ваш вопрос - как создать игру самому и осветил основные этапы создания игры. Делать игры - это очень увлекательная работа (или хобби), а так-же реальная возможность заработать.
Удачи вам в этом нелёгкое деле!
Как разработать RPG-игру за неделю с нуля и без бюджета. Часть I.RPG за неделю? С нуля? Это вообще возможно?
Я рискнул, и я сделал это.
В интернете полно информационных ресурсов, доступных мелким, независимым (indi) разработчикам игр. На одном таком общественном форуме, в процессе спора, я имел неосторожность ляпнуть, что, если мне дадут неделю времени, компьютер со свежеустановленной Windows, и хорошее соединение с Интернет, я смогу создать достойную игру, не потратив на это ни цента. Нет, она конечно же не сможет конкурировать с Halo 2 или чем-то такого же уровня(если бы я мог создать такую игру за неделю, я бы давно бросил работу), но она будет достаточно интересной и играбельной.
Tom Bampton, автор ежемесячных обзоров игр в номинации «Игра на день» (www.gameinaday.com), сказал: "Дерзай!" Затем он добавил дополнительное условие - я должен сделать это, не используя существующие игровые движки. Мне можно использовать только основные библиотеки / API.
Сначала я отказался от этой идеи. У меня не было лишнего времени, чтобы на неделю отстранится от разработки текущего игрового проекта на работе. Но потом я подумал: да черт с ним, ведь что такое неделя? В типичной компании, например в Е.А., рабочая неделя составляет 40 часов. Так почему бы не сделать игру не за календарную неделю, а за 40 чистых часов? Это уже реальнее, - но я не хотел создавать очередной тетрис или арканоид. А как насчет ролевой игры - одного из самых сложных игровых жанров? Это возможно?
Я знал, что это будет чрезвычайно трудно. Но я принял вызов.
Кроме того, я подробно записывал, что и как я делаю, описывал ход разработки. Я думал, что это может быть интересно для разработчиков игр - или по крайней мере получатся развлекательные записи о том, как я упал лицом в грязь, если у меня вдруг не получится. Все, что у меня получилось - длинная, бессвязная запись моей почасовой деятельности. Я попытался изменить ее таким образом, чтобы чтение не вызывало скуки. Как вышло, судите сами.
Так вот, как я создал игру в течение одной недели с нуля, и без бюджета. Если вам лень читать, и вы хотите побыстрее заглянуть в конец повествования, чтобы узнать, как выглядит конечный продукт, посмотреть все его баги, вы можете скачать версию игры для Windows здесь: http://www.rampantgames.com/hackenslash.html
ПЛАНИРОВАНИЕ
Цель
Создать олдскульную RPG в стиле старых игр начала 80-х, с видом "сверху вниз", например как The Temple of Apshai, Ultima III, и Telengard. Игрок будет двигаться через комнаты в типичном подземелье, сражаясь с различными монстрами с помощью «меча и магии». Постепенно он будет совершенствовать свои возможности получая опыт, повышая уровень, приобретая магическое снаряжение.
Однако, игра будет состоять не только из самого ведение боевых действий. Игрок также будет иметь возможность прокрасться мимо монстров, или вступить с ними в переговоры. Будут запертые двери и сундуки, и уникальные особенности подземелья, имеющие неожиданные эффекты. В игре не будет длинных описаний или диалогов, - в основном это будет типичный hack & slash. Вы будете двигаться по пути, пока не станете достаточно сильным, чтобы встретится лицом к лицу с финальным боссом, выполнить квест, и благополучно вернуться домой (в вашу стартовую комнату).
Правила разработки
Правило № 1: Время разработки ограничено одной неделей (включающей 40 часов)
На разработку игры должно быть потрачено в сумме не более 40 часов. Они будут включать время, потраченное на непосредственную работу над игрой и на ее обдумывание. Перерывы в разработке больше, чем десять минут, не будут учитываться. Это будет "идеальная" рабочая неделя из 40 высокопроизводительных часов.
За 40 часов будет сделана полнофункциональная альфа-версия. Дальнейшее допиливание, такое как окончательная отладка игры, создание инсталятора для распространения в общее время учитываться не будут, никакой новый функционал на этом этапе добавлен не будет. Документирование процесса разработки также не учитывается.
Правило № 2: Использовать только бесплатные инструменты
За исключением программного обеспечения, которое поставляется с установкой Windows, используется только свободный софт, по возможности с открытым исходным кодом. Смысл этого - показать, что не нужны дорогие (или пусть даже дешевые) инструменты для разработки игры. На оборудование, такое как сканер, микрофон и цифровая фотокамера, данное правило не действует - если у вас их нет, будем считать, что их можно у кого-то одолжить.
Правило № 3: Нет движкам, только стандартные библиотеки / API
Игра должна быть создана "с нуля" без использования существующих игровых движков. Никакого обмана, и создания игры или каких-то ее частей с помощью конструкторов игр или использования подобного программного обеспечения.
Инструменты
Код:
Python 2,3 (http://www.python.org/)
PythonWin
PyGame (http://www.pygame.org/)
Py2exe – чтобы собрать что получится в исполняемый файл для распространения. (http://starship.python.net/crew/theller/py2exe/)
Gimp 2,0 (http://gimp-win.sourceforge.net/)
MS Paint (тот что идет с Windows) - для вставки скриншотов, захваченных клавишей PrintScreen (GIMP почему-то отказался это делать)
Бесплатные текстуры были взяты (http://www.textureartist.net/textures/index.htm) и (http://www.mayang.com/textures/)
Audacity (http://audacity.sourceforge.net/) плюс мой микрофон или бесплатные.
Расписание (План) работ
Расписания составляют, чтобы их потом нарушать, но все же они нужны, чтобы контролировать прогресс и строки, и вносить коррективы по мере необходимости.
Час 1-10: Базовая архитектура
Проектирование движка и основных компонентов. Получить отображения мира на экране. Я должен реализовать возможность перемещать тестового игрока по всему миру, и смотреть на вещи, а затем превратить то, что получится, в игровой редактор.
Час 11-20: Возможности игрока
Реализация всех основных возможностей для игрока - перемещение, атака, открытие дверей, смерть, подбор вещей и использование инвентаря. Создать каркас представления всех объектов в окружающей среде, для тестирования возможностей игрока во взаимодействии с миром.
Час 21-30: Оживление мира
Добавить искусственный интеллект, игровые события, ловушки, спецэффекты. К концу этого периода я должен иметь достаточно полное техно-демо, включающее все основные особенности игры.
Час 31-40: Добавление контента и правил
Получить из техно-демки полноценную игру. Добавить все дополнительное содержимое. Добиться завершенности и баланса игровой механики. Отшлифовать все, на что хватит времени, добавить спецэффекты, анимацию и т.д.
После 40 часов: Тестирование и релиз игры
Протестировать, и устранить найденные ошибки (не добавляя новые возможности!) Собрать все в кучу, и выложить в интернете. Завершить документацию.
Дневник разработчика Hackenslash: Игра за неделю
Час 1 – Дикое проектирование и базовые классы
Этот час был проведен за созданием некоторых базовых классов для игры - и использования их в дальнейшем проектировании. Мир будет представлен в виде последовательности комнат, соединенных порталом. Все в мире базируется на комнатах, подобно тому, как это было в старых адвенчурах или MUDах. Большинство объектов в игре представлены как " GameObject ", который имеет позицию и содержимое (в том числе может содержать и другие объекты - карта может содержать комнаты, в комнате может быть сундук, в сундуке - меч... и, я думаю, меч может содержать несколько комнат, но мы так делать не будем.)
Я создаю объекты creature (существо) и player (Игрок)
Я генерирую набор атрибутов для существ, и внедряю их в класс. Видимо я задрот, который играет слишком много в РПГ игры. Я пока еще не знаю точно, как будет выглядеть и работать игровая механика.
Я делаю объект room (комната), наследуемый от GameObject. У комнаты есть ширина, высота, и стены - и на текущий момент больше ничего.
Постепенно я начинаю понимать, как все будет работать, и вношу необходимые исправления. Я даже не пытаюсь использовать PyGame на данном этапе, и программа не показывает ничего, кроме консоли. Но я чувствую, что все что сделано - большой прогресс!
Час 2 - PyGame 101
Цель этого часа - инициализация PyGame, ну и начать хоть что-нибудь рисовать на экране. На самом деле, я провожу большую часть времени за чтением документации PyGame, пытаясь выяснить что там и как, поскольку у меня почти нет опыта использования PyGame или SDL.
Завершается этот час программой, отображающей пустой экран, заполненный черным цветом. Не впечатляет. На самом деле за этим окном есть много чего. Там реализован игровой цикл, переключение кадров, вызов нескольких классов, и много бездельничающих заглушек. Но это не делает черный экран более внушительным.
Час 3 - Если бы стены имели уши, я б их сильно отругал.
Цель этой часа – обозначить контуры комнаты стенами, и отобразить это на все еще черном экране. Чтобы сделать это, мне нужна комната, и мне нужна графика. Приходится много сидеть над GIMPом, правя загруженные из интернета текстуры, так чтобы они превратились в подходящие тайлы. Я создаю класс менеджера текстур. И я заполняю структуру образца комнаты. Я также потратил немного больше времени, просматривая документацию PyGame, чтобы найти что-нибудь еще, что можно использовать, дабы сделать работу легче.
Час прошел. А у меня все тот же черный экран. Стен как не было, так и нет.
Часа 4 – В гостинице появился свободный номер
После борьбы с некоторыми синтаксическими ошибками, я, наконец-то смог добиться появления стен на экране. Правда отображаются они неправильно, находятся не в указанном месте, да еще и со щелями между сегментами. Это ужасно. Но немного настройки и правки, и я получил на экране что-то похожее на комнату, размером 10 на 10 квадратов.
Не имея подробного плана проекта, действительно довольно легко запутаться, когда выполнив определенную работу Вы задаетесь вопросом "Что дальше?" Я решил, что если рисунок одной комнаты хорошо, то нарисовать две – вдвойне лучше.
Для хранения созданных комнат я создал файл "minidungeon".
Я начать добавлять логику порталов "portals" - отверстий в стенах, для перехода в другие комнаты (и предоставляющих всю информацию о смещении, необходимую для правильного отображения смежных комнат).
Час 5 - Hackenslash получает больше комнат
Я изменил название окна на "Hackenslash!". Просто потому, что это круто.
Я создал карту объектов для хранения комнат, и класс MapMaster содержащий несколько карт.
Я добавил вторую комнату и подключил к первой через портал.
Соседние комнаты подключены к текущей через порталы, и теперь отображаются на экране.
Я исправил некоторые ошибки отсечения, чтобы правильно отображались стены, частично выходящие за пределы окна.
Час 6 - за который мы улучшаем скил рисования
Добавил класс дверей, а также настроил карты для размещения двери (дверь должна быть общей для двух комнат). (Правка: Жаль, что я никогда это так и не использовал!)
Я создал еще 3 тайла стен, объединил их в одно изображение.
Графический вид стен изменяется в зависимости от типа.
Я делаю простую графику для вида сверху вниз.
Часы 7-8 – Вращения и восклицания!
Я разобрался, как в PyGame поворачивать растровые изображения.
Я добился плавного вращения тестового игрока. Много регулировок необходимо для корректировки угла вращения.
Я узнал, как использовать шрифты в PyGame, и я создаю несколько классов для отображения и анимации текста.
Добавил класс для автоматической обработки текста, поскольку данная функциональность будет часто использоваться в будущем.
Часы 9-11 – Елементы - бррр!
И вот опять, мне нужно решить вопрос "Что дальше?".
Комнатам нужно больше интересных элементов, поэтому нужно составить их список. Я не знаю, как их систематизировать, поэтому решил начать с общих. Я ввел три статических элемента, которые можно найти в типичной комнате в подземелье: ковер, колона(блок с той же функциональностью что и у стен), и лестница (позволяет переносится на новое место)
Я решил, что элементы могут занимать больше, чем один тайл, и могут быть повернуты на любой градус. (Правка: В ретроспективе, очень тупое решение - я провел слишком много времени на его реализацию, но оно оказалось почти бесполезным.)
В общем, я потратил около трех часов, работая над элементами, разрываясь между созданием графики и написанием кода.
Часы 12 - 13 - Нам нужен Лут!
Я создаю графику и код для вещей. Удивительно, как много времени может отнять рисование. Особенно раздражает, когда изображение имеет вид, будто курица лапой рисовала, сколько бы усилий к этому не прилагалось.
Я добавил много характеристик вещам, в том числе их стоимость, размер, ячейки обмундирования, и много другого. С ними пока нельзя взаимодействовать, но, по крайней мере они отображаются в правильных местах в комнате.
Час 14 - Ковры
Я сильно отстаю от графика, что же мне делать?
Черный фон кажется слишком уродливым, поэтому я замостил полы внутри комнаты коврами - отдельными тайлами.
После этого вдруг обнаружилось, что я забыл добавить в спрайты игрока и вещей прозрачный фон. Пришлось потратить много времени на исправление этой оплошности.
Зато уровень теперь выглядит круто. Ну, по крайней мере круче, чем черный.
Часы 15-16 - Click! Click!
Я занялся управлением мышью и обработкой событий.
Добавил управление персонажем мышью. Движение пока происходит рывками, нет плавной прокрутки уровня.
Игрок может выйти за пределы комнаты, отсутствует проверка столкновений.
Я исправил несколько ошибок.
Помучил GIMP и создал красивые лестницы.
.
На разработку уже затрачено почти 17 часов, так что я начинаю немного нервничать. Я прошел 2/5 пути создания игры, - закончился второй "рабочий день" разработки. То, что у меня уже сделано впечатляет, но я понимаю, что сделать осталось много больше. У меня есть еще четыре часа, чтобы закончить основные возможности игрока, и вложится в график. Это будет трудно... но я все равно не жалею, что потратил лишнее время на рисование графики!
Час 17 – Плавно перемещаемся, пока не стукнемся лбом о стену
Большинство времени потрачено на доводку графики и исправление ошибок.
Добавлено обнаружения столкновений и плавная прокрутка, при движении игрока.
Игрок теперь может делать несколько шагов (оборотов) в ответ на действие мыши.
Час 18 - Переступаем пороги
Игрок теперь может проходить через порталы в другие комнаты.
Это вызывает косметический баг с взаимным перекрытием стен и полов между смежными комнатами.
Поправлено много ошибок, связанных с вращением, при котором порталы ставали непроходимыми.
Час 19 - Лестница в небо, Адское меню
Мой брат вызвался сделать музыку для игры. Он сделал музыку для Void War, и получилось довольно хорошо. Это напомнило мне, что нужно сделать воспроизведение звука (и музыки). Вроде бы в PyGame это сделать довольно просто, поэтому оно не должно занять слишком много времени. (Правка:. Я так и не нашел для этого времени, к сожалению в Hackenslash вы не услышите ни единого звука.)
Моя следующая цель состоит в обработке взаимодействия с существами и предметами. Мне очень нравится, как это сделано в The Sims и Neverwinter Nights, когда вы хотите взаимодействовать с игровым объектом, появляется контекстное меню. Я планирую реализовать что-то похожее.
Учу лестницы перемещать игрока в новую комнату.
Я немного проштудировал Интернет и документацию PyGame, ища, нет ли где открытых исходных кодов подобного меню на PyGame. И не нашел ничего.
Я начал делать собственное меню.
Часы 20 - 21 - Что там с меню?
Я продолжаю работать над меню. Меню может быть легко подключено к объекту, точнее объект как бы порождает меню, что позволило легко реализовать обратную связь для обработки выбора игрока.
Я начал работать над меню вещей. Оно уже появляется в нужном месте, и позволяет выбирать какой-нибудь пункт, но при нажатии пока ничего не делает, работает только кнопка закрытия меню.
Час 22 – Заснуть в процессе
Я продолжаю работу над вещами, - пытаясь реализовать их функционал и научить их реагировать на команды меню, включая возможность добавления контекстной информации. Сейчас оно малофункционально, но все же работает, отображая информацию о выполняющейся команде
Я улучшил расчет движения при выполнения различных действий, получив большую подвижность.
Я замечаю, что уже поздно, и что вышел далеко за пределы отведенного на эту работу часа. Если бы я не обращал внимания на общее время разработки – просидел бы, наверное, до утра. Но поскольку я ограничен во времени, потраченный практически впустую час - действительно плохие новости. Интересно, как сдвигаются приоритеты, когда не хватает времени. В общем, я ложусь спать.
Час 23 - Боевые параметры!
Я изменяю (ну фактически только начал работу) некоторые из атрибутов класса, созданные в первый час.
В правом верхнем углу я создаю панель, на которой будут отображаться параметры игрока.
Я оптимизировал это окно, превратив его в изображение, которое рисуется быстрее, чем шрифты. Обновления этого изображения происходит только тогда, когда изменяются связанные с ним параметры персонажа.
Час 24 - Меню игрока
Я завершил оптимизации для окна параметров.
Создал всплывающее меню, которое появляется, когда игрок кликнет на персонажа.
Я создал быстрое меню для использования зелий, кастования заклинаний и т. д.
Я исправил некоторые ошибки в работе меню.
Час 25 – До(раз)пиливаю полы и стены
Сегодня утром у меня в мозгу появилась идея (неужто у меня такой большой мозг, что в него вмещается столько идей?) как устранить проблему перекрытия стен в смежных комнатах (см. описание восемнадцатого часа). Что, если я буду рисовать только половинки стен? Таким образом перекрытия не будет вообще, и не нужно добавлять сложную логику для определения и исправления перекрытий.
Я начинаю работу над реализацией этой идеи. К сожалению, на самом деле придуманное упрощение еще больше усложняет отрисовку комнаты (в частности полов), и реализовать его можно не так быстро, как я надеялся. На создание и отлаживание этой системы было потрачено около часа. Но оно того стоило.
Отлаживая код, я обнаружил еще несколько ошибок, связанных с переходом между комнатами.
ПЕРЕРЫВ - Кризис!
Я только что осознал, что прошло больше чем 3/5 отведенного на разработку времени, и что осталось меньше пятнадцати часов, чтобы закончить игру. Посмотрев расписание необходимых функций игры, и прикинув, что на реализацию каждой нужно в среднем час, я понял, что на реализацию всего мне нужно около двадцати пяти часов. На десять часов больше, чем есть. Проект официально под угрозой срыва.
Выйти за пределы лимита времени мне нельзя. Также нельзя привлечь помощника или купить код/ресурсы, поскольку предусмотрено, что игру за 40 часов сделаю я один. Нужно придумать, как работать еще более эффективно – но я и так уже вкалываю на максимуме производительности. Похоже, у меня нет другого выбора, придется пересмотреть функционал, и решить, какие возможности выбросить из игры.
Двери: Вырезано! Я очень хочу сделать двери в игре. Жалко расставаться с этой функцией - тем более, что я уже некоторое время работал на ней. Но остается еще слишком много работ, например искусственный интеллект. И, наверное, понадобится 2-3 часа, чтобы заставить их работать, а их у меня нет.
Инвентарь: упростить! Забудьте о дополнительном инвентаре, и возможности смены оружия по желанию. Все, что подобрано и не стало текущим оснащением, будет сразу пересчитано в деньги.
Ловушки: упростить! Я хотел бы иметь множество ловушек с интересными и разнообразными последствиями их активации. Не судьба. Ловушки будет иметь простой визуальный эффект, наносить урон и временно увеличивать вероятность нарваться на случайного монстра
Луки (стрелковое оружие): Вырезано! В игре будет только оружие ближнего боя, на расстоянии можно атаковать заклинаниями.
Сохранение / загрузка игры: упростить! Сохранить можно только персонажа, а не состояние мира. (ПРАВКА: Я и этого не сделал!)
Система частиц: Отложить! Создание системы частиц перемещено в самый низ списка приоритетов. Я сомневаюсь, что придется их делать. Хотелось бы сделать впечатляющие визуальные эффекты с помощью частиц для заклинаний... но, скорее всего, этого никогда не будет.
Заклинания: упростить! У меня была серьезная концепция о заклинаниях: их можно было бы найти в виде свитков, и количество более десятка. Это грустно, но будет всего несколько заклинаний: Лечение, Урон, Ослабление, Усиление, и Восстановление. При повышении уровня, можно позволить игроку усилить заклинания за счет увеличения числа магических очков.
Анимация монстров и игроков: Вырезано! Я никудышный художник, чтобы сделать это достаточно быстро.
Принимая решение, что я не буду делать (или то, что отложу на после), не менее важно решить, что нужно сделать в первую очередь.
Есть много вещей, которые запланированные в игре, и которые я считаю очень важным – поиск ловушек, секретных дверей (ну теперь секретных проходов), и взлом сундуков. Но все же основой игры является бой. Поэтому я решил сосредоточится именно на нем, сделать его главным приоритетом. Я поставил перед собой цель, через полтора чала мои монстры оживут настолько, что их можно будет убить.
Отлично, с приоритетами разобрались, продолжаем разработку.
Час 26 - Бросим кости
Я работаю над механикой «игральных костей», - механизма, с помощью которого в игру будет внесен элемент случайности. Поскольку у нас нет ограничения реальных костей, мы можем получать случайное число любого желаемого диапазона. Например от 1 до 33, или от 6 до 17. Так что я могу бросить кости, сравнить то, что выпало со своей атакой и защитой врага. Если выпавшее число выше защиты, атака удалась.
Например, предположим, что у меня общее значение атаки 15. Я атакую монстра, у которого 10 защиты. Мои шансы 15 из 25 (25 =15 +10), или 3 из 5. Так игра будет генерировать случайное число между 1 и 25, и если оно выше десяти, я выиграю.
Для вычисления нанесенного урона используется немного другой способ. Я добавил защищающемуся параметр «броня», а атакующему "урон". Я генерирую случайное число от 1 до их суммы, а затем вычитаю броню. Если результат меньше единицы, урон не наносится. В противном случае, он равен полученному результату. Таким образом, если монстр, с уроном равным 10 атакует игрока с 5 очками брони, игра будет генерировать число от 1 до 15, из которого вычтет 5, то, что получится, и есть нанесенный урон.
Это объяснение и описание заняло больше времени, чем его реализация.
По завершении часа, я уменьшил размер области отображения подземелье, теперь часть окна справа полностью отведена под пользовательский интерфейс, это изменение дало небольшое увеличение производительности. Я также убедился, что движение игрока не зависят от частоты кадров.
Пост о воплощении мечты и о создании игры с нуля. И о граблях разной величины.
0. Дано
Когда-то, во времена не столь от нас отдаленные, когда интернет в Уфе был ещё с помегабайтной оплатой, я занимался созданием и разработкой локальных «фришных» серверов Lineage и WoW. Но вот появились безлимитные тарифы, а локальные сервисы начали терять свою актуальность и я ушёл в вебразработку.
В некотором роде, как хобби я даже сохранил своё отношение в Геймдеву, правда, с другой стороны – разработка ботов и всего такого.
Шли года, а мысль написать что-нибудь свое, с преферансом и поэтессами не переставала меня терзать. В какой-то момент я понял, что либо сейчас, либо уже никогда.
1. Идея и Прототип
С чего начинается разработка? C прототипа. А прототип - с идеи. Для первого проекта стоит создать что-то небольшое и простое. Питая любовь к головоломкам и пошаговым стратегиям, я увлекся мыслью, что нужно сделать какую-нибудь пошаговую головоломку. Поразмыслив, вспомнил одну интересную игру времён Спектрума (стоит отметить, что автор не так стар, как может показаться) идея которой была прекрасна в своей простоте. Игрок ходит на 1 клетку, обходя препятствия, а враги его преследуют и ходят на 2 клетки, но препятствия не обходят.
Если взять ситуацию “A,” то мы можем спокойно ходить вверх и вниз, а монстр просто будет упираться в стену. В ситуации “B” монстр находится в загончике, а мы можем спокойно ходить справа, сверху и снизу от него. Поскольку игра у нас детерминированная, то существуют два типа монстров, которые отличаются по цветам и алгоритму поиска пути. Это для того чтобы не было неопределённости куда пойдёт монстр, когда он стоит наискосок. Красный всегда сначала сокращает расстояние до нуля по оси X ситуация “C”, в ней монстр зайдёт в загончик и упрётся в стенку. Фиолетовый же по оси Y ситуация “D”, в ней монстр пойдёт вниз, а потом уже направо и съедает главного героя.
Тут ещё мог бы быть большой абзац про выбор «движка» для написания игры. Но, пожалуй, можно обойтись и парой слов; перед тем как попробовать Unity3D, я поковырялся в нативном Obj-C, Corona SDK, UE, Cocos2d и ещё пару 2D Фреймворках, название которых, так глубоко в стеке памяти, что уже и не откопать.
В итоге, выбор пал на Unity3D, он мне показался оптимальным и я неспешно начал писать. Через месяц появилось вот такое приложение для iPad.
В нём мы играли за мужичка в красном и убегали от мужичков в синем, параллельно собирали сердца – читай звезды. В тот момент мы ещё использовали кубы как стены, но затем для экономии пространства на экране заменили их.
Хотелось бы отметить, что до этого момента, я никогда не писал на C#, но писал на JS, поэтому прототип был написан UnityScript (это такой диалект JS в рамках Unity3D). И это были первые большие грабли, послужившие нам уроком. Пришлось переписывать всё на C# и это заняло пару месяцев.
2. Команда
Как верно то, что я писал на десятке языков, так верно и то, что я не в состоянии нарисовать даже прямую линию. Поэтому после создания прототипа я начал искать художника\3Dшника, для этого я зашёл на сайт по фрилансу и посмотрел первых три сотни человек, с десятком - списался. Найти человека, за долю в довольно рискованном проекте, задача не из легких. Но она разрешилась, и в проекте появился талантливый художник Рамиль; итак – нас стало двое.
Параллельно я искал инвестора. Дело не в отсутствии денег, чтобы купить плагины или устройства для теста, а в том, чтобы создать обязательства, которые помогут не забить (не сложить с себя полномочия) при определенных обстоятельствах. И такой инвестор нашелся, в виде друга, решившего вложить свои кровные, в эту сомнительную, как ему казалось, затею. Итак, нас стало трое. Отмечу, что к моменту запуска, бюджет игры составил всего около 100.000р., при этом, в эту сумму входит покупка нескольких Android устройств для тестирования, плагинов и озвучки.
3. Расширение базовой концепции игры
С самого начала предполагалось, что невзирая на то, что игра будет максимально простой, необходимо будет привнести несколько новых идей в базовую концепцию. Так у нас появились односторонние телепорты (позже станет ботинком), ловушки и одноразовые грибы съедающие тех кто к ним подойдёт.
Концепт Арт
Основной фишкой игры мы планировали сделать то, что персонаж может вернуться во времени, на несколько ходов назад. Т.е. не отмену хода, а возможность переместиться 1 раз за уровень на клетку, где персонаж был 3 хода назад. Это давало огромное количество вариантов хода, но на первых же тестах выяснилось, что обычные игроки не в состоянии пройти такие уровни. Слишком сложно. Может стоить таки сделать Brainiac Edition?
Также мы много экспериментировали с размером уровней, в итоге остановились на том что весь уровень должен вмещаться на экран, даже на устройствах с небольшим экраном. Так у нас получились уровни 5х8 клеток. Но при этом у нас есть pinch zoom, для большепальцых или уровней 6х10. Кроме сокращения размера уровней, отключения возврата во времени, для упрощения была ещё добавлена отмена хода, до 5 раз за попытку.
4. 2D vs 3D
В какой-то момент наши тестовые билды выглядели так:
Ужас ужас
Приходило осознание того, что мы не в состоянии сделать картинку, которую мы хотели бы видеть в 3D с нормальным fps. Тестовая сцена для сравнения производительность 2D и 3D показывала не утешительные результаты.
Скриншоты из сцены
В итоге на iphone4, слева(3D) было всего 20 кадров в секунду, а справа(2D), стабильные 60. При этом, справа, качество картинки, как вы видите, на порядок лучше. Сейчас конечно если ориентироваться на минимальную производительность уровня iphone5+ и делать специально несколько квадратную графику, кошерные шейдеры + lightmapping + lightp robes, можно и для 3D сделать отличную графику
В итоге было принято решение всё переделывать на 2D. Но тут мы совершили ошибку, которую уже потом было не исправить. 2D анимация может быть 2 типов, первый это последовательность кадров, второй это наложение и смещение спрайтов.
Наглядное сравнение
Поскольку у нас были 3D модели, мы выбрали первый вариант. В итоге это выльется в большой вес приложения, даже с учётом огромного кол-ва оптимизаций мы не сможем уложиться в 50 мегабайт.
5. Форс-мажоры - это возможность
Не знаю можно ли назвать рождение ребёнка и переезды форс-мажорами, но именно эти события исключили нашего художника из работы над проектом, на несколько месяцев. Эти же обстоятельства сослужили службу и мне. В целях самообучения и познания тонкостей магазинов, я сделал другое небольшое приложение – обычную угадайку фильмов.
Для тех кто не понял о чём речь
На этом приложении я смог протестировать интеграцию с соц. сетями, несколько рекламных сетей, внутреннею аналитику и покупки внутри приложения.
6. Техническая часть
Думаю, настало время поднять градус гиковости. Значимую часть времени разработки заняло создание генератора уровней. Генератор писался на питоне, потому как он был мне духовно близок и numpy позволял быстро оперировать матрицами.
Сам генератор на выходе создавал txt файл(который парсился Юнити для создания сцены) и серию картинок, показывающих пошаговое прохождение уровня.
Сейчас я могу сказать, что писание внешнего генератора на другом языке, это - плохая идея. Главным образом, тем, что игровая логика начинает прописываться в двух разных местах. А это - риск рассинхрона. Особенно, если учесть, что внутри игры, есть такие понятия, как анимация и время её исполнения. И в генераторе, и в игре каждая клетка сама следила за тем, что в ней происходит: кто вошёл, кто вышел, кто умер и т.д. Но клетки, вида телепорт или мухобойка (атакует близлежащие клетки), связывали несколько клеток между собой. И если в генераторе это не вызывало проблем, то в игре повторить то же было сложнее т.к. анимации персонажей из разных клеток должны были засинхронизироваться между собой.
Огромный кусок времени заняла интеграция нативных библиотек. Cкажу прямо: если можно купить готовую реализацию того, что вам нужно, смело покупайте. При этом желательно всё брать у одного продавца, потому как в Unity3D в манифесте (Андроид), есть такая штука как mainactivity и это место где разные плагины могут конфликтовать. Потом для iOS, скорее всего, у вас будут плагины, которые занимаются различным постпроцессингом, это тоже место для конфликтов. В целом нативные либы, это место где вы легко можете получить очень трудно выявляемые ошибки. Поэтому, почти всё, что связанно с нативным кодом, мы покупали у Prime31.
Полный список плагинов и несколько слов о каждом
7. Статистика
В релизе около 400кб, написанного мной кода. Ещё 150кб - это генератор и некоторые смежные скрипты.
В самой игре, на данный момент, 3 главы по 16 отобранных уровней. Также есть режим Испытаний, где ещё около 700 уровней, динамически распределённых по сложности.
В среднем уровень без звёзд можно пройти за 25 ходов. Самые сложные уровни со звёздами около 55.
8. Монетизация и продвижение
Пока нет каких то точных цифр, но у нас как и у сайлонов есть план.
На примере угадайки фильмов мы поняли, что на рекламе можно заработать, только если у вас от 300к+ пользователей. Поскольку проект у нас, как ни крути нишевой, думаю это не вариант. Но при этом делать платное приложение для Андроида - самоубийство. В итоге была выбрана стандартная нынче модель: показ рекламы и продажа монет. С любой покупкой монет идёт в комплекте полное отключение рекламы. Монеты даются при прохождении уровней и за них можно узнать идеальное прохождение уровня.
