I find it disconcerting that I never once bothered to question the merits of OOP until now. This thread has been really interesting, and I have been reading/watching related material. I especially enjoyed the video that Casey linked. It makes me wonder how many other programming assumptions that I have that I should question.
Thank you for the all the input.
Thank you for the all the input.
cmuratori
https://www.youtube.com/watch?v=rX0ItVEVjHc
I've never been a strong advocate for any form of paradigms, if something feels right for the current situation I use it. Classes, or a file full of structs and functions or global variables for that matter.
It all comes down to how and when. Do you prefer to use a class for your vectors with operator overloading? Then use that, you'll usually inline stuff like that so who cares. You feel like most of the code should be written in a C like way, then do that. And sometimes that global variable just makes lives easier...
What isn't making life easier though is people who firmly states that something is BAD ALWAYS. Use your own judgement and decide what is best for your own project. Too much of one particular paradigm is usually never good.
It all comes down to how and when. Do you prefer to use a class for your vectors with operator overloading? Then use that, you'll usually inline stuff like that so who cares. You feel like most of the code should be written in a C like way, then do that. And sometimes that global variable just makes lives easier...
What isn't making life easier though is people who firmly states that something is BAD ALWAYS. Use your own judgement and decide what is best for your own project. Too much of one particular paradigm is usually never good.
Lanz
What isn't making life easier though is people who firmly states that something is BAD ALWAYS. Use your own judgement and decide what is best for your own project. Too much of one particular paradigm is usually never good.
This!
I find it funny people like this thread as it contains almost no real information. Just opinion.
OOP is very much misunderstood. It is just structures + functions (like all kind of code). So does that mean structures are "bad"? Of course not. OOP is simply structures + functions where one of the parameters for the functions are not there anymore. Like when Casey uses Buffer or GameState all over the place. If you have many like that, over some complexity, an object would pull the Buffer parameter into the object. So it doesn't have to be pushed to the stack. Thats basically it. In addition, you avoid large case and if statements, by using virtual routines. OOP are for managing big complexity, and if used like that, it offers only advantages. And no performance penalty at all. If you believe that OOP is the oposite of dataorigented, you are dead wrong, and you have completly missed the point.
OOP is _supposed_ to be encapsulating a Spesific WELL-DEFINED functionality, and streamline it. Like a statemachine. An optimized statemachine. That is optimized for the most common in use case. And that ideally is as easy to use a call "Object.Play". It should offer this functionality without any perfomance penalties, and it MUST also offer to customize the statemachine at every important point in the execution of this welldefined functionality. Including replacing everything.
Inside the Object itself, OOP should be avoided. Unless the object is extremely complex, and it would help to also make some of the internals seperate objects.
It's just that people don't understand what they are doing. Maybe because they never take the time needed to fully evalutate the tools they use. IDK.
Edited by Livet Ersomen Strøm
on
Oh and one more important thing. The reason for using virtual routines, or dynamic routines, inside of COM, is to leave the developer oportunity to TUNE and UPDATE and IMPROVE the workings of the statemachine, without EVER, EVER EVER EVER needing to change the name of those interfaces. If you do that, like DirectX does to a level of insanity out of this world. Then you have shit the bed. And you have completely missed the point of OOP. But that is not a problem of the idea of OOP.
OOP is also extremely useful for long term development, and especially for small developers. As its perfect for agile development. AGILE understood as always having a working build, that you can tune and build on in small incremental steps.
But of course this can also be done without OOP. Clear as daylight that is. A simple function can of course also be a binding contract. The windows API is an example of just that. But the scope of OOP is different.
If you look at it from a distance, all code does is move, copy, manipulate data. This is true from the manipulation of registers, and to any level of complexity. It is the complexity that kills us. Over some complexity, nothing will help you. When you've exhausted your brains ability to understand the workings of your code, you're done. OOP was "invented" for helping to deal with the complexity of writing modules that got to be too complex.
Look at it this way:
mov eax, 1000 ; is mov a setter of the object EAX ?
UINT32 SetEAX(uint NewEAX);
{EAX == NewEAX};
By the way, on a side note that's the difference between C++ and asm. Are you sure you're better off? Isn't it a fact that it is the Syntax of C++ that makes OOP a nightmare, and not the other way around?
You may look at it like all code is a function at some level. Data and code. If you have only one, it is a function. If you have 100, and they are related, then you put them in a module. The module has data (the struct) and code. A library.
OOP is just like a module. And you dont write a module for a couple of functions of poor scope. You do it when you have a significant amount of functions for accessing the same data. And then OOP is helping. Just like a module is helping. But the point of OOP is not only to be a library of functions, but to be a library of spesific WELL DEFINED functionalities. That other may like to use! IF you like to use it, yourself, and it simplify your day, it can also be used by others.
The fact that you can employ OOP to write smaller things like an object for a vector, isn't a problem of OOP, but of the designer, which has failed to understand what OOP is supposed to solve.
OOP is supposed to take care of the Gameengine. To make sure that for the next game, ALL of the important INFRASTRUCTURE does not need to be written from scratch. You can jump staight to the gameloop, at once and start experimenting. And this is FULLY possible to achieve, as it is exactly what I am doing. When I follow Casey, I never have to deal with graphics primitives, and setting up DirectX, GDI buffers and such things, cause all of that is written long time ago. I just set ONE stateflag and off you go. I redirect ONE call to the Gameloop, and I create ONE new menuitem, for testing the new stuff he presents in the later chapters. And its all done in OOP. OOP takes care of the Windows, and the setup of my wanted graphicslibrary. And I have you note that it is blazing fast. None of my code is slower then the hardware. My allocator increases performance with time. It dynamically ajust to the requirements of the application.
But frankly, we had these debates for like as long as programming existed. And that is because we always would like to add functionality. And that tend to explode complexity. If your OOP is well written it should allow you to transend complexity, and become a powerful tool you can reuse and reuse, and slowly tune to your exact daily needs.
And done like that it very hard to ignore.
That said. When you explore new paths, like when you code the meat of your code. The game, OOP is of course not the path to take. When you explore, the way to do it is to do what Casey suggest. Because at that time, you do not really know what will become WELL DEFINED and what is not.
But for a LOT of code this isn't the case. If you think about it, the way we program the window response loop, the dispatcher, is a bit like OOP. In that you intercept the messages you want, and pass the rest to DefWndProc. That is how OOP is supposed to work. It is suppoed to supply a welltuned, fully working industry standard default statemachine, that you then can customize to your needs, but that you in most cases don't have to.
OOP is also extremely useful for long term development, and especially for small developers. As its perfect for agile development. AGILE understood as always having a working build, that you can tune and build on in small incremental steps.
But of course this can also be done without OOP. Clear as daylight that is. A simple function can of course also be a binding contract. The windows API is an example of just that. But the scope of OOP is different.
If you look at it from a distance, all code does is move, copy, manipulate data. This is true from the manipulation of registers, and to any level of complexity. It is the complexity that kills us. Over some complexity, nothing will help you. When you've exhausted your brains ability to understand the workings of your code, you're done. OOP was "invented" for helping to deal with the complexity of writing modules that got to be too complex.
Look at it this way:
mov eax, 1000 ; is mov a setter of the object EAX ?
UINT32 SetEAX(uint NewEAX);
{EAX == NewEAX};
By the way, on a side note that's the difference between C++ and asm. Are you sure you're better off? Isn't it a fact that it is the Syntax of C++ that makes OOP a nightmare, and not the other way around?
You may look at it like all code is a function at some level. Data and code. If you have only one, it is a function. If you have 100, and they are related, then you put them in a module. The module has data (the struct) and code. A library.
OOP is just like a module. And you dont write a module for a couple of functions of poor scope. You do it when you have a significant amount of functions for accessing the same data. And then OOP is helping. Just like a module is helping. But the point of OOP is not only to be a library of functions, but to be a library of spesific WELL DEFINED functionalities. That other may like to use! IF you like to use it, yourself, and it simplify your day, it can also be used by others.
The fact that you can employ OOP to write smaller things like an object for a vector, isn't a problem of OOP, but of the designer, which has failed to understand what OOP is supposed to solve.
OOP is supposed to take care of the Gameengine. To make sure that for the next game, ALL of the important INFRASTRUCTURE does not need to be written from scratch. You can jump staight to the gameloop, at once and start experimenting. And this is FULLY possible to achieve, as it is exactly what I am doing. When I follow Casey, I never have to deal with graphics primitives, and setting up DirectX, GDI buffers and such things, cause all of that is written long time ago. I just set ONE stateflag and off you go. I redirect ONE call to the Gameloop, and I create ONE new menuitem, for testing the new stuff he presents in the later chapters. And its all done in OOP. OOP takes care of the Windows, and the setup of my wanted graphicslibrary. And I have you note that it is blazing fast. None of my code is slower then the hardware. My allocator increases performance with time. It dynamically ajust to the requirements of the application.
But frankly, we had these debates for like as long as programming existed. And that is because we always would like to add functionality. And that tend to explode complexity. If your OOP is well written it should allow you to transend complexity, and become a powerful tool you can reuse and reuse, and slowly tune to your exact daily needs.
And done like that it very hard to ignore.
That said. When you explore new paths, like when you code the meat of your code. The game, OOP is of course not the path to take. When you explore, the way to do it is to do what Casey suggest. Because at that time, you do not really know what will become WELL DEFINED and what is not.
But for a LOT of code this isn't the case. If you think about it, the way we program the window response loop, the dispatcher, is a bit like OOP. In that you intercept the messages you want, and pass the rest to DefWndProc. That is how OOP is supposed to work. It is suppoed to supply a welltuned, fully working industry standard default statemachine, that you then can customize to your needs, but that you in most cases don't have to.
OOP is merely a pattern. You can roll your own in pure C. OOP in C
There are more other approaches. Par example, Entity-Component-System. ECS
But as a matter of fact, they can come handy, as well as the can come horrible. For prototyping purposes there is no sense to pre-design Handmade Hero in some bounds of patterns.
So, using functional style is totally OK.
There are more other approaches. Par example, Entity-Component-System. ECS
But as a matter of fact, they can come handy, as well as the can come horrible. For prototyping purposes there is no sense to pre-design Handmade Hero in some bounds of patterns.
So, using functional style is totally OK.
Kladdehelvete
OOP is very much misunderstood. It is just structures + functions (like all kind of code).
That is not what Alan Kay had in mind when he coined the term.
The picture that he had in mind was that software systems would be structured like biological systems. You would have something like individual cells ("objects") which interact with each other by sending something analogous to chemical signals ("messages"). You couldn't (or, at least, wouldn't) peer inside a cell; you would only interact with it via the signalling paths. Moreover, you could have more than one of each kind of cell if you needed to.
You can see that there are a few important themes here: the concept of a well-defined signalling protocol (in modern terminology, an interface), the concept of hiding implementation from the outside (in modern terminology, privacy), and the concept of having multiple "things" of the same type hanging around at the same time (in modern terminology, instantiation).
As an exercise, try to work out what inheritance means in this abstract picture. If you find it hard, then this may help explain why OOP lost its way at some point between the Three Amigos and the Gang of Four.
Working on a system with more than 30KK lines of mix C/C++ code built in the last 25 years I can say that OOP is some times very usefull and some times terrible.
I don´t think a little OOP to make things clear and encapsulated in their right places would affect performance that much.
It´s good to know exactly what you could or should do with some structure or data.
I don´t think a little OOP to make things clear and encapsulated in their right places would affect performance that much.
It´s good to know exactly what you could or should do with some structure or data.
This topic confuses me. I've been taught to OOP to find out now that "it's bad".
On the other hand, I find data-oriented design extremelly interesting, and it's one of the things that fascinated me the most of casey's coding.
Digging down the layers of abstraction that I'm used to from OOP, down to the naked data I wonder: how will I tie everything up in the end?
Can you guys suggest some lectures / books on this topic?
On the other hand, I find data-oriented design extremelly interesting, and it's one of the things that fascinated me the most of casey's coding.
Digging down the layers of abstraction that I'm used to from OOP, down to the naked data I wonder: how will I tie everything up in the end?
Can you guys suggest some lectures / books on this topic?
The general problem with OOP is that it presupposes that a hierarchy is always the best way to decompose a problem. Some languages go so far as to try to pretend it is the only way to organize a system (e.g. Math.sin(x) - really???).
Data Oriented Design is really trying to emphasize that, given the high cost of touching memory, if we want to be "oriented" towards anything it should be the data not the code.
There are a few articles here:
Data Oriented Design articles by Noel Llopis
An early presentation specifically addressing OOP:
The Pitfalls of Object Oriented Programming
Data Oriented Design is really trying to emphasize that, given the high cost of touching memory, if we want to be "oriented" towards anything it should be the data not the code.
There are a few articles here:
Data Oriented Design articles by Noel Llopis
An early presentation specifically addressing OOP:
The Pitfalls of Object Oriented Programming
Edited by Patrick Lahey
on
I used to think that OOP was the be all end all of programming. Then I took a class where the professor clearly stated on the first day that any OOP solutions to assignments would be automatically given an F.
It challenged me to think about things in different ways and ultimately lead me to doing many hours of research into the pros / cons of different programming paradigms.
Long story short, it is always a good idea to have as robust of a skill set as possible. Some approaches are perfectly suited to specific problems while being far less than optimal for others.
It challenged me to think about things in different ways and ultimately lead me to doing many hours of research into the pros / cons of different programming paradigms.
Long story short, it is always a good idea to have as robust of a skill set as possible. Some approaches are perfectly suited to specific problems while being far less than optimal for others.
I saw an article on Gamedev.net telling how to properly plan, I'll post the link if anyone is interested. I didn't agree with much of what it said, it basically said to plan out your program completely, and make every module and module interaction explicit in the design. The author also mention that he takes 2 weeks on this process.
I noticed something reading the comments though. It seems planning ahead really appeals to newer programmers. And I think its because a feel for good design isn't easy to come by, and using Casey's method, you really need that feel. Funny, I was the exact opposite, when I was newer, I tried the old OOAD stuff. Lots of planning, push coding to the final steps. It didn't work for me. How are you supposed to plan and design a program without code? I tried many times to do the OOP method, and the only time I really finished a program was using a "No-planning, just do it" method. Then I discovered Casey's blog, which really helped me a ton.
I think, really, when it comes down to it, there is no "best practice", I think OOP works for some, and OOP doesn't work for me because I think of problems, solutions and order differently. Still, I really wouldn't plan too far, even if you are doing a OOP approach.
I noticed something reading the comments though. It seems planning ahead really appeals to newer programmers. And I think its because a feel for good design isn't easy to come by, and using Casey's method, you really need that feel. Funny, I was the exact opposite, when I was newer, I tried the old OOAD stuff. Lots of planning, push coding to the final steps. It didn't work for me. How are you supposed to plan and design a program without code? I tried many times to do the OOP method, and the only time I really finished a program was using a "No-planning, just do it" method. Then I discovered Casey's blog, which really helped me a ton.
I think, really, when it comes down to it, there is no "best practice", I think OOP works for some, and OOP doesn't work for me because I think of problems, solutions and order differently. Still, I really wouldn't plan too far, even if you are doing a OOP approach.
I would be interested in seeing that. In particular, it would be interesting to know how to plan a game when there are hard deadlines (e.g. a console release title). I suspect that a prerequisite for this is having a lot of engine code already written, which helps dictate the structure of the bits that aren't written. There is friction between planning and creativity.
The only projects on which I've spent a lot of planning (as opposed to an hour of group brainstorming, which is common) are mission critical systems (i.e. if the software fails, a large amount of money is lost and possibly the business fails). I've never worked in safety critical systems (i.e. if the software fails, people get hurt), but friends who have report a similar story. I'm reliably told that the fact that you can't just get in there and code is more than amply repaid by the fact that you're in the world of metal, speed, and danger.
In the history of spaceflight, I believe there's been exactly one safety incident on a manned flight (Mir EP-3) which can be traced to a software fault. Nobody was hurt. So, yeah, how much planning you should do depends on what you're doing.
The only projects on which I've spent a lot of planning (as opposed to an hour of group brainstorming, which is common) are mission critical systems (i.e. if the software fails, a large amount of money is lost and possibly the business fails). I've never worked in safety critical systems (i.e. if the software fails, people get hurt), but friends who have report a similar story. I'm reliably told that the fact that you can't just get in there and code is more than amply repaid by the fact that you're in the world of metal, speed, and danger.
In the history of spaceflight, I believe there's been exactly one safety incident on a manned flight (Mir EP-3) which can be traced to a software fault. Nobody was hurt. So, yeah, how much planning you should do depends on what you're doing.
http://www.gamedev.net/page/resou...-visualization-is-important-r2969 Here it is Pseudonym73.
I understand that pre-planning has it's merrits, but we aren't talking about pre-planning what the software is and what it should do, we are talking about pre-planning the code.
I understand that pre-planning has it's merrits, but we aren't talking about pre-planning what the software is and what it should do, we are talking about pre-planning the code.
For a safety-critical system, I think I'd want even the code pre-planned.
But for a game? That's insane. It makes Agile look elegant.
But for a game? That's insane. It makes Agile look elegant.