[Лог #1] Немного кода.

» опубликован
Извиняюсь за не столь содержательный заголовок

ТЕМА: КОД

Генерация предметов

Весьма странно начинать лог разработки не рассказав об игре хотя бы двух слов, да ещё и издалека — предметы и инвентарь.
Будет затронута только программная часть т.е. без графики, а всю информацию будем выводить в консоль. В конце лог-статьи будет приведён код на языке С++.
А теперь приступим :)

Характеристики

Для начала определить структуру предмета необходимо… или же нет?
На самом деле, следует знать зачем эти всякие предметы нужны и на что они влияют, но тут ответ более-менее ясен — характеристики персонажа, но вот что это за характеристики? Это и следует обозначить.
// Характеристики
struct sAttributes
{
	short health;		// Здоровье
	short shield;		// Щит
	short defence;	// Оборона (глушитель урона)
	short damage;	// Урон
};
Если Вам знаком синтаксис языка Cи, то вопросов возникнуть не должно, а для тех кто «не в теме», следует пояснить кое-что, но не углубляться в подробности: (лучше найти информацию в интернете, а то я плохо объясняю)
struct название_структуры
{
	тип переменная;	// комментарий
};
Теперь у нас есть структура определяющая характеристики.
Можно завести структуру и для персонажа, затем для предмета, но лучше не спешить и немного подумать.

Описание предмета

Каждый предмет в игре лучше «зарегистрировать» т.е. записать их в особый список, который будет хранить всю «статичную» информацию о предметах ( характеристики, например ).
А оперировать в инвентаре будем с более простой структурой предмета, которая будет ссылаться на информацию предмета в списке.
// Качество
enum eQuality
{
	EQ_COMMON   =0,	// Обычный
	EQ_STANDARD =1,	// Стандартный (в чём отличие от обычного?)
	EQ_HANDMADE,	// Самопальный
	EQ_LEGENDARY,	// Легендарный
	EQ_EPIC,		// Эпичный

	Count_Quiality	// так узнаем кол-во
};

// Тип предмета, если установлен в OTHER, то может быть произвольный
enum eKind // TYPE
{
	Kind_WEAPON = 0,	// Оружие
	Kind_ARMOR,			// Броня
	//Kind_POTION,
	Kind_OTHER
};

// Бит-флаги предмета
enum eItemFlag
{
	IF_CLEAR			= 0x0000,	

	IF_EQUIP			= 0x0001,	// Можно экипировать
	IF_COLLECTABLE	= 0x0002,	// Занимает один слот, записывая кол-во
	IF_USABLE			= 0x0004,	// Можно использовать
	IF_QUEST			= 0x0008	// Предмет, необходимый по сюжету\квесту (нельзя выбросить, слот не учитывается)
};

// Описание предмета для глобального списка
struct sItemDescription
{
	// Уникальный ID
	unsigned long	ID;

	string		 name;	// название предмета для отображения
	string		 desc;	// описание
	sAttributes	 attrib;

	eQuality	qual;	// качество
	eKind		kind;	// тип
	long		 falgs;	// бит-флаги
	
	// Визуальная информация
	int			modelID;	// номер 3Д модели
	int			textureID;	// номер текстуры для 3Д модели
	int			pictureID;	// номер картинки\текстуры\иконки для отображения в инвентаре
	// Цена предмета, можно задать вручную или же воспользоваться специальной функцией
	int	cost; 
};
- Эй! Что такое unsigned long, string и eQuality ?
unsigned означает, что наша переменная имеет исключительно положительное значение (для целочисленных типов).
long - аналогично как и short, однако, занимает больше памяти и следовательно может иметь больше значений.
string - тип описывающий строку текста (из стандартной C++ библиотеки).
eQuality и eKind - перечисления.
Код, возможно, кого-то испугает, но на самом деле всё очень просто.
Мы имеем структуру описания предмета - это означает, что используя этот "бланк" можно будет обозначить любой предмет в игре.
Вот пример такого определения:
sItemDescription SuperSword;
SuperSword.ID = CurID++; // Для каждого предмета считается свой ID
SuperSword.name 	= 	"Супер меч";
SuperSword.desc 	= 	"Лишь избранный может нести его";

SuperSword.attrib.health		= 0;
SuperSword.attrib.shield		= 0;
SuperSword.attrib.defence	= 0;
SuperSword.attrib.damage	= 20;

