ООП - это для чайников (или историков машин 5-го поколения)
Вообще не понял, причём тут чайники и историки. Видно мы о разном говорим. История тут не при чём) Парню нужно решится, действительно ли он хочет написать движок и стать профессионалом в области программирования или ему достаточно будет готовых решений, т.е. рассматривать всё на более углублённом уровне он не собирается) Другими словами, хочет ли он написать свою технологию или воспользуется готовой)
Добавлено (22 мая 2016, 10:58) ---------------------------------------------
ЦитатаGudleifr ()
Как и любой программист
Ну не скажите) В отношении написания игрового движка такого не скажешь. Тут нужен чуткий профессиональный подход, оптимизация и системность, иначе это будет не двиг, а костыль, который никому не нужен, даже его созидателю) Я же займу позицию наблюдателя, потому как спорить об этом нет смысла)
Сообщение отредактировал ShortKedr - Воскресенье, 22 Мая 2016, 11:09
DeadDay, Что?!!?!? Вы хотите написать движок без ООП. Удивительно!) :D Не, не вариант без ООП и кучи математики) Прочитайте ещё раз мой пример, там несколько раз встречается слово/форма "унаследован", "базовый", "класс") ООП - объектно ориентированное программирование
Добавлено (22 мая 2016, 09:42) ---------------------------------------------
ЦитатаDeadDay ()
Можешь показать результат или хотя бы скрины чего нибудь?
В данный момент не могу. Ещё работаю над движком. Писать на нём что-то более менее серьёзноё ещё не начинал. Показывать пример игры Pinball или просто бегающего человечка не буду - думаю и так все знают, как это выглядит)
Сообщение отредактировал ShortKedr - Воскресенье, 22 Мая 2016, 09:54
DeadDay, ну смотри, тебе нужно реализовать все необходимые системы движка. Так как тебе не нужен общий доступ к движку, делай его как SDK. На C++ вроде как быстрее должно, потому как всеми аспектами использования памяти ты занимаешься) Но на С# тоже можно реализовать.
ЦитатаDeadDay ()
Движок будет создаваться только для своей игры. Не будет потом такого, что для общего пользования. И тем более для личной выгоды и денег. Нет, это я не планировал и не буду.
Надеюсь ты его не для одной игры собрался делать ^_^
Приведу пример, с чего я начал реализовывать движок для 2д игр под андроид на Java. Сначала я реализовал базовый класс для всех объектов, имеется ввиду игровых и подобных, реализовал все нужные механизмы, добавил методы, которые будут обрабатываться движком, что-то вроде OnStart, OnUpdate, OnDestroy. Далее сделал базовый класс сцены, которая является главным элементом контакта юзера и движка. Добавил туда обработку основных событий объектов через отдельный поток. Унаследовал от базового класса объектов несколько новых классов разновидностей объектов, добавил им всякий плюшки, анимацию, вращение спрайта и т.д. От базового класса сцены унаследовал два новых класса, один реализовывал графику под Windows, второй под Android. В тот же момент добавил Вьюпорты - камеры в 2д скажем так, для скрола сцены После реализовал систему обработки клавиш, она получилась аналогичной Unity3d. После этого я впервые его протестировал и написал небольшую демку с анимацией, прокруткой карты и бегающим человечком) Затем я реализовывал систему коллизий, систему звука, систему просчёта пути и т.п.
Первая часть делается достаточно быстро, а вот всё остальное...
Сообщение отредактировал ShortKedr - Суббота, 21 Мая 2016, 19:53
Скажу ещё... Всем кто является новичком или ещё не использовал такого метода: Попробуйте выстроить логическую цепочку решение вашей проблемы. Допустим вы придумали решение своей проблемы, но не знаете, будет ли оно работать. Попробуйте проанализировать его:
"Куча канвасов или элементы полукругом - выглядит не плохо, но не то, нет эффекта изгиба да и больше 1 canvas на интерфейс - это уже слишком). Идём дальше: дополнительный рендер с помощью камеры и наложение на цилиндрическую модель - уже лучше, но всё равно не то, т.к. лишние затраты на доп. рендер(хоть и не большие) и нужно добавлять кучу триггеров. Точно Canvas же выводится аналогично 3д модели, значит вероятно можно найти способ изменять его mesh, добавить изгиб. Ага, покапался в справке, нашёл UIVertex, нашёл в Unity3d компонент PositionAsUV1, почитал про него в справке, узнал, что он унаследован от BaseMeshEffect, увидел у него метод ModifyMesh, понял - это то что нужно. Исследовал 1-2 странички интернета или поковырялся сам, понял как он работает. Написал компонент изгиба mesh для UI элементов) С удовольствием закончил свою работу над этой задачей - принялся за следующую)"
Сообщение отредактировал ShortKedr - Пятница, 20 Мая 2016, 22:17
Lertmind, вопрос, собственно стоял в том, что бы погнуть canvas и его содержимое. Для этого: решение BaseMeshEffect. Но, да, можно и 3d mesh'ы тыкнуть, так даже лучше) Если предположить, что мы в старых версиях Юни(где не было UI), то эта задача реализовывалась за счёт 3d mesh'ей, преимущественно.
Добавлено (20 мая 2016, 18:48) ---------------------------------------------
ЦитатаBarbatos ()
А если серьезно, то множество канвасов это и есть ответ на твой вопрос.
Автору нужно скруглить интерфейс
Сообщение отредактировал ShortKedr - Пятница, 20 Мая 2016, 19:29
timur2008, а что значит в виде цилиндра - значит полукругом. Можно координату Z приплюснуть, но сейчас не об этом. Поищите способ выдернуть из canvas его рендер(материал, текстурку или ещё что-то), сделайте модель этого самого полуцилиндра, воткните в него эту текстуру, приделайте триггеры на места элементов и радуйтесь. Ещё вариант, откуда взять текстуру - выкинуть UI и рисовать вручную)
Другой вариант: Нашёл в справке UIVertex, думаю ясно зачем он) UI рендерится аналогично, как 3д модель(так можно сделать), можно попробовать покопаться в справке, найти всю нужную инфу по изменению вертексов и далее вас ждёт математика)
Добавлено (20 мая 2016, 16:55) --------------------------------------------- Немного покапал в этом направлении. Используйте BaseMeshEffect класс, на его основе можете написать класс, который будет автоматически изгибать элементы на Canvas, как вам надо, причём, каждый по отдельности) Работает, как компонент
Сообщение отредактировал ShortKedr - Пятница, 20 Мая 2016, 16:55
Minskii, первый вариант авто HotSpot на спрайте, но вроде он один(центр спрайта). Второй вариант - синусы, косинусы... Константой задаём позицию (относительно центра картинки) откуда пуля должна лететь при нормальной картинке без поворотов. В зависимости от поворота, при помощи синусов, косинусов расчитываем точку после поворота --> Создаём в точке пулю, запускаем в направлении дула)
Извиняюсь за неосведомлённость по поводу нововведений в GM, так как уже давно в нём не работаю) Вроде относительно этого ничего не поменялось)
Сообщение отредактировал ShortKedr - Понедельник, 16 Мая 2016, 17:30
Всё написанное стёрлось) Нехорошие браузерные жесты Минутку, сейчас напишу заново
Добавлено (15 мая 2016, 20:27) --------------------------------------------- Вот тебе моё оптимизированное решение: Скажем, создаёшь 3 тега "Enemy", "Player/NearEnemy" и "Player". Игрок на сцене один. Враги берут игрока по тегу и если он не null, то делают следующее:
Если дистанция меньше 5f(допустим), то ставим тег "Enemy", иначе "Player/NearEnemy" Часть с игроком: Далее игрок берёт все объекты наших ближних врагов(по тегу конечно), и по очереди, через цикл применяет свои насильственные действия
Ну или выкидываем часть с игроком и просто выполняем действия во врагах, так будет лучше)
Сообщение отредактировал ShortKedr - Воскресенье, 15 Мая 2016, 20:36
Sanprabhu, кординаты ты округляешь, а тип остаётся с плавающей точкой. Иногда при может получатся смещение(особенность скажем так), даже округлённые координаты будут выглядеть как 20.000000000001, а всё потому что это числовой тип с плавающей точкой. Делай тогда уж округление в проверке)
А вообще, так делать не хорошо, если у тебя, конечно, в игровой механике нет привязке к сетке) Как писали выше проверяй оффсетом - разницей между дистанцией
Сообщение отредактировал ShortKedr - Воскресенье, 15 Мая 2016, 20:30
NewbieDev, ну так, приступы эйфории и желание "расцеловать" игру во многом от графики зависит. Правильная графика может вызывать эйфорию даже в 8бит. Стоит заметить, то, что вы называете графикой - немного не правильно. Игровая графика - это лаконичное представление различных элементов, которые могут и сочетаются друг с другом, реализуют вместе целостную картину, которая может вызывать у человека как симпатию, так и наоборот)
В целом не плохо, но как-то много шаблонности что-ли. Попробуйте следующий сделать по собственным предпочтеньям... Например: Хочу FPS шутер. Хочу, что бы у игрока было основное оружие пистолет. Хочу, что бы второй рукой он мог отбрасывать врагов, используя импульс(типа магия).
После таких рассуждений начинайте делать) Я лично уже вижу, насколько это будет забавный шутер и насколько весело будет раскидывать регдолы врагов(живых), а они будут ещё что нибудь выкрикивать, когда их голова будет биться об стену и оставаться след крови. После они встают и пытаются далее избить гг Даже, если всё будет из кубиков и сфер(карта, враги, оружие и т.д.) - будет достаточно забавно) И реализовывается это быстро)
Человек, поигравший в это, думаю, поднимет себе настроение, следовательно уже отношение к вам и к вашим умениям меняется)
Сообщение отредактировал ShortKedr - Суббота, 14 Мая 2016, 19:23
Я боюсь, что во фрилансе, тем более зарубежном, нужны очень хорошие спецы.
Кстати там есть различные работы, по сложности. Самое интересное, сложность везде одинаковая(по исполнению на аналогичных заказах), учитывается опыт. Некоторые готовы взять на работу людей с меньшим опытом, а значит они соглашаются с тем, что человек может тратить большее кол-во времени на некоторые заказы и задания. Вот тут рассказывали про свой опыт работы на Upwork. Тык
Спецы разные бывают)
Скажу только, что вам нужен опыт, всё остальное у вас имеется, как я вижу) Опыт работы с клиентами, различными механизмами и т.п. А где можно взять опыт? Правильно - пойти работать туда, где вы получите этот опыт)
ЦитатаGudleifr ()
Основывается ли творчество на работе? Во-первых, творчество - это разновидность работы. И, к сожалению, именно та часть, которая не защищается всякими трудовыми кодексами и очень хреново оплачивается. Во-вторых, творчество должно иметь под собой возможность и желание что-то сотворить, что подразумевает наличие богатого жизненного багажа, в том числе рабочего.
Стоит ещё сказать, что можно по разному подходить к выполнению одной и той же работы. Можно просто работать, только ради денег и не вкладывать ни души, ни интереса. Можно работать, вкладывая душу, делать от души что-то, то есть с интересом и получать за это денежку. Гораздо интересней работать над тем, что для тебя ново. Что-то сложное, что ты уже делал, например недавно - не вызовет интереса и даже может вызвать упадок сил.
Когда я пишу очередную сложную систему, предназначенную для простого и быстрого решения чего-либо, и если её действительно долго писать, я обязательно её сохраню и буду использовать в других проектах. Это будет уже набор моих инструментов для решения тех или иных задач)
Сообщение отредактировал ShortKedr - Суббота, 14 Мая 2016, 13:00
8Observer8, что-то мне кажется, что идёт какая та недооценка самого себя. Если действительно "могёте", допустим сделать игрушку среднего уровня на unity, то начинайте заниматься практикой. Все эти уроки о том "Как красиво написать Hello World" никому не нужны. Каждый программист пишет по своему и как говорится: "Только программист может разобраться в своём коде". Практика подкидывает задачи, которые нужно решать, добавляет интереса, так сказать. То есть принцип "Работай и учись".
ЦитатаBarbatos ()
Я люблю рассказывать историю о том, как не понимая ничего в области создания мультиков и анимации, согласился сделать пяти минутный мультик, конечно, сделал я его где-то за месяц, но клиенты были довольны(при чем это люди из другой страны приехали).
Наглядный пример можно сказать)
Заказчик думает, что он рулит процессом создания продукта, но на самом деле этим процессом рулят исполнители, опираясь на требования к готовому изделию. Все же технические моменты и секреты, которые не нужно знать заказчику, по известной причине, скрываются)
8Observer8, не хотите попробовать поработать на UpWork. Это фриланс. Конечно заказов на Unity не так много как всего остального, но попробовать стоит. Очень много, прям очень много заказов на разработку под мобильные устройства. Я думаю вы это всё умеете и попробовать будет не лишним. Только нужен английский письменный
Сообщение отредактировал ShortKedr - Пятница, 13 Мая 2016, 17:37
Это да , но ты все равно не сможешь полностью избавиться от MonoBehaviour.
beril, а зачем? Это часть движка - способ связи движком) Если отказаться, то можно выкинуть Unity и взяться за написание своего движка. Через полгодика закончить основную навороченную часть, точнее ядро движка и приступить к реализации графического редактора))) Хотя я бы с своём движке графическую реализацию редактора выкинул, только код)
В итоге получится тоже самое, что будут способы связи с движком вроде MonoBehaviour, а без этого можно его так же выкинуть)
Сообщение отредактировал ShortKedr - Пятница, 13 Мая 2016, 12:43
8Observer8, да так и есть. Я бы сказал они настаивают. Ещё можете посмотреть Procedural Cave Generation. Наглядный пример создание более менее трудной системы где во всю применяется ООП. Автор, кстати, программист с не плохим стажем, который специализируется в основном на программировании игр, с созданием различных систем, которые в будущем упрощают жизнь) У него есть ещё несколько серий таких уроков, по написанию системы поиска пути и бесконечной генерации ландшафтов. Сейчас заметил, он решил сделать серию уроков по программированию для новичков, где расскажет все основы программирование, ООП и его широкое применение) Я так понимаю, мало кто из начинающих понял его размышления по поводу генерации и поиску пути. Мне же, лично, было интересно посмотреть знакомые для меня темы, взглянуть, какие свои особенные фичи он применит к своим системам)
Сообщение отредактировал ShortKedr - Пятница, 13 Мая 2016, 12:35
С этим не спорю :D Но сейчас не о работе, а о понимании) В крупных компаниях есть люди, которые как раз этим и занимаются - упрощают жизнь разработчикам)
Цитатаberil ()
Без MonoBehaviour большая часть API не будет доступна, нужны очень большие костыли будут....
Ну как сказать "будет недоступна", недоступна это вряд ли... Допустим я хочу создать объект на сцене, вызвав функцию из класса, который отвечает за дроп систему(не MonoBehaviour):
Код
namespace Game.Inventory{ public class DropSystem {
public static GameObject Instantiate(string itemName, int amount, Vector3 position, Quaternion rotation){
MonoBehaviour.Instantiate - создаёт объект на сцене, это мне и нужно Просто и красиво. Простым вызовом DropSystem.Instantaite я могу выкинуть в игровом мире предмет, который можно будет подобрать)
Сообщение отредактировал ShortKedr - Пятница, 13 Мая 2016, 12:26
