• 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
kaktusas2598

Am I thinking right OO way?

67 posts in this topic

[quote name='swiftcoder' timestamp='1299095369' post='4781111']
What happens when you need an enemy AI without a sprite?
[/quote]
Is he invisible o.O


[quote name='swiftcoder' timestamp='1299095369' post='4781111']
An enemy sprite without an AI?
[/quote]
Then I just draw the sprite : /

[quote name='swiftcoder' timestamp='1299095369' post='4781111']
The same AI with a non-sprite representation?
[/quote]
Again, invisible?

[quote name='swiftcoder' timestamp='1299095369' post='4781111']
The same sprite rendering attached to a different type of AI?
[/quote]
The sprite class I use has a pointer to the image associated with it that has been loaded into memory. It draws that image. It doesn't copy it. So... I'd just give it a copy of the sprite.

0

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1299094457' post='4781103']
Were we instead designing 'Pong the MMO', we might have to revisit that distinction...
[/quote]

I was thinking 4 possible players (top, bottom, left, and right) who could be either AI, human controlled, or no player (wall). I'd say that's within the scope of a one dude pong clone.

Anyway, I concede that either way works and better-ness depends on how much is planned on being implemented.
0

Share this post


Link to post
Share on other sites
[quote name='No Style Guy' timestamp='1299095713' post='4781112']
By your logic, if i [i]view[/i] a game as an object who is a singular object with attributes such as players and terrain and game mechanics and physics, then why not just make one God class that inherits everything from everybody and has no composition? Does that sound like fun to manage? [/quote]

XD if you view it that way, then go ahead. Personally I think it's much more believable than an enemy "is" both himself (the AI) and his graphical representation (his body) than your extreme. Look, I'm even using "is". That's the problem with the principal. It's opinionated. If I say something IS something and you say something HAS something then people get in this big argument. Just forget the damn principal and program it logically. >.< If you see the player as BEING the paddle, use inheritance. If you see the player as HAVING the paddle, use composition. I don't care.
0

Share this post


Link to post
Share on other sites
[quote name='slynk' timestamp='1299097566' post='4781128']
[quote name='No Style Guy' timestamp='1299095713' post='4781112']
By your logic, if i [i]view[/i] a game as an object who is a singular object with attributes such as players and terrain and game mechanics and physics, then why not just make one God class that inherits everything from everybody and has no composition? Does that sound like fun to manage? [/quote]

XD if you view it that way, then go ahead. Personally I think it's much more believable than an enemy "is" both himself (the AI) and his graphical representation (his body) than your extreme. Look, I'm even using "is". That's the problem with the principal. It's opinionated. If I say something IS something and you say something HAS something then people get in this big argument. Just forget the damn principal and program it logically. >.< If you see the player as BEING the paddle, use inheritance. If you see the player as HAVING the paddle, use composition. I don't care.
[/quote]

The is-a/has-a confusion here is in part due to the simplistic nature of the game. As the complexity of the object/class population grows, not only will it probably be easier to distinguish clear lines between inheritance cases and composition cases, but composition will beat out an ever-deepening inheritance tree in multiple areas (readability, group-programmer understanding, maintainability, etc).

"Forgetting the principal" and "programming it logically" are at odds...the principal is both logical and time-tested. One can design for both inheritance and composition, the heart of the matter is that your opinion, this programming style that works for you on your own projects, is bad advice for someone wanting to follow good oo practices [i]that scale well into any project.[/i]
0

Share this post


Link to post
Share on other sites
[quote name='slynk' timestamp='1299097566' post='4781128']
[quote name='No Style Guy' timestamp='1299095713' post='4781112']
By your logic, if i [i]view[/i] a game as an object who is a singular object with attributes such as players and terrain and game mechanics and physics, then why not just make one God class that inherits everything from everybody and has no composition? Does that sound like fun to manage? [/quote]

