Programming Design - Developers

Hello, I am trying to understand some things but can't find anything about them. • Procedural • Event Driven • Object Oriented And I would like to know this about them: • What the Language is? • What the language can be used for? • Good/Bad points of the language and why? • Limits of the language and why?

[QUOTE=R@Rdeathmatch;39722273]but can't find anything about them.[/QUOTE] [url]www.google.com[/url] Enter thing you want to know something about, press "search", click on links. It's really not that hard.

[QUOTE=R@Rdeathmatch;39722273]Hello, I am trying to understand some things but can't find anything about them. • Procedural • Event Driven • Object Oriented And I would like to know this about them: • What the Language is? • What the language can be used for? • Good/Bad points of the language and why? • Limits of the language and why?[/QUOTE]Those are programming concepts, not languages you can write code in. [url]http://en.wikipedia.org/wiki/Object-oriented_programming[/url] [url]http://en.wikipedia.org/wiki/Event-driven_programming[/url] [url]http://en.wikipedia.org/wiki/Procedural_programming[/url] Try reading up on those. If you need a language to start out with, many people around here like to use [url="https://love2d.org/"]Löve[/url] with LUA, personally I can recommend C# starting out with either just the console or [URL="http://www.microsoft.com/en-us/download/details.aspx?id=23714"]XNA[/URL]

[QUOTE=dije;39722428]Those are programming concepts, not languages you can write code in. [url]http://en.wikipedia.org/wiki/Object-oriented_programming[/url] [url]http://en.wikipedia.org/wiki/Event-driven_programming[/url] [url]http://en.wikipedia.org/wiki/Procedural_programming[/url] Try reading up on those. If you need a language to start out with, many people around here like to use [url="https://love2d.org/"]Löve[/url] with LUA, personally I can recommend C# starting out with either just the console or [URL="http://www.microsoft.com/en-us/download/details.aspx?id=23714"]XNA[/URL][/QUOTE] Also, [url]http://en.wikipedia.org/wiki/List_of_programming_languages_by_type[/url]

[QUOTE=DrLuckyLuke;39722423][url]www.google.com[/url] Enter thing you want to know something about, press "search", click on links. It's really not that hard.[/QUOTE] Well let me think. I did that or not, hmm ? Yes I already did that I found some information but not enough, I found just what they are nothing more. [editline]26th February 2013[/editline] Can anyone help me find like 3 good and bad things about each one ?

I recommend you start looking around stackexchange or stackoverflow because they've probably discussed indepth every programming topic you'll need to know. [url]http://stackoverflow.com/questions/552336/oop-vs-functional-programming-vs-procedural[/url] [url]http://programmers.stackexchange.com/questions/120019/whats-the-benefit-of-object-oriented-programming-over-procedural-programming[/url]

Procedural: -Good: -Does stuff in the order you tell it to. -Intuitive to understand. -Popular. -Bad: -It's as elegant as some other solutions Object oriented: -Good: -Hierarchical design -Decent scalability -Maybe even natural -Bad: -Can get out of hand -Often requires other features slapped onto it do to things that might seem trivial (I'd count interfaces as those for example) Event driven: -Good: -Easy to write -Straight forward to think up -Bad: -Doesn't scale too well This information should be practically useless for you. It's basically a construction worker explaining to someone who doesn't know what a hammer is, why he thinks the hammer is bad/good. Not saying that I'm an expert or anything. It's just that you can't really use the information if you're at the programming level I'm assuming you are by making a thread like this.

[QUOTE=Darwin226;39723504]Procedural: -Good: -Does stuff in the order you tell it to. -Intuitive to understand. -Popular. -Bad: -It's as elegant as some other solutions Object oriented: -Good: -Hierarchical design -Decent scalability -Maybe even natural -Bad: -Can get out of hand -Often requires other features slapped onto it do to things that might seem trivial (I'd count interfaces as those for example) Event driven: -Good: -Easy to write -Straight forward to think up -Bad: -Doesn't scale too well This information should be practically useless for you. It's basically a construction worker explaining to someone who doesn't know what a hammer is, why he thinks the hammer is bad/good. Not saying that I'm an expert or anything. It's just that you can't really use the information if you're at the programming level I'm assuming you are by making a thread like this.[/QUOTE] This helped me a lot, and yes I am learning c# at school and other things.