SuperSword.kind		= Kind_WEAPON;	 // Тип "оружие"
SuperSword.qual		= EQ_LEGENDARY;	 // Качество предмета как "Легендарный"
SuperSword.falgs	= IF_EQUIP;			 // можно экипировать

SuperSword.cost = ItemCost( SuperSword ); // Вычислим стоимость предмета
И это очень простой предмет, а представьте если их, скажем, 20 .. это же жуть их так все описывать, поэтому напрашивается идея генерации этих самых предметов. Разумеется представленный мой способ не очень, но надо же начать с чего-то :)

Генератор

Это функция, принимающая в качестве аргумента требования к процедурному предмету (смотри ниже).
sItemDescription GenerateItem( const sItemGenerationDesc &gendesc )
{
	sItemDescription desc;

	desc.ID = CurID++;

	desc.kind = gendesc.kind;
	desc.qual = gendesc.quality;

	desc.attrib.health = 0;
	desc.attrib.defence = 0;
	desc.attrib.damage = 0;
	desc.attrib.shield = 0;

	if( desc.kind == Kind_WEAPON )
	{
		desc.name = QualityToString(desc.qual) + " " + weapons_names[ RandomRange(0,weapons_names_count) ];
		// Лихо рассчитываем параметр используя качество, начальное значение и великий рандом 
		desc.attrib.damage = gendesc.attribs_ranges.damage + ((int)desc.qual) * RandomRange( 0, 4 );
	
		desc.falgs = IF_EQUIP;

	}else
	if( desc.kind == Kind_ARMOR )
	{
		desc.name = QualityToString(desc.qual) + " " + armor_names[ RandomRange(0,armor_names_count) ];
		desc.attrib.shield = gendesc.attribs_ranges.shield + ((int)desc.qual) * RandomRange( 0, 2 );
		desc.attrib.defence = gendesc.attribs_ranges.defence + RandomRange( 0, 2 );
		desc.falgs = IF_EQUIP;
	}

	desc.cost = ItemCost( desc ); // Вычисляем цену
	desc.desc = "Этот предмет сгенерирован программой"; // описание описания, извините за тавтологию 
	
	return desc;
}
А что-то за структура sItemGenerationDesc ?
struct sItemGenerationDesc
{
	eQuality		quality;			// Качество, которое мы хотим дать предмету
	eKind		kind;			// Тип предмета - оружие, броня или может ещё что
	sAttributes	attribs_ranges; 	// Разброс по атрибутам или их начальное значение
};
Таким образом, можно манипулируя тремя параметрами получить различные предметы.
Должен заметить, что с названием предметов есть неприятный момент, например, такой - "ЭПИЧНЫЙ труба" ... такое можно исправить, но это уже на будущее :)
Вот скриншот с консоли программы, демонстрирующие генератор предметов:
Можно скачать код или посмотреть.
Безусловно этот код изменится, ведь данная программа больше написана для тестирования.
Это первая статья из цикла, поэтому принимаю различные предложения по улучшению подачи контента )
Хотелось бы разрабатывать игру не просто для себя, а совместно с сообществом.

Что дальше?

На радаре концепт арты врагов! Если не терпится посмотреть на них, то можете разыскать их на сайте стопгейм.


Просмотров: 16 844

» Лучшие комментарии


