Пятница, 29 Марта 2024, 19:02

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 2
  • 1
  • 2
  • »
Форум игроделов » Движки для разработки игр и сложные системы разработки » Unity » пригорело по поводу ЯваСкрипта
пригорело по поводу ЯваСкрипта
alexsilentДата: Воскресенье, 05 Ноября 2017, 18:01 | Сообщение # 1
почти ветеран
Сейчас нет на сайте
Теперь Юнити решило избавиться от ЯваСкрипта?
Потому-что теперь нельзя создать JS файлы, если это конечно не ошибка (скорее они тупо избавляются),
то есть я должен свои около 500 скриптов переписывать в С#?
Да я его еще и плохо знаю.
PS Если б с самого начала не было бы выбора, то я б в любом случае бы уже выучил С#, но я выбрал более легкий язык,
ибо я не программист, а художник, и мне бы что попроще,
поскольку был выбор и всегда говорили, что он поддерживается на 100%.
PPS Интересно с какой версии прекратится поддержка ЯваСкрипта, какой примерно срок? Есть где-нибудь информация по этому поводу?


Сообщение отредактировал alexsilent - Воскресенье, 05 Ноября 2017, 18:04
RutrapleДата: Воскресенье, 05 Ноября 2017, 18:31 | Сообщение # 2
почетный гость
Сейчас нет на сайте
Уже давно Unity плавно уходит от поддержки UnityScript. Поищи статью из их блога UnityScript’s long ride off into the sunset
Еще когда появлялись первые туториалы, все советовали не останавливаться ни на UnityScript ни на Boo, а с сразу переходить на C#, надо было слушать ^_^


After Time
Last Of Time
Happy Pumpkin
drcrackДата: Воскресенье, 05 Ноября 2017, 18:37 | Сообщение # 3
старожил
Сейчас нет на сайте
По-моему они еще несколько лет назад начали говорить о том что планируют от него избавляться
Впрочем, его пока не отключают, старые скрипты работать будут, просто убрали из меню чтобы новички не сделали неправильный выбор, как когда-то сделал ты :D


Сообщение отредактировал drcrack - Воскресенье, 05 Ноября 2017, 18:38
HerrPotapovДата: Воскресенье, 05 Ноября 2017, 19:43 | Сообщение # 4
заслуженный участник
Сейчас нет на сайте
alexsilent, причем в посте четко было написано что они просто убрали такой пункт из меню. Руками файлы все еще можно создавать

Discord: alpotapov#1741

Интервью с разработчиком WarCastle - Читаем и вникаем!
pixeyeДата: Четверг, 09 Ноября 2017, 17:05 | Сообщение # 5
Red Winter Software
Сейчас нет на сайте
Цитата alexsilent ()
PS Если б с самого начала не было бы выбора, то я б в любом случае бы уже выучил С#, но я выбрал более легкий язык,
ибо я не программист, а художник, и мне бы что попроще,
поскольку был выбор и всегда говорили, что он поддерживается на 100%.
PPS Интересно с какой версии прекратится поддержка ЯваСкрипта, какой примерно срок? Есть где-нибудь информация по этому поводу?


если ты пишешь на яваскриптах то без проблем сможешь писать на C# скрипты. Даже удивишься насколько синтаксис C# чище и выразительнее в сравнении с яваскриптом.


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

InsaneSystemsДата: Четверг, 09 Ноября 2017, 18:26 | Сообщение # 6
участник
Сейчас нет на сайте
alexsilent, в старых версиях (вплоть до 2017 точно) возможность писать на US останется, поэтому решение - не обновляться. Или учить C#.
alexsilentДата: Четверг, 09 Ноября 2017, 18:37 | Сообщение # 7
почти ветеран
Сейчас нет на сайте
Цитата InsaneSystems ()
в старых версиях (вплоть до 2017 точно) возможность писать на US останется, поэтому решение - не обновляться. Или учить C#.

