Узкая специализация конструктора это не столько следствие низкой квалификации его разработчиков, сколько свидетельство, что его дизайн - под проектные задачи, а не под эффектную рекламу.
Это скорее отговорка чем обоснование, на мой взгляд ;)
Понимаете, это никак не уживается с той логикой, что движок можно использовать гораздо эффективней под те же задачи, что и конструктор - вы всегда можете вносить корректировки и апгрейдить код, как движка так и проекта на этом движке. В то время как конструктор просто скажет вам: "Гуляй вальсом отсюда, у меня нет решения этой проблемы, мой разработчики не позаботились об этом, а проапгрейдить ловко и правильно ты меня не сможешь". А движок тем временем можно использовать под все задачи одинаково эффективно.
Движок - это по сути рабочий код, который решает множество типичных проблем, мы его можем улучшать можем вешать что-то сверху; Конструктор - это закрытая оболочка, преимущественно для "поиграться", или для людей не знакомых с программированием вообще, что также ограничивает их довольно сильно и даёт неправильное понимание происходящего
Добавлено (26 июля 2016, 04:44) ---------------------------------------------
Цитатаdimakoles ()
Могу я спросить, откуда такая осведомленность о возможностях профессионалов?
Вероятно я сам к ним отношусь, слова ниже(про 2д движок) ничего вам не говорят, не? =)
Разрабатывая конструктор вы потратите больше времени на внедрение в массы, написание граф оболочки и прочих интересных вещей, в то время как сами возможности конструктора будут не велики. И где же тут не реклама? Как думаете, почему движки для Java не рекламируются? - потому что это код, и он только для тех, кто реально готов с ним работать, понимаете
Сообщение отредактировал ShortKedr - Вторник, 26 Июля 2016, 04:51
Узкая специализация конструктора это не столько следствие низкой квалификации его разработчиков, сколько свидетельство, что его дизайн - под проектные задачи, а не под эффектную рекламу.
Нуу, как раз наоборот. Конструкторы лепят для рекламы, а движки для разработки и удобной работы. Квалифицированные опытные программисты умеют сделать движок-шедевр тратя меньше человека-часов и в дальнейшем упростив себе задачу разработки новых проектов на их творении, в то время как программисты или не программисты вообще, клепают конструкторы, говоря что им так проще, в итоге тратя в несколько а то и сотню раз больше времени. Живой тому пример - парень с этого форума который решил сделать конструктор на конструкторе, обосновывая это как раз незнанием сфера. Карл!!! Конструктор на конструкторе, вы понимаете суть трагедии? ;) Прошло 2 года с тех пор как он начал этот каламбур и что я вижу в итоге - редактор уровней для платформера с функционалом noobster.
Не думайте, я не собираюсь никого унизить или ещё что-то, просто нужно сначала научиться а потом уже покорять такие высоты. В сравнения, мой 2d движок с базовым функционалом, написанный за 2 недели может гораздо больше, а точнее всё что нужно для полноценной разработки, а это коллизии, просчёт пути, анимация, манипуляции с изображением, псевдо физика, система событий и много чего другого - и это подходит под все задачи, при этом при надобности движок можно развить в 3д.
Сообщение отредактировал ShortKedr - Вторник, 26 Июля 2016, 04:42
Alfe, не коверкай тут :D Я написал: "Далее F и Ctrl + T(Triangulate) =)" Имелось ввиду нажал F и далее нажал Ctrl+T - триангулировал огромный плейн. Конечно получится некое подобие полного П, но если автор захочет это исправить, тоооо, найдёт как это сделать
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 23:47
bodya_WM, а зачем выкуп, мы можем использовать кучу идеи и подавать их таким образом, что бы они нравились людям, понимаешь. Речь не идёт о покупке исходников и интелектуальных прав на игру. Речь идёт об использовании одной простой или не совсем идеи для создания топового контента. Или вы хотите сказать, что сделав шутер с сюжетом я нарушу авторские права, потому что у вас тоже шутер с сюжетом, хотя это совершенно две разные игры с разной подачей? Глупость
Возможно не в тему не много, потому что это было не мне, но всё же =)
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 19:56
Fejk2015, действительно большая температура вроде бы. Пыли много внутри, не? Или сказывается железо так? Расскажите как выключается, мгновенно? Могут быть проблемы с БП или батареей, как писали выше. Расскажите, что подключено к ноуту, когда он выключается... Может с контактами что-то?
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 19:37
falcoware, а зачем шлак? Можно шлак в конфетку превратить, я видел у вас интересные проекты, но не в плане реализации а в плане задумки. Если всё красиво, аккуратно, няшно сделать, по феншую - получится не самый плохой вариант и заработать можно =)
Порой даже самую банальную и избитую идею можно подать так, что бы все сказали: "Вау!" =) Вывод: нужно делать вложения в художников и графику, а потом попросить талантливого программера всё это склепать вместе =)
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 18:54
Да, да знакомо - фишка UI, вот и приходится извращаться со scale и прочими штуками =) Понаблюдай за изменениями элементов в зависимости от разрешения экрана, возможно было бы интересно сделать, что бы scale вычислялся в зависимости от размера рендера. Ещё UI это же 3д техника, может лучше будет, если overlay на render перед камерой заменить
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 17:33
EchoIT, это позволяет избежать артефактов так называемого обратного соотношения. Когда у тебя 16:9 соотношения то всё нормально, а вот если, например становится противоположное соотношение, например на квадратных мониторах оно далеко не 16:9, то получается, что элементы лезут за пределы экрана. Вот для решение этой проблемы данный код.
Смазывание я решал довольно просто: уменьшаешь scale элементов на 20%, а размер повышаешь на те же 20% и в canvas убираешь pixel perfect. По моим наблюдениям, именно pixel perfect порождает эту проблему. Ну а scale просто для резкости Упоротые идеи решают все проблемы
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 17:17
EchoIT, нууу, относительно, с полукругом долго заморачиваться нужно =)
Добавлено (25 июля 2016, 15:17) ---------------------------------------------
ЦитатаEchoIT ()
Я, если честно, к новому UI ещё не привык, и изучаю его потихоньку. До последнего пользовался ещё guiTexture и guiText.
Неприличная особенность UI - это много, просто неприлично много классов MonoBehaviour =) Вторая особенность - У тебя сразу рисуются все объекты и что бы что-то убрать, нужно это найти и удалить. Третья особенность - 3д вывод, UI имеет 3д mesh для каждого элемента, можно искривлять UI как вздумается =)
И есть один секрет тёмных эльфов для правильного соотношения сторон, когда у Canvas Scaler есть ползунок Width-Height:
Код
using UnityEngine; using System.Collections; using UnityEngine.UI;
namespace Game.UI{ public class AutoMatch : MonoBehaviour {
public CanvasScaler scaler; private Vector2 lastScreenSize = Vector2.zero;
Lertmind, класс типа не меняет размер массивы или я что-то не понял? =) Остался один вопрос: "Искривиться ли оно полукругом правильно, или придётся кучу доп. точек добавлять?"
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 14:57
EchoIT, упоротые идеи - это всегда хорошо, хоть разнообразия появляется, появляются люди которые не повторяю(изобретать велосипед скучно). Вариант выше работает, да. О кривых я тоже думал :D
EchoIT, знаешь, что сделал бы другой человек с этой проблемой - пошёл бы искать ассет :D Поэтому, ещё раз говорю, я просто обожаю "упоротые" идеи и их авторов =)
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 14:48
Делаешь отступ по ребру, ставишь условные точки, на середине линии их соединения будет центр окружности, 2/3 расстояния от центра до основной вершины - это радиус и остаётся угол расчитать тангесом, поделить его на 2, затем точки посчитать и всё =)
Сообщение отредактировал ShortKedr - Понедельник, 25 Июля 2016, 14:34
