2015-11-12 3 views
0

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

Вот мой сценарий:

Я пишу небольшой 2D игровой платформы с характером игрока и различными препятствиями. У игрока могут быть разные текстуры, но, как правило, они имеют одинаковые возможности, такие как прыжок и спринт. Аналогично, препятствия обычно имеют разные текстуры, но в остальном имеют одни и те же возможности.

Оба персонажа и препятствия также имеют общие возможности, но не все, например препятствие не может прыгать. Имея это в виду, это то, как я написал свои классы ...

class GameObject { 

    let node : SKSpriteNode! 

} 

Class GameObstacle: GameObject { 

    init() { 
    super.init() 
    } 

    func explode() { 
    // explode code 
    } 

} 

class GameCharacter: GameObject { 

    init() { 
    super.init() 
    } 

    func jump() { 
    // jump code 
    } 

} 

class GameCharacter_Sheep : GameCharacter { 

    init() { 
    super.init() 
    self.node = SKSpriteNode(namedFile: "sheep") 
    } 

} 

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

Один вопрос у меня есть, правильно ли инициализировать мой узел (определенный в классе GameObject) в классе GameCharacter_Sheep? Мое объяснение состоит в том, что, поскольку текстура и, следовательно, физический корпус будут отличаться от характера к персонажу, это правильное место для реализации?

Опять же, я ценю, что это может быть базовый ООП и не очень быстрый, но я просто ищу некоторые рекомендации.

Большое спасибо, Jon

ответ

0

Если все ваши игровые объекты собираются иметь экземпляр SKSpriteNode который передается данные от имени файла, вы можете переместить его создания в базовый класс, а просто файл имя передано в звонок super.init().

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

Смежные вопросы