terminator-light

Кажется в рамках законодательства вы не обязаны помнить пароли. Плохая память вроде не преступление.

с интересом посмотрю на линух на фат...

За пределами России. В России творится мракобесие и такое чувство, что учёных начнут скоро снова сжигать на кострах.

Я вижу зависимость задач друг от друга (через данные). Пусть завершив свою работу, задача A запускает задачи B и C и никаких блокировок.

Или можно иметь некоторое хранилище данных и некоторую совокупность обработчиков воздействующих на данные н-р:
Один обработчик берет объекты типа Order у которых состояние NEW ставит им состояние CHECKED или FRAUD по какой-то своей логике.
Другой обработчик берет Order в состоянии CHECKED проводит транзакцию и ставит PAID или NOT_PAID. И т.д.
Архитектурный шаблон Blackboard_system.

Представь себе, ты раскрыл анатомический атлас и думаешь: что бы себе удалить? Но понять что к чему сложно, и ты приходишь с вопросом к нам.
Значит так: режь что угодно, кроме головы, так мы хоть вместе посмеёмся напоследок!

Веб-сайт в данном случае тоже сервер, и для понимания введем понятия:

• Игровой сервер (или просто сервер)
  
• Веб-сервер (бекенд)
  
• Браузер пользователя или клиент или фронтенд
  

Далее задачу можно разделить на два (три) этапа:

Этап первый

Вам нужно, чтобы ваш сервер отсылал на веб-сервер информацию о начале и конце. Это делается по протоколу HTTP или HTTPS, что-то типа java.net.HttpUrlConnection, но я точно не знаю, что вам лучше подойдет для этой цели.

Соответственно, на веб-сервере у вас должен быть свой скрипт на любом языке, обычно это PHP. Этот скрипт сохраняет информацию в базу (обычно MySQL).

Чтобы хранить таймер, который всё время меняется, нужно хранить неизменные его части. А именно - начало и конец, или начало и продолжительность, или просто время окончания (timestamp) с точностью до секунды.

Этап второй
Это общение веб-сервера и браузера (клиента). И тут есть свои тонкости.

Во-первых, сразу вилка на функционал - либо у вас таймер появляется по нажатию по F5 (обновить страницу). То есть вы обновляете страницу, браузер запрашивает новые данные с веб-сервера, и после этого показывает таймер. Либо у вас страница веб-сайта открыта, и там в реальном времени вдруг появляется таймер. Сам! Это можно сделать по-разному, но самый банальный способ - чтобы веб-страница (то есть браузер) делала запрос каждые 10 секунд в фоне (ajax), и если вдруг появляются новые данные, то страница преображается.

Во-вторых, если ваш сервер предполагает игроков из разных часовых поясов, то и локальное время в каждом браузере будет своё. Так что придется немного заморочиться с тем, чтобы правильно отображать время на сайте пользователю, независимо от сдвига по времени.

В остальном всё просто. Информация из базу тупо посылается на клиент, то есть время окончания, и дальше на клиенете скрипт работает локально. Он показывает отсчет времени до старта игры. Собственно, написание этого мини скрипта на JavaScript можно считать третьим этапом.

Думаю, что самое первоочередное - это rest api, чтобы были не просто черт знает какие запросы и json ответы

Не совсем понятно, какую цель вы преследуете. Исходя из вашего слова "профитнее" (т.е. по-русски "выгоднее") её можно трактовать по-разному.

1) Если вы рассматриваете свои игры, как дополнительные пункты в резюме разработчика игр, и выгода для вас означает профессиональный рост и потенциальную зарплату у работодателя, то нужно не вылизывать игру до идеала, а повышать KPI. То есть нужно обращать на те моменты, которые приносят прибыль, а которые не приносят - забить. Однако к программированию это имеет мало отношения, это больше маркетинг, психология, геймдизайн, и вот это вот всё. Одному человеку это, как правило, не под силу. Но если вдруг хотя бы одна из ваших игр будет иметь коммерческий успех, пусть даже вы будете лишь одним из ее разработчиков внутри небольшой команды, то это считается серьезным достижением при устройстве на работу и имеет реально солидный вес, какую бы более узкую специальность вы ни выбрали.