XD if you view it that way, then go ahead. Personally I think it's much more believable than an enemy "is" both himself (the AI) and his graphical representation (his body) than your extreme. Look, I'm even using "is". That's the problem with the principal. It's opinionated. If I say something IS something and you say something HAS something then people get in this big argument. Just forget the damn principal and program it logically. >.< If you see the player as BEING the paddle, use inheritance. If you see the player as HAVING the paddle, use composition. I don't care.
[/quote]

Precisely. My God class example used "is-a" because I was framing it to fit [i]your view[/i]. I personally think it makes more sense that "A game [i]has-a [/i]terrain, [i]has-a[/i] player, [i]has-a [/i]Physics system, etc" (as per my exmaple) or even "A player [i]has-a[/i] Body (sprite) and [i]has-a [/i]Brain (AI)" but you seem to think it should be "A player [i]is-a[/i] Body and [i]is-a[/i] Brain" (as per your example).

Regardless, I'll conceed that the [i]is-a[/i] and [i]has-a[/i] idiom can be subjective (or rather, both can work), so I wont argue that further.

The problem is that there are characteristics of each approach that are tangible, undeniable facts. If you have an inheritance tree where the current object has inherited attributes, either directly or indirectly, from, say, 10 different classes, the exact origin, purpose, and usage of those attributes is undeniably confusing. If the same current object was a composition of those classes, it would be (nearly) explicit where those attributes came from, what they affect, and why they're there.

I've lost count of the number of times where I've been trying to extend a class that seems to be modifying an undescriptive member variable (say, "count") which is not declared in the immediate class's header. I then backtrack through each of his multiple inherited base classes for somebody with a "count" member variable. If he had just had MyObject.baseclass.count, I would have had a lot less headaches.

Composition: easy maintainability, re-use, good cohesion and low coupling
Inheritance: less code, but poor {all of the above}

That is the basis for this argument, not opinions about how you view relationships of objects.
0

Share this post


Link to post
Share on other sites
[quote name='BCullis' timestamp='1299098253' post='4781132']
"Forgetting the principal" and "programming it logically" are at odds...the principal is both logical and time-tested. One can design for both inheritance and composition, the heart of the matter is that your opinion, this programming style that works for you on your own projects, is bad advice for someone wanting to follow good oo practices [i]that scale well into any project.[/i]
[/quote]

[s]My original advice was to inherit the player class from the paddle class as I view the player as pretty much being the paddle in this instance. This debate then started when someone quoted oo principal as a means to debunk my method when in fact it followed the said principal. So how was it bad advice? And how does it not scale? If someone views something in a large scale project as being something, doesn't your principal teach that they should use inheritance?[/s]

I'm done, you're all right. There can be one and only one way to do things. I give up. [img]http://public.gamedev.net/public/style_emoticons/default/rolleyes.gif[/img]

EDIT: "[color=#1C2837][size=2]from, say, 10 different classes" I wouldn't know I never use more than single inheritance :o[/size][/color]
0

Share this post


Link to post
Share on other sites
[quote name='slynk' timestamp='1299098940' post='4781137']
I'm done, you're all right. There can be one and only one way to do things. I give up. [img]http://public.gamedev.net/public/style_emoticons/default/rolleyes.gif[/img]

EDIT: "[color="#1c2837"][size="2"]from, say, 10 different classes" I wouldn't know I never use more than single inheritance :o[/size][/color]
[/quote]

There are tons of ways to do things. There are much fewer ways to do things well. I could walk home every night by first flying to New York and then walking the couple hundred miles back, but that would be inefficient. There are however a couple routes home that are practically the same distance and walking time.

A good counter example to your thing would be having a player with a sprite and a physics object and AI. Does he inherit from sprite? Does he inherit from his physics object? Does he inherit from AI? Not all languages support multiple inheritance, and there's no reason a sprite should also be a physics object or AI or any other order.