PhysCraft #1 - 5 лет назад (отредактировано ) 0
Планируется ли добавление в генератор предметов удлиненного названия за счет префикса и суффикса, соответствующим тем или иным способностям или бонусам, которые дает предмет?
Еще можно сделать, что бы в зависимости от значения предидущего параметра, вибранного рандомно, следующий принимал разные значения. Например, если качество "обычный", то это просто меч или топор, если "легендарный", то названия будут более епичные. Для мечей и топоров разный разброс урона, цены,вес (условный вес, можно использовать для расчета скорости атаки через силу героя).
На С++ будет написана вся игра или это лишь демонстрация идеи?
Doc #2 - 5 лет назад (отредактировано ) -1
Писать игры на с++ канеш смело (и глупо имхо), движок для графона уже подобрал?
lentinant #3 - 5 лет назад (отредактировано ) 0
Может, с моей стороны это и не правильно, но лично я в последнее время начал использовать индексы вместо энумераторов. Местами куда удобней.
Если представить слоты экипировки персонажа в виде массива, то каждый элемент массива будет отвечать за соответственный слот, например, в первом элементе будет броня, во втором - оружие, соответственно, индекс брони будет 0, индекс оружия - 1. Таким образом, можно существенно упростить код для использования экипировки. Когда ты хочешь экипировать предмет, ты можешь взять его индекс, и проверить соответственный элемент массива экипировки. Таким образом, вместо того, чтобы прописывать экипировку в каждый слот отдельно, ты обходишься одним общим методом.
Editor #4 - 5 лет назад 3
Легендарный труба, так вот кто делал перевод генератора названий для диабло 2.
Praytic #5 - 5 лет назад 3
А чего плохого в написании игры на плюсах? Мне правда интересно, ибо я пока только этот язык и изучаю.
Editor #7 - 5 лет назад (отредактировано ) 0
Praytic:
А чего плохого в написании игры на плюсах? Мне правда интересно, ибо я пока только этот язык и изучаю.
Да ничего там плохого, на них написаны дум3 и хл2 )
Просто костыли везде разные.
nvc123 #8 - 5 лет назад 2
Praytic, мне не нравится адресная арифметика и то что код читается по порядку
проще говоря этот код работать не будет :
void A0(){}

void A1(){
A0();
A2();
}

void A2(){}
да и у функций такие имена что хочется удалить c++
Praytic #9 - 5 лет назад 2
ну а как на счет прототипизации в головном файле?
Kozinaka #10 - 5 лет назад 2
Doc: Писать игры на с++ канеш смело (и глупо имхо), движок для графона уже подобрал?
Слабоумие и отвага - двигатель прогресса! Я тоже на C++/DirectX/Lua пишу - с каждым годом разработки всё отчётливей понимаю, что сделал правильный выбор. :D
H #11 - 5 лет назад 0
"легендарный труба"
ЭЙ! какОй у тебя легендАрный трубА!
DarkDes #12 - 5 лет назад 0
PhysCraft:
Генератор будет меняться, спасибо за некоторые идеи )
Да, вся игра будет на Си++.
Doc:
Писать игры на с++ канеш смело (и глупо имхо), движок для графона уже подобрал?
Ну это кому как) Графон? Не не гонюсь за супер графикой, всё что будет необходимо проекту можно написать самому - это же весело! Эксперименты и всякое такое )
lentinant:
Интересно, надо будет это запомнить)
nvc123:
Я старался показать более простой код. Решил попробовать метод "сделай проще", зачем мне вся мощь ООП, если я её использовать не буду?
Порядок функций, как заметил Praytic , решается прототипами функций в заголовочном файле.
Слабоумие и отвага - двигатель прогресса!
А то! :)
Doc #13 - 5 лет назад (отредактировано ) -2
Не, я наверное неправильно выразился частично, в голове одно, а пишу слегка другое.
Писать МАЛЕНЬКИЕ/инди игры на С++ - глупо, как я считаю. Это просто не нужно, больше борьбы с инструментом, чем собственно делания игры.
И я уверен, те кто пишут на С++ игры, даже не представляют, что это совсем не то, что делают большие компании. Посмотрите видео, где человек из Ubisoft объясняет, как они используют С++ в продакшне. Никаких эксцепшнов, шаблонов, буста и прочего. Вот эти ребята гонятся за производительностью. А зачем другие люди пишут на С++ мне не понятно :3

