Теперь Юнити решило избавиться от ЯваСкрипта? Потому-что теперь нельзя создать JS файлы, если это конечно не ошибка (скорее они тупо избавляются), то есть я должен свои около 500 скриптов переписывать в С#? Да я его еще и плохо знаю. PS Если б с самого начала не было бы выбора, то я б в любом случае бы уже выучил С#, но я выбрал более легкий язык, ибо я не программист, а художник, и мне бы что попроще, поскольку был выбор и всегда говорили, что он поддерживается на 100%. PPS Интересно с какой версии прекратится поддержка ЯваСкрипта, какой примерно срок? Есть где-нибудь информация по этому поводу?
Сообщение отредактировал alexsilent - Воскресенье, 05 Ноября 2017, 18:04
Уже давно Unity плавно уходит от поддержки UnityScript. Поищи статью из их блога UnityScript’s long ride off into the sunset Еще когда появлялись первые туториалы, все советовали не останавливаться ни на UnityScript ни на Boo, а с сразу переходить на C#, надо было слушать After Time Last Of Time Happy Pumpkin
По-моему они еще несколько лет назад начали говорить о том что планируют от него избавляться Впрочем, его пока не отключают, старые скрипты работать будут, просто убрали из меню чтобы новички не сделали неправильный выбор, как когда-то сделал ты
Сообщение отредактировал drcrack - Воскресенье, 05 Ноября 2017, 18:38
PS Если б с самого начала не было бы выбора, то я б в любом случае бы уже выучил С#, но я выбрал более легкий язык, ибо я не программист, а художник, и мне бы что попроще, поскольку был выбор и всегда говорили, что он поддерживается на 100%. PPS Интересно с какой версии прекратится поддержка ЯваСкрипта, какой примерно срок? Есть где-нибудь информация по этому поводу?
если ты пишешь на яваскриптах то без проблем сможешь писать на C# скрипты. Даже удивишься насколько синтаксис C# чище и выразительнее в сравнении с яваскриптом. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
если ты пишешь на яваскриптах то без проблем сможешь писать на C# скрипты. Даже удивишься насколько синтаксис C# чище и выразительнее в сравнении с яваскриптом.
pixeye, единственное, что мне пока нравится в Сишарпе, что можно в функции добавлять значения по умолчанию у переменных типа:
Код
void MyFunction(integer number = 3)
если я правильно написал это, я пока не знаком с синтаксисом C# ^_^'
А в остальном там больше текста писать придется, короткие скрипты типа:
Код
transform.position.x += .5;
похоже невозможно написать на C#, там вроде нужно полностью вектор писать, еще и всегда добавляя лишнее слово new перед вектором(( (не люблю, лишнюю писанину, придется привыкать)
наверное на СиШарпе эта строка должна выглядеть примерно так:
Код
transform.position = transform.position + new Vector3(0.5f,0,0);
(если сократить нельзя, то это меня это действительно пугает, и надеюсь я правильно это написал)
Да и еще, чтобы скрипту название поменять, придется еще и в коде всегда дублировать, название изменять, короче больше лишней работы, которой и так будет не мало. (придется весь код переписывать с ЯваСкрипта постепенно)
Ну ладно, надеюсь там еще есть плюсы
(лично для меня, как не программиста, то есть я поверхностно использую язык, чтобы сделать игру, не углубляясь далеко в дебри ООП)
в СиШарпе, помимо единственного, о котором я пока знаю.
Сообщение отредактировал alexsilent - Четверг, 09 Ноября 2017, 19:21
А в остальном там больше текста писать придется, короткие скрипты типа:
Цитатаalexsilent ()
похоже невозможно написать на C#, там вроде нужно полностью вектор писать, еще и всегда добавляя лишнее слово new перед вектором(( (не люблю, лишнюю писанину, придется привыкать)
разумеется. В javascript это делали ( new ) за тебя. Считай, что ты с автоматической коробки пересел на ручную. Оно действительно не лишнее а осмысленное.
new нужен потому что ты не меняешь векторы, а создаешь новый. Вектор это структура и при ее создании нужно инициализировать все параметры. https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/ почитай про классы и струтктуры.
ЦитатаInsaneSystems ()
не углубляясь далеко в дебри ООП
тебе необязательно писать в стиле ООП. ООП - это парадигма. Можешь хоть процедурно программировать.
Тебе кстати ничего не мешает написать свой синтаксический сахар для векторов в C# чтобы избавиться от NEW
Кода в С# описывать надо точно меньше. Это прям к гадалке не ходи. Но сколько ты будешь в действительности писать кода не зависит от языка, а от того как ты пишешь и как много пишешь одного и того же.
Например мой код выглядит так:
Я описываю логику модулями и храню переменные группами по смыслу, а не по объекту. Единожды описав поведение вращения пушки например я это потом могу использовать для любой пушки в игре. Первый скрипт относится к кораблю и является хранилищем всех поведений, второй скрипт реализует поведение пушки.
pixeye, спасибо! Кое-что прояснилось, но кое-что немножко непонятно.
Например:
Цитатаpixeye ()
Я описываю логику модулями и храню переменные группами по смыслу, а не по объекту. Единожды описав поведение вращения пушки например я это потом могу использовать для любой пушки в игре.
Я тоже например вот этот скрипт сделал для того, чтобы использовать на любом объекте, которому нужно постоянное вращение или движение, не только к одному единственному, а вообще к любому к какому захочу, и этот код не разделен на два кода, в чем смысл разделять на две части? Есть какой-нибудь простой урок для чайников? (То есть другими словами, как это понятие называется, я погуглю) а то выглядит очень сложно для меня, т.е. зачем их разделять на два скрипта, когда можно было бы функции в одном скрипте все написать? Наверное в этом есть какой-то глубокий смысл, который я упускаю, и который наверное очень пригодится при переходе на СиШарп.
Код
#pragma strict var alwaysTurns : Vector3 = Vector3.zero; var alwaysMove : Vector3 = Vector3.zero;
private var myTransform : Transform; private var rotateDir : int = 1; var rotateDirON : boolean;
function Start () { myTransform = transform; if (rotateDirON) rotateDir=Mathf.Sign(myTransform.localScale.x); }
function FixedUpdate () { if (alwaysTurns != Vector3.zero) { myTransform.Rotate(alwaysTurns*rotateDir); } if (alwaysMove != Vector3.zero) { transform.Translate(alwaysMove, Space.World); } }
Добавлено (09 ноября 2017, 20:13) --------------------------------------------- PS Графика классная :3
Сообщение отредактировал alexsilent - Четверг, 09 Ноября 2017, 20:16
alexsilent, честно говоря, код пиксая без серьёзных знаний C# вообще будет очень трудно понять.
Разделять код имеет смысл, например, чтобы не получались огромные скрипты по тысяче строк, особенно если описываемая вещь не сильно сложная. Ну и для того, чтобы из отдельных маленьких компонентов вы могли собрать большой, причём в любых комбинациях. Причин много, их понимание приходит со временем.
Сообщение отредактировал InsaneSystems - Четверг, 09 Ноября 2017, 20:23
Я тоже например вот этот скрипт сделал для того, чтобы использовать на любом объекте, которому нужно постоянное вращение или движение, не только к одному единственному, а вообще к любому к какому захочу, и этот код не разделен на два кода, в чем смысл разделять на две части? Есть какой-нибудь простой урок для чайников? (То есть другими словами, как это понятие называется, я погуглю) а то выглядит очень сложно для меня, т.е. зачем их разделять на два скрипта, когда можно было бы функции в одном скрипте все написать.
Вот кстати твой код: var alwaysTurns : Vector3 = Vector3.zero; объявляется как Vector3 alwaysTurns; в С# ( как видишь гораздо быстрее )
Так как я пишу писать необязательно. Причина кроется в том, что я использую всего один monobehaviour на объекте для его логики. Связано это с тем что используя кучу несвязных monobehaviour на префабе ты в них быстро начинаешь путаться и забываешь откуда ноги растут. Это просто из личного опыта.
Вообще нужно стараться писать как можно более предсказуемо. В моем случае это всегда наличии на игровом объекте класса актера который задает всё поведение. Я всегда знаю что есть только один юнитивский монобехейвер отвечающий за объект. Не два, не три, всегда один. Посмотрев его я легко могу определить все его поведения, все его параметры.
Мне это просто было нужно. Возможно тебе этого и не требуется, но у меня к примеру может быть 10-12 поведений на объекте. Юнити поощряет модульность и казалось бы ну ОК - вешай 12 monobehaviour на объект и копашись с ними в инспекторе. Это неудобно) вот прям ни разу. Плюс ты быстро начинаешь понимать что в общем-то большинству поведений вообще ненужны юнитивские методы и параметры наследуемые от monobehaviour.
Чем меньше у тебя инфы в инспекторе тем крепче ты спишь) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 09 Ноября 2017, 20:41
alexsilent, честно говоря, код пиксая без серьёзных знаний C# вообще будет очень трудно понять.
InsaneSystems, наверное в этом вся соль. Если бы мне нужно было бы поведение пушки, то я бы просто сделал поведение пушки и вешал на любые бы объекты. Например корабль, у него же есть объект пушки, вот туда бы и повесил, лишним скриптом бы тут был бы для меня Хранилище поведений, если бы я только не захотел бы получить доступ из другого скрипта, но я бы просто бы другим скриптом через GetComponent бы применил и оттуда бы воровал переменные или бы вмешивался в работу.
Сообщение отредактировал alexsilent - Четверг, 09 Ноября 2017, 20:33
Например корабль, у него же есть объект пушки, вот туда бы и повесил, лишним скриптом бы тут был бы для меня Хранилище поведений, если бы я только не захотел бы получить доступ из другого скрипта, но я бы просто бы другим скриптом через GetComponent бы применил и оттуда бы воровал переменные или бы вмешивался в работу
Ты думаешь абсолютно в верном направлении. Я тоже так думал. Еще года полтора назад.
Моя структура выглядит так:
Actor ( это monobehaviour ) , каждый уникальный игровой объект является актером. Например астероид будет ActorAsteroid. Это монобехейвер и через него я общаюсь с юнити. Каждый актер имеет массив компонентов. Это обычные классы не наследуемые от monobehaviour и отвечают за логику. Каждый актер имеет отдельный класс даты который хранит всю нужную дату для работы с компонентами.
Например AsteroidActor и PlayerShipActor оба имеют класс DecoratorFloat отвечающий за то что корабль/астероид/что угодно могло покачиваться в космосе. Текстом я это опишу гораздо быстрее чем ты залезешь в инспектор разным префабам и добавишь этот класс объектам : )
Причина кроется так де в том, что переменные для поведения не хранятся в самом классе поведения. Для чего это нужно? Ну допустим тебе нужно узнать как сильно качается корабль в космосе из другого скрипта.
Логически то что ты сделаешь это протянешь связку : GetComponent(DecoratorFloat) и вытащишь переменную. Твой код начинает быть похож на паутину обращений друг к другу компонентов. А что если ты удалишь компонент из игры? Придется править код в куче мест.
Поэтому вместо того чтобы думать категориями конечных объектов я думаю категорией информации. Я создаю класс который хранит например все вращения и положения для объекта. И уже и декораторФлоат и любой другой класс обращаются к этому классу содержащие только переменные.
Маловероятно что его я буду менять. А вот класс поведения - запросто.
В конечном итоге мне это позволяет развертывать и комбинировать новые объекты со скоростью автомата : )
Я могу практически мгновенно создать башню-пушку с лазерным щитом, тут же рядом сделать пушку без щита, третьей пушки присобачить лечение, четвертая пушка будет изрыгать истребители. Если мне нужно специфически описать поведение ТОЛЬКО для этого актера я могу смело описать это в коде актера или добавить компоненты-декораторы.
Все что для этого нужно это заранее написать скрипты для поведений. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 09 Ноября 2017, 20:44
Причина кроется в том, что я использую всего один monobehaviour на объекте для его логики. Связано с тем что используя кучу несвязных monobehaviour на префабе ты в них быстро начинаешь путаться и забываешь откуда ноги растут. Это просто из личного опыта.
Это я понимаю, у меня тоже немало скриптов на каждом префабе, правда до 12-ти вроде еще ни разу не доходило. Но иногда неудобно. Хотя если это все будет в одном модуле, то свернуть только часть не получится, иногда удобно ненужную часть свернуть, и оставить только нужный скрипт. А если все будет в одном, то оно всегда будет развернуто?
Сообщение отредактировал alexsilent - Четверг, 09 Ноября 2017, 20:46
Это я понимаю, у меня тоже немало скриптов на каждом префабе, правда до 12-ти вроде еще ни разу не доходило. Но иногда неудобно. Хотя если это все будет в одном модуле, то свернуть только часть не получится, иногда удобно ненужную часть свернуть, и оставить только нужный скрипт. А если все будет в одном, то оно всегда будет развернуто?
Вот именно чтобы такого не было я пишу это через 1 компонент.
Выглядит у меня это примерно так:
Главное различие: Мои компоненты добавляются к объекту после создания. Уже в игре. Я ими не оперирую в инспекторе ( только параметрами даты ) и не вижу их в инспекторе. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 09 Ноября 2017, 20:54
PS еще мне не хватает "частичного сворачивателя" в юнити, например у меня есть скрипт, где описаны все предметы, которые можно подобрать, чтоб загружать например в инвентарь с абсолютно любой локации. Пока их около 35 предметов, но когда количество вырастет до 100, то юнити начинает слегка притормаживать (тестировал уже), была бы возможность скрывать некоторую часть этого массива, чтобы не все 100 были одновременно на виду, было бы круто. Но это так, мечты)
Добавлено (09 ноября 2017, 21:03) ---------------------------------------------
На самом деле абсолютно не важно как ты пишешь пока это для тебя работает)) в этом вся крутость) ты сам приходишь к выводам и оптимизируешь под себя Убежал работать XD ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
