Differences in programming designs

[GSquadron]

Hi all!
I wanted to ask what are the differences between:
Programming langauge
Framework
Game engine
2D/3D engine
OOP
OOD
Tile mapper
And many more...
I think i have to distinguish these all at least to understand what i want to lear

 

[digibucc]

a framework is a constructed base for building applications. it is written in a specific programming language, and a language can and usually has more than one framework.

a game engine, and a 2d/3d engine, are frameworks as well i suppose, though much more complete. they have built in functions to handle everything the engine is capable of, from texturing to sound, from how light looks to how buildings do (or do not) destruct. this saves someone from having to program and troubleshoot millions of lines of code that every game needs (again video, sound, etc) and instead focus on the specifics of your game (what style of video, sound, etc)

ood/oop is a style of programming that has you create functions, classes, etc (objects) that can be used interchangeably. the alternative to that would have you recreate those functions every time you need to run it, instead of creating it once and calling it in each instance. there is also jump programming, for example GOTO , but that is not used much anymore.

a tile mapper i have never actually used, but from my understanding it simply allows you to lay out (map) each grid point (tile) to create a specific landscape or structure. it's basically piecing together the game world.

now honestly you can get better explanations through google, but those are decent i believe.

 

[GSquadron]

Ok, i know all you wrote, but i wanted to know more the differences (in logic)
Why someone creates a 2D engine for example? Benefits?
What is the difference between the framework and game engine?
Is it true that all can be achieve from the root(programming language)?
Can you use a framework to create an engine and vice-versa?
What is the difference between OOP and OOD? I know you have to learn first OOP than start making better choices to OOD
I am talking about logic so more little details of an experienced user should help me much more.
Maybe are some secrets i don't know!

 

[Kreij]

Why someone creates a 2D engine for example? Benefits?

A 2D engine for creating 2D games, like platformers, where you have an X and Y axis, but no Z (depth). 2D engines are typically sprite based (as opposed to models which are used in 3D).
There are also 2.5D engines, which incorporate an isometric view in 2D applications to give the impression of depth (even though there is none from a technical standpoint).

What is the difference between the framework and game engine?

A framework is the building blocks of any application. For instance, the .Net framwork(s) is a collection of APIs that are compiled into DLL that are used by applications.
A game engine is an application developed (using a framework) to support the functions of games.

Is it true that all can be achieve from the root(programming language)?

Technically, yes. If you start from scratch, though, you will be recreating the wheel ... A LOT.

You could take a language like C or C++ and create an entire framework, but it makes no sense to do that since all that work is alread done and freely available.
You could write an entire game engine youself, but even a lot of large studios license the engine from someone else as it's an incredible amount of work to get it right.

Can you use a framework to create an engine and vice-versa?

You must have a framework to build an engine, you can't build a framework from an engine.
An engine will have APIs that support game development funtions, but these are built upon a framework (like .Net and DirectX or whatever).

What is the difference between OOP and OOD? I know you have to learn first OOP than start making better choices to OOD

OOD and OOP are two halves of the same thing. OOD is a design paradigm used prior to coding an application in an OOP (a programming paradigm).

 

[GSquadron]

So can you place which is the first one, the root to the most advanced one?
for example:
1) Programming language
2) Framework
etc etc
I even learned that there is a OOP 'pattern'.

 

[Kreij]

A programming language is a collection of a compiler/parser, assembler/linker, debugger and builder.
I guess that could be considered the "root" as you must have a programming language to make a framework.

The modern languages use the framework APIs to make programming easier, more robust and faster.
C# is a fine example of RAD (Rapid Application Development). It give you thousands of already created API calls, forces type safety (unless you override it), and introduces coding shortcuts (like lambda expressions, generics, anonymous functions) to speed up development.
C# is a wrapper for the original Win32 functions (which you use in VC++), so it basically insulates the programmer from some of the pitfalls that the original APIs can cause if not used correctly. But it comes at the expense of not having every aspect of the original API in the wrapper, and thus limits its use unless you use something like PInvoke to access the base APIs.