Bad design can make sense in small games, but even on a one person game as complexity grows you will find these OOP principles come into play a lot more because eventually you will either be wasting tons of memory space/clock cycles or just won't be able to get your objects to work as desired.
0

Share this post


Link to post
Share on other sites
As stated, I refuse to argue the matter further, why beat a dead horse? Do you really think it's a mature thing to do? Do you really believe it's mature to claim some one is acting the victim? Your hostility, name calling, and sarcasm have been completely unwarranted. Get off your high horse, recognize that I have made SOME valid points and A LOT of not so valid ones. The user above you succeeds the the fact that when deciding whether something IS-A or HAS-A is completely subjective (although usually obvious). There's no reason for you to be so obtuse. If you can't handle a mature debate, don't participate in one. It's easy to debate. Assert your opinion, provide evidence to support your opinion and provide couter points to the other's arguments. Difference of opinion != hostile intent. ^^
0

Share this post


Link to post
Share on other sites
Wow! its been a while since I last seen a troll get this much attention.

Disregarding the troll under the bridge and addressing the concerns of the poor guy that posted this thread in the first place and went sort of neglected...

A lot of remarks on what is and what is not overkill have been posted, not just in this thread, however being this a post in "for beginners" and asking about the specifics of the object oriented philosophy I think it is best for the creator to learn the formal definitions first and then decide whether or not they fit the needs of his project, doing a simple game the complex formal way is not a waste if its purpose is learning.

As for the proper way I completely agree with Ravyne, the player and the AI are not paddles, they control the paddle, they have a paddle. Using inheritance in this case would be a "seems harmless now" mistake, stating that you need to expose the paddle member outside of player if you don't use inheritance in order to control its movement implies that the player is meant to keep score but does not know how to give orders to the paddle, which is just ridiculous, the player should handle input recognition for the specific needs of the paddle directly.

Also kaktusas2598 posted a concern for whether or not a game class is needed and then stated he would use an enum to represent current game state, as long as we are learning allow me to submit to you this technique: http://wiki.gamedev.net/index.php/Managing_game_state
It proposes a simple implementation with a lot of room to expansion but with a solid foundation in separating radically different state logics in a reusable way.
As for the game class, I would like to know which platform / framework are you using in order to recommend whether or not such a class is necessary, but with the current information I would advice in favor of its use.


2

Share this post


Link to post
Share on other sites
Reasoning:

I propose solution X.

Another user says X can't be true but Y can because of principle P.

If I can prove the principle P is implemented subjectively, then I can effectively determine:

X == Y due to the subjective nature of the principle

This makes me a troll.... how? If you want me to stop posting, stop fucking attacking me. Ignore me. No one can relinquish control. You can argue with me, WITH OUT REFERRING TO ME. With out saying things like, Slynks a troll and why can't he stop posting. The fact that you keep making personal attacks at me means, you want to get under my skin. <.> Which makes you worse than me unfortunately. Also, notice that this post is not one of my opinion, but of WHY I was arguing so please don't respond with "Yeah will it's not subjective bla bla bla" I'm tired of the immaturity. I just wanted to try and prove the point above but everyone just keeps restating the same thing over and over while attacking me.

I may a be a stubborn, sensitive idiot but at least I don't treat people like shit. : /

EDIT:
Want to know how to do it?

[url="http://www.gamedev.net/topic/596681-am-i-thinking-right-oo-way/page__view__findpost__p__4781141"]http://www.gamedev.n...ost__p__4781141[/url]

Notice he argued against my point BUT didn't attack me. I read that long before Hodgman responded. And guess what, I didn't reply to it... >.<
0

Share this post


Link to post
Share on other sites
[quote name='slynk' timestamp='1299173404' post='4781455']
Reasoning:

I propose solution X.

Another user says X can't be true but Y can because of principle P.

If I can prove the principle P is implemented subjectively, then I can effectively determine:

X == Y due to the subjective nature of the principle

[/quote]

My reasoning:

Your principle, P (the has-a/is-a implementation choices) may be subjective, but they have objective pros and cons.

As I, and others, have said many times, the issue is this:

Composition: better maintainability, reuse, decoupling, and cohesion.
Inheritance: less code, but worse (all of the above)

These aren't opinions, they are direct results of the implementation. There are numerous examples of that in this thread.

Basically, the part you're right about is: "One can view the problem many ways".
However, the part that you're wrong is: "Since one can view the problem many ways, all implementations are equally effective".

Now the burden is on you to show how your inheritance example lends itself to equal (or better) code reuse, maintainability, cohesion and decoupling than composition.
0

Share this post


Link to post
Share on other sites
I think this thread needs to be closed as it's going nowhere. You don't walk up to a building site and start telling builders there's an alternative way to lay bricks. True as it may be, it's useless because they have years of experience and know what works.
0

Share this post


Link to post
Share on other sites
[quote name='slynk' timestamp='1299085552' post='4781056']
[quote name='BCullis' timestamp='1299084969' post='4781050'][i]in the context of following good OO practices[/i] there is a right and wrong way to go about your design.[/quote]

I'm purely stating my opinion that:

"[size="2"][color="#1c2837"]composition should be preferred over inheritance whenever inheritance is unnecessary"[/color][/size]

[color="#1c2837"][size="2"]is an opinion and there for does not designate "Good practice" maybe "Preferred Practice" or "Industry Standard" but in my opinion, without *me* seeing a benefit of following the principle, it can't make for a "good" practice. That's just my opinion ^^[/size][/color]
[/quote]

I want to have two paddles per player. Revise your solution.

Done yet? Well, I changed my mind, I want 3.

Like others have said, composition promotes code reuse in a more direct way than inheritance. Anything that makes a project easier to build upon is good practice. Anything that does absolutely nothing for your code but resolves a sense of "it seems better to me" is not. "Good practice" is a tangible thing with tangible benefits. What are the tangible benefits in your method?
0

Share this post


Link to post
Share on other sites
[quote name='SeraphLance' timestamp='1299254766' post='4781781']
Like others have said, composition promotes code reuse in a more direct way than inheritance. Anything that makes a project easier to build upon is good practice. Anything that does absolutely nothing for your code but resolves a sense of "it seems better to me" is not. "Good practice" is a tangible thing with tangible benefits. What are the tangible benefits in your method?
[/quote]
If there are no bugs, it could take less time to code. This is the far far edge best case scenario.

I feel like Slynk has never worked on a legacy code base. Even on individual projects I don't like making bad design choices because of how much pain they've caused me in the past

edit: I've also changed my mind on a couple individual projects that resulted in me completely rewriting a lot of code and ended up taking days instead of minutes in changes.
0

Share this post


Link to post
Share on other sites
this thread helped me a lot. thanks people.
also, [u][b]slynk[/b][/u], are you here to learn? if yes, firstly, learn how to accept criticism and suggestions.
None of the replies here were of rude nature; they were very polite and informative. Don't bring "my opinion" into the game. I'd prefer to hear from you the "why"s. Opinions are very vague and abstract. Reasons and examples are concrete and exhibitive.
[url="http://www.gamedev.net/topic/596681-am-i-thinking-right-oo-way/page__view__findpost__p__4781305"]This post[/url] considers re-usability and maintainability of your system in a longer run.
On the same subject. Would it be a good approach to build an interface ([b][i]IGameEntity[/i][/b]) with such methods as [b]animation, motion updates, draw[/b] and then implement them in another class ([i][b]GameEntity : IGameEntity[/b][/i] with virtual methods for overriding in future) with members (compositions) such as rendering information (position, centre, angle, rotation, texture key in the map etc), state of an entity (alive, hp value etc) etc. and then, via inheritance do the following

PlayerShip : GameEntity, EnemyShip : GameEntity, Asteroid : GameEntity, etc ?
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