[QUOTE=Darwin226;39723504]Procedural: -Good: -Does stuff in the order you tell it to. -Intuitive to understand. -Popular. -Bad: -It's as elegant as some other solutions Object oriented: -Good: -Hierarchical design -Decent scalability -Maybe even natural -Bad: -Can get out of hand -Often requires other features slapped onto it do to things that might seem trivial (I'd count interfaces as those for example) Event driven: -Good: -Easy to write -Straight forward to think up -Bad: -Doesn't scale too well This information should be practically useless for you. It's basically a construction worker explaining to someone who doesn't know what a hammer is, why he thinks the hammer is bad/good. Not saying that I'm an expert or anything. It's just that you can't really use the information if you're at the programming level I'm assuming you are by making a thread like this.[/QUOTE] Out of interest, where does component-based design fit in to this?

[QUOTE=thomasfn;39744492]Out of interest, where does component-based design fit in to this?[/QUOTE] Well, most of the stuff I've read that promotes component-based design says that it scales much better than OOP. In my opinion it's a very elegant system. However, it often proves (at least it did when I was using it) that the elegance is only theoretical. Usually, you can't cleanly separate parts of your program. Most of the things need to talk to each other, and that adds a lot of code complexity. For example, if a component has to modify the state of another component, do you allow it to (leading to potentially unreadable code since everything can change everything) or do you make some sort of an access point in the other component through which they communicate? That means that if you want to change something in component B on component A's request, component B has to implement code that does that. As with anything, it's a tool and should be used where appropriate, but I would say it's generally a better system than pure OOP. You just have to do a lot of getting used to. [editline]28th February 2013[/editline] I'd say that component design focuses on the same ideas that were in mind when interfaces were added into a class system. Describe what something can do, not what something is.

[QUOTE=Darwin226;39747409]Well, most of the stuff I've read that promotes component-based design says that it scales much better than OOP. In my opinion it's a very elegant system. However, it often proves (at least it did when I was using it) that the elegance is only theoretical. Usually, you can't cleanly separate parts of your program. Most of the things need to talk to each other, and that adds a lot of code complexity. For example, if a component has to modify the state of another component, do you allow it to (leading to potentially unreadable code since everything can change everything) or do you make some sort of an access point in the other component through which they communicate? That means that if you want to change something in component B on component A's request, component B has to implement code that does that. As with anything, it's a tool and should be used where appropriate, but I would say it's generally a better system than pure OOP. You just have to do a lot of getting used to. [editline]28th February 2013[/editline] I'd say that component design focuses on the same ideas that were in mind when interfaces were added into a class system. Describe what something can do, not what something is.[/QUOTE] Learn Smalltalk (if you haven't already). Every interaction is a "message." [i]5 factorial[/i] is treated as the sending of the message "factoral" to the number 5. The instance delegates to its class to find out how to handle the message, which executes a block of code, which sends the result as a response message. The response is slotted into the current statement, so you can do [i]5 factorial factorial[/i]. From a system sense, there are no longer any private or public variables; in fact, the best Smalltalk programs have no implementation leaks at all and fit perfectly into your ideal of "describe what something can do".

Components are extremely useful if you have different behaviours that can be combined to work together, because you can keep code duplication near zero. It's also very clean in a language that supports meta programming. (In C# you can fully describe the connections with properties, events, methods and attributes, then reflect and validate easily from a central place.) I think it's most likely overkill to use it if you have only 2 or 3 variations and it's not a language feature. I don't really know C++ well, can multiple inheritance be used to implement it statically? In the one component system I've written so far, I've solved the data access issue by separating the entity state completely from behaviour components. I have a ValueComponent<T> with a single public field (for ref parameters), then a bunch of empty derivations to define position, velocity and so on. Behaviours have properties that are set to the required value components and methods that subscribe to events in a singleton that is added as component to all entities. Each value update is staggered into calculation (if the result is self-dependent or depends on a different entity) and then a few modification stages, depending on how many are needed to avoid race conditions. It's theoretically not slower than an equivalent pure OOP implementation, but it wastes a bit of memory. I'm sure a better solution exists. Edit: [URL="http://facepunch.com/showthread.php?t=1250048&p=39755827&viewfull=1#post39755827"]The framework is open-source now.[/URL]

