Courses or tutorials oriented to experienced developers

Hello Unity community, as the title of this post indicates, I'm looking for courses or tutorials on how to start with Unity, but aimed to experienced software developers (in other industries) that want to create games.

I've been searching for tutorials, and I now have some foundations in Unity, but I come to realize that they often show bad coding practices, and they lack of important topics on software development foundations and architecture. The code they write doesn't scale, and it seems very difficult that it can be reused; and I find those things annoying.
I understand that those tutorials are not supposed to overwhelm audience, since they are intended for people that is starting on programming as well. So rather than spending time watching the same things I thought of asking here, since I'm pretty sure there's people here that faced my same issue.

Maybe the reason I'm find those tutorials annoying might be my own experience, I see code and automatically try to think in advance, how the classes should be structured, how to generalize things, but maybe that's not how Unity should be used. So I want to learn how to put my SDE mindset aside and think as a game developer.

Some of the things I'm looking for are:

• How to actually use Unity (which is covered in most tutorials, no complaint on this regard)
• How to do a basic game architecture: This is very important to me, it covers simple things like how to properly structure the code, design patterns for games, depth in things like mono behavior and how unity works on the inside, test code, deploy, etc.
• How to use Unity to write software that scale: I have seen tutorials on how a game character is created or how animations are done, but what about reusing all that stuff? how do I generalize those things and use them in later projects or inside the same project but in different instances?
• Performance: How to handle resources, make improvements on the game performance, benchmarking, profiling, etc.

Thank you guys, and I'm really looking forward to become active on this forum!

 

These are good questions — I don't know of any tutorials offhand which address these directly, but they're certainly valid topics for this forum. I've worked on a lot of Unity projects of all sizes, and I've certainly seen ones that were a big spaghetti-like mess. Unfortunately Unity's basic design is built around putting everything on GameObjects in the scene, often relying on things like the physics engine for much of the behavior, which makes it very difficult to test, to look ahead for AI, run high-speed simulations, etc. I was once hired to add AI to a turn-based, grid-based strategy game... where all the game logic was distributed across dozens of GameObjects in the scene, game rules depending on physics-based ray-casting (!). It was a mess, and I ended up essentially replicating the entire game logic in a smaller, simpler set of POD (plain old data) classes so I do an alpha-beta search for the best move. That worked OK, but it couldn't match the actual game perfectly, and keeping it in sync as they changed things in the spaghetti was an ongoing issue.

All of that is a cautionary tale with the moral: think about doing a MVC-style separation of game logic from game view. As another, positive example, I'm involved in a fighting game project where we thought about this from the beginning, and so we designed 100% of the game logic in POD classes. Those represent the entire game state, including player inputs, and we can basically run the game forwards and backwards at high speed with no display at all. Then there is a display layer that simply examines this data, and poses models, camera, and special effects (particle systems etc.) accordingly. This lets us do things like net-frame rollback in a multiplayer game; it also lets us do things like run a bunch of unit tests on loading, very quickly and behind the scenes. So doing this sort of clean separation between model and view is possible, but you have to plan for it ahead of time.

The other thing I think you should know, as a newbie to Unity, is the proper use of Unity Events. These are extremely handy connectors for things at the view level, and often event Unity's own tutorials fail to really grok them. I made a short video about that here. Since then I've developed a little library of simple scripts that are designed to either invoke an event when something happens (Triggers), or do something when invoked by an event (Actions), or invoke another event in some way related to being invoked (Relays).



These are usually the first thing I drop into a new project (after Script Inspector 3), and I write my custom view classes using the same pattern: invoke an event when anything of interest happens, and do actions as public methods that can be invoked from an event. This lets me keep all that stuff highly decoupled and reusable.

Hope this helps, and I love digging into deeper topics now and then, so feel free to ask lots of questions!