OOP is not really a pattern, it's more of a design philosophy(or paradigm).
Patterns assume that if one follows a certain method (the pattern) to achieve a certain goal then it should be an optimal implementation for that goal, but that is not always the case.
Not every program will benefit from OOP.

 

[GSquadron]

Ok, enough theory. I understand them, really.
In real programming, for example, when would you use OOP?
For example i use OOP to create a framework (little one) and make projects i have on
c++ or php easier and quicker, so i wont do programming again and again but save them and use them later.
At least that is what i understand. What is the law that collapses the benefit and dissadvantages of OOP?
I truly understand that HELLO WORLD program is a waste of time in OOP. So it is a waste in little projects.
I came up to a law that if you have 3 types of buttons or 3 types of cubes in a game etc etc...
i mean when you have at least 3 types of things, the OOP is advantageous.
If less than 3, OOP is or can be a waste of time. If you have made OOP or frameworks yourself,
(i am not talking about game engines cuz i dont think i am that good yet)
can you explain any tricks you have found from your own phylosophy?
Have you found any better 'OOP'?
Explain with your own words, cuz i hate theory!!!
(and that is exactly why i created this thread)

 

[temp02]

The thing about using frameworks is just to make things simple further ahead, when the project gets more complex.
It's just like using C and C++: why do we use C++ for simple stuff? Because if we want to make more complex things latter on, it would be easier with C++ (at least it normally is).

Like is an FPS game, you can have a lot of enemies, they can all be different but they are all enemies, so each enemy type can a be subclass of the parent class enemy, and thus have all the properties of the standard enemy.

Much of these things are useless on simple applications, but if you want to take part on a shared/more-complex project they are not only handy but essential!

Good luck.

 

[Kreij]

Okay, in my own words (Just like my two last posts btw)

When the program you are using makes use of objects that have the same (or similar) methods.
For instance, a program to save contacts would be a good candidate for OOP because every instance of a contact could be an object, derived from a class called contact, and each contact would require the same methods (insert, delete, edit, etc.)

As far as the cut off point for number of objects needed to make something a good OOP candidate is highly subjective and dependent upon how they are used. One of the things that makes OOP really useful is inheritance. Using your example of cubes, let's say you only have one cube, but you have 10 objects that could inherit the cube class and use it in a different manner, then you would definitely want to use OOP. (like temp2's example above with "enemies").

As far as a framework goes, the framework does not have to have anything to do with OOP. The API calls (function reuse) are normally static methods and/or abstract classes that can be called from an OOP or from a program that is strictly functional in nature. The method may return an object, but the creation of that object does not have to be OOP in nature.
Remember, an object is simply a data type also. You could have a function that creates a struct, casts it to an object and returns it (why you would do that is beyond me, but you can. ) But that is not the same thing as a object created from a class.
(Does that make sense? lol)

Also remember that just because a language supports full OOP functionality, it does not mean you have to write an object oriented program in it. I use C# (which makes full use of OOP) for just about everything.

OOP has no real value if the program produces only functional output. For instance, a program that calculate a discrete fourier transform (FFT) for digital signal processing.

All the questions you are asking can be determined by having a solid understanding of the basic concepts of OOD, which then translates itself into OOP. It is also something you need to know to determine if your program is a good candidate for "objectifying", or just left as a collection of functions due to the progam having a linear code path that would make little or no use of objects.

Hope that helps, Alek.

 

[GSquadron]

Ok, really nice this time!
I am solely bumping if another one will talk on his own ideas

 

[Aquinus]

I think Kreij covered all the bases. There isn't a whole lot that I can add to the topic. How you program anything depends on what you're planning on building. For example, if you're going to be working with relational data and complex data sets, you're going to want to organize your code based on that data and for functional code (as Kreij also said,) like FFT, you're not going to care about objects since you're just taking a matrix and processing it.

Also depending on the language, OOP is sometimes unavoidable, like with Java and Ruby, where everything is a class (I think Ruby is a much better example of this.) Honestly, it's really a matter of organization. You want your code to cleanly reflect the data that you're application uses and the changes that data will undergo.