Очень забавно, что меня минусанул Denj, который тут вроде с 2012 года или вроде и все это время разрабатывал свой крутой модный очередной движок на С++ и в итоге где-то к 2015 подобрался все-таки к написанию игры на нем. Об этом я и говорил, no offense.
Другое дело Kozinaka, у него по-крайней мере есть игра, первый раз такое вижу, хотя вроде тоже много времени прошло.
Kozinaka #14 - 5 лет назад 0
Doc, для разработчика с нулевым опытом, безусловно, С++ не лучший выбор. Но бэкграунд сильно меняет дело - мне юнити осваивать дольше, чем накидать прототип игрухи пользуясь своими старыми велосипедами. Каждый делает свой выбор исходя из своих условий.
Doc #15 - 5 лет назад (отредактировано ) 0
Kozinaka, с этим никак не поспорить, квалифицированный разработчик, прекрасно знающий свой инструмент, использует его как угодно и где угодно лучше, чем что-то незнакомое, пусть и более подходящее для конкретной задачи.
Kozinaka #16 - 5 лет назад 4
Мне кажется С++ уже так разросся, то используют его только те, кто начал его изучать, когда он был ещё маленький, остальных он отпугивает. Впрочем, буду рад ошибаться.
DarkDes #17 - 5 лет назад 2
Писать МАЛЕНЬКИЕ/инди игры на С++ - глупо
Возможно ты прав. Я хоть этот язык знаю не на 100%, но я привык к нему и предпочту использовать его :)
Согласен с Kozinaka осваивать сторонний движок - долго, да ещё начинаешь зависеть от него( ограничения ), а вот когда своё написал, то и принципы работы принял, получил опыт, и можешь крутить-вертеть свой двиг\фреймворк\игру как хочешь )
Имхо, готовые движки вроде Юнити подходят для прототипирования игр т.к. эти самые движки накладывают ограничения.
Doc #18 - 5 лет назад 0
Ну ты загнул прям, юнити.
Я больше про что-то вроде pygame или slick2d говорил. Я на первом за 8 часов написал топдаун игру, из них 4 часа на освоение языка и движка
DarkDes #19 - 5 лет назад 0
Doc:
Просто не привык к готовым библиотекам ) Это конечно хорошо, когда есть какие-то основа, а не голый ЯП. Кто знает, возможно, возьму какое-нибудь готовое решение.
Kozinaka #20 - 5 лет назад 0
DarkDes, правда обычно где-то посередине. Любое готовое решение диктует свои правила и ограничивает тебя, но при этом экономит силы и время. Важно найти баланс между велосипедированием и проклинанием чужих кривых рук. Я использую движок Lua для скриптов, библиотеку TinyXml для работы с Xml, BASS для работы со звуком и т.д. - при контроле за главным (графический движок самопальный, я его часто кручу под свои нужды), тонкости реализации вещей, в которых я плохо разбираюсь, я перекладываю на сторонние библиотечки. Мне нравится. :)
lentinant #21 - 5 лет назад 0
Имхо, готовые движки вроде Юнити подходят для прототипирования игр т.к. эти самые движки накладывают ограничения.
А можно мне послушать, какие ограничения накладывает Юнити?
DarkDes #22 - 5 лет назад 0
какие ограничения накладывает Юнити?
Рендер в текстуру, и следовательно различные пост-процессы. Больше ограничений назовут те, кто дольше с юнити работал.
lentinant #23 - 5 лет назад 0
Рендер в текстуру, и следовательно различные пост-процессы.
Ну, это ограничение только в бесплатной версии, вообще-то. В платной есть полный набор функционала для пост-обработки.
Kozinaka #24 - 5 лет назад 2
lentinant: А можно мне послушать, какие ограничения накладывает Юнити?
Я не знаю Юнити, поэтому не могу рассказать про его ограничения. Но ограничения есть у всего, что что-то инкапсулирует и избавляет тебя от лишней работы.
Praytic #26 - 5 лет назад 0
nvc123:
Kozinaka, не у всего
Заинтриговал. Где нет ограничений?
nvc123 #27 - 5 лет назад 0
Praytic, сетеры/гетеры это инкапсуляция но они не накладывают ограничений
Kozinaka #28 - 5 лет назад (отредактировано ) 0
nvc123, сеттеры и геттеры это суть есть ограничение доступа внешнего кода к члену класса. Если ты используешь чужую библиотеку, то ты не сможешь легально воздействовать на приватное поле класса минуя его сеттер. А сеттер писал не ты. В сеттере могут быть баги, неустраивающая тебя или избыточная для твоих нужд функциональность.
Но вообще я про библиотеки и инструментарий писал. :)
I_D_ #29 - 5 лет назад 0
"Зачем создавать что то новое если есть досконально изученное старое?" - вот примерно так думают люди использующие только готовые движки и среды разработки. Увы но если люди перестанут крутить свои велосипеды, то просто остановиться прогресс.
Doc #30 - 5 лет назад (отредактировано ) 1
I_D_, вот люди которые бросаются в крайности точно далеко не уедут. Ну давай, расти рис на собственном поле (плуг использовать нельзя, все руками) а потом иди в лес и забивай камнем дикого кабана, каждый раз как захочешь поесть плов.
Готовить конечно же на костре.
А то вдруг мир "остановиться".
I_D_ #31 - 5 лет назад 0
1)Когда-то давно поля возделывали "палками" и находились удальцы кричащие зачем нам "плуг" у нас ведь есть "палка"
2)Разница между "плугом" и " палкой" в качестве обработки, и затрачиевыемых ресурсах для исполнения одной и той же цели
3)"плуг и "палка" это инструменты в исполнение одного и того же дела.
Так что я хотел сказать это то что есть люди сделавшие эти самые вещи до нас и они не показывали себя с плохой стороны и из-за этого и используются. Но попробуй плуг использовать в другом месте и для другого назначения увы этого у вас не выйдет. Так те конструкторы и движки представленные на этот момент в основном мультиинструменты "плуг" и "ружьё" в одном флаконе, но как пахать поле не удобно "ружьё" мешается также и для стрельбы.
И из-за этого создаются движки со своими единственными целями.С использование более простых инструментов.
Показавших свою надёжность. Но движок стоит писать если это действительно необходимо и вы сможете его реализовать.Но то что ты мне написал больше походило на то что "Бери asm и пиши всё с нулю даже вывод."
DarkDes #32 - 5 лет назад 0
... "Бери asm и пиши всё с нулю даже вывод."
Да это вызов! :D А вообще можно и на asm'е писать, чисто ради знаний, ведь интересно же)
Кет #33 - 5 лет назад (отредактировано ) 0
1)Когда-то давно поля возделывали "палками" и находились удальцы кричащие зачем нам "плуг" у нас ведь есть "палка"
Пример не совсем корректный.
  • Палки-копалки использовались до возникновения сельского хозяйства. Племена, вошедшие в эту стадию, уже могли изготовить мотыгу хотя бы из камня.
  • Соответственно, предшественник плуга — мотыга.
  • Плуг вошёл в использование там, где в него было, что запрячь. Без скота плуг не более эффективен, чем мотыга.