Я надеюсь, еще хотя бы на полгода останется, чтобы я плавно мог перейти на другой язык, переписав основные скрипты, их там немало.
InsaneSystemsДата: Четверг, 09 Ноября 2017, 18:40 | Сообщение # 8
участник
Сейчас нет на сайте
alexsilent, вроде полностью убирают в 2017.2, но это не точно. Давно блог читал. Может, в 2017.2 как раз просто из меню убрали.

Сообщение отредактировал InsaneSystems - Четверг, 09 Ноября 2017, 18:44
alexsilentДата: Четверг, 09 Ноября 2017, 18:46 | Сообщение # 9
почти ветеран
Сейчас нет на сайте
Цитата pixeye ()

если ты пишешь на яваскриптах то без проблем сможешь писать на 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
InsaneSystemsДата: Четверг, 09 Ноября 2017, 19:01 | Сообщение # 10
участник
Сейчас нет на сайте
Цитата
всегда добавляя лишнее слово new перед вектором

Оно не лишнее, а вполне осмысленное. Вообще, если бы вы поглубже разобрались, то, возможно, стало бы понятно и даже понравилось.

Цитата
transform.position = transform.position + new Vector3(0.5f, 0, 0);

Можно так:
Код
transform.position += new Vector3(0.5f, 0, 0);


Сообщение отредактировал InsaneSystems - Четверг, 09 Ноября 2017, 19:02
pixeyeДата: Четверг, 09 Ноября 2017, 19:46 | Сообщение # 11
Red Winter Software
Сейчас нет на сайте
Цитата alexsilent ()
А в остальном там больше текста писать придется, короткие скрипты типа:

Цитата alexsilent ()
похоже невозможно написать на C#, там вроде нужно полностью вектор
писать, еще и всегда добавляя лишнее слово new перед вектором(( (не люблю, лишнюю писанину, придется привыкать)

разумеется. В javascript это делали ( new ) за тебя. Считай, что ты с автоматической коробки пересел на ручную.
Оно действительно не лишнее а осмысленное.

new нужен потому что ты не меняешь векторы, а создаешь новый. Вектор это структура и при ее создании нужно инициализировать все параметры.
https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/ почитай про классы и струтктуры.

Цитата InsaneSystems ()
не углубляясь далеко в дебри ООП

тебе необязательно писать в стиле ООП. ООП - это парадигма. Можешь хоть процедурно программировать.

Тебе кстати ничего не мешает написать свой синтаксический сахар для векторов в C# чтобы избавиться от NEW

Кода в С# описывать надо точно меньше. Это прям к гадалке не ходи.
Но сколько ты будешь в действительности писать кода не зависит от языка, а от того как ты пишешь и как много пишешь одного и того же.

Например мой код выглядит так:



ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

alexsilentДата: Четверг, 09 Ноября 2017, 20:13 | Сообщение # 12
почти ветеран
Сейчас нет на сайте
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
InsaneSystemsДата: Четверг, 09 Ноября 2017, 20:22 | Сообщение # 13
участник
Сейчас нет на сайте
alexsilent, честно говоря, код пиксая без серьёзных знаний C# вообще будет очень трудно понять. :D

Разделять код имеет смысл, например, чтобы не получались огромные скрипты по тысяче строк, особенно если описываемая вещь не сильно сложная. Ну и для того, чтобы из отдельных маленьких компонентов вы могли собрать большой, причём в любых комбинациях. Причин много, их понимание приходит со временем. :)


Сообщение отредактировал InsaneSystems - Четверг, 09 Ноября 2017, 20:23
pixeyeДата: Четверг, 09 Ноября 2017, 20:25 | Сообщение # 14
Red Winter Software
Сейчас нет на сайте
Цитата alexsilent ()

Я тоже например вот этот скрипт сделал для того, чтобы использовать на любом объекте, которому нужно постоянное вращение или движение, не только к одному единственному, а вообще к любому к какому захочу,
и этот код не разделен на два кода, в чем смысл разделять на две части?
Есть какой-нибудь простой урок для чайников? (То есть другими словами, как это понятие называется, я погуглю) а то выглядит очень сложно для меня, т.е. зачем их разделять на два скрипта, когда можно было бы функции в одном скрипте все написать.




Так как я пишу писать необязательно. Причина кроется в том, что я использую всего один monobehaviour на объекте для его логики. Связано это с тем что используя кучу несвязных monobehaviour на префабе ты в них быстро начинаешь путаться и забываешь откуда ноги растут. Это просто из личного опыта.

Вообще нужно стараться писать как можно более предсказуемо. В моем случае это всегда наличии на игровом объекте класса актера который задает всё поведение.
Я всегда знаю что есть только один юнитивский монобехейвер отвечающий за объект. Не два, не три, всегда один. Посмотрев его я легко могу определить все его поведения, все его параметры.

Мне это просто было нужно. Возможно тебе этого и не требуется, но у меня к примеру может быть 10-12 поведений на объекте. Юнити поощряет модульность и казалось бы ну ОК - вешай 12 monobehaviour на объект и копашись с ними в инспекторе. Это неудобно) вот прям ни разу. Плюс ты быстро начинаешь понимать что в общем-то большинству поведений вообще ненужны юнитивские методы и параметры наследуемые от monobehaviour.

