Praise for instructor approach to Gameplay Framework usage here

[tiburbage]

I just wanted to call out this part of the ShooterGame training. Usage of the Gameplay classes, i.e. GameMode and all of its related “subclasses”, and including GameInstance, is often sort of glossed over in tutorials, including even those provided by Unreal folks.

A common refrain is “you wouldn’t want to do it this way for Multi-Player, but hey, my little tut doesn’t cover that…”.

My thought is, why not show people a strong demonstration of how to use those classes effectively which holds up for both single player and multi-player, for games with multiple levels, interactive and cut scene, and so on.

In this section the trainer brings that MP vs single player consideration into the discussion, and also includes how the crucial PlayerController usage also should play into it. Great stuff!

[DanM]

I’m sure @sampattuzzi greatly appreciates the appreciation

[sampattuzzi]

I do! I think it helps that I’ve implemented the multiplayer side of things. Many doing the tutorials haven’t.

[tiburbage]

Well, multiplayer is an advanced topic, so I didn’t expect it to be covered in this course’s sections directly.
But again, I think there can be some “best practices” for how to use the Gameplay Framework classes effectively in a way which is compatible with any form of game we want to build in UE.
Also, this course overall didn’t address saving state at all, which is a foundational element of most games. That, and especially in the context of multi-player, is where proper use of the GameInstance, GameState, PlayerState really come into play. Hopefully, topics like that will get coverage in more targeted, intermediate/advanced training in the future.

Thanks for all of the AI/NPC and animation-related content of your section. That stuff is hardly covered at all elsewhere. I think it reveals a couple of important things about game development in UE. First, that there are some things that really are best done in C++ for those who can, but also that there is a huge amount of stuff that can and should be delegated to the TA (technical artist), and that the right exposure of key elements (UFUNCTION, UPROPERTY) provides good structure, but defers to the TA to use that structure as specifically needed. I have as much of an asset creator POV as a developer one, so that just reinforced in my mind that unless one is trying to implement some really complex and performance sensitive things, the work on the C++ side doesn’t need to be hugely complicated, and should be done to to serve the downstream TA, level designer, and artist needs.