Сценаристам можно ещё книги писать. Если постараться и достигнуть тиражей от 10 тысяч, то уже за книгу тысяч 150-250 можно выручать, а сейчас издатели требуют книгу в течение 4 месяцев, и обязательно серию.
Да и посчитай расходы на содержание на своем хостинге такого проекта.
3 бакса-месяц, если на smartasp брать хостинг.
ЦитатаTLT ()
Если только начать новый портал на Вордпрессе на выделенном сервере,
Можно попробовать без cms. django, asp.net - простор в выборе функционала, теоретически перенести все получится. Главное найти специалистов. Правда, стоит ли все это трудов, когда проблемы вообще не критические. Во всяком случае, видимые.
Как известно, юнька не умеет сериализовать многие типы, например Dictionary<TKey, TValue>, следовательно данные не сохранятся.
Тут не совсем в юньке дело, а в самой версии .net, которая заложена в неё. Да, именно из-за этого пришлось создавать собственный класс, просто это оказалось быстрее и проще, чем реализовывать интерфейс. Просто у класса и свойств задал парочку атрибутов [XmlRoot(string name)] и [XmlElement(string name)], так получилось быстрее для корректной xml. Хотя изначально вообще через XmlDocument создавал xml, но когда дошел до сохранения, стало влом описывать вариант сохранения и решил, что сериализация мощнее и быстрее) п.с. надо будет попробовать что-то подобное, как у тебя написать, после конкурса...
Сообщение отредактировал xMoonGuarDx - Среда, 22 Июня 2016, 16:01
Все нравится, наоборот крутая штука Речь шла о том, что как раз графический вид для юньки, занял у меня львиную долю реализации (просто начинающий, первый раз смотрел что там можно вообще сделать), а не сама сериализация или логика.
ЦитатаShortKedr ()
В будущем было бы полезно добавить языки, а именно их список и возможность добавлять дополнительные языки
Да, это тоже отмечал. По факту это уже есть, логика под это написана. Просто GUI для добавления самого кол-ва языков пока не добавил. А так все поля языковые формируются автоматом, от заданного количества языков. п.с. редакторы классные. В description у квестов даже вижу вроде что-то скриптовое, любопытно. п.п.с. а ты что именно из предметов сериализуешь? Все? Просто вижу, что там подгружаются сами префабы, они сериализуются как-то? художник кстати тоже через юньку работает? Т.е. check library проверяет изменения в xml/json/etc на гите?
Сообщение отредактировал xMoonGuarDx - Среда, 22 Июня 2016, 14:35
И в чем сама проблема? Конкретные вопросы? Неплохо было бы сначала почитать материал, потом попробовать и вот уже конкретные вопросы, где возникли заминки, спрашивать.
Kempston, идея с морским боем выглядит интересной. Как вариант, можешь сделать разные виды ядер типо обычное ядро, картечь и т.д. Кстати, как вариант, при выстреле можно прикреплять камеру к ядру, что бы игрок летел вместе с ним, особенно если карта будет не маленькая. Но стоит сделать возможность отключения этой функции.
Не так выразился, то, что это дно и тоже действия я в курсе, просто в плане производительности разница есть или нет интересовался. Просто скармливаю все же GO... Профайлить пока возможности нет. Но как я понял тут свои тонкости серриализации.
В статье, что Lertmind, скинул выше скинул, как раз идет речь о производительности и сравнении методов. Почитайте. Очень смутно помню SR. Если будете делать каждую систему, как префаб, то тут явно вам поможет такой шаблон, Пул Объектов. Так как наверняка префаб системы будет большим и постоянно вызываться. Только не забывайте при убирании его в пул, обнулять состояние системы и обновлять, когда достаете из него. Жизнью ботов пусть занимается какой-нибудь менеджер ботов, который помечен, как неубиваемый объект при смене сцен (если у вас несколько игровых сцен). Только упростите логику просчетов поведения ботов, когда они не видны игроку.
Я бы посмотрел на реализацию) В моем движке что то похожее сделано.
Если говорить о технических аспектах, то это не выглядит столь интересно. Поскольку для отрисовки GUI я использую API unity3d. Сама xml-ка составляется с помощью сериализации в .net. Единственный наворот, что пришлось сделать обертку текста в [CData] что бы любые символы отображать. Но это так, что бы говорить "он может в любой текст", по факту врятли это будет использоваться Из минусов, что я вижу, это конечно неудобство, когда будет много текстовых элементов (нужен поиск и категории), а так же если будет большой текст (надо дать возможность заполнять в больших текстовых полях значения)
В качестве основы для TBS в юньке буду использовать такой ассет, как Turn Based Strategy Framework. Это очень классный такой "шаблон", имеет неплохую кастомизацию на первый взгляд, если верить документации. А ещё очень активный создатель, который ответил мне в течении суток на мой вопрос. Из плюсов так же стоит отметить бесплатность ассета. Из текущих минусов, с которыми я столкнулся пока, так это невозможность делать юнитов, которые занимают два и более шестиугольников (как в героях 3 - драконы). А я все же хотел обыграть размер юнитов на поле, из разряда "я слишком жирный, я сюда не влезу". Я как раз по этому поводу писал разработчику, он указал, какие элементы надо будет переопределить и возможные проблемы, в общем это слишком много для двух месяцев на первый взгляд. Поэтому я решил сделать более интерактивными сами гексы (т.е. разрушение мостов под весом юнита, замедление на более мягкой почве более тяжелых юнитов, или замедление легких при сильном ветре. Т.е. придеться обыгрывать именно вторичные характеристики, которые связаны с размером.
Сообщение отредактировал xMoonGuarDx - Вторник, 21 Июня 2016, 07:33
Суть плагина в том, что бы я из юнити мог описать все элементы текстовые, по ним составляется xml, которую потом кушает игра и может переключаться между языками. Т.е. просто стало лень руками составлять такую штуку, вот и прикрутил плагин. В дальнейшем хочу, так же как у l2 сделать подключение к гугл-таблицам и синхронизацию. Но это все после конкурса. Так же, если будет кому интересно, оформлю небольшую документацию, приведу в порядок и выложу в открытый доступ плагин, но опять же, после конкурса.
Название: Carnage metal Разработчик: xMoonGuarDx Жанр: TBS (turn-based strategy) Среда разработки: Unity3D Платформа: PC Описание: (временное) Далекое будущие, уже не первое столетие идет колонизация человечества. Дик - капитан небольшой передвижной базы на одной из колонизированных планет. Промышляет перевозом грузов между городами. Времена нынче неспокойные, идут постоянные распри за ресурсы между организациями. Вот и сейчас Дик взялся за горячий заказ с доставкой важного груза - местной “принцессы”.
Игрок действует на двух картах: стратегическая и тактическая. У игрока конечная цель доставить груз из точки А в точку Б на стратегической карте. Стратегическая карта состоит из шестиугольников. На каждом из которых генерируется событие. На тактической карте происходит сражение. Поле состоит из шестиугольников. Каждый из шестиугольников имеет различные характеристики, некоторые из них могут быть разрушены под различными воздействиями (например вес юнита). На тактической карте игрок управляет набором роботов. Роботы делятся на типы и имеют ряд уникальных модификаций, которые влияют на их параметры. Маленькие роботы более маневренные, большие роботы имеют более широкий арсенал вооружений, следовательно с их помощью легче получить некоторые тактические преимущества. Игрок перед каждым боем комплектует команду роботов, в зависимости от типа задач, которые ему необходимо будет решить на тактической карте (не всегда все сводится к полному уничтожению противника).
Если верить тому, что я хочу реализовать, идея будет раскрыта при помощи размера роботов. Для одних задач будут требоваться маневренные роботы, для других будет в приоритете огневая мощь, в третьих количество самих роботов, где-то их потребуется больше, где-то меньше. В общем основная идея - это тактические бои с разными условиями, где и будут обыграны "размеры" юинтов путем вторичных характеристик (как пример, больше размер -> больше вес -> хуже проходимость на местности, как следствия нельзя будет пройти такие места, как мост или для типа местности для которой характерны узкие пространства имеет смысл брать более мощных юнитов в ущерб количеству юнитов)
16.09 - Составляется диздок. Идет параллельно всем задачам. 17.09 - 19.09 - Написание плагина unity для локализации 20.09 - Настройка окружения unity: создание широковещательной рассылки (событийная система), система управления менеджеров.
Так как графен не завезли, скорее всего игра будет геометрического формата, т.е. из кубов, треугольников и шаров xD Хотя глянул ассеты, есть весьма вкусные с небольшой стоимостью, может их закину. В общем искать надо, но т.к. преимущественно я программист, то и стремлюсь больше в эту сторону :) Вообще давно хотел написать что-то в жанре TBS. Посмотрим сколько для конкурса успею.
Сообщение отредактировал xMoonGuarDx - Вторник, 21 Июня 2016, 08:12
Хочешь заниматься разработкой игр? Делай игры. Другой рецепт едва ли есть. А так, либо художник, либо программист, либо что-то связанное с музыкой, если говорить об инди-проектах. Ибо отдельный геймдиз в самом начале там точно не нужен, только лишнюю денюшку, без того маленькую жрать будет. Насчет художников, музыки и текстов сказать ничего толком про универы не могу. А насчет проганья - универ полезен тем, что дадут мат.базу хорошую, структуры данных расскажут, да и довольно много интересного из математики затронут, а так же в хороших универах про шаблоны проектирования расскажут и покажут, все это нужно будет для разработки ИИ в играх и оптимизации самих игр, что бы потом не удивляться, почему змейка на юньке для мобил жрет все ресурсы флагманских телефонов. Играм там конечно учить не будут, тут самому изучать движки, основы построения и прочее. Сейчас уже 4 года в основном, это конечно много, но тебе никто не мешает параллельно заниматься своими делами. Будет диплом, будет основа, ну и будет то, что ты заложишь параллельно в себя на самостоятельном изучении. Это только один из путей, который описывает плюсы от поступления в вуз программистом. Они не абсолютны и все это можно получить и при самостоятельном изучении. Так же это является лишь моим мнением.
А попытка немного автоматизировать мои измышлизмы не только не поддерживается современными WEB-фичами, в которых просто нет того, что не имеет очевидной визуализации, но, более того, противоречит самой идее WEB-бизнеса, требующей отдельно покупать "весь комплекс услуг" ради одной разнесчастной фичи.
ЦитатаGudleifr ()
(Зачем мне покупать новый Visual Studio, если мой FORTH, писаный на коленке за пару недель, может то же самое?)
Учитывая, что вы написали аналог VS на коленке за пару недель, вам не составит труда, за недельку написать абсолютно любую функциональность, которую вы хотите, разработав под неё нужные вам инструменты и продвигая нужные вам идеи, если конечно, современное железо позволяет реализовать ваши идеи. Хотя я лично, очень скептически отношусь к возможности этой, конечно, если вы под VS имеете ввиду только блокнот с подсветкой, то утверждение выше не имеет силы. п.с. кстати, используйте бесплатную версию. ЗАчем покупать? Она практически такая же функциональная, как и про-версия. Покупать придеться, если парк более 100 машин, обороты выше 1 млн (могу ошибаться с суммой, надо смотреть лицензию) и в вашей команде свыше 5 человек, использующих студию.
ЦитатаGudleifr ()
С этого момента задача программирования - заменить 1 инженера-программиста на 100 рабов-кодеров, 1 кассира/секретаршу - на 100 операционистов.
А вот это что-то не так, насколько я могу судить. Увеличение уровня производства не является прямой(линейной) зависимостью от количества сотрудников. Более того, при определенном количестве для определенной задачи есть некоторая критическая точка, после которой добавление новых кадров влияет отрицательно. Я не знаток области, но уверен, можно нагуглить что-нибудь в теории управления или в теории систем, какую-нибудь стройную теорию, которая описывает сей процесс. Так вот, к чему я это? А к тому, что бизнес не старается заменить одного классного спеца - 100 хреновых, ведь каждый адекватный бизнесмен понимает, что это несет вред, нежели пользу. Просто все стараются наращивать производство, ибо спрос пока большой, и он увеличивается, а боевого резерва не очень-то и много (а ресурсы команд ограничены). И если верить мониторингу вакансий программистов на hh, то как раз можно заметить, что просто жуткий спрос на хороших спецов.
Все же, стоит продемонстрировать своё портфолио, если оно есть. Ну и стоит учесть, что команде, которой нужен сайт, дешевле не специалиста за 40к держать постоянно, а единожды заказать этот сайт за 30-60к (не думаю, что игровой команде нужна будет функциональность сложная). Поэтому при портфолио вы выиграете себе пару бонусов и вам дадут кредит доверия, за счет которого с вами и свяжутся. офф-топ:
ЦитатаOrdan ()
Не буду огорчать но сайт может сделать любой человек несвязанный с программированием вообще никак т.к. в нете очень много конструкторов великолепного качества. Яркий пример, мой друг художник всего за два дня сделал своей компании сайт. До этого он ни разу этим не занимался.
Не, в корпоративном секторе вообще не вариант. Это, увы, не так легко. Надо знания, начиная от различных бд (реляционных, NoSql и т.д), паттернов проектирования и заканчивая знаниями библиотек из фронтэнда. Хотя, если говорить о сайтах-визитках то да, там главное шаблон красивый сделать и натянуть. Тоже являюсь разработчиком asp.net.