Чем меньше у тебя инфы в инспекторе тем крепче ты спишь)


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю



Сообщение отредактировал pixeye - Четверг, 09 Ноября 2017, 20:41
alexsilentДата: Четверг, 09 Ноября 2017, 20:28 | Сообщение # 15
почти ветеран
Сейчас нет на сайте
Цитата InsaneSystems ()
alexsilent, честно говоря, код пиксая без серьёзных знаний C# вообще будет очень трудно понять.


InsaneSystems, наверное в этом вся соль. Если бы мне нужно было бы поведение пушки, то я бы просто сделал поведение пушки и вешал на любые бы объекты. Например корабль, у него же есть объект пушки, вот туда бы и повесил, лишним скриптом бы тут был бы для меня Хранилище поведений, если бы я только не захотел бы получить доступ из другого скрипта, но я бы просто бы другим скриптом через GetComponent бы применил и оттуда бы воровал переменные или бы вмешивался в работу.


Сообщение отредактировал alexsilent - Четверг, 09 Ноября 2017, 20:33
pixeyeДата: Четверг, 09 Ноября 2017, 20:41 | Сообщение # 16
Red Winter Software
Сейчас нет на сайте
Цитата alexsilent ()
Например корабль, у него же есть объект пушки, вот туда бы и повесил, лишним скриптом бы тут был бы для меня Хранилище поведений, если бы я только не захотел бы получить доступ из другого скрипта, но я бы просто бы другим скриптом через GetComponent бы применил и оттуда бы воровал переменные или бы вмешивался в работу


Ты думаешь абсолютно в верном направлении. Я тоже так думал. Еще года полтора назад.

Моя структура выглядит так:

Actor ( это monobehaviour ) , каждый уникальный игровой объект является актером. Например астероид будет ActorAsteroid. Это монобехейвер и через него я общаюсь с юнити.
Каждый актер имеет массив компонентов. Это обычные классы не наследуемые от monobehaviour и отвечают за логику.
Каждый актер имеет отдельный класс даты который хранит всю нужную дату для работы с компонентами.

Например AsteroidActor и PlayerShipActor оба имеют класс DecoratorFloat отвечающий за то что корабль/астероид/что угодно могло покачиваться в космосе.
Текстом я это опишу гораздо быстрее чем ты залезешь в инспектор разным префабам и добавишь этот класс объектам : )

Причина кроется так де в том, что переменные для поведения не хранятся в самом классе поведения. Для чего это нужно? Ну допустим тебе нужно узнать как сильно качается корабль в космосе из другого скрипта.

Логически то что ты сделаешь это протянешь связку : GetComponent(DecoratorFloat) и вытащишь переменную. Твой код начинает быть похож на паутину обращений друг к другу компонентов.
А что если ты удалишь компонент из игры? Придется править код в куче мест.