2) Если вы рассматриваете свои игры, как дополнительные пункты в резюме программиста, то по сути и не важно, игры это или что-то другое. Здесь будет играть роль ваш опыт программирования (опять же просто количество лет), плюс опыт работы в команде. Чуть бОльшую роль имеют софт скилы при составлении резюме и прохождении собеседования. В остальном идеи из предыдущего пункта тоже применимы - то есть количество достойных проектов, считающихся достижениями, которые не стыдно показать.

3) Если выгода для вас означает собственно продажа своих игр, то эта цель сильно пересекается и первым пунктом, с той лишь разницей, что вы максимизируете прибыль (причем, для себя). Аналогично первому пункту, это сложная тема, и нужно уметь во многое, что одиночке не под силу. А если вы хотите свою команду (а не вхождение в чужую), то также нужен солидный бюджет. Программирования здесь будет еще меньше, точнее лично у вас на это просто не будет времени. Но этому пункту противоречат ваши слова "для саморазвития и дропа на гитхаб", что как бы намекает, что деньги непосредственно с игр вам не нужны.

4) Наконец, если вы хотите заниматься буквально саморазвитием, то есть повышать качество кода и снижать количество багов в нем, то нужно заморочиться конкретно на этом. Опять же, игры здесь ни при чем. Нужно наводить порядок в голове, приучать себя к хорошему оформлению кода и т.д. Опыт, конечно, тоже идет в плюс, но тупо опыта не достаточно. А точных рецептов здесь нет. Начать можно даже с гугления наивной фразы "как писать код без ошибок", а дальше как пойдет, это долгий путь. Но сразу скажу, что это имеет мало отношения к коммерческой выгоде. То есть даже если вы участвуете в ААА-проекте, где отсутствие багов критично, никто не пустит ваш код в продакшн сразу после написания. Ошибаются все, даже профи.

P.S. На уровне джуна можно быть только помощником. То есть хорошо зная лишь теорию, получать замечания от более опытных товарищей, которые отвечают за успех. Хотя деление это довольно условно. Пет-проекты могут как способствовать росту, так и просто отнимать время, смотря что и как качать.

200 - это не ошибка, а успешный результат

Во времена кнопочных телефонов и WAP java-приложения писались для специальной версии JVM - J2ME. Сейчас почти все android-приложения тоже написаны на Java и тоже под специальную JVM. То есть ни тогда, ни сейчас нельзя запустить на мобильнике любое java-приложение, только специально предназначенное для этого.

По IT? Никакие.
Почему? Потому что сам решаю, что и когда мне будет интересно, а не какой-то Васян.

Потому что в рамках подкаста невозможно всеобъемлюще и доходчиво разобрать какую-нибудь важную тему, а околоайтишные темы для дилетантов, да к тому же, в научно-фантастическом ключе, не нужны.

Потому что львиная доля подкастов - это дли-и-инный такой рекламный дайджест о "суппир-пуппир тихналогиях от наших спонсоров".

Потому что м-м-м не нравятся сами ведущие, которые э-э-э-э ставили голос в падике, а дикцию им а-а-а-а-а рихтовали гопники на переменах.

Правильно - строить логику игры так чтобы подставление пользователем своих данных не давало ему каких-то преимуществ, а наоборот.
Многопользовательские игры реализуются на сервере, на клиенте только рисование картинки как скажет сервер и слушание какие кнопки он нажал.
Если он себе квадратик нарисует не там где ему сервер сказал нарисовать - он только себе хуже сделает и никак не повлияет на ход игры.

Пользователь может обмануть сервер только в плане когда и какие кнопки он нажимал, иногда это имеет значение иногда нет. Если имеет - то тут уже всякие системы обнаружения таких случаев, в зависимости от логики игры и на сколько фантазии хватит

grep - gnu regular parser
cat - concatenate
perl - потому что так захотелось, хотя есть варианты

В чём вопрос-то?
Размещаешь медиафайл на сервере, передаёшь ссылку на него в приложение и показываешь, например через MediaPlayer.
Какой ещё 1 байт? Автор, ты что куришь?
Какую именно проблему ты хочешь решить?

В любом случае придется рисовать. Странный вопрос.

Я вопрос не понял. Вы пару часов назад писали,как собирать части игры в одну точку. Вы сразу пишете код под игру,что вам не нравится?