I think I will conclude by quoting the first paragraph in Wikipedia, which I believe sums up OOP very well as well as another paragraph a little further in.

Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance. Many modern programming languages now support OOP, at least as an option.
...
Objects can be thought of as wrapping their data within a set of functions designed to ensure that the data are used appropriately, and to assist in that use. The object's methods will typically include checks and safeguards that are specific to the types of data the object contains. An object can also offer simple-to-use, standardized methods for performing particular operations on its data, while concealing the specifics of how those tasks are accomplished. In this way alterations can be made to the internal structure or methods of an object without requiring that the rest of the program be modified. This approach can also be used to offer standardized methods across different types of objects. As an example, several different types of objects might offer print methods. Each type of object might implement that print method in a different way, reflecting the different kinds of data each contains, but all the different print methods might be called in the same standardized manner from elsewhere in the program. These features become especially useful when more than one programmer is contributing code to a project or when the goal is to reuse code between projects.

Take a car for example. Any car (basically,) is going to have an engine, a transmission, doors, windows, height, weight, length, width, and a couple other things. Any two cars may not be the same but share these attributes and methods (such as braking, accelerating, turning on, turning off, etc), so in an OOP design you would have an abstract object that defines what a car has where objects that inherit from this car object defines the specifics about the car while maintaining consistency between any two cars, even if one is a Ford pick-up and the other is a BMW convertible while letting each of these two different cars have different abilities, like the BMW will be able to "put the roof down" and the pick-up can "tow". Does that make sense?

 

[Kreij]

I think i have to distinguish these all at least to understand what i want to learn

You WANT to learn OOP. It will serve you well in many cases where doing without would be a lot more coding.
What language you want to learn it in is a whole 'nother story, but that too is not so important as once you learn the basics of how it works you just apply it to whatever OOP language you want to use. At that point it's just syntactical differences (and what the language makes available in APIs).

Many people don't like the .Net languages because of the lack of cross platform compatibility, but if you are coding for Windows there are thousands (maybe tens of thousands all told) of APIs in all the available DLLs to take a lot of the pain and guesswork out of what you may be doing. The Visual Studio IDE makes adding libraries a simple thing and the intellisense has gotten better with every iteration (although 3rd parties don't always take the time to make Windows DLLs very friendly).

If you want to see awesome power in a framework look at Windows Presentation Foundation (WPF).
It's hard to get used to if you are coming from a "do it all in one type of code" mindset (Just ask FordGT ), but what they have acheived seperating the interface from the business logic using XAML and the base language (C#, VB) and incorporating DirectX (full 3D in the GUI of a non-graphical application) into the mix, is stunning.

Okay ... I'll quit rambling.

 

[Aquinus]

You WANT to learn OOP. It will serve you well in many cases where doing without would be a lot more coding.

OOP is a good way to stay DRY (Don't Repeat Yourself,) as opposed to being WET (Write Everything Twice.)

whole 'nother

I say it that way out of habit and a co-worker at work corrects me every time.

I highly recommend learning the concepts of OOP. It's a very powerful tool in the appropriate situations, when used correctly. It also applies to most real world applications and can easily make your life easier, or at least just as hard if you use it incorrectly. I really makes for code that is easier to use and tends to organize your code as well by keeping like with like.

Just keep this in mind: Think of methods as something that the object does. A car accelerates and a car brakes, but a car does not drive itself. "Drive" would be appropriate on a "Person" object.

 

[Kreij]

I say it that way out of habit and a co-worker at work corrects me every time.

Send him here. I'll have him fixed in a week.

 

[GSquadron]

Ok, but from what i read from aquinus, was like reading a book, though not that formal.
That car example is so spread around. I mean, you are talking to someone who already knows OOP
and i am applying it on PHP for the moment. It is exagerately great and i thought that OOP was really stupid,
but that quits so much work! I make buttons in a single row.

If you were to ask me what is OOP i would reply:
Make things in a single row

And this is the best translation on OOP so far. This makes others to learn OOP.
Telling me that i have to think to objects as they drive and other stupid stuff which dont have
much to do with the computer, but with me, i think it is stupid. Tell me what the computer thinks
and i will create my own imagination with the 'car'.

And the ingredients are:

1) Class
a) Variables
b) Functions