Поэтому вместо того чтобы думать категориями конечных объектов я думаю категорией информации. Я создаю класс который хранит например все вращения и положения для объекта. И уже и декораторФлоат и любой другой класс обращаются к этому классу содержащие только переменные.

Маловероятно что его я буду менять. А вот класс поведения - запросто.

В конечном итоге мне это позволяет развертывать и комбинировать новые объекты со скоростью автомата : )

Я могу практически мгновенно создать башню-пушку с лазерным щитом, тут же рядом сделать пушку без щита, третьей пушки присобачить лечение, четвертая пушка будет изрыгать истребители. Если мне нужно специфически описать поведение ТОЛЬКО для этого актера я могу смело описать это в коде актера или добавить компоненты-декораторы.

Все что для этого нужно это заранее написать скрипты для поведений.


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю



Сообщение отредактировал pixeye - Четверг, 09 Ноября 2017, 20:44
alexsilentДата: Четверг, 09 Ноября 2017, 20:45 | Сообщение # 17
почти ветеран
Сейчас нет на сайте
Цитата pixeye ()
Причина кроется в том, что я использую всего один monobehaviour на объекте для его логики. Связано с тем что используя кучу несвязных monobehaviour на префабе ты в них быстро начинаешь путаться и забываешь откуда ноги растут. Это просто из личного опыта.


Это я понимаю, у меня тоже немало скриптов на каждом префабе, правда до 12-ти вроде еще ни разу не доходило.
Но иногда неудобно. Хотя если это все будет в одном модуле, то свернуть только часть не получится, иногда удобно ненужную часть свернуть, и оставить только нужный скрипт. А если все будет в одном, то оно всегда будет развернуто?



Сообщение отредактировал alexsilent - Четверг, 09 Ноября 2017, 20:46
pixeyeДата: Четверг, 09 Ноября 2017, 20:53 | Сообщение # 18
Red Winter Software
Сейчас нет на сайте
Цитата alexsilent ()
Это я понимаю, у меня тоже немало скриптов на каждом префабе, правда до 12-ти вроде еще ни разу не доходило.
Но иногда неудобно. Хотя если это все будет в одном модуле, то свернуть только часть не получится, иногда удобно ненужную часть свернуть, и оставить только нужный скрипт. А если все будет в одном, то оно всегда будет развернуто?


Вот именно чтобы такого не было я пишу это через 1 компонент.

Выглядит у меня это примерно так:


Главное различие:
Мои компоненты добавляются к объекту после создания. Уже в игре. Я ими не оперирую в инспекторе ( только параметрами даты ) и не вижу их в инспекторе.


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю



Сообщение отредактировал pixeye - Четверг, 09 Ноября 2017, 20:54
alexsilentДата: Четверг, 09 Ноября 2017, 21:03 | Сообщение # 19
почти ветеран
Сейчас нет на сайте
PS еще мне не хватает "частичного сворачивателя" в юнити, например у меня есть скрипт, где описаны все предметы, которые можно подобрать, чтоб загружать например в инвентарь с абсолютно любой локации.
Пока их около 35 предметов, но когда количество вырастет до 100, то юнити начинает слегка притормаживать (тестировал уже), была бы возможность скрывать некоторую часть этого массива, чтобы не все 100 были одновременно на виду, было бы круто. Но это так, мечты)

Добавлено (09 ноября 2017, 21:03)
---------------------------------------------

Цитата pixeye ()
Выглядит у меня это примерно так

Вау, как круто выглядит *_*
pixeyeДата: Четверг, 09 Ноября 2017, 21:04 | Сообщение # 20
Red Winter Software
Сейчас нет на сайте
На самом деле абсолютно не важно как ты пишешь пока это для тебя работает)) в этом вся крутость) ты сам приходишь к выводам и оптимизируешь под себя :)
Убежал работать XD


ACTORS - мой фреймворк на Unity
Until We Die - игра над которой работаю

Форум игроделов » Движки для разработки игр и сложные системы разработки » Unity » пригорело по поводу ЯваСкрипта
  • Страница 1 из 2
  • 1
  • 2
  • »
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг