Документация: https://docs.unity3d.com/Manual/index.html
Уроки: https://unity3d.com/ru/learn/tutorials
Форум: https://forum.unity3d.com
Магазин ассетов: https://assetstore.unity.com
На Unity сделано много замечательных игр: Zenless Zone Zero, V Rising, Hearthstone, VRChat, Escape from Tarkov, Valheim, Pathfinder, Cuphead, Genshin Impact, Subnautica, Albion Online, Endless Space, Beat Saber, Boneworks, Rust, Блицкриг 3, Pillars of Eternity, Tyranny, Kerbal Space Program и многие другие.
Главным преимуществом Unity перед другими движками является его простота для одиночной разработки. Не нужно иметь целую компанию девелоперов, чтобы сделать хорошую игру. Если ты один или имеешь небольшую команду и хочешь сделать хорошую игру без претензий на ААА, то Unity станет лучшим выбором. Тем не менее, даже крупные корпорации зачастую выбирают для своих игр именно Unity.
Какие у Unity сильные стороны?
Простота разработки, удобный инструментарий, кроссплатформенность, богатая документация, огромное сообщество.
Какие у Unity слабые стороны?
Сложность в создании фотореалистичной графики. Для графики "как в Crysis" рекомендуется взять другой движок. Хотя Unity вполне способен выдавать не уступающую любым другим движкам картинку, это требует определённого навыка от разработчика.
На каких языках я могу писать скрипты для Unity?
Поддерживается написание скриптов на C# 9.0
https://docs.unity3d.com/Manual/CSharpCompiler.html
Какие есть готовые решения для создания мультиплеерной игры?
https://www.photonengine.com
https://mirror-networking.com
https://playfab.com
На каких платформах работают созданные с помощью Unity игры?
Windows, Linux, MacOS, SteamOS, Android, iOS, Windows Phone, PlayStation4, Xbox One, WebGL, Oculus Rift и многие другие. Полный список можно найти на официальном сайте. Таким образом, игры Unity работают на десктопах, на смартфонах, планшетах, приставках, в браузерах, VR-очках и некоторых других системах.
Часто вижу скриншоты с красивой природой на Unity. Как такое создать?
Очень просто! В Unity встроены удобные инструменты для создания террейна и SpeedTree для создания деревьев и готовая реализация ветра - не нужно ничего писать или скачивать и подключать плагины - ландшафт в Unity создаётся в пару кликов.
Что нужно уметь делать для создания полноценной игры, кроме Unity-разработки?
Кроме непосредственной разработки игры на Unity, требуется также уметь создавать 3D модели (3ds Max, Blender, ZBrush), 2D рисунки (GraphicsGale, Aseprite, Piskel), текстуры (Substance Designer, NeoTextureEdit), музыку (FruityLoops, Ableton). Не обязательно учить это всё - например, в 2D играх не нужны 3D модели, а музыка необходима далеко не всегда. Также вы можете скачивать элементы для ваших игр на бесплатных сайтах. Если у вас есть деньги, то все необходимые элементы можно заказать у фрилансеров на https://www.fl.ru/ (русскоязычный) или https://www.upwork.com/ (англоязычный).
Бесплатен ли Unity?
Можно свободно скачивать, использовать и продавать готовые игры на Unity с лицензией Personal - это абсолютно бесплатно! Но на бесплатной версии при запуске игры будет появляться короткий стартовый ролик "Made with Unity", а также ваши доходы ограничены 100 000 долларов в год. Для снятия этих ограничений нужно приобретать платные версии лицензий Unity. В конечном итоге, платные варианты используются лишь крупными компаниями с огромными доходами, тогда как обычные разработчики в большинстве своём используют бесплатную Personal лицензию.
Обучение по книгам (печатные издания, актуальные электронные версии книг можно скачать на официальных сайтах издателей)
Обучение языку C# книги на русском языке:
1. C# для чайников Автор книги – Джон Пол Мюллер
2. Программирование на C# для начинающих 2е части Автор: Алексей Васильев
3. Head First. Изучаем C# 4е издание Авторы: Эндрю Стиллмен, Дженнифер Грин
4. Unity и C#. Геймдев от идеи до реализации Автор: Джереми Гибсон Бонд
5. Язык программирования C# 7 и платформы .NET и .NET Core Авторы: Филипп Джепикс, Эндрю Троелсен
Для людей абсолютно не знакомых с движком есть 3и основные книги на русском языке:
1. Разработка игр на Unity 2018 за 24 часа Майка Гейга
(Знакомство с движком, изучение редактора, создание 4х простых игр практически без кода, отличное пособие для полных новичков).
2. Изучаем C# через разработку игр на Unity. 5-е издание Харрисон Ферроне
(Пошаговое освоение всех базовых знаний по программированию на языке С# в редакторе юнити, создание одной игры стрелялки от первого лица, написание искусственного интеллекта врага, книга переведена не совсем корректно и порой встречаются не просто опечатки, а серьёзные неточности перевода.)
3. Unity в действии. Мультиплатформенная разработка на C#. 3-е межд. издание Хокинг Джозеф
(Правильное построение архитектуры кода для сложных проектов, углублённое изучение программированию на C#, создание 4х полноценных игр на движке, обязательно нужно скачать код проектов, так как в книге он местами уже устарел.)
Шапка: https://pastebin.com/JGUAcbwj
Прошлый тред: >>980548 (OP)
спросонья проебался немного
720x480, 1:30
что-то не нравится?
>Но на бесплатной версии при запуске игры будет появляться короткий стартовый ролик "Made with Unity"
Уже не актуально
720x1280, 0:59
Ожидание в секундах можно сделать через WaitForSeconds, щелчок мыши тоже можно отловить.
Но не могу понять а как это совместить, чтобы еще щелчок мыши, отменял корутину которая ждет секунды
coroutine = StartCoroutine(...)
StopCoroutine(coroutine)
Также это реализуемо через async await, в том числе с помощью UniTask.
И в целом у тебя должно бвть понимание, что это можно реализовать и без каких-либо корутин и асинк авейта, а чисто апдейтом переменной таймера в Update, но такое решение разумеется будет не очень годным.
Скинь скрин, что за UiImage?
> Теперь вся игра это как один гигантский интерфейс с дохулионом UI Image в нем. каких-то проблем с производительностью нет, но может она была бы раз в 10 лучше если бы делал все в Image?
Когда любой элемент в канвасе меняется - весь канвас перерисовывается. Поэтому с целью производительности есть смысл по разным канвасам всё распиливать.
А с точки зрения юзабельности и удобства - ещё и по разным префабам всё раскидать, возможно даже по разным сценам
Можешь хоть через инвок сделать.
У тебя есть номер текущего текста, допустим он сразу
int t = 124;
И контрольная переменная которая изначально равна 0.
int t_control;
В апдейте:
If (t_control != t)
{ t_control = t; Invoke("ChangePage", 10f); }
ChangePage()
{
If (t_control == t)
{
t += 1;
... // тут активируй следующий текст, и т.к. теперь t_control != t , то в апдейте будет запущен ивок для следующей смены текста
}
else
{
// тут нихуя нет, просто ничего не делаешь, т.к. t_control стал неравен t из-за нажатия мышкой. она поменяла страницу и инициировала очередной инвок в апдейте
}
}
// это метод для мышки
PickMouse()
{
t += 1;
... // тут активируй следующий текст
}
Можешь хоть через инвок сделать.
У тебя есть номер текущего текста, допустим он сразу
int t = 124;
И контрольная переменная которая изначально равна 0.
int t_control;
В апдейте:
If (t_control != t)
{ t_control = t; Invoke("ChangePage", 10f); }
ChangePage()
{
If (t_control == t)
{
t += 1;
... // тут активируй следующий текст, и т.к. теперь t_control != t , то в апдейте будет запущен ивок для следующей смены текста
}
else
{
// тут нихуя нет, просто ничего не делаешь, т.к. t_control стал неравен t из-за нажатия мышкой. она поменяла страницу и инициировала очередной инвок в апдейте
}
}
// это метод для мышки
PickMouse()
{
t += 1;
... // тут активируй следующий текст
}
Не надо так делать.
Если ты с кем-то на проекте заюзаешь инвок, то ебало разобьют сразу.
А если ещё и вот именно так, то ещё и обоссут.
Правой кнопкой в иерархии вызови меню, там есть UI (вторая снизу) и в ней уже Image.
>Не надо так делать.
Что не так, если делать в своем проекте? Кроме того, то это быстро, надежно и предельно понятно?
>на проекте заюзаешь инвок
Если ты на ебаной галере, где прогеры меняются раз в неделю и никто уже нихуя не понимает, откуда что вызывается и зачем проекте, то да. Тогда каротинами, и не забудь пару раз обмазать все это гет-сетами, чтобы кто-нибудь случайно не залез.
Вроде надо было делать игру в 3Д пространстве, просто создав плоские 3Д объекты, наклеить на них текстуры карт и выложив их на одной плоскости. А интерфейс типа только для интерфейса. А я в нем захуячил всю игру, т.к. удобнее было
да, через корутину уже сделал
Появилась другая хрень, что если в коце цикла булево переводить обратно в фалс сразу после окончания, то он переодически два прохода подряд хуярил, пришлось в начале цикла тоже дописать чтобы ставил, хрен знает почему
foreach(GameObject /////////)
{
canContinue = false;
///
yield return new WaitUntil(() => canContinue);
canContinue = false;
}
У инвока?
1. Название текстом(решается через nameof)
2. Нет контроля за лайфтаймом инвока
3. Нулевая расширяемость, более сложная логика требующая большего погружения в контекст
4. Непонятно нахуя его юзать, когда есть
>>6026
> В апдейте:
> If (t_control != t)
> { t_control = t; Invoke("ChangePage", 10f); }
> ChangePage()
> {
> If (t_control == t)
> {
> t += 1;
> ... // тут активируй следующий текст, и т.к. теперь t_control != t , то в апдейте будет запущен ивок для следующей смены текста
> }
> else
> {
> // тут нихуя нет, просто ничего не делаешь, т.к. t_control стал неравен t из-за нажатия мышкой. она поменяла страницу и инициировала очередной инвок в апдейте
> }
> }
> // это метод для мышки
> PickMouse()
> {
> t += 1;
> ... // тут активируй следующий текст
> }
Вот ты написал эту ебанину, надо держать в голове что этот вот _t у нас когда изменится, то по его изменению оно вызовет новый инвок, и этот инвок дальше увеличит _t, и это изменерие подхватится в апдейте дальше, а ещё мы можем его изменить кликом мышкой... Ебать.
Просто, Ебать.
А если я сделаю навигацию по страницам в любую сторону потом? А если добавлю ускорение текста на пробел? А если сделать добавить галочку - включить/выключить автоскролл?
Действительно, над этим кодом можно посидеть, подумать 2 минуты и разобраться что он делает, но нахуя это делать? И какоц пиздец будет, когда решишь это дальше расширять.
Я вот вообще не понимаю прикола сложной логике в угоду скорости, когда даже не видно профита, в своих проектах пишу ровно также как на работе, я хз нахуя писать а, b, _t, if (r+1 < y /5) r+=2 и прочую ебалу.
Почему бы не сделать просто
IEnumerator AutoScrollCoroutuine()
{
yield return Wait ...
SetNextText();
SetNextAutoScroll();
}
private void SetNextAutoScroll()
{
StopCoroutine(_autoScroll);
_autoScroll = StartCoroutine(AutoScrollCoroutine);
}
void Click()
{
SetNextText();
SetNextAutoScroll();
}
И сразу всё понятно, всё на естественном язвке почти, около нулевоц контекст надо в голове держать и 0 вопросов а что если.
У инвока?
1. Название текстом(решается через nameof)
2. Нет контроля за лайфтаймом инвока
3. Нулевая расширяемость, более сложная логика требующая большего погружения в контекст
4. Непонятно нахуя его юзать, когда есть
>>6026
> В апдейте:
> If (t_control != t)
> { t_control = t; Invoke("ChangePage", 10f); }
> ChangePage()
> {
> If (t_control == t)
> {
> t += 1;
> ... // тут активируй следующий текст, и т.к. теперь t_control != t , то в апдейте будет запущен ивок для следующей смены текста
> }
> else
> {
> // тут нихуя нет, просто ничего не делаешь, т.к. t_control стал неравен t из-за нажатия мышкой. она поменяла страницу и инициировала очередной инвок в апдейте
> }
> }
> // это метод для мышки
> PickMouse()
> {
> t += 1;
> ... // тут активируй следующий текст
> }
Вот ты написал эту ебанину, надо держать в голове что этот вот _t у нас когда изменится, то по его изменению оно вызовет новый инвок, и этот инвок дальше увеличит _t, и это изменерие подхватится в апдейте дальше, а ещё мы можем его изменить кликом мышкой... Ебать.
Просто, Ебать.
А если я сделаю навигацию по страницам в любую сторону потом? А если добавлю ускорение текста на пробел? А если сделать добавить галочку - включить/выключить автоскролл?
Действительно, над этим кодом можно посидеть, подумать 2 минуты и разобраться что он делает, но нахуя это делать? И какоц пиздец будет, когда решишь это дальше расширять.
Я вот вообще не понимаю прикола сложной логике в угоду скорости, когда даже не видно профита, в своих проектах пишу ровно также как на работе, я хз нахуя писать а, b, _t, if (r+1 < y /5) r+=2 и прочую ебалу.
Почему бы не сделать просто
IEnumerator AutoScrollCoroutuine()
{
yield return Wait ...
SetNextText();
SetNextAutoScroll();
}
private void SetNextAutoScroll()
{
StopCoroutine(_autoScroll);
_autoScroll = StartCoroutine(AutoScrollCoroutine);
}
void Click()
{
SetNextText();
SetNextAutoScroll();
}
И сразу всё понятно, всё на естественном язвке почти, около нулевоц контекст надо в голове держать и 0 вопросов а что если.
>1
это локальная задача, просто похуй. если опечатка, то не будет работать - сразу найду и поправлю
>2
нахуя в этом конкретном случае лайфтайм? ну, вот просто зачем он может понадобиться, хотя бы в теории?
>3
какой контекст, нахуй? у меня в своем соло-проекте овердохуя работы начиная от контента, заканчивая геймдизайном и поиском рефоф для аутсорс-композитора. и это не считая продвижения.
я ебанусь нахуй, если буду искать где можно еще погрузится в контекст, когда я эти 10 строк кода при надобности (она не возникнет) могу просто переписать
>4
затем что там буквально 3 строки кода, плюс пару строк на активацию текста, которые я быстро написал и попиздовал делать более важные вещи, вроде баланса или алгоритмов ИИ
If (t_control != t) { t_control = t; Invoke("ChangePage", 10f); }
ChangePage() { If (t_control == t) { t += 1; NextText(); } }
PickMouse() { t += 1; NextText();}
>А если я сделаю навигацию по страницам в любую сторону потом? А если добавлю ускорение текста на пробел? А если сделать добавить галочку - включить/выключить автоскролл?
Просто ты задроченная галерная мартыха, которую так часто били палками продакт-манагеры, что она пытается предусмотреть все, даже если это там в принципе не нужно.
А я - челове-творец собственных проектов, который знает, что к нему завтра не прибежит пидарас-манагер, хуево понявший техзадание от забугорного барина, с криком - а, бля, все надопеределать!
Если я делаю так - значит это оптимально и допустимо для меня. если нет, то я сам же себя потом накажу пределками. Но такого практически никогда не бывает. Поскольку я думаю дольше 2х минут прежде чем начать что-то кодить. Если я написал код таким образом, то я точно, блеать знаю, то никакого "ускорения текста на пробел" в этом месте никогда не будет. А если мне будет нужна прокрутка назад, то я добавлю еще две строки где будет присутствовать почти те же самыt строки только с t -=1;
> Просто ты задроченная галерная мартыха, которую так часто били палками продакт-манагеры, что она пытается предусмотреть все, даже если это там в принципе не нужно.
Ну какие продакты? Это чисто адекватный прикид что в игре может понадобится в будущем.
> А я - челове-творец собственных проектов, который знает, что к нему завтра не прибежит пидарас-манагер, хуево понявший техзадание от забугорного барина, с криком - а, бля, все надопеределать!
Хз, я никогда не работал на аутсорсе, только в продукте, а если что-то надо переделать(в связи с фидбеком) - это штатная ситуация, которую ты делаешь не с горелой жопой потому что "должны быть готово вчера", а в нормальном режиме, как обычное итерационное улучшение. И на своем проекте тоже самое.
> Если я написал код таким образом, то я точно, блеать знаю, то никакого "ускорения текста на пробел" в этом месте никогда не будет.
Ну я не знаю, значит это ты слишком спланированный какой-то. Что угодно если делаешь сам, у тебя всегда будет какое-то шатание в плане того что нужно, по мере появления нового фидбека(в том числе от себя)
Ты работаешь в условной команде и такой подход в составе команды правильный, что каждый на своем месте все предусматривает.
Если же ты делаешь проект в одно лицо, то разу должен прикидывать, какие вещи критически важны и могут потребовать изменений в дальнейшем, а какие второстепенны и для них нужен только базовый функционал. Без умения отсекать вторичное, ты никогда не сделаешь соло-проект из-за банальной нехватки времени. Поэтому в соло-проекте предпочтительны 3 работающие строчки кода, вместо 20 "таких как нужно".
Так же нет никаких блокировок доступа к данным, потому-что если ты будешь их писать, то реально ебанешься или во время написания или, когда начнешь что-то править
> Без умения отсекать вторичное, ты никогда не сделаешь соло-проект из-за банальной нехватки времени. Поэтому в соло-проекте предпочтительны 3 работающие строчки кода, вместо 20 "таких как нужно".
Так это ты 20 строчек написал с неочевидной логикой, а у меня 3 и вышло с корутиной и прозрачной работой, кек.
Не знаю как ты, но как по мне любой моло проект это тоже самое, что и не соло проект, если ты делаешь его больше месяца, и потом ты точно также будешь вспоминать где там у тебя что и как работает.
Привет, есть куча опыта как раз с такой частью, т.к сам делал пару новел.
Реализовывал это так:
Есть таймер который запускается при вызове, рядом каждую 0.1 сек печается новая буква, если буквы в переменной закончились, таймер останавливает и при нажатии передается вызов дальше, если же игрок нажал на текст то весь текст переносится в переменую и таймер так-же останавливается.
Все это дело у меня занимало немного апдейта, проблем ноль, работает идеально.
Проверка на null указывает существует ли UI тултипменю или же он был удалён.
В Unity оператор сравнения с null переопределён на уровне UnityEngine.Object. Можешь сам посмотреть.
В доках об этом написано:
https://docs.unity3d.com/6000.0/Documentation/ScriptReference/Object.html
Sometimes an instance of Object can be in a detached state, where there is no underlying native object. This can happen if the instance references an native object that has been destroyed, or a missing Asset or missing type. Detached objects retain their InstanceID, but the object cannot be used to call methods or access properties. An object in this state will appear to be null, because of special implementations of operator ==, operator != and Object.bool. Because the object is not truly null, a call to Object.ReferenceEquals(myobject, null) will return false.
The null-conditional operator (?.) and the null-coalescing operator (??) are not supported with Unity Objects because they cannot be overridden to treat detached objects objects the same as null. It is only safe to use those operators in your scripts if there is certainty that the objects being checked are never in a detached state.
>Проверка на null указывает существует ли UI тултипменю
какое-то странное написание, разве не должно быть:
if (shownTolltip != null)
со стороны выглядит подобно
if ( 0 != x)
пиздец как выглядит в общем
мимокрокодил
> if (shownTolltip != null)
Функционально тоже самое.
А по код стайлу - уж вопрос код стайла, некоторые слева пишут null в проверках на null. Главное чтобы во всем проекте единообразно было.
>Функционально тоже самое.
ебануто выглядит, "проверь не равен ли 0 моему числу" пиздец просто, типа это переменная которая может иметь дохуя значений. не знаю какие дегенераты так пишут, но я бы не взял такого на работу - у него гавно в голове, если он так формирует условия
А вот есть такие, видел какое-то обоснование чем так удобнее, но уже не помню, и судя по тому что я эту практику не взял - оно мне не понравилось.
чем удобнее? тем что первым делом в условии ты видишь константу, значение которой так знаешь и которая нихуя не меняется, т.к. внезапно это константа? охуеть удобно. повторю, что не знаю что в голове у такого человека, но думает он настолько нестандартно, что я бы избегал таких "программистов"
Потому что можно случайно вместо if(a == 0) написать if (a = 0), что присвоит a значение 0 и вернет false, вместо сравнения. А константе/литералу присвоить нельзя. Это очень олдовый способ, наверное еще из Си 80-х.
парни хочу побаловаться с физикой
как все rigid body на сцене в sleep режим ввести?
после блендера скриптовую логику недопираю
>написать if (a = 0)
компилятор сразу подчеркнет, раньше может было удобнее, когда компиляторов не было, но те прогеры уже должны были вымереть к настоящему времени.
Иногда в ифах проскакивает присваивание, но да комп сразу пиздит что что-то не так.
Ни разу не встречал реальных проектов где смогли бы задаваить все варнинги.
Справедливо. Но я за за последний год смутно припоминаю ток 1 раз когда так проебался.
>Если же ты делаешь проект в одно лицо, то разу должен прикидывать, какие вещи критически важны и могут потребовать изменений в дальнейшем, а какие второстепенны и для них нужен только базовый функционал. Без умения отсекать вторичное, ты никогда не сделаешь соло-проект из-за банальной нехватки времени.
Ну вот у меня сейчас проект где мне потребовалось маленько покумекать "а как сделать так вот штобы у меня была возможность конструировать геймплей прямо в конфигурационных файлах, и иметь возможность этот геймплейный юнит множить на много разных сущностей и при этом не охуеть", хотя изначальная задача стоит так - нужно реализовать определённые разные режимы командной игры с поэтапным развитием игровой ситуации. Я бы мог насрать сущностями, монолитно их связать или начать выдумывать какой-то хитровыебаный способ применять цепочку обязанностей который опять таки монолитом будет сидеть по звеньям, и понял что ебана рот, мы тут все свои, а давай я сделаю каждый этап и любой игровой объект как интерактивный, пропишу ему характеристики существования, пропишу дочерние интерактивы, впишу ему конкретно его код в ряд функций, добавлю генерируемые на основе конфига функции, когда объект сможет основываясь на информации из конфига искать целевой интерактив и предписывать ему что-то сделать, а захардкоженые для сложных целей функции буду дергать по имени из конфигурационного файла рефлексией, и в зависимости от того что в данный момент прописано в конфиге - объект себя будет вести так как мне надо. Правда на придумывание этой хуйни ушло полтора дня. Вот и скажи, зря или не зря я изьебнулся, потратил время, но очертил себе в будущем целый пласт упрощения контроля игрового процесса, и заодно для себя обнаружил что я могу неиронично дергать функционал из других режимов что изначально и не задумывалось.
А соло ты можешь делать как тебе удобно, главное на начальном этапе хорошо продумать, где у тебя возможно будет расти и меняться функционал (там желательно все делать по уму). А что не критично и можно будет потом переписать или даже просто выкинуть нахуй (понятно, что в этом месте нет смысла изъебываться и тратить время на разработку супергибкого функционала, достаточно будет и базового).
>Поэтому в соло-проекте предпочтительны 3 работающие строчки кода, вместо 20 "таких как нужно"
Ты потом заебешься дебажить и выковыривать баги этих 3 просто работающих строчек (без задней мысли). Я уж не говорю про то, как ты заебешься делать лазейки-костыли и обходные пути из-за этих 3 просто работающих строчек.
Когда у тебя четко организованный код, когда написанно ТАК КАК НУЖНО, когда это еще дело покрыто тестами, то если что-то отъебывает, то это дело 5 минут исправить, т.к. сразу знаешь что и где ебануло. Точно также в последующем легко модифицировать что-то, расширить. Или же переиспользовать в следующих проектах.
Когда у тебя проект весь состоит из таких вот тяп-ляп, просто и работает, то ты тратишь неделями время на дебаг, тратишь в 2 раза больше времени на разработку, а в следующем проекте охуеваешь и ломаешь голову, что это вообще такое, в итоге пишешь вообще все с нуля и каждый раз думаешь "а ведь мог бы сразу сделать все изначально нормально".
Все эти срезания углов работают в очень исключительных ситуациях. А общее правило неизменно - кроилово ведет к попадалову.
Нет, потому что серьёзную игру делать в соло будет совсем отчаянный, а простые проекты можно и на тяп-ляп
7 бед - один ответ - try catch & log context state
Что мешает наебнуться 20 строчкам? Или сотне абстракций? Они мало того что наебнутся, так ещё и наебнут того кто в них полезет. Я бы вообще нихуя не боялся кроме точек сосредоточения больших обьемов подвижных данных, особенно если это события или лямбды со всеми вытекающими, которые собираются на всяких шинах.
>когда написанно ТАК КАК НУЖНО, когда это еще дело покрыто тестами
Не работает в соло разработке. "ТАК КАК НУЖНО" даст х3 ко времени разработки. Ты просто никогда не закончишь проект или закончишь когда он уже будет нахуй не нужен. Или просто передумаешь его делать и все "ТАК КАК НУЖНО" улетит в мурор. Или через пару лет такой разработке захочешь что-то сильно поменять и опять все это улетит в мусор.
В соло ты должен быть быстрым. И уметь в планирование проекта - уметь видеть финальной результат еще до завершения проекта. Так ты сделаешь архитектуру, которая не потребует кардинальных переделок и не потратишь время на разработку того, что никогда не понадобится.
Большинство успешных соло проектов написаны через жопу. Хуяк-хуяк и в релиз. Пролет? Следующий проект. Успех? Нанял команду прогеров - пусть переписывают код.
>>6507
Это спор ни о чем, каждый сам выдумал какое-то понятие и вложил какой-то смысл и представляет что его оппонент доказывает противоположное на самом деле.
В целом то что вот тут >>6507 написано это очень важное замечание, что слишком сильная экономия на спичках в плане архитектуры и написания кода часто приводит к тому, что время разработки будет дольше.
Но опять же вопрос в том где же там эта грань проходит и в чем конкретно должна заключаться, и этот вопрос не имеет ответа без какой-то конкретики.
Я лично в своем проекте ебашу всё практически также как на работе, просто потому что так быстрее, у меня итоговая цель сделать как можно быстрее и решения принимаю исходя из этого.