Как я могу управлять этой текстовой игрой и как бы классы получили лучшую структуру для этого?

Question

Если у меня есть текстовая игра, в которой есть объект мира, у которого есть объекты типа room, в которых есть объекты предметов и врагов, а затем объект gamehelper, у которого есть пользовательские объекты для реального игрока. (в этой игре нет блуждающих врагов, так как это усложнит мой вопрос для меня :-))

Как я могу либо убить врага, либо поднять объект? Или я должен думать о другом способе, когда полностью структурирую свои классы? У меня появилось предположение, что мне нужен менеджер, который контролирует мир и посредничает между пользователями и объектами, но я не могу определить , как бы это выглядело/работало.

Я бы также реализовал интерфейсы, которые можно было бы убивать и подбирать для разделения объектов друг от друга, если это необходимо, если это имеет значение ... И я изучаю Java, чтобы в этом мог быть написан любой примерный код, который может быть полезен для понимания.

Ie:

 World 
     | 
    ____Rooms____ (could be like a 4x4 array or something with X and Y cords) 
    |   | 
    Objects  Enemies (Either killable/pickupable) 

     Game 
     | 
     User (can walk around in rooms, kill monsters and take treasure) 

Answer 1

Я не вижу ничего плохого, очевидно, с классовой структурой, если ваша схема не является схемой его. :) Номера, объекты и враги должны, конечно, не inherit Мир. Похоже, вы сдерживаете диаграмм, но это нормально.

Как вы можете убить врага или поднять объект? Разве это не зависит от того, что означают эти действия в вашей игре? Похоже, что для подбора объекта объект имеет среду, которая может быть либо комнатой, либо пользователем; объект, среда которого является пользователем, находится в инвентаре этого пользователя. Приобретение объекта меняет свою среду из комнаты на пользователя.

Возможно, объекты могут иметь врагов как их окружающую среду, так что убийство Врага разрушает Врага и перемещает Объекты в его инвентаре в Комнату, в которой находился Враг. Или, может быть, вам нужен тип «мертвого врага»? На самом деле все зависит от вашей игровой модели.

Answer 2

Интерфейсы для уязвимый и pickupable элементов, возможно:

interface IAttackable { 
    void Attack(); 
    event Killed; 
} 
interface ILiftable { 
    void Get(Container putHere); 
} 

Затем вы можете сделать простые проверки типа, чтобы увидеть, если вы можете атаковать или забрать вещи.

Да, объект медиатора звучит как хорошая идея ... Например, он может подписаться на все события IAttackable.Killed и отправить сигнал классу User, когда что-то умирает в той же комнате, что и они. Это также может быть промежуточным звеном для организации того, сколько урона каждый раз.

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

Answer 3

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

Этот вид дизайна предупрежден против! Существует хороший book об OO-Design, который включает в себя это предупреждение и другие действительно хорошие принципы.

Я также могу рекомендовать для OO-Design в целом статьи «Дядя Боб» Robert C. Martin.Вы должны посмотреть в «Принципы проектирования» и здесь специально первые статьи.

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

С этим вооружением вы будете гораздо лучше подготовлены к дизайну.

Ваш дизайн также может быть начат, если подумать, какие действия должны выполняться с помощью каких-либо объектов. Объекты, которые собирают все виды деятельности, пахнут, как богоборцы, - избегайте их! Объекты, которые вообще не имеют никакой активности, пахнут, поскольку они не нужны вообще - коробки «Мир» и «Игра» несколько пахнут в этом направлении, если они действительно не обладают некоторой функциональностью, которую не может переносить ни один другой объект.

Когда вы создаете какие-то мысли, как мир работает - дизайн может быть очень простым. Такое мышление, как «Окружающая среда» как ассоциация, может быть сделано здесь. Но возможно и другое моделирование. Как насчет этого (просто догадайтесь!): Почему ваши комнаты должны быть объектами все вместе? Вы также можете иметь объект World-Object, который просто содержит 2D-массив с слотами для объектов, содержащихся в комнате (включая пользовательский объект?). Это может облегчить ситуацию, когда у вас большой «Мир». Но, конечно, комнаты как объекты имеют то преимущество, что неограниченные объекты (враги, пользователи, предметы) могут легко содержаться в них.

Итак, сначала вы можете подумать об этом, если у вас есть класс Item или класс «Takeable» ... и так далее.

Надеюсь, это поможет немного - не стесняйтесь спрашивать.

Answer 4

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

Для однопользовательских пошаговых игр, следующие основные наброски должны дать вам один подход (Python-подобный псевдокод):

def main_loop(): 
    while not finished: 
     command_text = ask_user_for_input() 
     execute_player_command(command_text) 
     update_world() 
     send_output_to_player() 

def execute_player_command(command_text): 
    # look up the command object and work out what parameters to pass it 
    command, parameters = parse(command_text) 
    # ask the command to do its stuff 
    command.execute(player, parameters) 

def update_world(): 
    # obviously you can munge these together with an Updateable interface 
    # or something similar 
    for each creature in all_creatures: 
     creature.update() 
    for each object in all_objects: 
     object.update() 

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

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