Hi,

In 'real life' I'm a manager, part time designer in the video game industry. That's all fun and all, but the truth is, I'm an indie at heart.

In my journey to becoming a full-fledged indie by my mid 30s, I've recently started programming "again".

Long story short, I've been 'programming' runtime since I was 9, in various languages with limited success.

Spent a year studying computer sciences and dropped out despite keeping my score above 90% (I was obsessed with Game Design back then...)

Nowadays, I find myself using a number of API, namely Dart.

While I still understand algorithmic, and can relatively learn to adapt to syntax, I find myself faced with a very difficult wall: Object-Oriented Programming.

I'm not exactly estranged to the idea of Object-Oriented Programming, I've already used Visual Basic to some degree.

But the big bad and ugly truth is that I still 'think' in terms of Runtime, and somehow reason things through that way, which appears to limit me in adapting to OOP.

I've come to the conclusion that I need to start from scratch so that I really understand what I'm doing, and the way to go is to understand the logic of OOP.

I've looked up the Wikipedia articles on OOP, and they've helped, to a degree, but I can't help but figure there must be a more appropriate guide to OOP out there, so that I can modernise my knowledge and finally adapt to that way of thinking.

Anybody here knows of such an article/book?

I looked trough the FAQ stickies around here to no avail.

(Found: http://www.gamedev.net/page/resources/_/technical/game-programming/object-oriented-game-design-r3116 but this is C++ only)

To be honest, I'm not understanding this part of your post.

Well, before OOP, programming (as I knew it) was a lot of lines, individual variables, etc.

In other words, I can't fully take advantage of classes, objects and instancing because I'm finding it very hard to fully understand the underlying logic.

The fact that I struggle against many aspects of OOP has led me to believe that there is an inherent problem: I do not understand OOP as much as I believed I did. Just because I can reference an object.method() with proper syntax doesn't mean I can fully leverage the advantage of OOP way of thinking, and this is the issue I'm faced with. Without proper understanding of the concept of OOP, I'm not really using OOP.

I think OP seems to be referring to procedural programming. He programmed in Visual Basic before.

To understand Object Oriented Programming is to relate to real life. You can think of yourself as an object. You have some methods or behavior that you possess. You have the eat() method and sleep() method etc. You have several fields or variables associated with you. You have the age variable = 30 represented by an integer. You are an instance or an example of the Human Class.

Try applying this concept in an object oriented language. The fact that you do not understand now does not mean you will not understand later. Take the time to learn it properly. I think you are beating yourself up.

Warnexus, yes I do understand at least that. I also understand how superclass can have children that will inherit all methods and properties (extending).

Taking this simplified theory to actual practice is where I'm having troubles.

For example, if I want to design a map system with enemies on it, I'll instantly think of making an array for the map coordinates along with an array that contains all game objects, etc. Unless forced, I will not naturally think in terms of 'objects' & 'classes' because, while I believe I understand the underlying theory, I'm having a rough time applying it in context and leveraging it efficiently.

One thing I'd like to do is to code pong in a non-procedural way for example, but I'm having a hard time architecturing my concepts in terms of classes and objects. I can code allright, but I can't think in terms of how it needs to be built if it is to be OOP.

Is it any clearer? (its hard to talk about things I only half grasp)

Warnexus, yes I do understand at least that. I also understand how superclass can have children that will inherit all methods and properties (extending).

Taking this simplified theory to actual practice is where I'm having troubles.

For example, if I want to design a map system with enemies on it, I'll instantly think of making an array for the map coordinates along with an array that contains all game objects, etc. Unless forced, I will not naturally think in terms of 'objects' & 'classes' because, while I believe I understand the underlying theory, I'm having a rough time applying it in context and leveraging it efficiently.

One thing I'd like to do is to code pong in a non-procedural way for example, but I'm having a hard time architecturing my concepts in terms of classes and objects. I can code allright, but I can't think in terms of how it needs to be built if it is to be OOP.

Is it any clearer? (its hard to talk about things I only half grasp)

The point of a class is for re-using code which prevents duplicated code and allows for reusability of this class in other projects.

Before jumping ahead to code up the game, take paper and a pencil and think about the general things that are going to be in the game.

Below is one way to structure Pong. Most of the classes besides the two classes: paddle and ball can be used in future game projects. Code is in Java.

In a pong game, there are two paddle objects. So both paddle object will inherit from the same class Paddle.

Paddle playerOne = new Paddle(x,y);

Paddle playerTwo = new Paddle(x,y);

public class Game extends Canvas
{
 
}

public class Vector2D
{
 
private double x;
private double y;
}

public class Ball extends Sprite
{
 
}

// this paddle object will inherit from the class Sprite
public class Paddle extends Sprite
{

private Vector2D position;
private Vector2D velocity;
 
public void draw(Graphics g)
{
 
}
 
public void update(long milliseconds)
{
 
}
 
}

public class Sprite implements GameObjects
{
 
public void draw(Graphics g)
{
 
}
 
 
public void update(long milliseconds)
{
 
}
 
}

public interface GameObjects
{
 
public void draw(Graphics g)
{
 
}
 
public void update(long milliseconds)
{
 
}
 
}

Thanks for the input.

Also, I was lucky to find this article which is pretty much what I was looking for.

Thanks again!

Thanks for the input.

Also, I was lucky to find this article which is pretty much what I was looking for.

Thanks again!

Ah yes that is an awesome article!