|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On October 03 2013 11:36 sluggaslamoo wrote:Show nested quote +On October 03 2013 10:54 3FFA wrote:On October 03 2013 09:21 misirlou wrote:On October 03 2013 08:50 sluggaslamoo wrote:On October 02 2013 17:08 Tobberoth wrote:On October 02 2013 10:05 Kambing wrote:On October 02 2013 09:52 sluggaslamoo wrote:On October 01 2013 15:21 Tobberoth wrote:On October 01 2013 15:03 Abominous wrote:On October 01 2013 07:46 Kambing wrote:
[quote]
Those two sentences contradict each other. If kids are writing code that they don't understand, then programming is far from trivial. What can be said is that, we're still learning how to effectively teach it when the ground underneath us changes rapidly. They understand the code, not the work behind it. And in todays world, 90% of programmers do not need to understand what's going on behind and why. Just like programmers in the old days didn't have to know exactly how a CPU is wired electronically. It's just another level of abstraction. It gives more power to programmers at lesser cost, but the actual problem-solving is the same. One the one hand, you can be pissed that someone can, for example, make a flash game more advanced that NES games with less than half the knowledge of the people making the actual NES games... on the other hand, you can appreciate that the programmers of those days could not make modern games with the tools at hand. Yeah, simple shit is easier to make today, but the difference between a bad and good programmer isn't shown in simple things. The level you have to perform at to be considered a really good programmer today has simply been raised, it's not enough to be able to do some sweet optimization on a sorting algorithm, you have to be able to juggle big code bases and far more calculations per second. Then why start with Java. Why not use Haskell? 1. Its a "higher level of abstraction" to Java. 2. You can write things with less code. 3. You can problem solve better with Haskell 4. You don't have to worry about memory management as much as Java ... Some people would argue that Haskell meets those goals better than Java. For example, I would be in that camp. The problem is that Haskell is not as accepted in industry as Java (and other alternatives) which is a detriment for most people. This. Learning using haskell would make perfect sense if it was actually widely used in the industry. However, there are several more issues why Haskell would be worse than Java as a learning language. 1. Functional programming is far more different from classic procedural programming than OOP. If you learn Java first, you can learn C quite easily. If you learn haskell first, you'll probably be confused when you go to either C or Java. 2. Haskell might be shorter codewise than Java, but it's certainly not less complex. It's a complete copout to use the PutStr example since understanding of IO actions in Haskell takes longer learning than classes, static and hell, add in a huge part of the standard library as well. OOP is, countrary to popular belief it seems, actually not a difficult concept to grasp for beginners. Employees has a name and can say hello. I have two employees, one is named James, one is named Earl. When they say hello, they do it the same way but show different names. Cool, now you understand classes, objects, fields and methods. What the goal of an introduction to programming is to have students who don't know how to program and get them to the point where they can experiment and learn on their own. Java is far better than C and haskell in this situation, because once you learn the basics of OOP, you can make full-on programs, with GUI, IO, networking etc. I'd say Python is a great contender as well, though Java is still stronger in the industry. Its popular belief because it is a difficult concept to grasp. http://www.netgore.com/sites/default/files/ObjectOrientedProgramming.pdfStructured programming took me about 6 months to master. Once you learn the concepts of functional decomposition, expression and abstraction you are 90% of the way there. OOP about 3 years to get to the point where I actually wrote clean code (of course when I started I thought I was writing clean code, then I look back on it years later and realise it was terrible). That journal was written after 6 months of learning OOP, if I were to write it again it would be completely different. ah memories. when I look back on my high school days and every var was called i1,i2,i3,str1,str2,str3,x1,x2,y1,y2 and I managed to not get turned around, so it was good standard.  Yeah I have to agree with you, I use OOP for 5 years (1 high school + 4 college) and everytime I turn in a project I find something new that I was not doing/doing wrong in OOP, feeling I am still a long way from mastering it. But I also agree it's very easy to understand the principle. The truth is every language has it's purpose and if your purpose is readability you go for a higher language and if you want performance you go for a lower. Could you demonstrate an example of a common OOP mistake you made in HS and how you would write it differently now, just for my HS eyes?  Not sure if you're asking both of us but just in case you wanted my input... For me when I initially started delving into OOP books and Responsibility Driven Design, it was over-engineering the design of objects and object decomposition and thinking way too hard. I would spend hours figuring out the best layout of my new project. Now I don't even bother to design the overall layout of my program and somehow end up with a much simpler and easier to maintain program. That's not to say that the core principles of OOP (Abstraction, Encapsulation, Polymorphism, Inheritance) and RDD aren't important, its that these principles work much better when you use them on the fly. Its not that learning these concepts help you design better, its that you often fall into common patterns which these concepts help you to fix much more quickly. For example if you have a lot of like objects, you will immediately think of using a base class that these objects can inherit from to reduce the size of your code base. Without learning about inheritance, you will not only waste time reinventing the wheel, but you will also have an inferior solution. Its like the old saying 'When you are given a hammer, everything turns into a nail'. When you learn new concepts in OOP, you always feel like you HAVE to use them. The advantages of certain features of OO should only be used when you really need them, they are much more specific than you think. For example don't use inheritance to plan for the future, use inheritance ONLY if you can see the benefits of it RIGHT NOW, if its not immediately making your code base smaller, don't use it, you can always do it later. Refactoring > Designing. Sometimes I see people design big vertical inheritance hierarchies and end up with really fragile programs, when they could have just used one robust concrete base class with half the code, a quarter of the time, and half the headaches to maintain. If you think too far ahead you end up writing way too much boiler plate and getting locked into a framework which you realise later doesn't fit well with what you wanted. So the idea should be that you should spend a lot of time learning the principles and how to design, but when it comes to coding, be in the present. http://en.wikipedia.org/wiki/You_aren't_gonna_need_it
I agree with all of those issues and definitely recognize them as issues I've had myself with OOP. However, you are talking about mastering it and using it in a way which is most productive to you. Indeed, structured programming is far simpler to master (since it's a far simpler process) but we are talking about first time students, their goal isn't to master it, it's to start getting somewhere, giving them as much power as possible in the least amount of time and effort. Problems such as over-using OOP concepts, you learn by experience, it's not really something you have to be taught.
|
Problems such as over-using OOP concepts, you learn by experience, it's not really something you have to be taught.
Well just by looking at this thread I'd say 90% of people who seriously studied OO have fallen victim to it and haven't learned.
|
on haskell and java and 'industry':
haskell is used in cool jobs you can't get,
java is used in shit jobs you can get but don't want to do.
assuming you actually find programming interesting / successfully learned how to do it at some point.
probs the best jobs where you program are the ones where your job title isn't 'developer'.
after the initial excitement of "hey i can do computer!" wears off, that is.
im not cosigning z.a. shaw in general but i feel like this a lot http://programming-motherfucker.com/.
dijkstra was right about basically everything and every time a program breaks despite extensive testing or your course teaches you useless corporate information, he warned us. it's not like knuth's programs are often broken, and his methodology is close to what dijkstra prescribes.
also, learning oop and 'design patterns' is a horrible substitute for actually learning about data structures.
|
On October 03 2013 15:58 sluggaslamoo wrote:Show nested quote +Problems such as over-using OOP concepts, you learn by experience, it's not really something you have to be taught. Well just by looking at this thread I'd say 90% of people who seriously studied OO have fallen victim to it and haven't learned.
Could you specify why?
|
On October 03 2013 11:36 sluggaslamoo wrote:Show nested quote +On October 03 2013 10:54 3FFA wrote:On October 03 2013 09:21 misirlou wrote:On October 03 2013 08:50 sluggaslamoo wrote:On October 02 2013 17:08 Tobberoth wrote:On October 02 2013 10:05 Kambing wrote:On October 02 2013 09:52 sluggaslamoo wrote:On October 01 2013 15:21 Tobberoth wrote:On October 01 2013 15:03 Abominous wrote:On October 01 2013 07:46 Kambing wrote:
[quote]
Those two sentences contradict each other. If kids are writing code that they don't understand, then programming is far from trivial. What can be said is that, we're still learning how to effectively teach it when the ground underneath us changes rapidly. They understand the code, not the work behind it. And in todays world, 90% of programmers do not need to understand what's going on behind and why. Just like programmers in the old days didn't have to know exactly how a CPU is wired electronically. It's just another level of abstraction. It gives more power to programmers at lesser cost, but the actual problem-solving is the same. One the one hand, you can be pissed that someone can, for example, make a flash game more advanced that NES games with less than half the knowledge of the people making the actual NES games... on the other hand, you can appreciate that the programmers of those days could not make modern games with the tools at hand. Yeah, simple shit is easier to make today, but the difference between a bad and good programmer isn't shown in simple things. The level you have to perform at to be considered a really good programmer today has simply been raised, it's not enough to be able to do some sweet optimization on a sorting algorithm, you have to be able to juggle big code bases and far more calculations per second. Then why start with Java. Why not use Haskell? 1. Its a "higher level of abstraction" to Java. 2. You can write things with less code. 3. You can problem solve better with Haskell 4. You don't have to worry about memory management as much as Java ... Some people would argue that Haskell meets those goals better than Java. For example, I would be in that camp. The problem is that Haskell is not as accepted in industry as Java (and other alternatives) which is a detriment for most people. This. Learning using haskell would make perfect sense if it was actually widely used in the industry. However, there are several more issues why Haskell would be worse than Java as a learning language. 1. Functional programming is far more different from classic procedural programming than OOP. If you learn Java first, you can learn C quite easily. If you learn haskell first, you'll probably be confused when you go to either C or Java. 2. Haskell might be shorter codewise than Java, but it's certainly not less complex. It's a complete copout to use the PutStr example since understanding of IO actions in Haskell takes longer learning than classes, static and hell, add in a huge part of the standard library as well. OOP is, countrary to popular belief it seems, actually not a difficult concept to grasp for beginners. Employees has a name and can say hello. I have two employees, one is named James, one is named Earl. When they say hello, they do it the same way but show different names. Cool, now you understand classes, objects, fields and methods. What the goal of an introduction to programming is to have students who don't know how to program and get them to the point where they can experiment and learn on their own. Java is far better than C and haskell in this situation, because once you learn the basics of OOP, you can make full-on programs, with GUI, IO, networking etc. I'd say Python is a great contender as well, though Java is still stronger in the industry. Its popular belief because it is a difficult concept to grasp. http://www.netgore.com/sites/default/files/ObjectOrientedProgramming.pdfStructured programming took me about 6 months to master. Once you learn the concepts of functional decomposition, expression and abstraction you are 90% of the way there. OOP about 3 years to get to the point where I actually wrote clean code (of course when I started I thought I was writing clean code, then I look back on it years later and realise it was terrible). That journal was written after 6 months of learning OOP, if I were to write it again it would be completely different. ah memories. when I look back on my high school days and every var was called i1,i2,i3,str1,str2,str3,x1,x2,y1,y2 and I managed to not get turned around, so it was good standard. Yeah I have to agree with you, I use OOP for 5 years (1 high school + 4 college) and everytime I turn in a project I find something new that I was not doing/doing wrong in OOP, feeling I am still a long way from mastering it. But I also agree it's very easy to understand the principle. The truth is every language has it's purpose and if your purpose is readability you go for a higher language and if you want performance you go for a lower. Could you demonstrate an example of a common OOP mistake you made in HS and how you would write it differently now, just for my HS eyes? Not sure if you're asking both of us but just in case you wanted my input... snip
My input.
Ill give you this example. This is from a map of mars where "mars object" represents one cell.
https://www.dropbox.com/s/l9p2t9h1ycwpv8t/MarsObject.java
it represents empty cells, valuable cells, obstacle cells. Maybe I should have refactored it to different classes each but I used a base class for everything, overall it was more basic and easy approach but its not the right one. Seperating it would make it easier to add new object types or modify existing ones. I also use some object propertys that are global so they should have been static instead.
|
On October 03 2013 20:08 bigglesbiggles wrote:on haskell and java and 'industry': haskell is used in cool jobs you can't get, java is used in shit jobs you can get but don't want to do. assuming you actually find programming interesting / successfully learned how to do it at some point. probs the best jobs where you program are the ones where your job title isn't 'developer'. after the initial excitement of "hey i can do computer!" wears off, that is. im not cosigning z.a. shaw in general but i feel like this a lot http://programming-motherfucker.com/. dijkstra was right about basically everything and every time a program breaks despite extensive testing or your course teaches you useless corporate information, he warned us. it's not like knuth's programs are often broken, and his methodology is close to what dijkstra prescribes. also, learning oop and 'design patterns' is a horrible substitute for actually learning about data structures.
How is learning OOP and design patterns a substitute for learning about data structures? How will your knowledge of how a hashtable works help when you need the observer pattern? How will your knowledge of a linked list help you when you need the factory pattern?
Those things are not comparable at all. OOP and design patterns are on a completely different level than data structures.
|
OOP is particularly unsuited for game objects, because
1) Components like position, exploration status, color, visibility, resource content, et cetera, can not be grouped in any semantical sense, all inheritance based attempts will be incorrect and lead to long, fragile class hierarchies. This antipattern smells rather rancid, just consider a class called ExploredCellWithColorAndResource.
2) Class hierarchies are strictly static, you can not modify entities on-the-fly, for example in the case of resource depletion of a cell, only by replacing the object, which destroys the identity of the entity, which gives rise to numerous bugs. Case in point: Starcraft unit transformations.
3) Uniform data collections are much better suited for batch processing than classes.
The correct solution is to use Component-Based Entities, also called Entity Component Systems.
Use the proper tools.
|
for what it's worth, it wasn't a game. Its a collection of AI Agents exploring Mars using REPAST for the simulation framework
|
On October 04 2013 01:24 Frigo wrote:
OOP is particularly unsuited for game objects, because
1) Components like position, exploration status, color, visibility, resource content, et cetera, can not be grouped in any semantical sense, all inheritance based attempts will be incorrect and lead to long, fragile class hierarchies. This antipattern smells rather rancid, just consider a class called ExploredCellWithColorAndResource.
2) Class hierarchies are strictly static, you can not modify entities on-the-fly, for example in the case of resource depletion of a cell, only by replacing the object, which destroys the identity of the entity, which gives rise to numerous bugs. Case in point: Starcraft unit transformations.
3) Uniform data collections are much better suited for batch processing than classes.
The correct solution is to use Component-Based Entities, also called Entity Component Systems.
Use the proper tools.
OOP is quite essential in a lot of ways in game programming. "Entity Component Systems" are mostly a giant load of hype, and hardly anyone really understands what is important and what is not important when it comes to game engines.
Just try to realize that any advice you give is likely ill-informed and probably going to just do more harm than good. It's silly of you to assume OOP = inheritance.
|
On October 04 2013 01:24 Frigo wrote:
OOP is particularly unsuited for game objects, because
1) Components like position, exploration status, color, visibility, resource content, et cetera, can not be grouped in any semantical sense, all inheritance based attempts will be incorrect and lead to long, fragile class hierarchies. This antipattern smells rather rancid, just consider a class called ExploredCellWithColorAndResource.
2) Class hierarchies are strictly static, you can not modify entities on-the-fly, for example in the case of resource depletion of a cell, only by replacing the object, which destroys the identity of the entity, which gives rise to numerous bugs. Case in point: Starcraft unit transformations.
3) Uniform data collections are much better suited for batch processing than classes.
The correct solution is to use Component-Based Entities, also called Entity Component Systems.
Use the proper tools.
It is not unsuited for it, it's just not as clear cut. In a business applications, it's usually quite easy to model using OOP, it becomes harder in a game. That said, it can still be very beneficial. Separating game logic from the rendering is a tough job with huge benefits. Good knowledge of OOP, MVC in particular, can help a ton.
|
With all these OOP sceptics, I was wondering when you really shouldn't use OOP? Are those cases only when:
I know OOP isn't a silver bullet.
|
On October 04 2013 04:06 darkness wrote:With all these OOP sceptics, I was wondering when you really shouldn't use OOP? Are those cases only when: I know OOP isn't a silver bullet.
It turns out that OOP is quite compatible with performance-demanding, memory constrained contexts, e.g., C++. It is, foremost, a code organization principle that does not place particular demands on implementation. On the other hand, the main tenant of functional programming, that of referential transparency, place constraints on how a program executes which in turn affects performance and memory footprint. However, even functional programs can be made performant given appropriate optimizations, e.g., OCaml, MLton. In this sense, choice of programming paradigm is independent of your first two cases; it is the implementation of a particular programming system that dictates performance and memory usage.
|
On October 04 2013 04:06 darkness wrote:With all these OOP sceptics, I was wondering when you really shouldn't use OOP? Are those cases only when: I know OOP isn't a silver bullet.
There isn't really ever a definitive reason not to use OOP unless you are programming a microchip with 1kb of memory or something similar. Sometimes it's not the best tool for the job, but there isn't really a situation where you could say "Never use OOP in this case". In some situations like throwaway scripts it's overkill and procedual solutions are simpler, in others functional programming is better suited for the job, but OOP is never really "bad". It all depends on the situation.
OOP is a very broadly defined thing, it's not just about using classes and inheritance, it also encompasses some really useful design principles that you can use even without using a single object. There are also some parts in OOP that are completely overused, e.g. inheritance, and that should be used as little as possible even when writing fully object oriented code.
|
Speaking of pros and cons of OOP, what do you guys think about Go's opinion about it? I don't have any experience with a large project, let alone a heavy use of OOP, so I can't really agree or disagree on much of anything. But I'd like to see if anyone here can relate to their decisions.
|
On October 04 2013 06:25 billy5000 wrote:Speaking of pros and cons of OOP, what do you guys think about Go's opinion about it? I don't have any experience with a large project, let alone a heavy use of OOP, so I can't really agree or disagree on much of anything. But I'd like to see if anyone here can relate to their decisions.
I don't really see an opinion about OOP in there.
It uses a different approach to classes/interfaces than C++/Java/C#, which is for the most part just that: different.
|
On October 04 2013 03:28 CecilSunkure wrote:Show nested quote +On October 04 2013 01:24 Frigo wrote:
OOP is particularly unsuited for game objects, because
1) Components like position, exploration status, color, visibility, resource content, et cetera, can not be grouped in any semantical sense, all inheritance based attempts will be incorrect and lead to long, fragile class hierarchies. This antipattern smells rather rancid, just consider a class called ExploredCellWithColorAndResource.
2) Class hierarchies are strictly static, you can not modify entities on-the-fly, for example in the case of resource depletion of a cell, only by replacing the object, which destroys the identity of the entity, which gives rise to numerous bugs. Case in point: Starcraft unit transformations.
3) Uniform data collections are much better suited for batch processing than classes.
The correct solution is to use Component-Based Entities, also called Entity Component Systems.
Use the proper tools.
OOP is quite essential in a lot of ways in game programming. "Entity Component Systems" are mostly a giant load of hype, and hardly anyone really understands what is important and what is not important when it comes to game engines. Just try to realize that any advice you give is likely ill-informed and probably going to just do more harm than good. It's silly of you to assume OOP = inheritance.
Please do a bit of research before you write such a sorry excuse of a post that essentially boils down to "it is a hype, therefore it is crap, also you are stupid".
Contrary to your claim, there are many people who are aware of the various aspects and details of game engine design, as well as software development considerations. The fact that it seems cloudy and unsure to you, is a product of your ignorance and lack of experience on the subject matter, rather than some inherently mysterious property of game development and game engine design.
Among people with proper knowledge of game engines and component based entities (i.e. not you), there is virtually no disagreement about the superiority of ECS. It is a very powerful software development pattern, and has overwhelming advantages over OOP or even mixins for game objects:
- Easier, faster game design and prototyping without having to modify the codebase. Game designers have to bother programmers less.
- No poorly built, fixed inheritance trees you have to hack your way around. No structural constraints encouraging poor quality code full of hacks.
- Dynamic component addition, removal and change. Inheritance and mixins are static, they can not handle this change common in games.
- Clear separation between component data and logic. Unified handling of the same components. All logic is in "systems". No more spaghetti logic all over the place.
- Cleaner, better refactored, more reusable components. Existing components are much more flexible and can fit a much wider range of cases than OOP hacks. They are called components for a reason.
- Component processor systems naturally fit in the game loop. Their order and result is more deterministic than unpredictable multi threaded OOP hacks with logic all over the threads.
- Component based entities can be better serialized, deserialized and edited either via text files or appropriate tools.
- Component based entities and game worlds can be better synchronized between servers and clients.
- Entities and their components naturally fit relational databases, completely bypassing the object-relational impedance mismatch. This is especially important for MMORPGs and other persistent world games.
- Depending on component storage, bulk processing can be faster by exploiting cache locality, branch prediction and other modern processor features.
On October 04 2013 03:39 Tobberoth wrote:Show nested quote +On October 04 2013 01:24 Frigo wrote:
OOP is particularly unsuited for game objects, because
1) Components like position, exploration status, color, visibility, resource content, et cetera, can not be grouped in any semantical sense, all inheritance based attempts will be incorrect and lead to long, fragile class hierarchies. This antipattern smells rather rancid, just consider a class called ExploredCellWithColorAndResource.
2) Class hierarchies are strictly static, you can not modify entities on-the-fly, for example in the case of resource depletion of a cell, only by replacing the object, which destroys the identity of the entity, which gives rise to numerous bugs. Case in point: Starcraft unit transformations.
3) Uniform data collections are much better suited for batch processing than classes.
The correct solution is to use Component-Based Entities, also called Entity Component Systems.
Use the proper tools.
It is not unsuited for it, it's just not as clear cut. In a business applications, it's usually quite easy to model using OOP, it becomes harder in a game. That said, it can still be very beneficial. Separating game logic from the rendering is a tough job with huge benefits. Good knowledge of OOP, MVC in particular, can help a ton.
There is at least one business module at my workplace that would benefit from component based entities. Unfortunately they use an inheritance tree and as a result the code smells all over the place. I will tell more about these code smells and how to recognize whether your particular use case requires components rather than inheritance or mixins.
Game logic and rendering is naturally separated with component based entities. Though actually you can reuse the movement system for interpolated rendering.
And remember, if you try to enforce OOP in cases that require components, you are digging your own grave.
|
On October 04 2013 07:03 Frigo wrote:
Among people with proper knowledge of game engines and component based entities (i.e. not you), there is virtually no disagreement about the superiority of ECS. It is a very powerful software development pattern, and has overwhelming advantages over OOP or even mixins for game objects:
So I'm by no means an expert on this, but the idea I had of 'component-based' entities wasn't that it replaced OOP at all - rather, I thought the idea was to break up the fragile, painful inheritance heirarchy part of it, and make your code more modular and easier to use. Now admittedly inheritance is one of the things that people kind of seem pretty gung-ho on when they're really excited about OOP - but that being said, there is a LOT more to OOP than using inheritance, and component-based design seemed to me to be ONLY about removing that specific, painful part of OOP and keeping all the other nice parts of it.
So correct me if I'm wrong, but are 'component-based entities' and 'object-oriented entities' actually mutually exclusive? Because it seems to me like the better comparison would be 'component-based' vs. 'inheritance-based' which is a whole different discussion, and definitely not the one we're having right now ^^
|
On October 04 2013 07:30 Cyx. wrote:Show nested quote +On October 04 2013 07:03 Frigo wrote:
Among people with proper knowledge of game engines and component based entities (i.e. not you), there is virtually no disagreement about the superiority of ECS. It is a very powerful software development pattern, and has overwhelming advantages over OOP or even mixins for game objects:
So I'm by no means an expert on this, but the idea I had of 'component-based' entities wasn't that it replaced OOP at all - rather, I thought the idea was to break up the fragile, painful inheritance heirarchy part of it, and make your code more modular and easier to use. Now admittedly inheritance is one of the things that people kind of seem pretty gung-ho on when they're really excited about OOP - but that being said, there is a LOT more to OOP than using inheritance, and component-based design seemed to me to be ONLY about removing that specific, painful part of OOP and keeping all the other nice parts of it. So correct me if I'm wrong, but are 'component-based entities' and 'object-oriented entities' actually mutually exclusive? Because it seems to me like the better comparison would be 'component-based' vs. 'inheritance-based' which is a whole different discussion, and definitely not the one we're having right now ^^
No. Component-based entities and object-based entities are not mutually exclusive. The distinction is between composition vs. inheritance. Over the last decade, people have come to realize that the former is much more useful than the latter in practice.
Relating this to the discussion about Go, many Java and C# programmers nowadays prefer to use interfaces and shallow class hierarchies over inheritance and deep class hierarchies. This is the style of "object-oriented programming" that Go promotes. As mentioned before, it's "just different", but it is more inline with current OO practices.
|
On October 04 2013 07:03 Frigo wrote:Show nested quote +On October 04 2013 03:28 CecilSunkure wrote:On October 04 2013 01:24 Frigo wrote:
OOP is particularly unsuited for game objects, because
1) Components like position, exploration status, color, visibility, resource content, et cetera, can not be grouped in any semantical sense, all inheritance based attempts will be incorrect and lead to long, fragile class hierarchies. This antipattern smells rather rancid, just consider a class called ExploredCellWithColorAndResource.
2) Class hierarchies are strictly static, you can not modify entities on-the-fly, for example in the case of resource depletion of a cell, only by replacing the object, which destroys the identity of the entity, which gives rise to numerous bugs. Case in point: Starcraft unit transformations.
3) Uniform data collections are much better suited for batch processing than classes.
The correct solution is to use Component-Based Entities, also called Entity Component Systems.
Use the proper tools.
OOP is quite essential in a lot of ways in game programming. "Entity Component Systems" are mostly a giant load of hype, and hardly anyone really understands what is important and what is not important when it comes to game engines. Just try to realize that any advice you give is likely ill-informed and probably going to just do more harm than good. It's silly of you to assume OOP = inheritance. Please do a bit of research before you write such a sorry excuse of a post that essentially boils down to "it is a hype, therefore it is crap, also you are stupid". Lots of angry, angry words.
So, umm? You are able to use these fancy Component Based Entities without classes and objects? Sounds pretty hard... that's a lot of functions... How do you even pass around that much data?
While his response was quite baiting, it is completely true that OOP != inheritence. Just because you use an OOP language doesn't mean you have to be an idiot and only use inheritance. Favoring composition ( has a ) over inheritance (is a) generally works for the better anyways.
|
On October 04 2013 08:50 berated- wrote:
So, umm? You are able to use these fancy Component Based Entities without classes and objects? Sounds pretty hard... that's a lot of functions... How do you even pass around that much data?
It is pretty easy, you just have to eat your veggies and then you can do it too.
While his response was quite baiting, it is completely true that OOP != inheritence. Just because you use an OOP language doesn't mean you have to be an idiot and only use inheritance. Favoring composition ( has a ) over inheritance (is a) generally works for the better anyways.
Mixins, aka composition based reuse without inheritance, still does not solve the problem of dynamic component addition and removal, neither the runtime change of the "class" of an entity. Close but no cigar.
|
|
|
|
|
|
EPT
