Next course

Unity Courses Talk
,
#1

I would love to see a course unifying this (strategy) course and the RPG course.
1- swapping between free movement and our grid upon enemy engagement
2- saving system integrated
3- weapons and action scriptable objects
4- inventory effects on attack stats
5- discuss and agree on singleton pattern usage
6- discuss and agree on namespace patterns
etc…

i love both courses. i am learning a lot. but some guidance on the above would be awesome!
(plus every one who bought both courses would buy this course!)

3 Likes
#2

I want this too.

#3

Since everything you listed is covered in one of the two courses I don’t see the point of covering it again. Ideally, at this point, your coding skills should be intermediate, this means you should be able to pull all of that off, specially when you already did it once. The game’s genre doesn’t really matter when talking about coding.

I think the only thing that isn’t covered during courses is namespace patterns, that’s mainly because there’s no such thing as far as I’m aware of, namespaces are just an organization tool and it can vary from project to project, but there are some type of namespaces that aren’t shown in the courses, like nested namespaces.

I highly suggest you try to make all of that work by yourself, otherwise you are going to get stuck on the infamous “tutorial hell”. What is tutorial hell?

Unfortunately, a lot of the tutorials out there leave you there, in tutorial hell, 1) by design; because it leads to more money, just see yourself, you are asking to pay for yet another tutorial that you don’t actually need, or 2) by accident, a lot of tutorials are created by people that give you the fish instead of teaching you how to fish, and if you are asking for yet another fish, that’s great feedback for the Gamedev.tv team.

I’m not saying the team shouldn’t create the course you are asking, I’m saying that if you took those courses you can do it on your own.

1 Like
#4

I do agree. I guess I would like discussions on how to combine the ideas. As I am doing this myself, I am hit with issue after issue that I’m interested in how the two designers if the two courses would solve. I can make a sln, but it usually breaks some underlying pattern used in one other the other course.

#5

Ironically enough, I suggest this course if you are having issues:

Sam explains patterns, how to use them, when to use them, and gives coding examples. It’s short but really good, it might give you an idea on how to fuse those things together.

#6

While we don’t have plans for this, the good news is that I’m covering this course as well as the RPG series, and am more than happy to assist and answer questions involving integration for students interested in blending the two.

Ooh, I like this idea a LOT

Easy stuff to integrate. I’d suggest giving it a go, and ask questions as issues arise.

Discuss? Certainly. Agree? No, and that’s ok!! Hugo and I have competing philosophies on both Singletons and Namespaces, but that doesn’t actually mean that either of us are wrong, just that we use different tools to achieve the same result.

In the case of Namespaces, the project in this course is small enough that namespaces aren’t necessarily helpful. The RPG course is massive, so we introduced namespaces early in the course, knowing that the four or five namespaces in the first course balloons into a couple dozen by the time the project is done. The RPG series is actually the only one in our catalogue that emphasizes the use of namespaces. I think, when integrating the two projects, that it’s beneficial to apply namespaces.

Singletons have been a point of debate since the dawn of OOP, and have been hailed as both the perfect solution for global state problems to an actual article entitled “Singletons are Pathological Liars” (I kid you not, Google it). We’re not going to solve that debate here. The fact is that sometimes Singletons are necessary. To prove it, I’ll point back to the RPG course. In that course, as well as the Design Patterns course, there is a lecture “Better than a Singleton”… I’m going to let you in on a little secret: The PersistentObjectsPrefab in the RPG course is a Singleton.

Singletons do come with some inherent problems that need to be addressed. It’s harder to spot cross dependencies when using Singletons, and execution order can be an issue (you’ll note that Hugo tackles the execution order issue in this course). I have a version of this course that I wrote without a single classic Singleton, but even then, I needed to use static events to make it work, and static events are actually an object shared by all instances of a script, and are technically… Singletons. Sometimes, you just need them in one form or another. Am I recommending that everybody here ditch the Singletons as Hugo is using them? Absolutely not! It’s quite the undertaking, and in the end, I don’t know that I realized any benefit in my version of the game besides being able to say that I did it.

2 Likes
#7

For the idea of swapping between free movement and the gird system upon enemy engagement, would writing a new script for swapping between scenes be an appropriate way to implement this? or creating a boolean field like “isBattle” and assigning it to be true or false when an enemy is engaged? would really like to implement this idea and would love to hear your thoughts on how you would go about this

#8

That may depend on how you wish to have the battle ensue. For example, a classic JRPG quite literally switches scenes to a Battle scene whenever you enter battle. These are actually one of my favorite styles of RPGs, as you get the combination of freedom of motion through the world, with more constraints and order during the battles.

Some newer games are literally overlaying a grid system directly into the scene, which is cool, but quite a bit more complicated to work with.

1 Like
#10

Hi Brian and all. I’m also interested in this discussion. I finalized this course and RPG courses and currently thinking to integrate them into a game like “Wasteland 3” which only the combat use grids, the rest of the game would just behave like real-time RPG game.