[QUOTE=Darwin226;39747409]Well, most of the stuff I've read that promotes component-based design says that it scales much better than OOP. In my opinion it's a very elegant system. However, it often proves (at least it did when I was using it) that the elegance is only theoretical. Usually, you can't cleanly separate parts of your program. Most of the things need to talk to each other, and that adds a lot of code complexity. For example, if a component has to modify the state of another component, do you allow it to (leading to potentially unreadable code since everything can change everything) or do you make some sort of an access point in the other component through which they communicate? That means that if you want to change something in component B on component A's request, component B has to implement code that does that. As with anything, it's a tool and should be used where appropriate, but I would say it's generally a better system than pure OOP. You just have to do a lot of getting used to. [editline]28th February 2013[/editline] I'd say that component design focuses on the same ideas that were in mind when interfaces were added into a class system. Describe what something can do, not what something is.[/QUOTE] I really like the idea of having 'components' just be data and then having a 'controller' for each system in the game that actually manipulates that data. So you could have a physics controller that works with the position and velocity and mass components, but your rendering controller also uses the position. If you do things that way you essentially treat your components like database rows instead of them handling the heavy lifting for their data.

[QUOTE=KmartSqrl;39749951]I really like the idea of having 'components' just be data and then having a 'controller' for each system in the game that actually manipulates that data. So you could have a physics controller that works with the position and velocity and mass components, but your rendering controller also uses the position. If you do things that way you essentially treat your components like database rows instead of them handling the heavy lifting for their data.[/QUOTE] I think I've noted this earlier, but I've been researching in to this and found that there's an actual paradigm based around this idea: Model View Controller.

[QUOTE=Jookia;39750316]I think I've noted this earlier, but I've been researching in to this and found that there's an actual paradigm based around this idea: Model View Controller.[/QUOTE] In MVC, the model usually handles business logic itself. In this case the model is just a [URL=http://en.wikipedia.org/wiki/Plain_old_data_structure]plain old data structure[/URL]. I would probably consider it [URL=http://dice.se/publications/introduction-to-data-oriented-design/]data oriented design[/URL]. It's usually associated with functional programming more than an object oriented design is.

[QUOTE=Jookia;39750316]I think I've noted this earlier, but I've been researching in to this and found that there's an actual paradigm based around this idea: Model View Controller.[/QUOTE] Yeah, I'm mainly a web dev and MVC is an incredibly common pattern in that space. I didn't mention it because I don't think the way that I see the controllers working is aligned with how they work in MVC, and there isn't really a "view" for some of the subsystems you could be handling.

[QUOTE=Deco Da Man;39748544]Learn Smalltalk (if you haven't already). Every interaction is a "message." [i]5 factorial[/i] is treated as the sending of the message "factoral" to the number 5. The instance delegates to its class to find out how to handle the message, which executes a block of code, which sends the result as a response message. The response is slotted into the current statement, so you can do [i]5 factorial factorial[/i]. From a system sense, there are no longer any private or public variables; in fact, the best Smalltalk programs have no implementation leaks at all and fit perfectly into your ideal of "describe what something can do".[/QUOTE] Though the idea sounds interesting, I'm getting a feeling that it's not really different to any other approach. Just called differently. Why is 5 factorial factorial different from 5.factorial().factorial() Though the approach of doing 5.factorial() as opposed to factorial(5) is a bit unique, it's just the opposite of the functional way of thinking. I can't really say I can see an obvious advantage to objects implementing behavior over functions implementing it. I'll probably make myself learn Smalltalk though. It seems nice.

[QUOTE=ArgvCompany;39750509]In MVC, the model usually handles business logic itself. In this case the model is just a [URL="http://en.wikipedia.org/wiki/Plain_old_data_structure"]plain old data structure[/URL].[/QUOTE] Hm? Usually the controllers handle business logic. The model is a plain data structure. What kind of MVC have you been using, or what kind of bad information was I given? It doesn't add up.

[QUOTE=Darwin226;39753526]Though the idea sounds interesting, I'm getting a feeling that it's not really different to any other approach. Just called differently. Why is 5 factorial factorial different from 5.factorial().factorial() Though the approach of doing 5.factorial() as opposed to factorial(5) is a bit unique, it's just the opposite of the functional way of thinking. I can't really say I can see an obvious advantage to objects implementing behavior over functions implementing it. I'll probably make myself learn Smalltalk though. It seems nice.[/QUOTE] Yeah, to me that looks very weird, and doesn't it seem to imply that simple data types have to 'know' much much more than they should? At least it breaks OOP of objects having one purpose.

From Design Patterns, Elements of Reusable Object-Oriented Software [quote] MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before MVC, user interface designs tended to lump these objects together. MVC decouples them to increase flexibility and reuse. MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model's data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it. [/quote] This book is fucking old (1994), but it's surprisingly good so far.

Hmm.. Where would you put game logic then? A controller on the server?

Well, MVC is primarily a GUI design pattern, so I'm not sure it's the best for the game-logic. At work, our model is DB backed and populated by an [url=http://en.wikipedia.org/wiki/Object-relational_mapping]ORM[/url] tool.