А у простых смертных такая возможность есть ? Если да, то с радостью прочитал бы статью на подобную тему как заказать, что для этого нужно, сколько по стоимости выйдет и т.д.
Здравствуйте, задумка вашего устройства мне понравилась, правда лично я бы хотел такое именно как аналог часов и/или экрана для вывода всякого. Да, да, знаю про LaMetric, и именно внешне сходство (да и частично фунционал тоже) с ним меня и заинтересовали.
Давно хочу собрать нечто подобное, но никак не могу найти светодиодные панели похожего размера, все слишком большие. Подскажите пожалуйста как с ними обстоят дела у вас. Может намного не правильно задал вопрос. Меня интересует вы сами их паяете (какое оборудование тогда нужно для этого ?) Или же заказываете у кого ?
Извиняюсь если вопрос звучит глупо. С электроникой пока что у плохо.
Не буду утверждать нужно ли ВО, но всё же хочу описать своё видение.
У меня например средне-специальное профильное. Потом я пошёл в универ и отчислился с 3 курса. Потом начал искать работу и понял что ничему из того что требуется нас нет учили. Правда потом всё же занялся самообразованием и устроился джуном.
И тут получается что вроде учился в ВУЗе, но ВО не получил. При этом по моему мнению больше знаний я получил в колледже (за что благодарен преподавателям). Но так же должен отметить что начал увлекаться IT лет с 12 и по большей части изучал самостоятельно. Возможно что-то не понимал в силу возраста, но у меня было самое главное, желание учиться и огонь в глазах, и я уверен что даже без средне-специального я всё равно достиг бы своей цели.
При этом я учась пошел и в колледж и в университет осознанно, а не как большинство. И учась я знал чего я хочу, в отличие от 90% мой группы, которая училась только чтобы получить корочку.
Что косвенно приводит нас к тому, что важно не высшее образование а 'огонь в глазах' и понимание того, чего ты хочешь.
И небольшой комментарий про сравнение ВО и курсов. Хоть я и недолюбливаю все эти инфоцыганские курсы, но должен признать что базовое понимаемые инструментов и работа над хоть и учебным но проектом после курсов мне бы больше помогла бы в устройстве на работу, чем то, что изучают в университете.
Ну и под конец сделаю оговорку что это моё мнение, после моего опыта обучения в не самом именитом вузе. Возможно мое мнение было б другое, если бы я учился в более престижном вузе с более квалифицированными преподователями.
Если кандидату нужны только деньги, он может эти деньги получить и в любой другой конторе?
Может, по этому собственно и откликается на десятки (а то и сотни) вакансий. Или вовсе ему поступают предложения. Если вы думаете что человек специально идёт работать именно к вам, то вы сильно заблуждаетесь.
Такой кандидат как начал работать, так и легко может уйти. Если человека держат только деньги он не очень надежный в определенном плане.
А тут уже задача компании удержать человека и предложить ему что-то кроме денег.
А если у компании будут проблемы — он просто сбежит от них в другую?
Сначала вы написали про то, что человек может быть не очень надёжный, а теперь получается что и компания может быть ненадёжной, но при этом работник должен быть надёжным, и как говорится в случае чего тонуть вместе с кораблём.
Если проблема компании коснутся работника (переработки, задержки зарплаты, недоплаты) то конечно же он уйдёт в другую, более надёжную компанию.
Не лучше ли взять кандидата с навыками послабее, но преданного фирме / бренду / задаче и подучить его, чем брать сильного, но которого держат лишь деньги?
А предан компании он будет до тех пор, пока не получит опыта чтобы перейти другую компанию. Бывают конечно и исключения, когда человека всё устраивает, но это не преданность, а именно человека устраивают текущие условия, и если они станут хуже, то он как минимум задумается об уходе.
но сотрудники должны гордиться, что они работают именно в этой фирме или на задаче, а не просто тем, что смогли устроиться куда-то.
А вот это работа самой фирмы, чтобы сотрудники гордились что работают именно у них. И кстати посмею заметить, что гордость за фирму и забота о процветании фирмы это совершенно разные вещи.
И если человек работает на окладе то ему пофиг получит ли фирма 1 миллион или 10. Если конечно сотрудник не имеет своей доли в фирме.
И снова вернусь к этой фразе:
А если у компании будут проблемы — он просто сбежит от них в другую?
А если у сотрудника будут проблемы - то фирма будет искать другого сотрудника ?
Как видите всё написанное вами работает и в обратную сторону.
Как уже сказали порой Копилот очень хорошо вспоминает чужой код и некоторые специфичные моменты кода (например предложенный массив с какими-то числами) могут спокойно выдать что этот код чужой.
Java мне кажется тоже не лучший вариант. Да на этом языке можно делать игры, но имхо не нужно. На мой взгляд Java лучше использовать в северной части игры, если такая предполагается.
Да вот нет, там не бесплатно а в прицепе это максимум (я честно сказать не вникал , ссылку взял из кометов)
'Я не вникал, но буду спорить'.
Если вы всё же прочтёте то что вы скинули то заметите что речь во первых про Photon Cloud, во вторых там говорится что для одной игры бесплатный лимит это 100 человек, а следующий (уже платный) доступный пакет это 500 человек. А в третьих там же на примере комнат говорится что считать количество подключений несколько не правильно, и правильнее будет считать количество пакетов за единицу времени.
Ну и извиняюсь если где обидел или могу обидеть в спорах, просто очень люблю дискутировать на интересующие меня темы.
П.с. ваши статьи мотивируют, но скорее мотивируют сделать и показать 'как надо' 😊
Тем не менее вы так и не ответили причём тут база данных и зачем что-то читать из неё.
И что значит НПС это те же игроки ? Допустим у вас есть сущность character с набором действий от которой наследуются персонажи игрока и НПС, но это не делает НПС игроком и обращаться к базе или гонять пакеты по сети им тоже не нужно. (Есть конечно исключения, но не в данном случае).
Если кому-то поможет то что вы написали в текущих 4 статьях, то я ему сочувствую, ибо эта информация есть в открытом доступе в куда более понятном и более информативном виде.
А по именно архитектуре вы пока что ничего толкового не написали.
Так же вы говорите что вы программист а не блогер, но при этом ведёте себя полностью противоположно. Задумайтесь.
При грамотной архитектуре на клиенте не должно быть разницы 1 НПС или 1000, или вы на движение каждого НПС собираетесь слать отдельный пакет на клиент ?
Ладно бы вы сказали 1000 игроков, там то хоть понятно, что количество пакетов будет N*(N-1), из-за чего собственно и случаются лаги в людных местах в мморпг.
Зачем у вас НПС что-то читают и пишут в базу тоже не понятно.
В общем я начинаю сомневаться в вашей квалификации на счёт геймдева.
Я желаю успехов в ваших начинаниях, да и в принципе всем кто хоть что-то желает, ибо не ошибается тот кто ничего не делает.
Но. Как и сказал 'iamkisly' в комментариях к 1 статье - у вас нет понимания как и что происходит в геймдеве. Складывается ощущение что вы наспех прочитали несколько статей и теперь пытаетесь пересказать нам то как вы их поняли.
Команды вида [8,117,17] труднее читаются чем move_right, но куда правильнее, имхо. Я бы вообще использовал бы пакеты вида '13FFAC0D'.
Дальше вы утверждаете 'но так же можно атаковать через всю карту' и тут вы правы только частично. Можно попробовать атаковать через всю карту, но задача сервера как раз проверить может ли игрок атаковать, хватает ли дальности, можно ли вообще атаковать данный объект и т.д. и желательно ещё вести статистику таких вот выкрутасов от игрока. Если их много то кик с сервера, если это повторяется регулярно там бан.
В вашем же апи используют команды 'иди влево', 'иди вправо', 'иди вверх', 'иди вниз'. Это конечно прекрасно (нет), но мы пишем не 'черепашку' а ММО (хотя на вашем бы месте прежде чем бросаться такими словами, я бы попробовал написать сервер хотя бы на пару десятков человек).
Тут я вижу 2 варианта на какие пакеты заменить: 1) это координаты и дальше сервер уже двигает персонажа постепенно туда (как в стратегиях например, или в МОБА), и вариант 2) это вектор куда и с какой скоростью движется персонаж.
Идём дальше, редис.. вот тут ничего не скажу, вещь полезная, и когда я занимался попытками создать сервер для игры, то я о подобных технологиях не знал. Но имхо вы используете редис не правильно. Незачем хранить там то, что и так может лежать в оперативной памяти.
Количество НПС влияет на пинг - а вот так быть не должно. Это говорит нам о том, что у вас неправильная архетиктура.
П.с. читаются ваши статьи достаточно трудно, ибо то что связано с сетью и разработкой сетевых игр вы пытаетесь объяснить словно маленьким детям (и делаете это на техническом ресурса, как сказали ранее), а то, что на мой взгляд не относится к разработке сервера напрямую, а скорее имеет отношение именно к PHP вы наоборот описываете наиболее подробно, только вот не понятно зачем. Мы и так поняли что PHP вы знаете. Но к разработке ММО это именно очень посредственное отношение.
Будь я на вашем месте, то писал бы статью которая не привязана к языку, и если были бы какие-то ключевые моменты в языке который использую я, то выносил бы это под спойлер отдельно.
Предыдущая часть была на мой взгляд более информативная, хоть мне человеку далёкому от php не совсем понятны некоторые моменты. (Читаю чтобы в целом узнать что-то новое про архитектурные решения).
В данной части мы видим информацию о UDP и TCP протоколах, но информации мало. Можно добавить что довольно часто в играх используют либо оба протокола, чтобы важная информация точно доходила до сервера и обратно, а менее важная, как например передвижение в том же самом CS всегда приходила нам наиболее актуальная. Ведь в чем минус TCP кроме того что он медленный, а в том, что в случае если пакет не получен он его переотправит, но не факт что к этому моменту там будет актуальная информация.
Плюс можно было б упомянуть такую вещь как Reliable UDP.
А теперь небольшой п.с: скачал я ваше демо приложение на андроид. Управление сделано ужасным образом. Мало того что движение воспринимается только в 4 стороны, так ещё и очень часто неправильно определяет сторону, вплоть до противоложной.
Пока увидел только Joom который в рф не доставляет (хотя есть люди что успели заказать) и нашёл на Амперке за 16к. Но это имхо дорого.
А у простых смертных такая возможность есть ? Если да, то с радостью прочитал бы статью на подобную тему как заказать, что для этого нужно, сколько по стоимости выйдет и т.д.
Здравствуйте, задумка вашего устройства мне понравилась, правда лично я бы хотел такое именно как аналог часов и/или экрана для вывода всякого. Да, да, знаю про LaMetric, и именно внешне сходство (да и частично фунционал тоже) с ним меня и заинтересовали.
Давно хочу собрать нечто подобное, но никак не могу найти светодиодные панели похожего размера, все слишком большие. Подскажите пожалуйста как с ними обстоят дела у вас. Может намного не правильно задал вопрос. Меня интересует вы сами их паяете (какое оборудование тогда нужно для этого ?) Или же заказываете у кого ?
Извиняюсь если вопрос звучит глупо. С электроникой пока что у плохо.
Не буду утверждать нужно ли ВО, но всё же хочу описать своё видение.
У меня например средне-специальное профильное. Потом я пошёл в универ и отчислился с 3 курса. Потом начал искать работу и понял что ничему из того что требуется нас нет учили. Правда потом всё же занялся самообразованием и устроился джуном.
И тут получается что вроде учился в ВУЗе, но ВО не получил. При этом по моему мнению больше знаний я получил в колледже (за что благодарен преподавателям). Но так же должен отметить что начал увлекаться IT лет с 12 и по большей части изучал самостоятельно. Возможно что-то не понимал в силу возраста, но у меня было самое главное, желание учиться и огонь в глазах, и я уверен что даже без средне-специального я всё равно достиг бы своей цели.
При этом я учась пошел и в колледж и в университет осознанно, а не как большинство. И учась я знал чего я хочу, в отличие от 90% мой группы, которая училась только чтобы получить корочку.
Что косвенно приводит нас к тому, что важно не высшее образование а 'огонь в глазах' и понимание того, чего ты хочешь.
И небольшой комментарий про сравнение ВО и курсов. Хоть я и недолюбливаю все эти инфоцыганские курсы, но должен признать что базовое понимаемые инструментов и работа над хоть и учебным но проектом после курсов мне бы больше помогла бы в устройстве на работу, чем то, что изучают в университете.
Ну и под конец сделаю оговорку что это моё мнение, после моего опыта обучения в не самом именитом вузе. Возможно мое мнение было б другое, если бы я учился в более престижном вузе с более квалифицированными преподователями.
Может, по этому собственно и откликается на десятки (а то и сотни) вакансий. Или вовсе ему поступают предложения. Если вы думаете что человек специально идёт работать именно к вам, то вы сильно заблуждаетесь.
А тут уже задача компании удержать человека и предложить ему что-то кроме денег.
Сначала вы написали про то, что человек может быть не очень надёжный, а теперь получается что и компания может быть ненадёжной, но при этом работник должен быть надёжным, и как говорится в случае чего тонуть вместе с кораблём.
Если проблема компании коснутся работника (переработки, задержки зарплаты, недоплаты) то конечно же он уйдёт в другую, более надёжную компанию.
А предан компании он будет до тех пор, пока не получит опыта чтобы перейти другую компанию. Бывают конечно и исключения, когда человека всё устраивает, но это не преданность, а именно человека устраивают текущие условия, и если они станут хуже, то он как минимум задумается об уходе.
А вот это работа самой фирмы, чтобы сотрудники гордились что работают именно у них. И кстати посмею заметить, что гордость за фирму и забота о процветании фирмы это совершенно разные вещи.
И если человек работает на окладе то ему пофиг получит ли фирма 1 миллион или 10. Если конечно сотрудник не имеет своей доли в фирме.
И снова вернусь к этой фразе:
А если у сотрудника будут проблемы - то фирма будет искать другого сотрудника ?
Как видите всё написанное вами работает и в обратную сторону.
Или в метро.
В самой капсуле сделать интерактивный дисплей, чтобы можно было выбрать остановку/станцию и капсула тебя разбудила незадолго до выхода.
С того что вы батенька на техническом ресурсе.
И пишите в хабе: 'Разработка игр', а тут про разработку ничего и нету.
Можно было бы написать про разработку админки, какие плагины использовали, какие именно трудности возникли, как прикрутили оплату.
Как уже сказали порой Копилот очень хорошо вспоминает чужой код и некоторые специфичные моменты кода (например предложенный массив с какими-то числами) могут спокойно выдать что этот код чужой.
Ну и да, этичность и человечность.
Java мне кажется тоже не лучший вариант. Да на этом языке можно делать игры, но имхо не нужно. На мой взгляд Java лучше использовать в северной части игры, если такая предполагается.
'Я не вникал, но буду спорить'.
Если вы всё же прочтёте то что вы скинули то заметите что речь во первых про Photon Cloud, во вторых там говорится что для одной игры бесплатный лимит это 100 человек, а следующий (уже платный) доступный пакет это 500 человек. А в третьих там же на примере комнат говорится что считать количество подключений несколько не правильно, и правильнее будет считать количество пакетов за единицу времени.
Ну и извиняюсь если где обидел или могу обидеть в спорах, просто очень люблю дискутировать на интересующие меня темы.
П.с. ваши статьи мотивируют, но скорее мотивируют сделать и показать 'как надо' 😊
Давайте определимся что мы имеем ввиду под онлайном. Ибо онлайн может быть общий (на условных 10 серверах).
Онлайн на 1 сервере (но при этом игроки распределены по серверу равномерно) (тут кстати сервер тоже может быть на нескольких физических машинах)
Онлайн а 1 локации.
Онлайн на 1 локации где все игроки видят друг друга.
Если вы думаете что у Фотона ограничение в 100 человек из-за того что сервер не тянет, то вы ошибаетесь.
100 человек это всего лишь бесплатная лицензия, ибо люди хотят денег за свой труд и я их понимаю.
Я даже готов поспорить что если вы сделаете своё популярное решение на уровне Фотона, то вы тоже рано или поздно захотите с этого иметь денег.
Кстати хочу заметить что Фотон делал явно не один человек. Думаете в одиночку сможете лучше ?
Ну вы уж определитесь пожалуйста
И может всё таки стоит сделать что-то более менее рабочее и похожее на BrowserQuest. А не то что есть сейчас, и потом уже писать статьи ?
Тем не менее вы так и не ответили причём тут база данных и зачем что-то читать из неё.
И что значит НПС это те же игроки ? Допустим у вас есть сущность character с набором действий от которой наследуются персонажи игрока и НПС, но это не делает НПС игроком и обращаться к базе или гонять пакеты по сети им тоже не нужно. (Есть конечно исключения, но не в данном случае).
Если кому-то поможет то что вы написали в текущих 4 статьях, то я ему сочувствую, ибо эта информация есть в открытом доступе в куда более понятном и более информативном виде.
А по именно архитектуре вы пока что ничего толкового не написали.
Так же вы говорите что вы программист а не блогер, но при этом ведёте себя полностью противоположно. Задумайтесь.
При грамотной архитектуре на клиенте не должно быть разницы 1 НПС или 1000, или вы на движение каждого НПС собираетесь слать отдельный пакет на клиент ?
Ладно бы вы сказали 1000 игроков, там то хоть понятно, что количество пакетов будет N*(N-1), из-за чего собственно и случаются лаги в людных местах в мморпг.
Зачем у вас НПС что-то читают и пишут в базу тоже не понятно.
В общем я начинаю сомневаться в вашей квалификации на счёт геймдева.
Я желаю успехов в ваших начинаниях, да и в принципе всем кто хоть что-то желает, ибо не ошибается тот кто ничего не делает.
Но. Как и сказал 'iamkisly' в комментариях к 1 статье - у вас нет понимания как и что происходит в геймдеве. Складывается ощущение что вы наспех прочитали несколько статей и теперь пытаетесь пересказать нам то как вы их поняли.
Команды вида [8,117,17] труднее читаются чем move_right, но куда правильнее, имхо. Я бы вообще использовал бы пакеты вида '13FFAC0D'.
Дальше вы утверждаете 'но так же можно атаковать через всю карту' и тут вы правы только частично. Можно попробовать атаковать через всю карту, но задача сервера как раз проверить может ли игрок атаковать, хватает ли дальности, можно ли вообще атаковать данный объект и т.д. и желательно ещё вести статистику таких вот выкрутасов от игрока. Если их много то кик с сервера, если это повторяется регулярно там бан.
В вашем же апи используют команды 'иди влево', 'иди вправо', 'иди вверх', 'иди вниз'. Это конечно прекрасно (нет), но мы пишем не 'черепашку' а ММО (хотя на вашем бы месте прежде чем бросаться такими словами, я бы попробовал написать сервер хотя бы на пару десятков человек).
Тут я вижу 2 варианта на какие пакеты заменить: 1) это координаты и дальше сервер уже двигает персонажа постепенно туда (как в стратегиях например, или в МОБА), и вариант 2) это вектор куда и с какой скоростью движется персонаж.
Идём дальше, редис.. вот тут ничего не скажу, вещь полезная, и когда я занимался попытками создать сервер для игры, то я о подобных технологиях не знал. Но имхо вы используете редис не правильно. Незачем хранить там то, что и так может лежать в оперативной памяти.
Количество НПС влияет на пинг - а вот так быть не должно. Это говорит нам о том, что у вас неправильная архетиктура.
П.с. читаются ваши статьи достаточно трудно, ибо то что связано с сетью и разработкой сетевых игр вы пытаетесь объяснить словно маленьким детям (и делаете это на техническом ресурса, как сказали ранее), а то, что на мой взгляд не относится к разработке сервера напрямую, а скорее имеет отношение именно к PHP вы наоборот описываете наиболее подробно, только вот не понятно зачем. Мы и так поняли что PHP вы знаете. Но к разработке ММО это именно очень посредственное отношение.
Будь я на вашем месте, то писал бы статью которая не привязана к языку, и если были бы какие-то ключевые моменты в языке который использую я, то выносил бы это под спойлер отдельно.
Ну как то так. Жду вашу 5 статью.
Советую так же добавить в каждую из статей ссылки на все остальные, для более удобной навигации.
Предыдущая часть была на мой взгляд более информативная, хоть мне человеку далёкому от php не совсем понятны некоторые моменты. (Читаю чтобы в целом узнать что-то новое про архитектурные решения).
В данной части мы видим информацию о UDP и TCP протоколах, но информации мало. Можно добавить что довольно часто в играх используют либо оба протокола, чтобы важная информация точно доходила до сервера и обратно, а менее важная, как например передвижение в том же самом CS всегда приходила нам наиболее актуальная. Ведь в чем минус TCP кроме того что он медленный, а в том, что в случае если пакет не получен он его переотправит, но не факт что к этому моменту там будет актуальная информация.
Плюс можно было б упомянуть такую вещь как Reliable UDP.
А теперь небольшой п.с: скачал я ваше демо приложение на андроид. Управление сделано ужасным образом. Мало того что движение воспринимается только в 4 стороны, так ещё и очень часто неправильно определяет сторону, вплоть до противоложной.
Именно эта статья практически не несёт в себе полезной информации.
Вертикальные видео это вообще ужас.
Но на всякий случай всё же подписался и буду следить. Не уверен что у вас получится, но желаю удачи.