• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

oop fundamentology question

6 posts in this topic

I am not sure if i will be understood (If my question will be understood) but hope so

 

I am not using oop, and I think i do not understand its ideology, but there is some question i could ask and maybe answers would help me to better understand it

 

I understand in oop you can build some graph/net of objects where objects can seen each other through the references to other objects they hold as its own fields,

for example

 

class Game  

private: 
        Graphics& g; 
        Window& w; 

public:

     ///

 

}

 

class Window  

private: 

      InputSystem& i;

      Audio& audio;

public:

     ///

 

}

 
class Audio {
private:

      HardwareSubsystem& h;

public:

   ////

}

 

etc, this is fictiuos example but it shows that in OOp you can build some net 

of objects seeing each other through the references 

 

My question is : is this kind of graph environment main purpose or such oop program; On the other words Is the main aim of oop coder to build such net

of objects which will be interfering each another throught this references

 

I dont know if this pure way of interacting between objects is the aim of this

 

I am asking becouse of that in oop languages like c++ for example you could

probably reach to other objects in some other way than through such kind of

references (would it be violation of oop rules for oop programmers?)

 

Other part of the question is that before you have the objects (like Game, Audio, Window here) and before you have setted the references between them you must

set up then manually (you must instantiate the objects somewhere in the code

tree and you must run also the code which will setup/bind the references - this is some kind of 'inner' and 'outer' sides of oop if you understand what i mean :

 

in inner side of the oop you got internal code of objects and references to other as its fields - in outer side of oop you must setup the objects and setup the references before the system of objects could work

 

is the main purpose of oop to work in this inner side (when you are not interested where objects was instantiated if it is global space, main function or field of another objects of local scope of some function - but only interested in the inners of objects and explicit references ) and the outer side is only used to setup the

thing -

or the outer side (and scope visibility and such things) is also a field where some oop techniques could be developed and used (or they should be avoided and only focused to develop the proper objecst graph)

 

I hope i will be understod, I am curious how indyvidual oop programmers see this thing (though i am not sure if i will be understood what i mean by inner and outer

side of oop)

 

 

 

 

 

 

0

Share this post


Link to post
Share on other sites

I have been told that this kind of coupling between objects is a big no no! This is kinda seen as a "trick" to make OOP not be OOP.

 

 

The OOP purists out there will rather spend 500 lines of OOP code, building all kinds of interfaces and objects, where as a procedural programming can get away with less then 10. It is all about memory leakage, stacks overflowing, exceptions and so on. I think the idea is that if you abide by OOP you will be "safe".

0

Share this post


Link to post
Share on other sites

@up allright, tnx, i understand it though i need a little time to get it more claryfied

 

though I got yet some general question about oop:

 

are here some set of rules defined how it should look like

or at least some set of sub rules what should be not used,

or in hgeneral this is a 'free wrestling' way where you could

write it anyway you like?

 

yet as to my question - in such example i wrote you 

got a set of objects glued by references and only allowed

way would be reaching the other objects by this explicit

references - Is this reccomended way? I mean other kind

of referencions banned (the other would be mainly direct 

reaching for other objects data or functions

(by direct i mean without pointer - just by use avaliable

scope visibility)

 

I must say that i dont see clearly the rules that would

rule in this field, i f i got no rules i could do many strange things

here (and many strange things are done here by mane people

here) Is there one official reccomended style maybe or there are

very many styles here?

 

0

Share this post


Link to post
Share on other sites

 

is the main purpose of oop to work in this inner side (when you are not interested where objects was instantiated if it is global space, main function or field of another objects of local scope of some function - but only interested in the inners of objects and explicit references ) and the outer side is only used to setup the
thing - or the outer side (and scope visibility and such things) is also a field where some oop techniques could be developed and used (or they should be avoided and only focused to develop the proper objecst graph)

No, you're using OOP in both of those situations.
e.g. your "outer" code might look like this, but it's still OOP as you're working with OO objects and relationships:

int main() {
  InputSystem input;
  HardwareSubsystem hwAudio;
  Audio audio( hwAudio );
  Window win( input, audio, 640, 480 );
  Graphics gfx( win );
  Game game( gfx, win );
  game.Run();
}

This code is often called "glue code", because it's setting up the relationships between actual objects (the relationships between classes was already coded earlier - in your example code), or gluing objects together. You will find this kind of "glue code" inside the main function for sure, but you will also find it inside more complex classes (so it appears at both "inner" and "outer" levels).
 

 

PS I would call such glue code always as 'outer' code, because it

is only a setup code for the real environment of objects, where the real code works (so this glue code is some kind of outer even if it is spreaded across the whole source - it also has no real purpose except of setupping the object environment - or no? it is also probably mostly unchanging i mean when references between objects are setupped they rarely change in runtime - if they will change the object graph of a program would be changing in time and i think it is assumed to be static - or no? (this is maybe not so important but those are my thoughts here, more important to my understanding would be if there is some reccomended style of oop (against other styles maybe and what are rules of it)

0

Share this post


Link to post
Share on other sites

Not sure how experienced in the language you are, so if this is obvious forgive me, but are you familiar with the difference between a pointer ([i]Sometype* name[/i]) and a reference ([i]Sometype& name[/i]) in C++? It's fairly significant. I could be wrong, but I have [i]never[/i] used or seen references used that way. I suppose it's legal, but you'll have to initialize those references with Object::Object(SomeObject some_value) : some_reference(some_value){}. Is that really what you wanted? Can it never reference nothing (as in nullptr/NULL)?

 

Also, referencing objects is only necessary for objects that the base object does not own. Ownership is not clear from your post, but say a Box owns 6 Sides, it would probably look more like

[source]class Box{

    Side top,front,back,bottom,left,right;

};[/source] rather than a bunch of pointers to Sides (Side*) or worse references.

 

If a Train runs on a Railroad, which is presumably shared between many railroads, it might look more like

[source]

class Train{

    Railroad* railroad;

};[/source]

 

Of course, this has its own problems. Raw pointers are easy to get wrong, but c++11 has introduced smart pointers to the stl (and boost has had them for ages)... but that might be a topic for another day. Coupling an object with a hard reference (SomeType&) makes it very hard to check if SomeType is even still around. Scoping also seems like it would become a real pain - and if you're dynamically allocating the memory, why go through the hastle of storing it's location as a reference instead of a pointer?

 

Then again, I'm no expert. Just chipping in.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0