Announcement

Collapse
No announcement yet.

Community Led Training - Exploring Code Principles in Blueprint - July 18 - Peter L Newton

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

    [LIVESTREAM] Community Led Training - Exploring Code Principles in Blueprint - July 18 - Peter L Newton


    WHAT
    Peter Newton takes up the mantle for our second community led training stream. He'll explain the Single Responsibility Principle, why it's useful, and how to apply it to your own Blueprint projects!

    Please feel free to post questions here prior to the stream and folks from Epic will join the live chat to help field your questions during the stream.

    WHEN
    Tuesday, July 18th @ 2:00PM ET [Countdown]

    WHERE
    Twitch
    Youtube

    WHO
    Peter L Newton - @PeterLNewton / Peterlnewton.com

    ARCHIVE
    Last edited by Amanda.Bott; 07-20-2017, 11:38 AM.

    #2
    Congrats Peter, you deserve it
    Join the Unreal Engine community on Reddit! | Twitter: @ZioYuri78

    Comment


      #3
      Interested to hear about SRP with regard to best practice / simplicity

      Especially when prototyping, as its often confusing where best to put stuff...
      Take a SP/local MP game with: Player-Controller, Gamemode, Pawns, HUDs...
      (6DOF Spaceshooter / Strategy-type game w/ lots of Spaceships/Weapons).

      You don't want game logic in HUDs or you want to minimize that if possible.
      But putting it all instead in Gamemode / PC may make code harder to read.
      Whereas Pawn is a more natural simpler choice. But then this bloats Pawn.
      Interfaces / Dispatchers etc, may or may not help all that much here either...

      Marketplace packs, where things are done differently, can also bring chaos.
      Especially when classes receive direct 'Player-Inputs' or little is centralized.
      That may simplify learning sample code, but its also far harder to maintain.

      Comment


        #4
        THANK YOU


        I'm excited for everyone to join me! My plan is for everyone to be able to take away skills which they can use now to help manage and maintain their Blueprint code. This has less to do with naming conventions, but now how you layout your nodes.

        I posted a tweet about this which clearly demonstrates the idea.

        What typically is done.
        Click image for larger version

Name:	d158ead51af907383617b55c639da748.jpg
Views:	1
Size:	630.8 KB
ID:	1131290

        What the results of following the guidelines.
        Click image for larger version

