Если бы меня с год назад попросили поговорить о религии - я бы привел с сотню логических ошибок, реальные данные истории, и в целом бы просто испетушился бы доказывая свою позицию. Но что-то со временем радикализм притупился. Однако есть вещи, которые мне все так же не нравятся - замечу, я ничего не доказываю, просто говорю по факту о минусах в быту.
Бесит меня не столько какой-то там бизнес, массовый обман и прочая хрень - меня реально напрягает, что люди врут себе сами, не пытаясь честно отвечать на вопросы, выстраивая ошибочные суждения и не пытаясь их опровергнуть. Короче меня бесят не сами религии, а порождаемое ими невежество.
Второе что напрягает - это то что верующие лезут со всей этой хренью к остальным. Тобиш это даже с родительского дома, все эти - "носи крестик", "отче наш не забудь", "соблюдай пост" и прочая мишура, которой лично у меня в детстве было полно.
Третье - люди забивают свою жизнь всем этим мусором. Не хочу показаться грубым, но насколько я вижу - искренне верующие фанатики выглядят в своих убеждениях так, что по ним психушка плачет. Когда я лежал в отделении неврологии с травмой позвоночника, там было очень много верующих к которым приходили попы со свечками, они молились, читали евангелие и один даже дал мне почитать "откровение". Мне было скучно лежать в палате, все что приносила читать девушка я уже прочел, ну и наверное потому я согласился. Но выглядит это все просто ужасно. Одна мамаша там лежала в женском отделении, так она дочери вообще проходу не давала со своими взглядами.
Короче фу таким быть. В основном люди верующие которых я встречал были малообразованными людьми, вот и писали они так же не грамотно, как пост ровно надо мной.
Надеюсь в блогах не банят за обсуждение таких тем.
ZLOI_DED, эти тонкости нужно знать и для общения с Unity, если вы делаете проект на должном уровне, а не открыли движок побаловаться. И для них не обязательно писать свой движок или что-то подобное. Достаточно ознакомиться с основными принципами технологии. И отсутствие/присутствие этих знаний никак с самим движком не связано.
Вообще в целом странный подход. Вот вы когда пишете шейдеры, вам же не кричат "сначала вручную построй весь графический конвейер, иначе не поймешь что такое шейдеры". Когда пишете код, вам не кричат "сначала напишите свою программную среду и свой язык, чтобы понимать как они работают". Вы это прекрасно понимаете, просто ознакомившись с каким-то базисом по этому вопросу.
Очень жаль что вы кроме кнопочек в Unity ничего не увидели.
Пруф на то что я должен учить. Хотелось бы лицезреть какие знания в геймдеве я могу получить только на выдуманном вами "низком уровне". То есть как я понимаю "знания которые я не пойму, не зная языков низкого уровня и не конструируя движок с нуля". Именно не пойму.
Пруф на майнкрафт в котором по сути десятки моментов по оптимизации, которые по вашим словам можно сделать в 2 клика. Кстати если бы это было возможно - я считаю это был бы дикий плюс.
Пока вы пишите свой движок с нуля на каждый типичный гейм - ваши конкуренты уже уйдут на пенсию.
И уж если на то пошло и знания таковые действительно будут, и своими внушительными комментариями аля "долой Юньку, я считаю она для школьников и потому фу на ней писать" - почему бы вам не поделиться полезной информацией с сообществом в виде статей по gamedev'у? Я думаю вам все будут признательны, если это будет что-то отличное от комментария с вашим пустым негодованием. Опишите те знания "низкого уровня", лично я бы с удовольствием почитал что-то из того что еще не знаю. А покуда нет - ваши слова будут равны ценности моего диплома (про него мне тоже что-то втирали аля вот надо его и всё тут).
майнкрафт в два клика вы не сделаете, хоть что вы юзайте.
нет ни одной причины, по которой пользуясь Unity вы не сможете узнавать как движки вообще устроены.
Более того, скачайте .NET Reflector и смотрите как "внутри" выглядят библиотеки Unity.
Сабж, кстати, не бывает на "низком уровне". Все что вы смогли бы тут перечислить - не потребует знания "низких уровней", а потребует просто знаний, без этого постфикса.
Цифры не с потолка, реальный тест который был проведен в недалеком 2010 году. Может с тех пор что-то и поменялось, но на заметку - как знаю
До Unity я писал на других движках (и даже покупал лицензии!)
Вкратце, почему Unity:
Развитая документация
Кроссплатформенность
Код
Не сильно высокая разница по производительности с нативным кодом.
Особо тяжелые места можно заекстернить с плюсов.
Из авторитетных источников мне известно что в сравнении с тем же UDK - код в 20 раз быстрее (UDK в 30 раз медленней нативного кода).
Я лишен необходимости постоянной работы с техническими проблемами - в коде игры есть игровая логика и только игровая логика и это явный плюс.
При том первое обращение к скриптам - компилирует их в натив. Проблемы с кодом нет.
Есть расширяемый язык boo, который упрощает ввод некоторого специфичного кода, такого как протоколы.
Редактор - имеется возможность дописывать свои возможности к функционалу движка
Большое комьюнити
Мне ничто не мешает использовать не нативную сетевую, а чью-либо иную реализацию, или даже свою
Программирование на лету. Мне не надо запускать компилятор из cmd и писать с нуля хранение инфы на уровне
Внятные условия лицензии
Кстати за участие в развитии движка, где юнитехи диктуют правила, аля перевод документации на ваш язык, вам могут эту лицензию просто "дать" за то что вы переводите. Так что ее реально получить даже без денег.
Они громоздкие и плохорасширяемые
Это просто не соответствует действительности. В юнити я могу отключить лишний функционал, например физику, если я собираюсь задействовать свое octree-дерево, и стандартное мне не нужно. И как уже написал - бесконечные модули, которыми можно расширить движок.
Дико напрягают темы, аля "Я пишу на С++ и Java, а ты пишешь на C#, значит ты УГ". УГ имхо то что многие без причин остаются консерваторами и циниками в отношении нового. C# кстати по функционалу и удобству НАМНОГО лучше чем Java. Есть пара моментов, аля "оператора break", но это настолько редкая фича что я бы ей не гордился. Вообще у людей сформировались стереотипы, аля "сложнее делать = лучше". Ну и сидите, тогда на своем ассемблере и напишите игру, в которую будут играть. Но ведь вы не будете этого делать, это же самоубийственно.
При том всегда находится с десяток кретинов, которые кричат "НОВЫЙ %NEWLANGUAGE% ГАВНО!!11, МЕДЛЕННЕЙ И ХУЖЕ ОСТАНЬТЕСЬ В %OLDLANGUAGE%".
Так кричали про C, про C++, сейчас кричат про C#. Но вот скажите, где бы были ЯП, в каком месте, если бы вас кто-то слушал?
Про игровые движки тоже самое, стереотип "низкий порог вхождения == лучше". В то время как не видно ни одной реальной причины почему это так, по той простой причине что "низкий порог вхождения != расширяемость/скорость".
И самое важное - никому не нужен лишний геморрой за какой-то мифический 1% выгоды. В итоговом приложении вы не будете иметь никакой разницы в том, на каком движке она написана. Пользователям на это просто наплевать. Так что будет лучше - написать быстро и с удобством, или медленно, без удобства, зато с кодом, который быстрее на какие-то 30%? Еще раз повторю - 30%. На операцию которая выполняется в Unity 8мкс, пользователю на вашем собственном движке на C++ будет 6мкс. Ну он прямо разницу почувствует, оценит.
Зайдите на Asset Store и введите Voxel. Вы будете удивлены, но на юнити его юзают и вполне успешно. Правда не для моделей в целом, а например для построения ландов.
Андреич, противостояние глупо - пока ты противостоишь, кто-то посидит и научится nazo_seven, Construct 2 это не движок, это конструктор игр ZLOI_DED развел тему на пустом месте = самоутверждается
Сделали хорошую фичу? => Она тебя не касается? => Просто не пиши ничего
Molecyla, разницы в произношении особо нет, все же понимают о чем речь.
Все эти придирки аля ява/жава/джава, хтмл/аштиэмль, пхп/пиашпи, хгм/эксгээм - до жути глупо. Вреда они несут только в лице возмущающихся.
я бтв говорю вообще самым неправильным образом - КСЭ гэ эм. Откуда КСЭ - хрен знает, просто так легче произносить.
Не слышал только варианта "Экс Джи Эм", но по любому кто-то так говорит, как бы уж если до правил в чтении докапываться - сам должен произносить так
RSQR, что ты имеешь ввиду под кастомными гуискинами и растяжением? Думаю я мог бы объяснить.
Ты наверное имел ввиду кастомные гуистили в гуискине.
Если ты про растяжение текстуры фона то там все очень просто - они растягиваются по дефолту.
Есть параметр border который отвечает сколько пикселей нужно отобразить в нормальном размере с каждой стороны. А все что остается как и прежде растянется.
alexprey, может. Но жажда начать работать, а не сидеть 10 и 11 класс + доп года универа перевешивали и я не пошел в вуз. Тем более, как и оказалось - диплом в нашей области просто кусок картона.
alexprey, хорошие лабы, хорошие преподователи. Я когда учился нам даже про указатели, макросы, классы ничего рассказывать не хотели, а уж тем более ассемблер. А ведь просил - учите нас. Но они сами ничего этого не знали, просто место пригрели. Такая вот суровая история челябинского обучения. Правда не в вузе, но к реальной профессии нас абсолютно по нулям подготовили.
Поднятие оценки по количеству не есть хорошо. Можно закончить один, но большой проект, а можно закончить 10, но маленьких.
Немного смущает смешанность понятия "статья" и в целом "запись" (новость в блоге/проекте/дневнике, мб обычная копипаста или малоинформативный пост).В профиле на них один счетчик, но по своей задумке это совершенно разные вещи. Потому тут оценить пользу без нормальных делений "что есть польза" довольно-таки тяжело.
ScorpioT1000, ну там вообще не рассмотрены практические примеры, только базовые знания по интерполяции и экстраполяции можно подчерпнуть. По протоколам я где-то на хабре видел хорошую абстрактную статью, но лично с себя - я ее не понял, пока не столкнулся с этим сам.
ScorpioT1000, немного не те дебри ) Речь шла о стандартной сериализации Unity, позволяющей хранить объекты на сцене и обновлять данные о них по мере того как мы программируем клиент.
Сериализация в сети, или что правильней сказать - работа с протоколами, это совсем другая тема. Могу написать статью о сериализации в сети, как это делается на быстрых серверах, но немного позже. alexprey, придумывать способы - не понадобится. Сериализация является неотъемлимой частью работы с движком Unity. Она везде, где сохраняются данные. Но когда данные не сохраняются - приходится вникать в механизм как это работает, и вот об этом эта статья
alexprey, о, да запросто.
Сериализация нужна в проекте для того чтобы у нас в принципе сохранялась информация.
Дело в том, что когда мы пишем новый код и юнити его компилирует, происходит вынужденное уничтожение этих объектов. Соответсвенно, после ребилда часть данных просто исчезает, если мы не сериализовали ее.
Вот простой пример. Есть у нас класс
public class Example : MonoBehaviour
{
[NonSerialized]
public int count = 0;
[ContextMenu("Plus")]
public void Plus()
{
Debug.Log(count++);
}
}
Теперь сделаем какие-нибудь изменения в коде чтобы вызвать ребилд (лично я поставил пробел и сохранил). И повторим пункт 2. В чем резон? А в том что мы увидим тоже самое снова:
А теперь посмотрим как это выглядело, если бы мы сейчас убрали атрибут [NonSerialized]. То есть что нужно сделать: удалить атрибут и сделать все тоже самое что я писал выше. Результат будет такой:
создайте с нуля любой класс, не наследуемый ни от чего. Просто класс.
используйте его как поле в MonoBehaviour
теперь попробуйте с простого - сделать отображение этого класса в редакторе, чтобы настроить его поля.
А в целом - если вы не сталкиваетесь в повседневном программировании с механизмом сериализации - вам пока рано читать эту статью. Но не забывайте про нее, она вам понадобится когда вы начнете писать редакторы под свои игры, для которых сами создаете какие-то данные. И когда вы с подобным столкнетесь - первое ваше разочарование может быть связано как раз с тем, что данные не сохранились. И отгадайте, кто этому будет виной. Вот тогда вы перечитаете то что я тут написал и сразу все станет ясно - зачем вам этот зверь.
Насчет копилки идей - звучит интересно.
Насчет "рекомендаций специалистов" - имхо получится такая вещь, что образуется так скажем верхушка-элита к которой все будут обращаться, а все прочие останутся в тени. И вообще, лучшая рекомендация = портфолио (или по сайту - вклад в комьюнити)
alexprey, так нельзя писать. Забудьте про использование оператора "=" в функциях и коротких записях. Да, решарпер их предлагает как "улучшения", но единственное на что вы наткнетесь - баг юнити. Компиляция в Unity не переваривает "=" правильно, если вы используете его в выражениях такого вида. Например, в вашем коде объект при первом обращении вернет null, несмотря на то что по логике он должен вернуть компонент. Пруф как тестили (здесь можно нажать)
Случай такой как оказалось потом не только с Transfrom, но отлавливать ноги у таких багов, где весь код по логике - дико и не нужно. Та же херня и с телами методов и еще кучей классов.
using UnityEngine;
namespace MyNamespace
{
public class Test : MonoBehaviour
{
public static void Create(int a, Transform v = null)
{
}
}
}
Уберите пространство имен, статик у метода, перегрузку, либо наследование и скрипт будет валидным. На этом я и построил вывод о том, что необходимо соблюдение всех 4 условий.
UPD: со статиком перегнул, он не обязателен.
Если вы кинули валидный скрипт - он никуда не денется (единственное что при перезагрузке может сбиться, либо поля захайдить), так как проверка идет при добавлении элемента.
Не ясен смысл кеширования int во втором примере. Абсолютно надуманный пример
Не раскрыта тема как лучше использовать GetComponent. Обращение к компонентам может оказаться на стороне редакторе где никакой Start не выполнялся. Или создан посреди сцены.
А самый частый пример - кеширование компонента при первом обращении к нему. Например:
private MyComponent _mycomponent;
public MyComponent mycomponent
{
get
{
if (_mycomponent == null)
_mycomponent = GetComponent<MyComponent>();
return _mycomponent;
}
}
Насчет создания Rect в циклах - чушь. Rect представлен struct, что по дефолту является легковесным, так как не требует ссылок. Даже если вы закешируете Rect в отдельное поле, вы все равно при использовании будете просто копировать значение, как и при операторе new. А вот постоянные перерасчеты того что можно посчитать один раз - губительны, здесь спору нет. Уж тем более - ЧЕМ опасно создание переменных в цикле? Что за ересь? Вы можете создавать тысячи переменных в цикле, это абсолютно безопасно! Даже могилки не ощутят эту операцию.
» Альбом Железного Художника / Поздравляю всех с Днём Реанимации!
» XGM Team / Встречайте, Unity Web Player
Вообще в целом странный подход. Вот вы когда пишете шейдеры, вам же не кричат "сначала вручную построй весь графический конвейер, иначе не поймешь что такое шейдеры". Когда пишете код, вам не кричат "сначала напишите свою программную среду и свой язык, чтобы понимать как они работают". Вы это прекрасно понимаете, просто ознакомившись с каким-то базисом по этому вопросу.
Очень жаль что вы кроме кнопочек в Unity ничего не увидели.
Ред. Devion
» XGM Team / Встречайте, Unity Web Player
- Пруф на то что я должен учить. Хотелось бы лицезреть какие знания в геймдеве я могу получить только на выдуманном вами "низком уровне". То есть как я понимаю "знания которые я не пойму, не зная языков низкого уровня и не конструируя движок с нуля". Именно не пойму.
- Пруф на майнкрафт в котором по сути десятки моментов по оптимизации, которые по вашим словам можно сделать в 2 клика. Кстати если бы это было возможно - я считаю это был бы дикий плюс.
Пока вы пишите свой движок с нуля на каждый типичный гейм - ваши конкуренты уже уйдут на пенсию.И уж если на то пошло и знания таковые действительно будут, и своими внушительными комментариями аля "долой Юньку, я считаю она для школьников и потому фу на ней писать" - почему бы вам не поделиться полезной информацией с сообществом в виде статей по gamedev'у? Я думаю вам все будут признательны, если это будет что-то отличное от комментария с вашим пустым негодованием. Опишите те знания "низкого уровня", лично я бы с удовольствием почитал что-то из того что еще не знаю. А покуда нет - ваши слова будут равны ценности моего диплома (про него мне тоже что-то втирали аля вот надо его и всё тут).
Ред. Devion
» XGM Team / Встречайте, Unity Web Player
- майнкрафт в два клика вы не сделаете, хоть что вы юзайте.
- нет ни одной причины, по которой пользуясь Unity вы не сможете узнавать как движки вообще устроены.
Более того, скачайте .NET Reflector и смотрите как "внутри" выглядят библиотеки Unity.Сабж, кстати, не бывает на "низком уровне". Все что вы смогли бы тут перечислить - не потребует знания "низких уровней", а потребует просто знаний, без этого постфикса.
Цифры не с потолка, реальный тест который был проведен в недалеком 2010 году. Может с тех пор что-то и поменялось, но на заметку - как знаю
Ред. Devion
» XGM Team / Встречайте, Unity Web Player
Вкратце, почему Unity:
- Развитая документация
- Кроссплатформенность
- Код
- Не сильно высокая разница по производительности с нативным кодом.
- Особо тяжелые места можно заекстернить с плюсов.
- Из авторитетных источников мне известно что в сравнении с тем же UDK - код в 20 раз быстрее (UDK в 30 раз медленней нативного кода).
- Я лишен необходимости постоянной работы с техническими проблемами - в коде игры есть игровая логика и только игровая логика и это явный плюс.
- При том первое обращение к скриптам - компилирует их в натив. Проблемы с кодом нет.
- Есть расширяемый язык boo, который упрощает ввод некоторого специфичного кода, такого как протоколы.
- Редактор - имеется возможность дописывать свои возможности к функционалу движка
- Большое комьюнити
- Мне ничто не мешает использовать не нативную сетевую, а чью-либо иную реализацию, или даже свою
- Программирование на лету. Мне не надо запускать компилятор из cmd и писать с нуля хранение инфы на уровне
- Внятные условия лицензии
Кстати за участие в развитии движка, где юнитехи диктуют правила, аля перевод документации на ваш язык, вам могут эту лицензию просто "дать" за то что вы переводите. Так что ее реально получить даже без денег. Это просто не соответствует действительности. В юнити я могу отключить лишний функционал, например физику, если я собираюсь задействовать свое octree-дерево, и стандартное мне не нужно. И как уже написал - бесконечные модули, которыми можно расширить движок.Дико напрягают темы, аля "Я пишу на С++ и Java, а ты пишешь на C#, значит ты УГ". УГ имхо то что многие без причин остаются консерваторами и циниками в отношении нового. C# кстати по функционалу и удобству НАМНОГО лучше чем Java. Есть пара моментов, аля "оператора break", но это настолько редкая фича что я бы ей не гордился. Вообще у людей сформировались стереотипы, аля "сложнее делать = лучше". Ну и сидите, тогда на своем ассемблере и напишите игру, в которую будут играть. Но ведь вы не будете этого делать, это же самоубийственно.
При том всегда находится с десяток кретинов, которые кричат "НОВЫЙ %NEWLANGUAGE% ГАВНО!!11, МЕДЛЕННЕЙ И ХУЖЕ ОСТАНЬТЕСЬ В %OLDLANGUAGE%".
Так кричали про C, про C++, сейчас кричат про C#. Но вот скажите, где бы были ЯП, в каком месте, если бы вас кто-то слушал?
Про игровые движки тоже самое, стереотип "низкий порог вхождения == лучше". В то время как не видно ни одной реальной причины почему это так, по той простой причине что "низкий порог вхождения != расширяемость/скорость".
И самое важное - никому не нужен лишний геморрой за какой-то мифический 1% выгоды. В итоговом приложении вы не будете иметь никакой разницы в том, на каком движке она написана. Пользователям на это просто наплевать. Так что будет лучше - написать быстро и с удобством, или медленно, без удобства, зато с кодом, который быстрее на какие-то 30%? Еще раз повторю - 30%. На операцию которая выполняется в Unity 8мкс, пользователю на вашем собственном движке на C++ будет 6мкс. Ну он прямо разницу почувствует, оценит.
Ред. Devion
» XGM Team / Встречайте, Unity Web Player
nazo_seven, Construct 2 это не движок, это конструктор игр
ZLOI_DED развел тему на пустом месте = самоутверждается
Сделали хорошую фичу? => Она тебя не касается? => Просто не пиши ничего
Ред. Devion
» XGM Конкурсы / Искренне от Jusper'а
Все эти придирки аля ява/жава/джава, хтмл/аштиэмль, пхп/пиашпи, хгм/эксгээм - до жути глупо. Вреда они несут только в лице возмущающихся.
я бтв говорю вообще самым неправильным образом - КСЭ гэ эм. Откуда КСЭ - хрен знает, просто так легче произносить.
Не слышал только варианта "Экс Джи Эм", но по любому кто-то так говорит, как бы уж если до правил в чтении докапываться - сам должен произносить так
» Unity / GUISkinViewer - окно для просмотра стилей
Ты наверное имел ввиду кастомные гуистили в гуискине.
Есть параметр border который отвечает сколько пикселей нужно отобразить в нормальном размере с каждой стороны. А все что остается как и прежде растянется.
» Администрация XGM / Перенос ссылок
Для гуглхрома есть плагин Switcheroo Redirector, чтобы работал автоматический редирект с xgm.ru на xgm.guru
Как временное решение
» XGM Team / Да здравствует новый король!
» XGM Team / Да здравствует новый король!
» XGM Team / Да здравствует новый король!
правда не понимаю, почему в профиле написано привет из доса, а код на ассемблере» XGM Team / Да здравствует новый король!
» XGM Team / Да здравствует новый король!
» XGM Конкурсы / XGM - спасибо, что живой!
» XGM Team / Общение с пользователями
Немного смущает смешанность понятия "статья" и в целом "запись" (новость в блоге/проекте/дневнике, мб обычная копипаста или малоинформативный пост).В профиле на них один счетчик, но по своей задумке это совершенно разные вещи. Потому тут оценить пользу без нормальных делений "что есть польза" довольно-таки тяжело.
» Unity / Нативная сериализация и её подводные камни
Ред. Devion
» Unity / Нативная сериализация и её подводные камни
Сериализация в сети, или что правильней сказать - работа с протоколами, это совсем другая тема. Могу написать статью о сериализации в сети, как это делается на быстрых серверах, но немного позже.
alexprey, придумывать способы - не понадобится. Сериализация является неотъемлимой частью работы с движком Unity. Она везде, где сохраняются данные. Но когда данные не сохраняются - приходится вникать в механизм как это работает, и вот об этом эта статья
Ред. Devion
» Unity / Нативная сериализация и её подводные камни
Сериализация нужна в проекте для того чтобы у нас в принципе сохранялась информация.
Дело в том, что когда мы пишем новый код и юнити его компилирует, происходит вынужденное уничтожение этих объектов. Соответсвенно, после ребилда часть данных просто исчезает, если мы не сериализовали ее.
Вот простой пример. Есть у нас класс
» XGM Team / Общение с пользователями
Насчет "рекомендаций специалистов" - имхо получится такая вещь, что образуется так скажем верхушка-элита к которой все будут обращаться, а все прочие останутся в тени. И вообще, лучшая рекомендация = портфолио (или по сайту - вклад в комьюнити)
Ред. Devion
» Unity / Оптимизация
Ред. Devion
» Unity / Оптимизация
Пруф как тестили (здесь можно нажать)
Случай такой как оказалось потом не только с Transfrom, но отлавливать ноги у таких багов, где весь код по логике - дико и не нужно. Та же херня и с телами методов и еще кучей классов.
Ред. Devion
» Unity / Ошибка с MonoBehaviour классом
Тело:
UPD: со статиком перегнул, он не обязателен.
Если вы кинули валидный скрипт - он никуда не денется (единственное что при перезагрузке может сбиться, либо поля захайдить), так как проверка идет при добавлении элемента.
» Unity / Оптимизация
- Не ясен смысл кеширования int во втором примере. Абсолютно надуманный пример
- Не раскрыта тема как лучше использовать GetComponent. Обращение к компонентам может оказаться на стороне редакторе где никакой Start не выполнялся. Или создан посреди сцены.
А самый частый пример - кеширование компонента при первом обращении к нему. Например:» Unity / Ошибка с MonoBehaviour классом
- Задействовано пространство имен
- Имеются статические методы
- Имеется перегрузка метода
- Наследие от MonoBehaviour
В этом случае действительно происходит вот такой вот баг. Однако если хотя бы один из этих пунктов упущен - все будет работать на ура.