2) Functions
a) this->variable
b) variable

3) Objects
a) $name = new Class;
b) $name->function('Hello World');

DONE

To tell the truth i think of them as colors, not as objects

 

[Aquinus]

Ok, but from what i read from aquinus, was like reading a book, though not that formal.
That car example is so spread around. I mean, you are talking to someone who already knows OOP
and i am applying it on PHP for the moment. It is exagerately great and i thought that OOP was really stupid,
but that quits so much work! I make buttons in a single row.

If you were to ask me what is OOP i would reply:
Make things in a single row

And this is the best translation on OOP so far. This makes others to learn OOP.
Telling me that i have to think to objects as they drive and other stupid stuff which dont have
much to do with the computer, but with me, i think it is stupid. Tell me what the computer thinks
and i will create my own imagination with the 'car'.

And the ingredients are:

1) Class
a) Variables
b) Functions

2) Functions
a) this->variable
b) variable

3) Objects
a) $name = new Class;
b) $name->function('Hello World');

DONE

To tell the truth i think of them as colors, not as objects

There are right and wrong ways to use objects. Good design puts methods on an object where it is applied. That is why I used the example that a Person drives a car, a car doesn't drive itself. It's how objects should be designed to make sure you don't have leaky abstraction and so you don't go violating half of the reasons why OOP exist.

The simple fact I was trying to make is that objects aren't just things, they're things with a specific purpose. So if you're going to make an object, have it do a ton of things that aren't related and leave it at that, you just missed the entire point of using OOP.

Lets say you're using the moodle_form class in Moodle. It has methods for defining the form, outputting the form, and getting data for the form. Saving that data in a database would be outside the scope of the object so it shouldn't exist in the form class. That is what I'm trying to get at.

Bad design leads to more problems down the road and if you ever work on a large project with other people you will learn that people don't think the same way you do but you're code still needs to be readable by others. This is why I personally believe that how you write your code is just as important as how you design the application itself.

Also, be careful what you call stupid. I do this professionally and I have been for over 4 years now and there are a lot of things you learn when working in groups and when other people review your code. Having a firm grasp on what everything is used for and how to use it correctly, not just how it works, is a very important thing to know how to do.

 

[Kreij]

And the ingredients are:

1) Class
a) Variables
b) Functions

2) Functions
a) this->variable
b) variable

3) Objects
a) $name = new Class;
b) $name->function('Hello World');

DONE

Done what? The above is just a description of a very simple class layout.
It explains none of the basic concepts of OOP/OOD like encapsulation, data protection (or hiding), inheritance, interfacing and polymorphism, which are the entire reason for using OOP.
If someone asked what OOP was, and you showed them that, they would still have no clue as to what OOP actually is.

The reason that manuals, tutorial and teachers in classes start with examples, like a car, is to get someone who is not familiar with OOP to start thinking in terms of objects by relating them to something people can understand (a real world example). It helps them to understand how to use OOP on an abstract level so in the future they learn to make good decisions on how to design a project.
The actual coding is far less important than having a good design to begin with.

I can teach anyone to code, coders are a dime a dozen, but good software design is an art as much as a science and requires a complete understanding of the underlying concepts and the ability and insight to know how to most effectively and efficiently implement them.
To be honest, if I started a software company I would hire good designers who have more real world, large project experience than I possess. Then I could happily be an owner, and a dime a dozen coder, and not have to constantly be worried about the design.

Since you love analogies p) ... if you give someone all the tools they need to repair a car and teach them how it all works, they still would not be able to design one.

 

[GSquadron]