Currently, I have 2 main ideas of achieving this, but don’t know which one is more suitable, would like to hearing your opinions and other ideas if any.

First idea is: The Grids and Gridsystem only got spawned when a new combat starts (meaning only battle uses grids to move etc). When not starting combat, I would like the game to be controlled by NavMesh and NavAgent. This doesn’t involve switching to a new scene to combat, but spawning grids to the same scene.

Second idea is: to spawn a giant grid map to cover the whole scene when game starts (my scene is not very large), but disable the “Turn system” and grid visual that player and AI can do their things simultaneously like real-time RPG. Only when the combat starts should the “Turn system” and grids visual enabled. Kind like using our gird system to replace the NavMesh to navigate the player and AI movement.

However, I already can see some potential issues for both ideas, first ideas Only spawning the grids when combat starts could result issue that grids map not correctly match the scene such as the walls and obstacles may not perfectly align with the grid position.

Which makes second idea more closes to what I what, I tried a few scenes like generate 100*100 grids map is still smooth and player and AI can move normally. But one potential issue would be the girds for slopes terrain would be difficult to spawn, such as I’d figure out how to spawn grids against stairs or path on the hills.
I’d like to hear more ideas. Thanks a lot.

#11

I suspect in the case of Wastelands3, that what they’ve done is design the world with the grids in mind… constructing the world out of tiles (probably a lot of custom designed tiles for that particular tile). Then it’s just a matter of activating the system when you go to combat.
I could be wrong on that, though. It’s tough, sometimes, to mimic the behavior of a game that was written by a dedicated team.

Since the grid positions are essentially a math function more than anything else, they could be doing it with a simple terrain, and then projecting the grid using Decals. You can still place obstacles in the terrain, even if they’re simply blank colliders.

Either way, there’s going to be some work to implement.

#12

Thanks for prompt reply, Brian. I tested their game a few times, feels like they did both. It would be hard, maybe cannot make it exactly the same, but I got a few ideas going to have a try.

#13

The saving and loading would be an amazin add on to the course

#14

This one definitely burned me. :slight_smile:

I wanted to add in scene management in my code and realized that events, namely static events ended up breaking. So then I had to make a few changes to subscribe and unsubscribe from events. As I found more bugs I eventually just moved all my event subscriptions to OnEnable. But changing the order of event listener registration created what seemed like a circular dependency on execution order between UnitActionSystem and GridSystemVisual.

It was hard to spot it since it created a Null exception but the game quickly recovered so you didn’t notice anything was broken until I got to the HexGrid lesson and copying my scene over changed my execution order in a way that broke something more strongly than before.

Wow it was so hard to figure this out.

I solved it by adding an “isInitialized” boolean on UnitActionSystem and pulling the code out of Start and putting it in Update(). Then the first time through update I set the selected unit.

Singletons, static events, scene management… the combination of all those adds a lot of complexity to the code. But as Brian mentions there’s really no avoiding it. I guess what I’d be interested in is how to do all this without driving yourself crazy. Are there certain best practices of how you set up your architecture to avoid these problems.

#15

The one I’ve been trying to use for my own development is
a) to try to put my singleton classes early in execution order
b) register and unregister listeners in OnEnable and OnDisable
c) keep singleton classes as light as possible on code within Start(). The fewer singletons the better since I now see first hand how it creates problems in execution order.

If there’s something better I would love to hear it!

#16

As I said earlier, the task of making the project work without a single Singleton was ultimately not worth more than my ability to say I’d done the intellectual exercise. It’s not really worth the headache in the long run.

#17

When I said “how to do this,” by “this” I was referring to “how to use singletons and static events without driving yourself crazy.” Certainly not trying to eliminate altogether. When I tried to expand the project with more features, I ran into some seemingly circular dependencies. Since singletons are hard to completely avoid, what are some simple easy things we could do to limit the scope of such problems?

#18

The biggest pitfalls with Singletons in general are actually issues you can encounter without using Singletons at all.

Circular dependencies - Any time two classes refer to each other, you’re opening up the risk of a circular dependency. When events become involved, it’s possible to find yourself in a difficult to diagnose infinite loop. This isn’t unique to Singletons or static events at all, but any time you do encounter cross references you need to be aware of the possibility. A great way of avoiding circular dependencies is through the use of interfaces, or through dependency injection.

Race conditions - Again, hardly unique to Singletons. While Script Execution Order is one way of tackling the issue, another is by making best practice useage of the Unity Callback methods:

  • Awake() – Initialize instance level variables and cache references here. Do not access methods on other classes in Awake() as they may or may not have been properly initialized at this point. You can subscribe to events here, but do not Invoke() events yet.
  • OnEnable()/OnDisable() – Best place to subscribe to/unsubscribe from events.
  • Start() – finalize initialization of variables dependent on other classes. At this point, assuming that you don’t have circular references, you should be free to access other classes without race conditions (there are exceptions).
1 Like

Privacy & Terms