Создание игры: взаимодействие логики и UI
Игра карточная для Андроида (пишется на Java). Логикой игры занимаюсь я, отрисовкой хода игры посторонний человек.
Под логикой я подразумеваю: полный ход игры от начала и до конца, реализация логики компьютера. В общем вся игра, все возможные варианты развития и реакции на это.
Опыт разработки подобных игр - ноль. Я смотрел на создание игры с точки зрения MVC (очень грубо говоря). Т.е. я реализовал логику в коде, работает нормально. Для передачи данных программисту-дизайнеру я выбрал события. Т.е. программист-дизайнер создает объект, задает параметры (~параметры игры), создает свой event listener и вешает его на игру. В этом event listener он уже отрисовывает события игры.
Т.е. таким образом я достиг того, что программист-дизайнер лишь слушает события, а логика игры от него не зависит.
Сам ход игры происходит в отдельном потоке, который запускается программистом-дизайнером из главного UI потока. Но иногда требуется выйти из игры досрочно.
Как в таком случае остановить игру? В Java нет возможности просто убить поток, его надо завершить.
Ведь у меня поток, по сути - это не циклическая операция. Также в нем встречаются блокирующие выполнение операции - ввод пользователем данных. Таким образом, корректно завершить игру досрочно невозможно.
Как лучше поступить? Решения я пока не нашел. Понимаю, что проблема в подходе.
P.S.: возвращаться к типичному подходу, когда будет смешана и логика, и UI абсолютно не хочется - станет значительно сложнее поддерживать и увеличит объемы кода.
P.S.2: в Java есть метод Thread.interrupt(), но это не то. С таким подходом придется через каждую строчку логики вставлять if( Thread.interrupted() ), да и проблем с блокирующими операциями тоже особо не решит.
ваш поток выдаст событие "килл" и сам закроется .
прога дизайнера увидит "килл" и тоже закроется . хеппи енд )
У меня просто такой подход, что поток сам не закроется - там большая последовательность операций, и чтобы "килл" реально сработал, то надо будет ставить условные переходы каждые пару строк (о чем я выше сказал).
В общем, да, взвесил все за и против, оценил перспективу требуемого в будущем функционала - решил переписать все с одного последовательного потока на конечный автомат, который будет постоянно в цикле обновляться - при таком подходе легче будет сохранить игру (чтобы в будущем продолжить с места окончания) и прервать.