Announcement

Collapse
No announcement yet.

Still breaking the ice - Adding a player (Character) with C++

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

    Still breaking the ice - Adding a player (Character) with C++

    • I have gone to the Unreal editor and clicked add code to project
    • I selected character and called it BasePlayer
    • I have gone to the Unreal editor and clicked add code to project
    • I selected character and called it Player1, it inherits from BasePlayer. I've repeated this for Player2
    • I have added one property which is made public to BasePlayer:
      Code:
      UCLASS()
      class ****_API ABaseCharacter : public ACharacter
      {
      	GENERATED_UCLASS_BODY()
      
      	UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category=Camera)
      	TSubobjectPtr<UCameraComponent> SideViewCameraComponent;	
      };
    • I now want to add a method that works out where the camera should be between the 2 players... Am I okay to simply add a new method called void SetCameraLocationBetweenPlayers() and not declare it as a UFUNCTION or do I have to add UFUNCTION so that Unreal compiles it in or something?

      Code:
      UCLASS()
      class ****_API ABaseCharacter : public ACharacter
      {
      	GENERATED_UCLASS_BODY()
      
      	UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category=Camera)
      	TSubobjectPtr<UCameraComponent> SideViewCameraComponent;	
      
              UNFUNCTION()
              void SetCameraLocationBetweenPlayers();
      };
      
      ....cpp:
      
              void ABaseCharacter::SetCameraLocationBetweenPlayers()
             {
                 // get current location of player[ 0 ]
                 // get current location of player[ 1 ]
                 // do some shizbadizzle
                 // set camera location based on what I worked out
             }
      Regarding this function, do I have to get a players location before being able to modify it? where's the documentation for doing this, can't find it ?


    Do I need to have some class that holds an array of players?

    do I need to do something like create my own class called InputDelegator and then havea vector of how many players I want as a property of type Character... then on tick I iterate over the players, then relocate them based off of their iteration of the playercontroller... I just need a little direction then i'm set to go really... I have made games before with local coop however I just want to do it the unreal way...

    P.S this is for cooperative play on one single viewport
    Last edited by jimmyt1988; 08-04-2014, 12:42 PM.

    #2
    Hi, Jimmy!

    Summarizing, UFUNCTION is a macro that allows you call functions using Blueprint, using in-game console, set the function network behaviour or other things depending on the specifiers. Take a look at: https://docs.unrealengine.com/latest...ons/index.html

    Ok, you know what iterators are, but here's a link anyway: https://wiki.unrealengine.com/Iterat..._Faster_Search

    You can also create your own singleton class, and there store references to actors. Look: https://wiki.unrealengine.com/Global...During_Runtime
    Last edited by fireapache; 08-05-2014, 07:18 PM.

    Comment


      #3
      So, I think you've helped... This may be what you've just said, what do you think:

      Create a singleton and set up an input delegator: This input delegator has properties like:

      Code:
      Gamepad* gamepads[4];
      Keyboard* keyboard;
      // Mouse* mouse;
      Create a singleton for players, this player store has properties like:

      Code:
      APlayer* players[2];
      On the construct of the input delegator singleton class, I will setup the gamepads and keyboard and allow a menu to select for players from the player store, which input will be assigned to which player (I'm sure their will be a type definition problem there, I'll have to abstract them away to InputType class that has an internal pointer to the input controller)

      Then when any button is pressed, the input delegator will look at which player is assigned to that controller and apply actions for that player only.

      I'm not sure about the use of singletons, I don't like their global access when it really isn't required... Is there no starting place I can just go and pass pointers down into?

      Comment


        #4
        Don't know if you got this idea of singleton class...

        Imagine a sort of "global data base", a object that every other can access at any time. So when your players receive input signals they all can access this "global data base" and verify if it's assigned to him take an action. Put the key mapping variables in this singleton class.

        Am I helping here?

        Comment


          #5
          My problem with singletons is the fact they are typically global and thus can be affected from anywhere, they have to be watched in debug due to them not belonging to any other classes. Singletons are typically a bad idea... After coding for 8 years, you stop making these mistakes... However, that doesn't get me closer to solving the issue... and i'm fine to take your approach if I do not get another response... however, for now:

          Do you know a place where I can actually pass a class down into the main layer of the engine, then I can pass the InputDelegation class around like a dirty hooker to the objects that require it rather than just allow everyone to suckle upon its teat?

          -----------------------

          Just thought this'd be useful:

          Paraphrased from Brian Button:
          1.They are generally used as a global instance, why is that so bad? Because you hide the dependencies of your application in your code, instead of exposing them through the interfaces. Making something global to avoid passing it around is a code smell.
          2.They violate the single responsibility principle: by virtue of the fact that they control their own creation and lifecycle.
          3.They inherently cause code to be tightly coupled. This makes faking them out under test rather difficult in many cases.
          4.They carry state around for the lifetime of the application. Another hit to testing since you can end up with a situation where tests need to be ordered which is a big no no for unit tests. Why? Because each unit test should be independent from the other.

          P.S Tight coupling is not so true here, you can always create a layer outside of your code as an interface, and use that as the code you will use... it may just be that in this very case... it's not such a bad idea, but I still don't like it.
          Last edited by jimmyt1988; 08-06-2014, 05:31 AM.

          Comment


            #6
            Hey, Jimmy, sorry the delay!

            Yup, for huge software projects I would be very cautious at using singletons, it may be a real problem, indeed!

            But, for small games where is known that a few and controlled number of objects will access the singleton, it would not be a big problem.

            ... but, if you are really afraid of this approach, then an option is to add these key/players mappings in the GameMode class! It's easy to get a GameMode pointer and access the variables there.

            Did you get anything working already?
            Last edited by fireapache; 08-07-2014, 01:12 AM.

            Comment


              #7
              I got side-tracked by the ease of adding physics volumes lol... I will come back to this post when I refocus...

              Comment


                #8
                "Hours later"...

                "More hours later"...

                Thanks man, this works okay. I declare my instances inside the GameMode class and just call upon them from there, it's much easier to track where those are in debugger too. Ta.

                Comment

                Working...
                X