I have to say, no matter whatever wikipedia says, it will never explain what it is.
I don't know but writting a full page and explaining like a teacher is awful!
So i said done, because that is the real explanation. (not to create any contradicts here, it is just for me)
If you say, car, dog, cat, horse, girl, boy....
That is going to make a big headache.
And what i wrote is not even a layout! What i wrote is the very simple explanation of someone who doesn't know well the concepts.
Though i understand that you know C#, because what i wrote is correct in PHP.

Also, i wrote that for the understanding of colors concept, not creating objects and classes.

@aquinus
I had a teacher who did 10 years of programming and cought himself like a freak when someone like me, who never heard of programming before taught him about the Gauss formula used in programming. So essentially he was stupid (referring to einstein relativity) creating a for cycle in 3 rows and i made a single row of formula. Bear in mind that having 4 years, means your imagination has worse boundaries than you have had when you didnt know anything.

 

[digibucc]

I have to say, no matter whatever wikipedia says, it will never explain what it is.
I don't know but writting a full page and explaining like a teacher is awful!

but it is a complicated topic, and you need that level of instruction to actually understand it - otherwise, you won't.

And what i wrote is not even a layout! What i wrote is the very simple explanation of someone who doesn't know well the concepts.

but it doesn't explain anything. not only is it missing a lot of important information, but to someone who doesn't already have the knowledge it simply makes no sense.

there is no avoiding a textbook type explanation. you may have a grasp with an overview - but to actually understand the subject takes a LOT of reading, it's as simple as that. Even people who are good at learning with action and not reading (like myself) eventually hit a wall when something is not comprehensible or simply comes out of the blue.

no matter how smart or accomplished you think you are, you have never passed the need for reference books.

 

[GSquadron]

ok, but really, at first i thought it was going to be extremely difficult.
After reading a lot, i understood that it is a concept created to easy the work.
And it is very easy, really. Only latelly i have started reading, because i hate books!

But still, you know, only a fool will learn things by heart. (i dont mean with love, LOL!)

 

[digibucc]

ok, but really, at first i thought it was going to be extremely difficult.
After reading a lot, i understood that it is a concept created to easy the work.
And it is very easy, really.

no disagreements - but it's only easy because you did all that reading. what you just typed out would have made no sense to you in the beginning, it only makes sense because of what you now understand having done all of that reading.

But still, you know, only a fool will learn things by heart. (i dont mean with love, LOL!)

i understand

 

[GSquadron]

Yes

 

[Kreij]

I love to discuss things so I'll continue.

After reading a lot, i understood that it is a concept created to easy the work.

OOP was create to address shortcomings in the non-OOP languages. Programming in OOP is no easier (or harder) than programming in any manner, it just gives you more tools to accomplish things that are near impossible to acheive without it. I guess one could say that makes your life easier as a coder, but there is no direct correlation to how much work will need to be performed.

When you learn how to code in OOP, it is easy, and once you understand the underlying concepts it all makes sense. If you are working on small projects (you alone or a very small group) design is not so much of an issue either as all of you will most likely be coding for end user use.

When you jump to large scale projects that involve teams (as Aquinus correctly stated), all of that falls apart. Design is critical and is by no means an easy thing. Many times there are tiers of coders, especially if the project includes some kind of foundation (Framework, if you will). A group of coders may be writing classes not for end use consumption, but for use by the next tier of coders. This is when the correct implementation of the 5 basic fundamentals of OOP become very very important.

Then you toss into the mix the constructs of the language itself.

For instance ...
- Should my class be abstract? What problems would abstracting the class solve (if any)?
- How do I need to define the variables and methods in my class (private? Protected? Public? etc.). Who is going to need to access these variable and methods and how?
- Given the functions performed in the methods within the class, do they need to work on varying input types (polymorphic)? When is writing multiple seperate methods preferable over a single polymorphic one?
- Where's the !@#$ aspirin?

Now add to that the case where you may be working with a team of designers who may have different ideas on how things should be ... and you have to take feedback from the coders and testers, and reassess (and possibly change) the design throughout the life of the project's development.

So much for "easy".

Completely off topic but cool and will give your brain a break after reading this thread ...

 

[GSquadron]

This thread is becoming cool with colas
Will edit tomorrow, have to sleep!