Announcement

Collapse
No announcement yet.

Extending ShooterGame Pawn Blueprints

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Extending ShooterGame Pawn Blueprints

    Hi,

    How would you go about extending ShooterGame with pawn blueprints? My concern is that there are two pawn blueprints: PlayerPawn which extends ShooterCharacter, and BotPawn which extends BotCharacter (which in turn extends ShooterCharacter).

    For example, if we extend PlayerPawn with some blueprint to drive third party animations, all of it will have to be copied to BotPawn to get the same result for bots. It's not possible to create a BasePawn with shared functionality, because both need to extend a different C++ class.

    Is this really the best way to set things up? And how would you go about sharing common functionality between the two (other than copy and paste)?

    #2
    Just to clarify, you're saying the hierarchy goes like this?

    Code:
           ShooterCharacter
            /         \
    PlayerPawn      BotCharacter
                        \
                      BotPawn
    If so, why not set it up like so?

    Code:
           ShooterCharacter
                  |
          AnimatedCharacter (for example)
            /         \
    PlayerPawn     BotCharacter
                        \
                        BotPawn
    (Used code block as normal space was being ignored and I don't know how else I would format it)

    This way, both PlayerPawn and BotPawn have access to the animated stuff.

    The blueprints can re-parent easily enough. Not sure about C++, I imagine it wouldn't be too difficult.

    That said, I'm still learning myself, so it may not be the best solution, if it's even a solution that works.
    Last edited by bogieman987; 06-19-2015, 10:01 PM. Reason: Formatting
    YouTube Playlist of W.I.P game project - https://www.youtube.com/playlist?lis...XCXMLFckHVo_bV (May contain swearing, I'm Irish :P)

    Comment


      #3
      Originally posted by bogieman987 View Post
      Just to clarify, you're saying the hierarchy goes like this?

      Code:
             ShooterCharacter
              /         \
      PlayerPawn      BotCharacter
                          \
                        BotPawn
      If so, why not set it up like so?

      Code:
             ShooterCharacter
                    |
            AnimatedCharacter (for example)
              /         \
      PlayerPawn     BotCharacter
                          \
                          BotPawn
      (Used code block as normal space was being ignored and I don't know how else I would format it)

      This way, both PlayerPawn and BotPawn have access to the animated stuff.

      The blueprints can re-parent easily enough. Not sure about C++, I imagine it wouldn't be too difficult.

      That said, I'm still learning myself, so it may not be the best solution, if it's even a solution that works.
      That would be ideal, but I don't think C++ classes can extend Blueprints, am I wrong? BotCharacter is a C++ class, so making AnimatedCharacter a Blueprint probably won't work.

      After giving it some thought I figured it may not be a big issue anyway. Animation related stuff can probably be mostly contained to the animation blueprint, and most other blueprint related stuff (UI, etc) should not affect bots anyway. This still leaves things like adding logic or variables for game modes, but having to add those in C++ is not the end of the world.

      Comment


        #4
        As a little update to myself: It turned out that ShooterBot (not BotCharacter, mea culpa) really doesn't do much on top of ShooterCharacter, so it seemed reasonable to merge it with ShooterCharacter. Now the BotPawn BP can extend the PlayerPawn BP which means that PlayerPawn can contain any custom functionality. Much happier now.

        Comment


          #5
          As far as i know, the BP versions of these classes are only used to fill variables easier, like models, animation etc.
          This is a perfect use of BPs when mainly using C++. So you don't need to load assets into the code, you just expose
          the variable to the CHILD BP class and fill it there.

          That's why the BP Versions of these classes won't have new code in it. Or at least not much. Epic did the same thing with
          the Weapon classes. There is a base weapon and an instanthit weapon (rifles). The final weapon with all its models etc
          is a BP Child of these classes, because you can easily fill all the needed properties (:

          I hope that makes it easier to understand!
          Open for contracted work | C++/BP (incl. Multiplayer) | Tutoring | VR

          My UE4 Blog/Page with Tutorials and more: Hit me for ALL the things!
          (Including 100+ Pages Multiplayer Network Compendium to get you started.)

          Comment


            #6
            Originally posted by eXi View Post
            As far as i know, the BP versions of these classes are only used to fill variables easier, like models, animation etc.
            This is a perfect use of BPs when mainly using C++. So you don't need to load assets into the code, you just expose
            the variable to the CHILD BP class and fill it there.

            That's why the BP Versions of these classes won't have new code in it. Or at least not much. Epic did the same thing with
            the Weapon classes. There is a base weapon and an instanthit weapon (rifles). The final weapon with all its models etc
            is a BP Child of these classes, because you can easily fill all the needed properties (:

            I hope that makes it easier to understand!
            Yeah I know, but I wanted a setup that lets me extend the pawn with Blueprint when appropriate. For some tasks it's just better suited, and I don't like to limit myself to just one or the other.

            Comment

            Working...
            X