Name:	b43b33ac22069ec9d70d9fbd87f7ec9b.jpg
Views:	1
Size:	877.2 KB
ID:	1131291

        Notice that instead of showing all of the high-level functions, which tell us nothing other than something is happening.

        Once changed, the Blueprint Visual Scripting code itself tells us what is happening. We don't need comment nodes, although they can help.

        This loosely follows the principles called Single Responsibility Principles. It's true definition applies to classes and modules, but I am applying it to functions. Curly's Law is the principle used for functions. But the take away is that your code is itself is understandable.

        We don't need documentation to understand the original authors intent. So I want to bring over a lot of principles which already exist, and that I have no part in creating. I am just bringing it to you, so that you all can benefit as I do from the benefits of SRP Principles, and the others like it.


        LEARN MORE


        If you're interested in SRP and SOLID. Here are some awesome articles about it.
        SOLID on Wikipedia


        Game Tut's The SOLID Principles
        (Game Tut's is an amazing source for foundation game knowledge.)


        Curly's Law Principles, Similar to SRP, for functions.
        Attached Files
        Last edited by PeterLNewton; 07-18-2017, 12:10 PM.

        Comment


          #5
          Will you be able to show these coding principles in practice with a networking mindset as well?

          Comment


            #6
            Originally posted by Oldsiren View Post
            Will you be able to show these coding principles in practice with a networking mindset as well?
            In theory, it would be no different. But I could take the time to provide examples of how I would it. But it's truly subjective, the end goal is, can you mentally follow your code? If you cannot without really trying, then you've failed.

            When going back to code that is really old. It shouldn't be impossible to understand. Which is the case if you don't prepare. You should just have to take the time to step through all of your code. Most of the time, people don't have the patient to collapse your code into smaller reusable code. Such as myself once upon a time. But, when you take the time to break everything into smaller segments and reuse them as necessary. You actually find that code is generally much easier to recall.

            Comment


              #7
              First things first.
              I will be watching this for your incredible sense of humor.
              Your skills, and tutorials helped teach me a lot, but your corny jokes, and your gigglesALWAYS keep my attention.
              Thanks for everything you do.

              Comment


                #8
                I've always wondered what the L stood for. I guess it does have a better ring to it than just Peter Newton. Gotta have the L in there.

                Good that there's a stream that show that Blueprint shares the benefits of good coding practices with other languages. Always suspected that those who didn't get into Blueprints never really learned to apply common coding style principles to their visual scripting.

                Comment


                  #9
                  Originally posted by thadkinsjr View Post
                  First things first.
                  I will be watching this for your incredible sense of humor.
                  Your skills, and tutorials helped teach me a lot, but your corny jokes, and your gigglesALWAYS keep my attention.
                  Thanks for everything you do.
                  You've made my week haha. Thank you for that! Means the world.

                  Originally posted by ag858 View Post
                  I've always wondered what the L stood for. I guess it does have a better ring to it than just Peter Newton. Gotta have the L in there.

                  Good that there's a stream that show that Blueprint shares the benefits of good coding practices with other languages. Always suspected that those who didn't get into Blueprints never really learned to apply common coding style principles to their visual scripting.
                  ^^, hope you never find out. It's something I do like to keep to myself. But I do agree, it's not complete without the L.

                  Yes! That's the plan! Hope you enjoy the stream.

                  Comment


                    #10
                    Looking at the screenshot, it would be great to include a brief explanation when to use Macros, Functions and Events, because all the first google links only say what they are and what you can do with them, but fail to explain when to use which one. <3
                    https://twitter.com/Ninjin42

                    Comment


                      #11
                      Originally posted by Ninjin View Post
                      Looking at the screenshot, it would be great to include a brief explanation when to use Macros, Functions and Events, because all the first google links only say what they are and what you can do with them, but fail to explain when to use which one. <3
                      I could do a stream just about that! I am currently writing a peer reviewed book on Blueprints with a few of the Unreal Engine Community experts. So we're going to talk a lot about use of Macros, Functions, and Events/Delegates in the book. BUT, I can definitely talk to Epic about doing another stream on that topic.

                      Originally posted by franktech View Post
                      Especially when prototyping, as its often confusing where best to put stuff...
                      Take a SP/local MP game with: Player-Controller, Gamemode, Pawns, HUDs...
                      (6DOF Spaceshooter / Strategy-type game w/ lots of Spaceships/Weapons).

                      You don't want game logic in HUDs or you want to minimize that if possible.
                      But putting it all instead in Gamemode / PC may make code harder to read.
                      Whereas Pawn is a more natural simpler choice. But then this bloats Pawn.
                      Interfaces / Dispatchers etc, may or may not help all that much here either...

                      Marketplace packs, where things are done differently, can also bring chaos.
                      Especially when classes receive direct 'Player-Inputs' or little is centralized.
                      That may simplify learning sample code, but its also far harder to maintain.
                      You bring up a lot of excellent points. These are all extensions of this conversations. It's not something that I could just explain in one breath, of else it would be common practice.

                      What I hope is by introducing a wave of different topics which I think are foundational to understanding where to place logic.

                      Think of this way, if you take the time to effectively break your code into pieces. It's much easier to identify where it can be improved, but also just as easy to understand where to interject subroutines to expose parts of the functionality in graceful way. Instead of constantly making hacks when you need a particular variable.

                      The problem is if you don't try to organize your code with any sort of patterns or principles, it's nearly impossible to effectively improve your code. Bugs are harder to see, repetition is harder to see, and when you come back in 2-6 months. Can you remember what you where doing?

                      So all very good points, I'll continue to bring up over the streams.
                      Last edited by PeterLNewton; 07-18-2017, 01:14 PM.

                      Comment


                        #12
                        I for myself try to use as many Interfaces as possible.

                        I try to make an oldschool Action RPG where the Game stops when someone casts a spell for example.

                        Everything is handled by the GameState. And to access the GameState, I use Interface Messages.
                        I created multiple Interfaces for the Combat. for example "GetBasePhysicalDamage". For Characters, this takes the Weapon and Status in Account, while it is a predefined number for enemies.
                        For hit detection i simply need to call getBasePhysicalDamage without caring about the actual type. This is why I like Interface Messages so much.
                        All they lack is Replication. At the moment you need to implement the Interface Event and then call a separate Event with your desired Replication Settings.

                        Comment

                        Working...
                        X