Олег Бених

Наиболее популярная схема деления это:

1. Прототипирование
   
2. Пре-продакшн
   
3. Продакшн
   
4. Закрытый бета-тест
   
5. Soft launch
   
6. Релиз
   

Фаза прототипирования подразумевает написание кучи маленьких прототипов, которые выражают какую-то часть будущей игры. Например, у вас есть идея классного управления для персонажа, которое станет основной фишкой. Берёте и делаете на кубиках пяток вариантов реализации, убеждаетесь, что идея годная/какашка, продолжаете/прекращаете разработку. Суть этого этапа - минимальными средствами в кратчайшие сроки проверить все свои предположения и, если повезёт, найти новые идеи.

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

Продакшн это этап, во время которого выполняется основная работа. К этому моменту вы уже чётко знаете что, сколько и как вы делаете. В этой фазе уже нельзя менять планы, все эксперименты надо было делать раньше. Конечно, может получиться и так, что несмотря на все усилия спустя месяцы и годы игра не складывается, в таких случаях процесс разработки откатывают на шаг-два назад. Например, так было с Prey, Overwatch и Rainbow Six Siege.

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

Мягкий запуск это по сути открытый бета-тест, но, в контексте мобилок и социалочек, игроки могут даже не знать в какую игру играют. В мобильной разработке популярна практика запуска игр на малых рынках под другим именем. Например, в какой-нибудь Новой Зеландии с другими иконками. Это позволяет дать игру в руки реальным пользователям, но в случае провала не портить репутацию своей компании. Во время этого этапа тасуют кнопки в интерфейсе, развлекаются с A/B-тестированием и в целом пытаются оценить возможные результаты от полноценного релиза. Если прогнозы печальные, то игру могут и похоронить, чтобы не тратить впустую деньги на продвижение.

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

Что касаемо экономики игры, она должна быть описана хотя бы в общих чертах к середине пре-продакшена. Монетизацию нельзя просто взять и прилепить к игре, все механики должны её поддерживать. Например, вы решили, что будете делать фритуплей. Какой фритуплей? Если будете продавать шапки, то все купившие шапки должны иметь возможность ими хвастаться перед другими игроками. А раз нужно хвастаться, то скорее всего нужна фича или две, следовательно, программисты должны о них знать как можно раньше. Опять-таки никто не мешает сделать прототип монетизации, хоть на бумаге.

Как-то так:
js:

var someObj = {a:1,b:2};
var xhr = new XMLHttpRequest();			
xhr.open('POST', 'scratch.php');
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');			
xhr.send('param=' + JSON.stringify(someObj));
xhr.onreadystatechange = function()
{
	if (this.readyState == 4) 
	{
		if (this.status == 200)
		{
			console.log(xhr.responseText);
		}
		else
		{
			console.log('ajax error');
		}
	}
};

php:

$param = json_decode($_REQUEST["param"]);
$result = "Результат: a = ".$param->a."; b = ".$param->b;
die($result);

На данный момент для Python есть следующие движки на выбор:

2D:
- Cocos 2D (сам лично им не пользовался и ничего сказать не могу, но знаю, что русскоязычное сообщество использует этот движок для с++, вместо python)

- Kivy (это потомок Pygame, о котором напишу ниже. В основном он предназначен для создания приложений под андроид, но 2D игры тоже на нём делают)

- Собственно PyGame (Это библиотека Python для создания 2D игр. Очень проста в освоении и есть много уроков и книг на английском и русском. Можно создать практически любую 2D игру. Русское сообщество тоже есть. Хорошая книга на русском здесь)

- Так же есть 2D + 3D движок с внутренним языком программирования, который очень похож на Python. Т.е если знаешь Python, то этот ЯП освоишь максимум за неделю или даже меньше. Godot Engine

3D:
- Из 3D движков единственные это Blender Game Engine. Движок прост в освоении и, в принципе, даже не надо знать языка программирования для создания хорошей игры. Однако если знаешь Python, то это большой плюс, так как скрипты для этого движка пишутся именно на этом языке. Хорошая книжка по движку здесь, а здесь перевод. Примеры игр: раз, два.

- И , конечно же, Panda 3D. Это не конструктор игр, как Blender Game Engine, где ты создаешь игру, не написав строчки кода. Это конкретный игровой движок, где ты с нуля пишешь код на Python используя API этого движка и создаешь 3D игру. Я сейчас сам его осваиваю и у движка есть живое русскоязычное сообщество, где могут подсказать если что. Так же по движку много видео уроков и книг на английском. Вот одна из этих книг- она на английском, но написано всё понятно, что даже я, не зная инглиш, понимаю))))) Примеры игр: раз, два, три.