Что же касается инвестиций или интереса - это маловероятно. Однако у издателей давно появились свои "фермы" по игрострою - ты можешь попробовать договориться с ними.
Типа https://wargamingalliance.com ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 15 Декабря 2017, 15:10
Может мэйл-ру групп и не запинают, но для простого человека есть риск потерять несколько месяцев расчетов и мозгового штурма, просто показав результат не тому человеку.
никакого. Абсолютно. Это известное заблуждение. Нам всем хочется верить что наша идея именно та самая. Так думает каждый и тот кто действительно в теме много работает не может сидеть сложа руки ожидая судьбоносной встречи с тобой чтобы получить идею/концепт/документ. Он уже во всю пашет над своими.
Представь что ты уже на середине своего пути со своей игрой ( и это заняло например пол года ). Тут прихожу я с горящими глазами и рассказываю тебе о своей гениальной задумке. Что? Ты бросишь то что делал пол года и переключишься на мой "концепт" - который всего лишь концепт? Стоимость идеи стоит ничего. Реализация - всё. Чтобы реализовать хорошо идею надо много граблей пройти даже в безобидных вещах. Это труд.
Это проблема менталитета. Уверенность что ты тот самый , а кругом все спят и видят как обобрать.
Цитатаmim2002 ()
Сразу оговорюсь, я не программер, не музыкант, не художник и самостоятельно реализовать такое для меня нереалистично.
Цитатаmim2002 ()
В этом документе подробно изложено все- .... до расчетов скоростей передвижения, размеров игровых полей, эскизов интерфейса, моделей и пр.
И каким образом ты это сделал? На глаз? Я уже с десяток лет игры делаю и то не смогу без начала работ тебе точно сказать про цифры размеров и прочая. Нюансов куча начиная от движка и заканчивая костылями которые обязательно появятся. Такие вопросы решаются в процессе работы c небольшим забеганием вперед. Откуда ты знаешь что именно эти "скорости" будут правильными/интересными/играбельными?
Исходя из того что ты описал вижу ход вещей такой:
- Ты находишь квалифицированного геймдизайнера. Еще лучше с опытом законченных проектов где он выступал в роли лида. И просишь дать оценку твоему концепту/документу. ( За денежку или как договоритесь ) Общаетесь, приходите к каким то новым мыслям, правите документ.
- Ты находишь программиста который начинает набрасывать общий вид того что вы в предыдущем пункте оговорили.
- Правите/подгоняете прототип
- На основе прототипа принимаешь взвешенное решение тратить ли дальше время и деньги.
Так как ты не идешь по пути инди ( твоя ценность в разработке нулевая ) - то ты оплачиваешь всё и конечное качество продукта уже будет зависить от того уровня исполнителей которое сможешь себе позволить. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Пятница, 15 Декабря 2017, 15:04
ашел способ, делать канвас дочерним. А можно как-то сохранять ссылки на внешние канвасы ?
Ты не способ нашел, а просто сохранил канвас в префабе. Ну подумай сам. В чем логика? Префаб может быть использован на любой сцене. Если бы он хранил ссылки на объекты конкретной сцены то уже не было бы смысла.
Для связки компонентов у тебя есть методы Awake/Start/OnEnable(иногда)
Дорогие друзья! Спешим сообщить Вам, что мы получили письмо от ЕА GAMES с убедительной просьбой закрыть проект. У нас все. Это п*здец!
Не парься : ) В свое время близы хотели сделать игру для вселенной вахи, те заартачились и получился мир варкрафта. Тебе никто не сможет помешать делать игру в околосхожем сеттинге) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
тут нечего подходящего не обнаружил..либо в глазки долблюсь нещадно)
Ты аккуратнее с долбежом. Вредно это.
Непредставляю зачем тебе такое вообще нужно но почему просто не сделать корутину на 1-2 кадра? ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Выглядит эффектно. Щит какой-нибудь у корвета будет? По силе выстрела создаётся впечатление, что корвет не должен выдержать более одного залпа.
Щиты будут, а корвет действительно будет мало выдерживать ударов. Нужно быть аккуратным : ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Воскресенье, 12 Ноября 2017, 11:31
Люди те еще копрафилы и онлайн для меня ничего не значит.
Спорить бесполезно. Ты кстати тоже человек. C очень резкими суждениями. Это всегда вызывает противодействие со стороны. А ты просто ограничиваешь себя отрицанием.
Например я могу с тобой согласиться что пабг тебе и мне не нравится. Но называть такую игру посредственностью/зашкваром.. недальновидно. Вот хотя бы представь что ты нашел программиста для своей MMOFPS. И тут ты такой - да ПАБГ - зашквар. А он фанат этой игры. Получается, человек тот же еще копрафил и зашквар. Как думаешь, захотят с тобой работать? Я бы не стал. Просто неприятно. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
PS В принципе, попробую просто погуглить на Add Behaviour
ты вряд ли найдешь инфу так как я просто делал свою систему.
Я ее собираюсь описывать и даже частично начал в видео подводить к этому, но там немало всего надо донести будет. Если тебе интересно то читай про инъекции
Если пока сложно и непонятно то не парься. Не рекомендую в корне менять свой подход к написанию. Привычки штука сильная. Это видео рассказывает как работать со скритабл обджектами - оч мощная штука в юнити о которой часто забывают. Она подтолкнула меня в свое время на разные мысли.
Закроют меняй текстуры и имена : ) На самом деле выглядит классно. Каким бы хобби не было, труд большой и не хотелось бы чтобы он просто исчез в комоде. Имхо ) ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
На самом деле абсолютно не важно как ты пишешь пока это для тебя работает)) в этом вся крутость) ты сам приходишь к выводам и оптимизируешь под себя Убежал работать XD ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Это я понимаю, у меня тоже немало скриптов на каждом префабе, правда до 12-ти вроде еще ни разу не доходило. Но иногда неудобно. Хотя если это все будет в одном модуле, то свернуть только часть не получится, иногда удобно ненужную часть свернуть, и оставить только нужный скрипт. А если все будет в одном, то оно всегда будет развернуто?
Вот именно чтобы такого не было я пишу это через 1 компонент.
Выглядит у меня это примерно так:
Главное различие: Мои компоненты добавляются к объекту после создания. Уже в игре. Я ими не оперирую в инспекторе ( только параметрами даты ) и не вижу их в инспекторе. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 09 Ноября 2017, 20:54
Например корабль, у него же есть объект пушки, вот туда бы и повесил, лишним скриптом бы тут был бы для меня Хранилище поведений, если бы я только не захотел бы получить доступ из другого скрипта, но я бы просто бы другим скриптом через GetComponent бы применил и оттуда бы воровал переменные или бы вмешивался в работу
Ты думаешь абсолютно в верном направлении. Я тоже так думал. Еще года полтора назад.
Моя структура выглядит так:
Actor ( это monobehaviour ) , каждый уникальный игровой объект является актером. Например астероид будет ActorAsteroid. Это монобехейвер и через него я общаюсь с юнити. Каждый актер имеет массив компонентов. Это обычные классы не наследуемые от monobehaviour и отвечают за логику. Каждый актер имеет отдельный класс даты который хранит всю нужную дату для работы с компонентами.
Например AsteroidActor и PlayerShipActor оба имеют класс DecoratorFloat отвечающий за то что корабль/астероид/что угодно могло покачиваться в космосе. Текстом я это опишу гораздо быстрее чем ты залезешь в инспектор разным префабам и добавишь этот класс объектам : )
Причина кроется так де в том, что переменные для поведения не хранятся в самом классе поведения. Для чего это нужно? Ну допустим тебе нужно узнать как сильно качается корабль в космосе из другого скрипта.
Логически то что ты сделаешь это протянешь связку : GetComponent(DecoratorFloat) и вытащишь переменную. Твой код начинает быть похож на паутину обращений друг к другу компонентов. А что если ты удалишь компонент из игры? Придется править код в куче мест.
Поэтому вместо того чтобы думать категориями конечных объектов я думаю категорией информации. Я создаю класс который хранит например все вращения и положения для объекта. И уже и декораторФлоат и любой другой класс обращаются к этому классу содержащие только переменные.
Маловероятно что его я буду менять. А вот класс поведения - запросто.
В конечном итоге мне это позволяет развертывать и комбинировать новые объекты со скоростью автомата : )
Я могу практически мгновенно создать башню-пушку с лазерным щитом, тут же рядом сделать пушку без щита, третьей пушки присобачить лечение, четвертая пушка будет изрыгать истребители. Если мне нужно специфически описать поведение ТОЛЬКО для этого актера я могу смело описать это в коде актера или добавить компоненты-декораторы.
Все что для этого нужно это заранее написать скрипты для поведений. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Сообщение отредактировал pixeye - Четверг, 09 Ноября 2017, 20:44
Я тоже например вот этот скрипт сделал для того, чтобы использовать на любом объекте, которому нужно постоянное вращение или движение, не только к одному единственному, а вообще к любому к какому захочу, и этот код не разделен на два кода, в чем смысл разделять на две части? Есть какой-нибудь простой урок для чайников? (То есть другими словами, как это понятие называется, я погуглю) а то выглядит очень сложно для меня, т.е. зачем их разделять на два скрипта, когда можно было бы функции в одном скрипте все написать.
Вот кстати твой код: 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#, там вроде нужно полностью вектор писать, еще и всегда добавляя лишнее слово new перед вектором(( (не люблю, лишнюю писанину, придется привыкать)
разумеется. В javascript это делали ( new ) за тебя. Считай, что ты с автоматической коробки пересел на ручную. Оно действительно не лишнее а осмысленное.
new нужен потому что ты не меняешь векторы, а создаешь новый. Вектор это структура и при ее создании нужно инициализировать все параметры. https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/ почитай про классы и струтктуры.
ЦитатаInsaneSystems ()
не углубляясь далеко в дебри ООП
тебе необязательно писать в стиле ООП. ООП - это парадигма. Можешь хоть процедурно программировать.
Тебе кстати ничего не мешает написать свой синтаксический сахар для векторов в C# чтобы избавиться от NEW
Кода в С# описывать надо точно меньше. Это прям к гадалке не ходи. Но сколько ты будешь в действительности писать кода не зависит от языка, а от того как ты пишешь и как много пишешь одного и того же.
Например мой код выглядит так:
Я описываю логику модулями и храню переменные группами по смыслу, а не по объекту. Единожды описав поведение вращения пушки например я это потом могу использовать для любой пушки в игре. Первый скрипт относится к кораблю и является хранилищем всех поведений, второй скрипт реализует поведение пушки.
PS Если б с самого начала не было бы выбора, то я б в любом случае бы уже выучил С#, но я выбрал более легкий язык, ибо я не программист, а художник, и мне бы что попроще, поскольку был выбор и всегда говорили, что он поддерживается на 100%. PPS Интересно с какой версии прекратится поддержка ЯваСкрипта, какой примерно срок? Есть где-нибудь информация по этому поводу?
если ты пишешь на яваскриптах то без проблем сможешь писать на C# скрипты. Даже удивишься насколько синтаксис C# чище и выразительнее в сравнении с яваскриптом. ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Я себе представляю что игра больше похожа на Divine Divinity по геймплею. Надеюсь вас купят EA и вы допилите игру официально XD ACTORS - мой фреймворк на Unity Until We Die - игра над которой работаю
Спорить бесполезно. Ты кстати тоже человек. C очень резкими суждениями. Это всегда вызывает противодействие со стороны. 
