I think a simple game in Unity is probably as good a platform as any for learning what you want to learn. In any case, I wouldn't worry too much about finding the 'right' project to start with.

A possible strategy would be not to worry too much about the 'OOP' part of things. Just start working in Unity or the engine of your choice, and if something doesn't make sense, research it or ask online about it.

Part of the appeal of OOP (I think) is that it mirrors how we experience and think about things in real life (e.g. there are types of things, and instances of those types, and those instances interact with each other in various ways). As such, you may find that how to apply object-oriented techniques will naturally become clear as you progress.

3 hours ago, NoviceOfProgramming said:

I have been off and on learning programming, mostly because of confusion or impatience when it came of OOP. I understand loops, if, using paramters and arguments, using local and global variables, even some general practices when writing out pseudocode for OOP. Though every time I finish up learning the "basics" with structured; I try to jump straight into Unity to try to test my skills at OOP, and I get a bit overwhelmed or confused what would actually be a good beginner project. I know learning programming's end goal for me was to make games, but I understand if there is a better in between goal to help connect my knowledge together.

I don't how to take my little javascript/python practices to something like using Unity or Unreal? Any ideas on a good mid-goal to do?

What I think is you should think of OOP more of a concept instead of a concrete piece of code in this case. Unity is more about visual and usability, so you got to think of their entities and their components as the "object" themselves. For example, you create a game object, this should be conceptually assumed as an "instance" of your "class" (therefore object, a game object). Prefab is something you can call as "class" in OOP, where you can create "instances" of that "class". This is almost the same as Unreal Engine's actor blueprints/C++ class, where you can create instances out of it.

The components are conceptually composition of that game object. For example:

class ICanBeGameObjectButNoIdeaWhatIAm { // <-- This is what will become your "game object" as an instance of it, or prefab.
    ...
    SteeringComponent steeringComponent; // <-- Your custom script to Steer left or right. By this, you describe that this game object can steer left or right. Could be a car, but that's up to you!
}

Unity has made it easy for you that your paradigm should be simply create a game object and attach components you need to describe that game object.

Your pure OOP concept will still be useful when you do all things behind that concept, most often related to event listeners, messaging system, networks, or your own game play systems, some things that aren't bound to their Behavior architecture. But everything related to common things such as rendering, user input, physics, audio, it's all provided for you, with their own way. That means you got to learn its architecture to extend them.

On 9/1/2018 at 7:15 PM, NoviceOfProgramming said:

try to test my skills at OOP

Yeah, don't do that.  OOP is a buzzword, and the tech for it is built in to the language itself. Everything you create is an object and all your elements are inside those objects. Congratulations, you've got 100% OOP by default. ?

At this point in your learning try to build whatever you can that mostly works okay.  Maybe that means placing a bunch of items on a map and trying to create an enemy that runs toward the player, or 

maybe building your own controls for an aimbot, or self-driving cars through an obstacle course, or whatever simple experiments you want to learn with.

I'm pretty new to Unity, but I've been programing for 15 years. Personally I think you won't find much use OOP concepts in the Unity, especially when it comes to game objects. It looks like classes are only used a collection of Components in Unity. You can do subclasses of course, but it might not be very useful.

The same thing goes for Unreal Engine as well, if I'm not mistaken.

Probably there are much uses of it in other area than the game objects, I don't know.....

On 9/1/2018 at 10:51 PM, mychii said:

What I think is you should think of OOP more of a concept instead of a concrete piece of code in this case. Unity is more about visual and usability, so you got to think of their entities and their components as the "object" themselves. For example, you create a game object, this should be conceptually assumed as an "instance" of your "class" (therefore object, a game object). Prefab is something you can call as "class" in OOP, where you can create "instances" of that "class". This is almost the same as Unreal Engine's actor blueprints/C++ class, where you can create instances out of it.

The components are conceptually composition of that game object. For example:

class ICanBeGameObjectButNoIdeaWhatIAm { // <-- This is what will become your "game object" as an instance of it, or prefab.
    ...
    SteeringComponent steeringComponent; // <-- Your custom script to Steer left or right. By this, you describe that this game object can steer left or right. Could be a car, but that's up to you!
}

Unity has made it easy for you that your paradigm should be simply create a game object and attach components you need to describe that game object.

Your pure OOP concept will still be useful when you do all things behind that concept, most often related to event listeners, messaging system, networks, or your own game play systems, some things that aren't bound to their Behavior architecture. But everything related to common things such as rendering, user input, physics, audio, it's all provided for you, with their own way. That means you got to learn its architecture to extend them.

Your reply really got to the heart of my perception of the whole thing!