Про рейдерский захват жилья не слышали? Или как в аренду берут квартиру, заселяют туда табор, который потом фиг выселишь? Всё это типичное мошенничество. В данном случае мошенники заезжают в квартиру и притворяются добропорядочными арендодателями, пользуясь недостатками судебной системы.
ИМХО, чаще всего рейтрейссинг дает картинку не лучше, а ДРУГУЮ. Чуть по другому затеняются объекты, чуть по другому переотражается свет. Всё потому, что еще в прошлом десятилетии разработчики научились вкусно готовить графику без всяких рейтрейссингов. Глобальное освещение давно уже запекают, а для красивых отражений существует SSR. Единственное, что рейтрейссинг делает на совершенно ином уровне - это рендеринг растений. Здесь он вне конкуренции - плоское превращается в объемное. При обычном рендеринге сделать очень сложно.
Вы же в курсе, что так всё и работает? Нравится вам повестка или нет - её обсуждают. Чем больше обсуждают, тем больше продукт на слуху. Поэтому всякий продукт, который имеет шансы провалиться в прокате, старается сделать что-то вызывающее и трендовое. И чем больше вы бомбите, тем больше студии будут прибегать к подобным манипуляциям.
А по факту это 4060, но кто купит 4060 за 600-700$? Поэтому назовем её 4070! С 4080 же прокатило... Осталось лишь еще один искусственный дефицит создать и дело в шляпе! STONK!
Круто было бы заскринить дорелизную статку по вишам и прочему, а потом поделиться успехами через месяц после старта продаж. Это поможет другим инди-разработчикам понять, чего ждать в текущем году.
В любом случае, желаю всяческих успехов! Главное помнить, что выход в ранний доступ - это лишь подготовка перед настоящим релизом!
Для начала разберитесь - вам нужно спорить или блок выбирать?
Отвечу на ключевое и за сим откланиваюсь.
Кстати, с чего Вы взяли, что у pm800d и BEQUIET SP 10 разные по качеству компоненты?
Потому что посмотрел оба блока. У одного в тех же фильтрах кондеры Chengx, у другого - Teapo. Разные контроллеры, разные шимы. Разная компоновка. Разные силовые транзисторы. Вопрос в другом - стоит ли всё это переплаты?
PM800D - это совсем бюджетка. BEQUIET SP 10 - имеет компоненты и охлад лучше, но всё равно это также бюджетка. Бюджетка, которая сейчас стоит в полтора раза дороже PM800D и лишь на 500р дешевле PQ850M у которого начинка довольно высокого уровня. Ту же самую начинку берет асус, пихает в неё свои "геймерские" радиаторы и продает как ROG серию за много денех.
Смотреть нужно по начинке, а не по сухим цифрам, но я не согласен с Вами по выбору.
Мой выбор - PQ850M. BEQUIET SP 10 должен стоить 7000-7500р. Он лучше PM800D, но не настолько. Что с этим выбором не так? Вопрос риторический.
Да, не хватает фильтров, да радиаторы не везде. А нужны ли они? Если блок будет работать на номинальном режиме?
В днс есть прекрасные блоки от Xilence. 850 ватт за 5к. Киловаттник за 6к. В них вообще нет ничего лишнего. У них изумительные пульсации и просадки напряжения по всем линиям. Самое то, чтобы подключать его к 4080 за 100 кусков. Есть вещи, на которых стоит экономить в последнюю очередь. БП - это одна из таких вещей. Удачи.
Ха, проблема в том, что нет никакой гарантии, что у более дорогого блока будет все лучше.
Если производитель не занимается тайной подменой компонентов, то обзоры в помощь. Толковый обзор блока - это полная разборка, замер температур, просадок и пульсаций. Если ровнять pm800d и тот же BEQUIET SP 10, то там большая разница в качестве охлаждения и качестве компонентов. Если брать PQ850M - это вообще совершенно другая категория блоков.
Самое забавное, что be quiet имеет меньший диапазон входных напряжений, чем deepcool.
Это всё циферки. В реальности же блок убивают перепады напряжения и работа на больших мощностях, приводящая к высокому нагреву. И чем комплектующие в блоке лучше, тем живучее он будет, вот и вся логика. Что там пишет производитель - это всё маркетинг.
Но ориентироваться на цену по принципу "дороже - лучше" - это тоже неправильно.
И где это было заявлено? Цена вообще нигде не была упомянута. Смотреть нужно только начинку. Ниже два блока. Один pm800d, другой - PQ850M. Разница всего 50 ватт. Оба золотые. Общий бренд. Но в одном места свободного нет - всё в фильтрах, стабилизаторах, с нипоновскими кондерами, держащими 105 градусов и с охладом всего, что только можно. А второй - обычный бюджетник с бюджетной начинкой. 800 ватт он выдаст. Но сколько он на них проработает - вопрос открытый.
Выбирать добротный блок, смотря только на циферки и сертификат - это такое себе. Этот блок дешевый не просто так - у него хуже кондеры, хуже начинка в целом. В условиях сети не лучшего качества, такие блоки долго не живут. Поэтому как он поведет себя на дистанции - большой вопрос. А что он с собой заберет когда сгорит - вопрос еще больше.
Этот дипкул собран не просто на удачной платформе, а на платформе сисоника. Для понимания - все эти дипкулы, корсары и прочие не производят блоки питания. Они перепродают чужие потроха в своей обертке. Обычно блоки данным конторам клепает CWT. Это крепкий середняк. Но конкретно этот блок сделан на базе Seasonic FOCUS Gold. Он имеет очень годную начинку, но в сравнении с оригиналом у него победнее провода и комплектация. По соотношению цена/качество это отличный вариант.
Если мышь берется надолго, то смотри в строну ZOWIE. BenQ не упарываются по задержке в 1 мс на кнопках и поэтому не страдают от дабл-кликов. Главное - форму подобрать правильно. Остальное на рынке - это мыши с продолжительностью жизни строго на гарантийный срок (а многие уже даже и этот срок не живут).
Ниже советовали Logitech 502 Hero - она очень тяжелая. И узкая. И даблкликает уже через год.
А вот из интересного, рейзеры в deathadder v2 обновили свичи. Сделали их оптическими - они неплохи и решают проблему даблкликов. По форме deathadder - это как раз ZOWIE EC, так что можно рассматривать как альтернативу, если нужна именно такая форма. Из минусов - мышь фарфоровая. Чтобы снизить вес, пластик сделали супер-тонким. Ну и лично моей руке этот горб не очень зашел - форма на любителя.
Также стоит глянуть на Razer Viper 8khz. В этой версии исправлены ключевые косяки обычного вайпера (люфтящие и скрипящие кнопки, резинки приклеенные на соплях и пр.). У Viper установлены такие же оптические свичи как на DA2. Профиль у неё поменьше чем у DA, поэтому тоже нужно пробовать на месте.
И внезапно, неплохая мышь есть у A4Tech - это Bloody W90 PRO. Из минусов у неё кроме что вес (где-то 110г) и слабые боковые кнопки (если активно используешь, то развалятся через год). На указанный бюджет можно взять две таких мыши, хватит как раз на пяток лет. По форме она что-то вроде DA, но без горба.
Остальное же - это плюс-минус одно и тоже. И с одними и теми же болячками - дабл-клики и выходящие из строя энкодеры. Потроха у многих современных мышек из одной бочки, поэтому выбирать имеет смысл кроме что форму.
Разъем PCIe x16 дает карте 75 ватт питания. Восьми-пиновый коннектор дает еще 150 ватт. В сумме будет 225 ватт. И это номинал, а не пиковое значение. Даже если блок имеет раздельные линии питания PCIe (что вообще не факт), то этого должно хватать. Хочешь подстраховаться? Зайди в GPU Tweak III и уменьши Power Target до 80-85%. Энергопотребление упадет до 180-200 ватт, температуры понизятся, а производительность уменьшится на 2-5%.
А в обратном случае, что ты ожидаешь получить? Нагрев и оплавление проводов? Там сечение такое, что на них можно полкиловата гонять. От двухсот ватт там нечему греться. Но TDP у карты всё же убавь. Конкретно для этой модели это лишним не будет.
Выживачи в нынешней форме - это гриндилки. Кривая сложности в подобных играх вполне стандартна - в начале ты задохлик, которого с пары тычек убивает любой моб, а под конец ты не убиваемый супер-имбо-терминатор с вагоном ресурсов за спиной.
В более линейных играх кривую сложности строят подобно американским горкам - сложность постепенно нарастает (на горках ты поднимаешься вверх), затем идет небольшая передышка для подготовки (на горках ты уже на самой вершине), далее идет потный босс-файт (ты несешься с горки), а затем идет разгрузка, сбор ресурсов/наград и прочее. Далее цикл повторяется. Здесь игрок постоянно держится в тонусе, поэтому не скучает (если игра сделана хорошо).
В выживачах подобное реализуют редко. Обычно тебя просто выбрасывают в игру, у тебя разбегаются глаза, ты изучаешь механики/технологии, узнаешь особенности боевки, знакомишься с противниками. Всё это сверху посыпают гриндом. И именно из-за подобного старта игра кажется насыщенной, интересной и хардкорной. Из-за недостатка опыта возникает множество уникальных ситуаций, что, собственно, и развлекает игрока.
Но спустя некоторое время в игре ты всё узнаешь, всё изучишь. И если разработчики не стали заморачиваться, а сделали простую песочницу в стиле “развлеки себя сам”, без сюжета, цели и челенджа, то твой интерес закончится ровно тогда, когда ты осознаешь, что кроме однотипного гринда далее в игре ничего не будет.
Именно в этот момент начинаешь видеть игру такой, какая она есть. Станут бросаться в глаза все недостатки игры, а её масштабы, которые поначалу казались огромными, очень быстро сожмутся до вполне себе ограниченных.
В общем, дело не в технологиях и не в развитии, а строго в однообразии и отсутствии нового и интересного. Выживачи поначалу кажутся куда больше, чем они есть на самом деле. От этого и возникает подобный казус, когда в игре вдруг становится абсолютно нечего делать. Ибо гринд завезли и много, а геймплей - как всегда забыли.
Это информация для новичков и обычно к подобному решению приходит каждый, кто решится провести рефакторинг своей писанины. То есть уникальности тут нет никакой. Можете смело брать, повторять и записывать доработанный туториал с уменьшенным количеством костылей.
Этот метод слишком не оптимизирован. Вы понимаете, что попусту отрисовываете сцену второй камерой? К тому же, может возникнуть проблема с тем, что на карте будут отображаться лишние объекты. Причем в реалтайме. Контролировать слои - это будет тот еще геморрой.
Карта в любом случае должна быть совершенно отдельным объектом - это может быть как “запеченная” картинка уровня, так и 3д геометрия. Главный смысл тут в том, что ты рендеришь малозатратный по ресурсам объект, а не уровень целиком.
Алгоритм работы с такой картой не столь интуитивный, как прямая привязка спрайтов к объектам, но в разы более оптимизированный. Сперва-наперво убираем все эти костыли с рендером второй камеры в Raw Image. Далее запекаем/скриним/рисуем карту уровня в большую картинку. Делаем отдельный Canvas под это дело.
Естественно выйдет так, что координаты уровня и канваса у нас не совпадают. Чтобы решить эту проблему, нам нужен простой алгоритм для калибровки карты. Интуитивнее всего его реализовать так - создаем два объекта пустышки внутри координат канваса карты. Назовем их X и Y. Точно такие две пустышки делаем внутри координат игрового мира.
Далее расставляем координаты относительно неких ориентиров, например домов или деревьев. То есть находим дерево на уровне, двигаем к нему пустышку Х, а дальше ищем тоже самое дерево на карте и двигаем к нему уже пустышку Х, которую создавали внутри канваса. Для пустышек Y делаем всё тоже самое, но по другой оси. Чем дальше будут X и Y друг от друга, тем точнее будет калибровка.
Теперь берем позиции пустышек из сцены и сравниваем их с пустышками в канвасе. И из всего этого вычисляем точные коэффициенты в процентном соотношении по двум осям. Умножая на эти коэффициенты, мы сможем перевести координаты объекта из сцены, в соответствующие координаты на карте. На этом самое сложное закончилось.
Добавлять иконки на карту лучше так же через скрипт. Коэффициенты у нас есть. Если объект статичный, то шлем его позицию из сцены в карту, создаем UI объект из префаба и назначаем координаты по коэффициенту. Делать это нужно всего один раз, при старте. Никаких апдейтов. Если маркер нужно удалить, опять же шлем по триггеру инфу в карту и удаляем.
С миникартой дело обстоит ровно также. Но теперь нам нужно отделить и зафиксировать иконку игрока в центре карты, а двигать мы будем сам канвас миникарты, внутри которого будут все иконки со статичными объектами. Опять всё с коэффициентами и бла-бла-бла. Причем не обязательно использовать метод Update(). Лучше всего вообще сделать лок на обновление миникарты в 25-30 кадров - разницы никто не заметит, а нагрузка на железо будет меньше.
Главное текст в массивах инициализировать в коде, а не писать ручками в редакторе юнити. Иначе получается тот же ад с редактированием полей по одной штучке.
Вопрос не в идеальности, а именно в грубой ошибке. И лучше её дальше не распространять. Поправить дело можно, если изучите уже проверенные способы работы с текстом и запишите ролик как именно нужно реализовывать локализацию. Просто, правильно и без пустой траты ресурсов по принципу "Но зато работает!"
1. Обращение к UI элементам (Text, Image и т.д. ) - это довольно затратный метод. Менять кучу текстовых объектов в апдейте просто ради смены языка - это бессмысленная трата ресурсов. Сотня-другая таких объектов и одна только смена языка будет отжирать 25-50% производительности.
Решений тут два: первое и самое простое - вызывать проверку языка только один раз при старте сцены. При смене языка сцену нужно будет перезапустить.
Второй вариант - подписать метод смены языка на определенное событие через корутины. Проверка смены языка будет вызываться лишь один раз, при нажатии на определенную кнопку. Смысла в этом особого нету - лишний код ради функции, которую игрок за всю игру активирует единожды.
Поэтому оптимально будет сделать данный функционал только в главном меню. Если так уж нужна смена языка "на горячую" и без перезапуска, то лучше привязать элементы главного меню именно к нажатию кнопки, но никак не плодить кучу Update() там, где это не нужно.
2. Сам метод работы с локализацией удобоварим, если у тебя текста на пару десятков объектов. В ином случае, ты замучаешься работать с таким объемом окошек и объектов. Лучший метод для работы с текстом - вешать в скрипт объекта только его ID. В объекте должен быть только персональный ключ и всё. А весь остальной функционал нужно вызывать из некого синглтона, в котором и находятся все методы для работы с текстом.
То есть, ровно так же, как ты создал статическую переменную со значением текущего языка, ты создаешь целый статический класс, с методами и текстовыми массивами. В эти методы и обращается твой текстовый объект при старте. Он отсылает свой ID и получает по нему текст, который к себе применит.
Это обязательно нужно делать, потому что текстовых файлов у тебя может быть тысячи и при смене методов работы с локализацией, тебе нужно будет перенастроить их ВСЕ. Поэтому их функционал не должен содержать никаких уникальных данных, кроме одного - ключа, ID, который определяет, что именно это за слово или текст. А вот синглтон у тебя один. И менять его ты можешь как и сколько хочешь, без ущерба для своих объектов.
3. Сами текстовые данные лучше хранить в отдельном текстовом файле. Какая там будет верстка и формат - вопрос открытый. Кому-то гугл-таблицы нравятся, а кому-то html-формат - самое оно. Но это актуально, если у тебя объем текста выше 30 слов и далеко не пара языков на выбор.
Пока что это видео про то, как делать нельзя ни в коем случае.
Юмор в том, что были барабаны в игре. Но я убрал их, чтобы повысить динамику боя. Мотивов точно уже не помню, но в реальности барабаны работали не так как в WoT. По сути, это был автомат заряжания на 12 снарядов. Когда снаряды заканчивались, экипажу нужно было сматывать удочки и прятаться на перезарядку. Причем перезаряжать "барабаны" нужно было вручную, через крышу башни танка.
Мб сделаю еще попытку запихать эту механику.
Ещё я бы поработал над текстом. Непонятно куда идёт упор.
Сюжет уже полностью перерабатывается Будут вот такие вставки:
Помню другой топдаун шутер - Hybrid Wars, там все просто и неинтересно
Я постоянно держу этот проект на карандаше с пометкой "как делать не надо".
Там ровно те же референсы, но реализация совершенна другая. Больше аркадности, больше насыщенности, больше всего. И в итоге оно просто не работает. Мне всё же кажется, что магия Desert Strike была именно в том, что внутри аркады были реализованы реалистичные механики.
пулемёту/автопушке прикрутить параметр бронепробития, некоторые БМП слишком лёгкие, чтоб тратить снаряд на них.
Там вроде достаточно было, чтобы пробивать мелочевку. Но перепроверю. Остальное запишу в todo-лист. Огромное спасибо за отзыв!
Если статья рассчитана на новичков, откуда они могут знать как работает большая корпорация? Крупные компании - это множество отделов с разной специализацией, которые внутри себя нередко делятся еще на отделы. Чтобы просто повторить их пайплайн, нужно обладать множественным расстройством личности, как минимум.
2) Используйте Git
Опять же, многие начинающие игроделы даже кодить не умеют и используют визуальное программирование. Контроль версий для них - это дело не первоочередной важности.
3) Не делайте графику параллельно с геймплеем
Это почему? Если человек - профильный художник, то графику он будет делать как раз параллельно с геймплеем. Причем это вполне эффективный метод, ведь время от времени меняя сферу деятельности, ты не так сильно утомляешься от рутины.
4) Начните с чего-то небольшого и доведите до конца
Человек должен начинать с того, что ему нравится. Если он делает нудную ерунду, то он её бросит, даже если она будет “небольшой”. Вернее тут будет сказать - “трезво оценивайте свои силы”. Но загвоздка в том, что оценивать свои силы учишься только с опытом. А пока нет опыта - лепи что хочешь, только в стим не спеши выкладывать.
5) Старайтесь не давить на тиммейтовПервый проект лучше всего начинать делать самому. Только в процессе разработки поймешь где не справляешься и чья помощь тебе нужна. А еще научишься ценить чужой труд и время, тогда и подобных проблем с давлением возникать не будет.
6) Не думайте об игроках, метриках и тд - думайте о себе. Важно, чтобы интересно было вам
За здоровьем еще следить не забывайте. Физкультурка и хорошее питание - вещь обычная, но очень полезная и необходимая в долгосрочной перспективе.
7) Показывайте прогрессПоказывайте тогда, когда есть что показать. Если вы новичок, то лучше поначалу не лезть в паблики, а брать советы у художников-погромистов-девелоперов на тематических ресурсах. На ранних этапах вам полезнее будет получить опыт и советы, а не одобрение и признание.
8) Придумайте простой и понятный синопсис. Без подробностей и ограниченийРазработка игр - коварная вещь. Только при реализации идеи становится ясно работает она или нет. Вполне может оказаться, что вашей идеи хватает на 10 минут геймплея и всё. Увы, таков этот мир.
9) Гоните перфекционизм прочь
Перфекционизм - годная вещь, не нужно его гнать. Но держать в узде следует. Опять же, с опытом приходит понимание лимита своих возможностей. В попытке сделать что-то идеально нет ничего плохого, просто нужно научиться ставить себе ограничения в этом вопросе.
10) Старайтесь не бросать. Выделите время каждый день чтобы двигать разработку понемногу вперед
Смотря что делаете. Если проект был строго обучающий и вы получили от него весь нужный вам опыт, то смысла за него цепляться нет. Если же вы изначально делаете что-то перспективное, то да - зачем было начинать, если будете бросать? А если бросаете, то уверены, что так будет лучше? Если да, то да.
Про рейдерский захват жилья не слышали? Или как в аренду берут квартиру, заселяют туда табор, который потом фиг выселишь? Всё это типичное мошенничество. В данном случае мошенники заезжают в квартиру и притворяются добропорядочными арендодателями, пользуясь недостатками судебной системы.
Это лишь затравка. Весь сок дальше. Не буду спойлерить.
Копай глубже, там такие удивительные вещи написаны, что диву даешься
Конечно бояре. 200к в комп вложишь, а это всего-лишь "средне-бюджетная сборка для 2к гейминга".
ИМХО, чаще всего рейтрейссинг дает картинку не лучше, а ДРУГУЮ. Чуть по другому затеняются объекты, чуть по другому переотражается свет. Всё потому, что еще в прошлом десятилетии разработчики научились вкусно готовить графику без всяких рейтрейссингов. Глобальное освещение давно уже запекают, а для красивых отражений существует SSR. Единственное, что рейтрейссинг делает на совершенно ином уровне - это рендеринг растений. Здесь он вне конкуренции - плоское превращается в объемное. При обычном рендеринге сделать очень сложно.
Вы же в курсе, что так всё и работает? Нравится вам повестка или нет - её обсуждают. Чем больше обсуждают, тем больше продукт на слуху. Поэтому всякий продукт, который имеет шансы провалиться в прокате, старается сделать что-то вызывающее и трендовое. И чем больше вы бомбите, тем больше студии будут прибегать к подобным манипуляциям.
Осанку бы поправить персонажу. Текущая поза - жуть какая неестественная.
А по факту это 4060, но кто купит 4060 за 600-700$? Поэтому назовем её 4070! С 4080 же прокатило... Осталось лишь еще один искусственный дефицит создать и дело в шляпе! STONK!
Круто было бы заскринить дорелизную статку по вишам и прочему, а потом поделиться успехами через месяц после старта продаж. Это поможет другим инди-разработчикам понять, чего ждать в текущем году.
В любом случае, желаю всяческих успехов! Главное помнить, что выход в ранний доступ - это лишь подготовка перед настоящим релизом!
Для начала разберитесь - вам нужно спорить или блок выбирать?
Отвечу на ключевое и за сим откланиваюсь.
Кстати, с чего Вы взяли, что у pm800d и BEQUIET SP 10 разные по качеству компоненты?
Потому что посмотрел оба блока. У одного в тех же фильтрах кондеры Chengx, у другого - Teapo. Разные контроллеры, разные шимы. Разная компоновка. Разные силовые транзисторы. Вопрос в другом - стоит ли всё это переплаты?
PM800D - это совсем бюджетка. BEQUIET SP 10 - имеет компоненты и охлад лучше, но всё равно это также бюджетка. Бюджетка, которая сейчас стоит в полтора раза дороже PM800D и лишь на 500р дешевле PQ850M у которого начинка довольно высокого уровня. Ту же самую начинку берет асус, пихает в неё свои "геймерские" радиаторы и продает как ROG серию за много денех.
Смотреть нужно по начинке, а не по сухим цифрам, но я не согласен с Вами по выбору.
Мой выбор - PQ850M.
BEQUIET SP 10 должен стоить 7000-7500р. Он лучше PM800D, но не настолько. Что с этим выбором не так? Вопрос риторический.
Да, не хватает фильтров, да радиаторы не везде. А нужны ли они? Если блок будет работать на номинальном режиме?
В днс есть прекрасные блоки от Xilence. 850 ватт за 5к. Киловаттник за 6к. В них вообще нет ничего лишнего. У них изумительные пульсации и просадки напряжения по всем линиям. Самое то, чтобы подключать его к 4080 за 100 кусков. Есть вещи, на которых стоит экономить в последнюю очередь. БП - это одна из таких вещей. Удачи.
Ха, проблема в том, что нет никакой гарантии, что у более дорогого блока будет все лучше.
Если производитель не занимается тайной подменой компонентов, то обзоры в помощь. Толковый обзор блока - это полная разборка, замер температур, просадок и пульсаций. Если ровнять pm800d и тот же BEQUIET SP 10, то там большая разница в качестве охлаждения и качестве компонентов. Если брать PQ850M - это вообще совершенно другая категория блоков.
Самое забавное, что be quiet имеет меньший диапазон входных напряжений, чем deepcool.
Это всё циферки. В реальности же блок убивают перепады напряжения и работа на больших мощностях, приводящая к высокому нагреву. И чем комплектующие в блоке лучше, тем живучее он будет, вот и вся логика. Что там пишет производитель - это всё маркетинг.
Но ориентироваться на цену по принципу "дороже - лучше" - это тоже неправильно.
И где это было заявлено? Цена вообще нигде не была упомянута. Смотреть нужно только начинку. Ниже два блока. Один pm800d, другой - PQ850M. Разница всего 50 ватт. Оба золотые. Общий бренд. Но в одном места свободного нет - всё в фильтрах, стабилизаторах, с нипоновскими кондерами, держащими 105 градусов и с охладом всего, что только можно. А второй - обычный бюджетник с бюджетной начинкой. 800 ватт он выдаст. Но сколько он на них проработает - вопрос открытый.
дабл-пост
Выбирать добротный блок, смотря только на циферки и сертификат - это такое себе. Этот блок дешевый не просто так - у него хуже кондеры, хуже начинка в целом. В условиях сети не лучшего качества, такие блоки долго не живут. Поэтому как он поведет себя на дистанции - большой вопрос. А что он с собой заберет когда сгорит - вопрос еще больше.
Этот дипкул собран не просто на удачной платформе, а на платформе сисоника. Для понимания - все эти дипкулы, корсары и прочие не производят блоки питания. Они перепродают чужие потроха в своей обертке. Обычно блоки данным конторам клепает CWT. Это крепкий середняк. Но конкретно этот блок сделан на базе Seasonic FOCUS Gold. Он имеет очень годную начинку, но в сравнении с оригиналом у него победнее провода и комплектация. По соотношению цена/качество это отличный вариант.
Если мышь берется надолго, то смотри в строну ZOWIE. BenQ не упарываются по задержке в 1 мс на кнопках и поэтому не страдают от дабл-кликов. Главное - форму подобрать правильно. Остальное на рынке - это мыши с продолжительностью жизни строго на гарантийный срок (а многие уже даже и этот срок не живут).
Ниже советовали Logitech 502 Hero - она очень тяжелая. И узкая. И даблкликает уже через год.
А вот из интересного, рейзеры в deathadder v2 обновили свичи. Сделали их оптическими - они неплохи и решают проблему даблкликов. По форме deathadder - это как раз ZOWIE EC, так что можно рассматривать как альтернативу, если нужна именно такая форма. Из минусов - мышь фарфоровая. Чтобы снизить вес, пластик сделали супер-тонким. Ну и лично моей руке этот горб не очень зашел - форма на любителя.
Также стоит глянуть на Razer Viper 8khz. В этой версии исправлены ключевые косяки обычного вайпера (люфтящие и скрипящие кнопки, резинки приклеенные на соплях и пр.). У Viper установлены такие же оптические свичи как на DA2. Профиль у неё поменьше чем у DA, поэтому тоже нужно пробовать на месте.
И внезапно, неплохая мышь есть у A4Tech - это Bloody W90 PRO. Из минусов у неё кроме что вес (где-то 110г) и слабые боковые кнопки (если активно используешь, то развалятся через год). На указанный бюджет можно взять две таких мыши, хватит как раз на пяток лет. По форме она что-то вроде DA, но без горба.
Остальное же - это плюс-минус одно и тоже. И с одними и теми же болячками - дабл-клики и выходящие из строя энкодеры. Потроха у многих современных мышек из одной бочки, поэтому выбирать имеет смысл кроме что форму.
Разъем PCIe x16 дает карте 75 ватт питания. Восьми-пиновый коннектор дает еще 150 ватт. В сумме будет 225 ватт. И это номинал, а не пиковое значение. Даже если блок имеет раздельные линии питания PCIe (что вообще не факт), то этого должно хватать. Хочешь подстраховаться? Зайди в GPU Tweak III и уменьши Power Target до 80-85%. Энергопотребление упадет до 180-200 ватт, температуры понизятся, а производительность уменьшится на 2-5%.
А в обратном случае, что ты ожидаешь получить? Нагрев и оплавление проводов? Там сечение такое, что на них можно полкиловата гонять. От двухсот ватт там нечему греться. Но TDP у карты всё же убавь. Конкретно для этой модели это лишним не будет.
Выживачи в нынешней форме - это гриндилки. Кривая сложности в подобных играх вполне стандартна - в начале ты задохлик, которого с пары тычек убивает любой моб, а под конец ты не убиваемый супер-имбо-терминатор с вагоном ресурсов за спиной.
В более линейных играх кривую сложности строят подобно американским горкам - сложность постепенно нарастает (на горках ты поднимаешься вверх), затем идет небольшая передышка для подготовки (на горках ты уже на самой вершине), далее идет потный босс-файт (ты несешься с горки), а затем идет разгрузка, сбор ресурсов/наград и прочее. Далее цикл повторяется. Здесь игрок постоянно держится в тонусе, поэтому не скучает (если игра сделана хорошо).
В выживачах подобное реализуют редко. Обычно тебя просто выбрасывают в игру, у тебя разбегаются глаза, ты изучаешь механики/технологии, узнаешь особенности боевки, знакомишься с противниками. Всё это сверху посыпают гриндом. И именно из-за подобного старта игра кажется насыщенной, интересной и хардкорной. Из-за недостатка опыта возникает множество уникальных ситуаций, что, собственно, и развлекает игрока.
Но спустя некоторое время в игре ты всё узнаешь, всё изучишь. И если разработчики не стали заморачиваться, а сделали простую песочницу в стиле “развлеки себя сам”, без сюжета, цели и челенджа, то твой интерес закончится ровно тогда, когда ты осознаешь, что кроме однотипного гринда далее в игре ничего не будет.
Именно в этот момент начинаешь видеть игру такой, какая она есть. Станут бросаться в глаза все недостатки игры, а её масштабы, которые поначалу казались огромными, очень быстро сожмутся до вполне себе ограниченных.
В общем, дело не в технологиях и не в развитии, а строго в однообразии и отсутствии нового и интересного. Выживачи поначалу кажутся куда больше, чем они есть на самом деле. От этого и возникает подобный казус, когда в игре вдруг становится абсолютно нечего делать. Ибо гринд завезли и много, а геймплей - как всегда забыли.
Это информация для новичков и обычно к подобному решению приходит каждый, кто решится провести рефакторинг своей писанины. То есть уникальности тут нет никакой. Можете смело брать, повторять и записывать доработанный туториал с уменьшенным количеством костылей.
Этот метод слишком не оптимизирован. Вы понимаете, что попусту отрисовываете сцену второй камерой? К тому же, может возникнуть проблема с тем, что на карте будут отображаться лишние объекты. Причем в реалтайме. Контролировать слои - это будет тот еще геморрой.
Карта в любом случае должна быть совершенно отдельным объектом - это может быть как “запеченная” картинка уровня, так и 3д геометрия. Главный смысл тут в том, что ты рендеришь малозатратный по ресурсам объект, а не уровень целиком.
Алгоритм работы с такой картой не столь интуитивный, как прямая привязка спрайтов к объектам, но в разы более оптимизированный. Сперва-наперво убираем все эти костыли с рендером второй камеры в Raw Image. Далее запекаем/скриним/рисуем карту уровня в большую картинку. Делаем отдельный Canvas под это дело.
Естественно выйдет так, что координаты уровня и канваса у нас не совпадают. Чтобы решить эту проблему, нам нужен простой алгоритм для калибровки карты. Интуитивнее всего его реализовать так - создаем два объекта пустышки внутри координат канваса карты. Назовем их X и Y. Точно такие две пустышки делаем внутри координат игрового мира.
Далее расставляем координаты относительно неких ориентиров, например домов или деревьев. То есть находим дерево на уровне, двигаем к нему пустышку Х, а дальше ищем тоже самое дерево на карте и двигаем к нему уже пустышку Х, которую создавали внутри канваса. Для пустышек Y делаем всё тоже самое, но по другой оси. Чем дальше будут X и Y друг от друга, тем точнее будет калибровка.
Теперь берем позиции пустышек из сцены и сравниваем их с пустышками в канвасе. И из всего этого вычисляем точные коэффициенты в процентном соотношении по двум осям. Умножая на эти коэффициенты, мы сможем перевести координаты объекта из сцены, в соответствующие координаты на карте. На этом самое сложное закончилось.
Добавлять иконки на карту лучше так же через скрипт. Коэффициенты у нас есть. Если объект статичный, то шлем его позицию из сцены в карту, создаем UI объект из префаба и назначаем координаты по коэффициенту. Делать это нужно всего один раз, при старте. Никаких апдейтов. Если маркер нужно удалить, опять же шлем по триггеру инфу в карту и удаляем.
С миникартой дело обстоит ровно также. Но теперь нам нужно отделить и зафиксировать иконку игрока в центре карты, а двигать мы будем сам канвас миникарты, внутри которого будут все иконки со статичными объектами. Опять всё с коэффициентами и бла-бла-бла. Причем не обязательно использовать метод Update(). Лучше всего вообще сделать лок на обновление миникарты в 25-30 кадров - разницы никто не заметит, а нагрузка на железо будет меньше.
Главное текст в массивах инициализировать в коде, а не писать ручками в редакторе юнити. Иначе получается тот же ад с редактированием полей по одной штучке.
Вопрос не в идеальности, а именно в грубой ошибке. И лучше её дальше не распространять.
Поправить дело можно, если изучите уже проверенные способы работы с текстом и запишите ролик как именно нужно реализовывать локализацию. Просто, правильно и без пустой траты ресурсов по принципу "Но зато работает!"
1. Обращение к UI элементам (Text, Image и т.д. ) - это довольно затратный метод. Менять кучу текстовых объектов в апдейте просто ради смены языка - это бессмысленная трата ресурсов. Сотня-другая таких объектов и одна только смена языка будет отжирать 25-50% производительности.
Решений тут два: первое и самое простое - вызывать проверку языка только один раз при старте сцены. При смене языка сцену нужно будет перезапустить.
Второй вариант - подписать метод смены языка на определенное событие через корутины. Проверка смены языка будет вызываться лишь один раз, при нажатии на определенную кнопку. Смысла в этом особого нету - лишний код ради функции, которую игрок за всю игру активирует единожды.
Поэтому оптимально будет сделать данный функционал только в главном меню. Если так уж нужна смена языка "на горячую" и без перезапуска, то лучше привязать элементы главного меню именно к нажатию кнопки, но никак не плодить кучу Update() там, где это не нужно.
2. Сам метод работы с локализацией удобоварим, если у тебя текста на пару десятков объектов. В ином случае, ты замучаешься работать с таким объемом окошек и объектов. Лучший метод для работы с текстом - вешать в скрипт объекта только его ID. В объекте должен быть только персональный ключ и всё. А весь остальной функционал нужно вызывать из некого синглтона, в котором и находятся все методы для работы с текстом.
То есть, ровно так же, как ты создал статическую переменную со значением текущего языка, ты создаешь целый статический класс, с методами и текстовыми массивами. В эти методы и обращается твой текстовый объект при старте. Он отсылает свой ID и получает по нему текст, который к себе применит.
Это обязательно нужно делать, потому что текстовых файлов у тебя может быть тысячи и при смене методов работы с локализацией, тебе нужно будет перенастроить их ВСЕ. Поэтому их функционал не должен содержать никаких уникальных данных, кроме одного - ключа, ID, который определяет, что именно это за слово или текст. А вот синглтон у тебя один. И менять его ты можешь как и сколько хочешь, без ущерба для своих объектов.
3. Сами текстовые данные лучше хранить в отдельном текстовом файле. Какая там будет верстка и формат - вопрос открытый. Кому-то гугл-таблицы нравятся, а кому-то html-формат - самое оно. Но это актуально, если у тебя объем текста выше 30 слов и далеко не пара языков на выбор.
Пока что это видео про то, как делать нельзя ни в коем случае.
Концептуально!
А байкалы разве не TSMC выпускает?
Большое спасибо за отзыв.
На счёт барабана на 1390 дельный совет.
Юмор в том, что были барабаны в игре. Но я убрал их, чтобы повысить динамику боя. Мотивов точно уже не помню, но в реальности барабаны работали не так как в WoT.
По сути, это был автомат заряжания на 12 снарядов. Когда снаряды заканчивались, экипажу нужно было сматывать удочки и прятаться на перезарядку. Причем перезаряжать "барабаны" нужно было вручную, через крышу башни танка.
Мб сделаю еще попытку запихать эту механику.
Ещё я бы поработал над текстом. Непонятно куда идёт упор.
Сюжет уже полностью перерабатывается Будут вот такие вставки:
Помню другой топдаун шутер - Hybrid Wars, там все просто и неинтересно
Я постоянно держу этот проект на карандаше с пометкой "как делать не надо".
Там ровно те же референсы, но реализация совершенна другая. Больше аркадности, больше насыщенности, больше всего. И в итоге оно просто не работает. Мне всё же кажется, что магия Desert Strike была именно в том, что внутри аркады были реализованы реалистичные механики.
пулемёту/автопушке прикрутить параметр бронепробития, некоторые БМП слишком лёгкие, чтоб тратить снаряд на них.
Там вроде достаточно было, чтобы пробивать мелочевку. Но перепроверю.
Остальное запишу в todo-лист. Огромное спасибо за отзыв!
Увы, пока руки не дошли. Там нужно будет прикручивать какую-нибудь удобную механику прицеливания.
о нет! зачем вы напомнили? я только избавился от этого навязчивого мотива в голове!
Обязательно проследим.
О да! Моя любимая рубрика с советами!
1) Не пытайтесь работать как большие корпорации
Если статья рассчитана на новичков, откуда они могут знать как работает большая корпорация? Крупные компании - это множество отделов с разной специализацией, которые внутри себя нередко делятся еще на отделы. Чтобы просто повторить их пайплайн, нужно обладать множественным расстройством личности, как минимум.
2) Используйте Git
Опять же, многие начинающие игроделы даже кодить не умеют и используют визуальное программирование. Контроль версий для них - это дело не первоочередной важности.
3) Не делайте графику параллельно с геймплеем
Это почему? Если человек - профильный художник, то графику он будет делать как раз параллельно с геймплеем. Причем это вполне эффективный метод, ведь время от времени меняя сферу деятельности, ты не так сильно утомляешься от рутины.
4) Начните с чего-то небольшого и доведите до конца
Человек должен начинать с того, что ему нравится. Если он делает нудную ерунду, то он её бросит, даже если она будет “небольшой”. Вернее тут будет сказать - “трезво оценивайте свои силы”. Но загвоздка в том, что оценивать свои силы учишься только с опытом. А пока нет опыта - лепи что хочешь, только в стим не спеши выкладывать.
5) Старайтесь не давить на тиммейтовПервый проект лучше всего начинать делать самому. Только в процессе разработки поймешь где не справляешься и чья помощь тебе нужна. А еще научишься ценить чужой труд и время, тогда и подобных проблем с давлением возникать не будет.
6) Не думайте об игроках, метриках и тд - думайте о себе. Важно, чтобы интересно было вам
За здоровьем еще следить не забывайте. Физкультурка и хорошее питание - вещь обычная, но очень полезная и необходимая в долгосрочной перспективе.
7) Показывайте прогрессПоказывайте тогда, когда есть что показать. Если вы новичок, то лучше поначалу не лезть в паблики, а брать советы у художников-погромистов-девелоперов на тематических ресурсах. На ранних этапах вам полезнее будет получить опыт и советы, а не одобрение и признание.
8) Придумайте простой и понятный синопсис. Без подробностей и ограниченийРазработка игр - коварная вещь. Только при реализации идеи становится ясно работает она или нет. Вполне может оказаться, что вашей идеи хватает на 10 минут геймплея и всё. Увы, таков этот мир.
9) Гоните перфекционизм прочь
Перфекционизм - годная вещь, не нужно его гнать. Но держать в узде следует. Опять же, с опытом приходит понимание лимита своих возможностей. В попытке сделать что-то идеально нет ничего плохого, просто нужно научиться ставить себе ограничения в этом вопросе.
10) Старайтесь не бросать. Выделите время каждый день чтобы двигать разработку понемногу вперед
Смотря что делаете. Если проект был строго обучающий и вы получили от него весь нужный вам опыт, то смысла за него цепляться нет. Если же вы изначально делаете что-то перспективное, то да - зачем было начинать, если будете бросать? А если бросаете, то уверены, что так будет лучше? Если да, то да.