Tramp Coder
Дорогая игрушка)
Может это крепеж для шариков или флага неудачи?
Слушаю Ютуб радио из любимых игр
Задачи из реального мира нужно искать. Посмотрите на вакансии, которые вам подходят и нравятся. Может найдешь идеи куда смотреть. Ещё как попробовать, напиши липовое резюме на удалённую работу. Будут приходить предложения, с немного конкретной информацией. Тоже ориентир небольшой.
Выбрав направляющую, попробуй сам составить задачи под какую-то концепцию.
Если это бэкенд, то посмотри что в вакансиях пишут на требования разных api, те же платежные системы или внешние сервисы.
Рекомендую в игры. Весело задорно и как написал автор, всё может уместится на размер визитки, а не вот это всё мимолётное
И как вам дедушка Билл в живую? Для меня он в свое время был один из кумиров что-ли. Я так понимаю, это была конференция в Москве. Он тогда третий раз посещал посещал Россию.
Лично у меня тоже есть пожелание к усилению акцента. Но я программист в проекте и доверяю художникам. Были комментарии в прошлых статей, что лучше оставить как есть. Наверное в следующих можно провести голосование.
Что касается обводки персонажа, скорее всего точно нет. Я пробовал накинуть шейдер и игрался с ним, выглядит плохо. Не вписывается.
Цветовая палитра возможно изменит положение, могу также это проверить написав шейдер.
Спасибо. Стараемся.
По поводу вставок рисованных - будут. Скорее всего будут анимированные иллюстрации в катсценах. Их же потом вставим в другой трейлер, уже ближе к релизу.
Засрать раздел геймдев ссылками на чужой материал )) А как же авторство и интересные диалоги с аудиторией
а смысл? знаешь сколько обучающей информации по геймдеву, если каждый будет делится и кидать ссылку на чужой источник и все вопросы туда, ну как бы зачем... тем более тема шейдеров непростая
Ох уж эта тема) геймдизайнер и планы. В небольших проектах так мало людей и времени, что про ачивки начинаешь думать уже перейдя порог порта под платформы. У нас маленькая команда и первый проект с ачивками был в самом конце. Когда игра уже есть и при входи в тот же мир playstation мы долго думали над ачивками. Там тем более есть свои правила, та же платина. Как разобрались с правилами и инструментами, начали расставлять триггеры на ачивки, рисовать картинки и придумывать названия.
А ачивка как сущность на стороне платформы, может ли иметь счётчик обращения. Например, если нужно убить 10 врагов и есть такая ачивка, можно ли в апи ачивке указать количество обращений, чтобы не хранить их на своей стороне? Это бы реально сняло часть кода на стороне игры
Ну чувак. Ссылка на другой не свой источник и вопросы все туда.
Это точно
Не знаю как у других, но я начинаю планировать архитектуру не сразу. После первых черновиков основных механик - архитектура начинает подсказывать что с ней делать. В итоге конечная логика в ней перестраивается несколько раз. И конечно все зависит от опыта. Проходит год и ты смотришь на это немного по другому. И если есть возможность, то выносишь правки. Хорошо когда за спиной уже не один проект. Но для меня это был наверное первых, где пришлось очень много делать проверок, проб и ошибок.
Как бы такой велосипед и у нас. Есть один поток и в нем разные блоки, которые хранят объекты для обновления. А сами объекты уже туда могут добавляться и удаляться. При необходимости можно каждый блок вынести в отдельный поток.
Ух мне тоже предстоит этим заниматься в ближайшее время, только под все платформы и для Юнити. Спасибо что напомнили)
А как дела обстоят с проверкой достижений пока игра ещё не залита? Есть ли в Стиме инструмент, который позволяет это виртуально отладить и визуально увидеть?
Спасибо за отзыв, попробую ответить на ваш вопрос.
Когда-то давно, изучая тему оптимизации, я натолкнулся на ряд статей, например вот эту:
https://blog.unity.com/ru/technology/1k-update-calls
Что касается метода Start, так сложилось со временем, мы перестали использовать его совсем из-за архитектуры, которую выстрадали. "Управляющий уровнем" на старте сцены собирает все объекты со сцены. Ищет там ряд интерфейсов. Создает и восстанавливает различные объекты окружения, врагов и прочее. У этого работяги есть свои состояния или этапы: факт загрузки сцены, сбор и идентификация объектов, создание противников, инициализация объектов (вместо Start), восстановление состояний объектов, создание доп. объектов (например, места урона противников). Так мы, в том числе, понимаем на каком этапе загрузка сцены и какое значение прогресса загрузки отображать в UI.
Я вас понимаю) ECS у нас не используется. Начиналось все стандартным подходом. Потом начали городить свои велосипеды. Есть даже в архитектуре часть, где объектом управляет скрипт, который не крепится к объекту как компонент. Например, враги собираются на сцене в объекты используя данные из scriptableobject. И ими может управлять уже более глобальный блок. Но наверно я расскажу об этом в другой раз.
В данном примере просто наследование основного объекта от MonoBehaviour. Если кто-то хочет использовать ECS - пожалуйста. Я не стал описывать и делать акцент на ECS. Хотя это один из вариантов куда можно двигаться дальше. Цель статьи немного в другом. Усложнять не хотелось.
Не совсем понимаю, можете привести пример пожалуйста?
Здесь наследование, композиция не подходит, так как нужно размещать объекты в виде компонентов. Чтобы настраивать параметры в Inspector. Например в Inspector настраивать связи с другими объектами, которые реализуют интерфейс IInteraction.
Постараюсь ответить на все вопросы. Техническая часть статьи была на мне
А я тоже баги ловил в ноябре 2019
А моя бабушка говорила: не прекидуйся шлангом
Так речь ведь про обучение когда умеешь программировать. Конечно это субъективное мое мнение. Сужу по себе. Помню была свободна неделя, я решился на юнити. Пара дней и уже могу базовые вещи делать через код. Главное больше практиковать. Через неделю пробовал повторить разное. Ютуб видео смотрел. И самое главное, использовать официальный источник, все что есть на сайте юнити.
Моя мысль в том, что прежде чем планировать свой проект, нужно базу знаний отработать. Ведь производство своего продукта это большой процесс. Вкатывать в него свое время, тем более прыгать на фултайм, это должно быть взвешенное решение. А как его можно принять не имея базовых навыков. Тогда точно больше рисков бросить на полпути
Смысл немного в другом. Допустим я программист. Хотя я действительно программист до геймдева почти 15 лет. Работая долго с с# я останавливаюсь на unity. Начинаю это изучать. Но общие вещи в контексте в 2д уже понимаю с первых дней. За две недели вхожу в хату и могу что-то делать самостоятельно. Теперь нужны реальные задачи, живые. Смотрю на игры 2д например sideview. И поехали. Выделил механику, воссоздал. И так на протяжении нескольких месяцев. Цель освоить, до своей игры ещё далеко. Конечно если уже есть видение игры, то смотрю на игры похожие...
Я бы порекомендовал программистам со стажем в других направлениях, которые хотят в "свободное время" заняться играми следующие: выберите движок, который ближе к тому языку программирования, на котором вы работаете. И начните повторять механики из других игр. Это как шаг первый. Потом вектор развития будете строить по ходу событий и сил.
У меня очень бурная фантазия, даже не знаю как ответить. Пока мы все находимся в подвале, человек наш. У вас тоже есть такой? )
Спасибо. Она нам понадобится
Идея для стартапа