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

Archived

This topic is now archived and is closed to further replies.

Remnant

The 5millionth post on OO design principles..

52 posts in this topic

so when, say, the 5th subclass in an inheritance graph would call it''s own destructor when it went out of scope and then each of it''s superclasses would call theirs?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I have no name that you may call me. I am merely Succinct.
~Succinct Demos Online~

"Hey, where''d that display list rotate off to now?"
-(Drop me a line here)-

0

Share this post


Link to post
Share on other sites
quote:

so when, say, the 5th subclass in an inheritance graph would call it''s own destructor when it went out of scope and then each of it''s superclasses would call theirs?



Yep, classes a destructed it the opposite order of construction - including base classes. Try this program to see:


class Base
{
public:
~Base()
{
cout << "Base::~Base()" << endl;
}
};

class Sub : public Base
{
public:
~Sub()
{
cout << "Sub::~Sub()" << endl;
}
};

int main()
{
Sub sub;

return 0;
}
0

Share this post


Link to post
Share on other sites
furby100
quote:

A good combination of inheritance and encapsulation would be the following:
Every ship has an array of CModification, and there are a maximum amount of modifications
like a vistor, not exactly though


First I'd whack the stereotypicall array, and at least use a re-dimensionable one. In this case a linked list makes the most sense to me, becuae you'll have a fairly small indeterminet number of mods. Could be 4, could be 100. Array's would waste alot of space in over allocation. Also, you'll never need to access them by index, it's nearly uselss and provide no speed benefit. Most the time, you'll being doing complete iterations which is about the same speed for arrays as LL.
The pattern you describe is like a vistor, but not quite, you would eventually arrive at the visitor if you continued brainstorming. Pass a struct pointer (or an object) along for the MakeMod ride, to accumulate the result.


...
This thread fell off the OOD track

bogdanontanu even sounds like a troll name j/k
Abused OOD can have a catastrophic performance hit, and well tuned asm can run 400% faster on the machine its designed for.
But no one would ever OOD to the pixel level. You would never call a virtual function per pixel on the screen. That's a perfect example of misconstrued OOD. You could make the same mistake with asm, and call a bios routine to blit each pixel. My very first blitter worked this way
The difference would be a handfll of virtual function calls to one function call and a handful of array indexes. The array indexes are much faster than a virtual call, but not compared to the amount of work that needs to be done to render the scene.
On a modern machine a performance conscientious OOD will be 1-3% slower than a strictly procedural program.

If you can strip 400% more speed with asm when compared to C compiler, please go into the compiler business and help all the C programmers on earth as well as make a mint for yourself. A single properly coded asm routine might be 400% faster than a strictly C one, but the C coder could use your routine (as well as the C++ coder, or delphi coder).
So once that field has been leveled, your program is faster than most programs by deisgn implementation, not the constructs of the language you use. So you gain a significant level of speed in non-speed sensitive code, and a marginal level of speed in speed sensitive code.

An amateur with OOD is not much different than an amateur with asm. The problem is, if you're taking up OOD, you're no long an amateur coder. So you have a new learning curve to surf, and this is the serious problem many people have with OOD.
Why should I learn a new way to program? I can write programs now, that do exactly what I want them to!
And if that works for you then, no one's gonna change your mind, and they probably shouldn't!

I get pissed if I have to do the same thing twice. Special cases make for redundant code. OOD lets you handle all cases in a uniform manor.

The biggest problem with an all asm project, is that it won't run well on new processors. Go read about the pentium 4, and start crying, because you're hand crafted PIII optiized code is going to run slower on a higher clocked P4!!!

If you had written the speed critical section in asm, you would need only to add a method to determine the processor, and load the appropreiate routine. Then you only need to rewrite a small bit of code to acheive the greatest performance. I suppose you could leave the unoptimized sections of code alone, and just rewrite the speed critical sections, but now your asm project is slightly slower than a C one!
Now compare the 30minute rebuild to the daunting task of re-optimizing 150,000 lines. Of course I'd have to wait for a C compiler that supports the new processor... M$ seems to lag behind a couole of years, Intel comes out with new ones faster.
I suppose its a moot point, because today's code on tomorrow's computer is gonna be waiting an eternity for the vsync anyway.
I have a funny feeling, you didn't use any threads. (Afterall, why would you use a thread, you can do everything with one!)


...
I almost forgot:
quote:

OOP also moves you away from the CORE of programming ...slowly moveing you to the USER side...


This could not be farther from the truth. If we were trying to use Director or power point to make a game I might agree. You can teach bateria how to add, but most people aren't capible of abstactly solving a problem in a procedural fashion - never mind an OO fashion.
The implementation can always be made more efficent.
An OOD *can* be implemented in C or even asm - as you have proven since you did use directX. C++, Ada, & smalltalk were made with OOD in mind, so they help automate the process and are more logical choices if you decide on an OOD.

Magmai Kai Holmlor
- The disgruntled & disillusioned


Edited by - Magmai Kai Holmlor on January 9, 2001 12:03:26 AM
0

Share this post


Link to post
Share on other sites