...вообще у вас обоих какие-то странные аналогии, я запутался. Если можешь себе позволить написать движок и справишься с этим — почему бы и нет? Если тебе это не нужно или ты этого не можешь (по затратам времени, труда или по навыкам) — почему бы не использовать готовый?
UPD: Извините, что дописываю камент, но если продолжить аналогию с плугом и мотыгой, то тут так: если ты силён как бык и можешь тягать плуг сам — почему бы и нет? Но если нет, лучше найти быка. Может, быком управлять не так удобно, как идти самому, но уж точно справишься.
I_D_ #34 - 5 лет назад 0
Кет:
1)Когда-то давно поля возделывали "палками" и находились удальцы кричащие зачем нам "плуг" у нас ведь есть "палка"
Пример не совсем корректный.
  • Палки-копалки использовались до возникновения сельского хозяйства. Племена, вошедшие в эту стадию, уже могли изготовить мотыгу хотя бы из камня.
  • Соответственно, предшественник плуга — мотыга.
  • Плуг вошёл в использование там, где в него было, что запрячь. Без скота плуг не более эффективен, чем мотыга.
...вообще у вас обоих какие-то странные аналогии, я запутался.
А вот как она по литературному называется - брал пример с палкой лишь из-за упущения литературного названия мотыги.
lentinant #35 - 5 лет назад 0
I_D_, развитие довольно редко возможно без отталкивания от существующих технологий. Взять тот же велосипед. Вместо того, чтобы приделать к нему мотор, и получить мопед, а впоследствии и мотоцикл, ты предлагаешь делать что-то абстрактное с нуля.
Doc #36 - 5 лет назад 0
И самое главное не факт, что ты собрав свой велосипед, ты получишь что-то лучшее, а время точно потратишь.
Я не предлагаю сидеть на всем готовом. Нормальный движок не будет сажать тебя в свою песочницу, закидывать игрушками и говорить "сиди тут и не дергайся", нормальный движок дает ящик с инструментами и выкидывает на улицу. Нужно грамотно использовать реюзаемые части кода и инструменты, чтобы создать энвайронмент под себя.
nvc123 #37 - 5 лет назад (отредактировано ) 2
Doc, но если готовый движок тебя не устраивает то иногда лучше сделать свой чем терпеть готовый
но только при условии что накопилось достаточно кода который можно использовать повторно
и сборка велосипеда помогает узнать как он устроен
ehnaton #38 - 5 лет назад 0
У меня такое чувство, что против готовых движков выступают люди, никогда не делавшие ничего коммерческого.
Собственный движок нужен только для высоко-производительных вещей или для реализации каких-то необычных технологий, которые к уже готовым движкам стыкуются чуть более чем никак.
Заказчику искренне пофиг на твою нелюбовь к готовым движкам, ему важен результат и за приемлимое время. Проще говоря, заказ явно выполнит быстрее человек, не побрезговавший воспользоваться тем же Unity, чем тот, кто из принципа будет писать велосипеды.
Долгострои редко нормально окупаются...
Инди разработчик делает игру так, как ему хочется, поэтому для него это не так критично.
Doc #39 - 5 лет назад 4
Тут коммерческое и окупаемость не при чем даже...
Если делать игру ради процесса написания движка - вперед. Дальше 95% людей не уйдут. Я слишком много сидел на ресурсах по геймдеву чтобы этого не знать. Две типичные новичковские ошибки - брать и пытаться делать на ВСЁМ готовом и делать ВСЁ с нуля. Грамотно совмещайте и все будет оки.
Два человека, которые на практике сделали в наше время собственными руками игровой движок, сравнимый с гигантами индустрии, это David Rosen и Josh Parnell, у них обоих ушли на это ГОДЫ, с сотнями тысяч долларов в виде стимула. И их игры все еще не закончены. На что надеетесь вы, когда начинаете писать движок? Что получится лучше и быстрее?
I_D_ #40 - 5 лет назад 0
Кажется кто то кого то не понимает с нуля движок крайне редко пишется в некоммерческих проектах а используются сторонние библиотеки, и ты в большей части делаешь лишь взаимодействия не предусмотренные нигде более но которые действительно нужно. Никто и не говорит пилить всё с нуля а как МИНИМУМ воспользоваться графическим ядром
Doc #41 - 5 лет назад (отредактировано ) 0
Я считаю если ты начинаешь с SDL/LWJGL и начинаешь писать файлменеджер, загрузку шейдеров, сценграф, фреймбуфферы, отрисовку теней, загрузку моделей (все это уже написано ТЫСЯЧУ РАЗ и надеяться, что в этот раз получится лучше чем у всех остальных - глупо) это по сути и есть с нуля.
I_D_ #42 - 5 лет назад 0
Считай так как считаеш нужным всё равно такие споры безрезультатны в большинстве случаев так как новые аргументы я не видел. Лишь то что это долго и невыгодно. И то что считаешь с нуля просто вдумчиво прочитай верхний комментарий.
Вон кстати enhaton дело говорит.
Doc #43 - 5 лет назад 4
и сборка велосипеда помогает узнать как он устроен
Алсо это хороший аргумент, написание движков полезно в этом плане, только в отдельности от написания игр
Kozinaka #44 - 5 лет назад (отредактировано ) 0
Doc, сборка велосипеда позволяет тебе сделать у него ровно столько колёс и ручек, сколько тебе нужно. Например одно колесо и вообще без ручек. :)
I_D_ #45 - 5 лет назад 0
:D а если не получается собрать то что хотел то иди ищи того у кого получилось хоть что-то похожее.
Praytic #46 - 5 лет назад 0
Сколько аллегорий, я уже запутался.
I_D_ #47 - 5 лет назад 0
Сами запутались -_- уже
DarkDes #48 - 5 лет назад 3
Тут конечно разгорелась дискуссия "Готовый движок против велосипеда" :)
Я не буду яро отрицать, что иногда готовые движки - лучшее решение, например, когда проект ограничен по времени и выбранный двиг удовлетворят требованиям. А когда хочется посидеть у камина завернувшись в одеяло изучать "кишки", разобраться в устройстве работы в принципе ну или когда не ограничен в строках и можешь вообще переписать весь код, скажем, под мобилы. Вы наверно заметили, что к разработке игры я подошёл по большей части со стороны контента, смекаете ? :) Этот контент можно использовать хоть в своём велосипеде, хоть в готовом супер-движке со стоимостью в 99999$ (разумеется, цена - совсем другой вопрос). Что я хочу сказать. Делайте игры\моды и всё ! :D
GeneralElConsul #49 - 5 лет назад (отредактировано ) 0
Сколько аллегорий, я уже запутался.
Не надо слушать всех. Делай как тебе удобно.
Каждый год(2-ой или 3-ий подряд?) возникает подобный спор и каждый год все приходят к одному и тому же выводу:
DarkDes:
Делайте игры\моды и всё ! :D
Грамотно совмещайте и все будет оки.
ну ребят)