• 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

Hi again

Wow i did not think that my simple (intended helpfull) remark will generate such an emotional flame

but know it did....so:

Guys, if u think modern computers dont help ASM or non OOP programming also...you are wrong...

So when a OOP compiled program runs "decent" an ASM program "rocks the sky". I know it because i do it. My whole RTS game is done in ASM....so...wanna check compiler speeds?

My whole project is now about 150.000 lines of code, about 1000 files and it re genereates an exe from scratch (compile,link with resouces add) in about 1 (ONE) second on a P2/400 computer

Of course i have no OOP (besides DirectX code i call, an the window class if u can call that OOP )

today most "optimized" compilers only make about 100% up to 300% slower programs then ASM and again OOP compiled code is about 200% slower then normal HLL code...

Yes there are tricks to make it run a little faster...but the only thing that really can be done is pump up the hardware...
(but again ASM will benefit more ...)

For the ones that think their OOP code is fast, think about it:
Are you calling hardware assisted 3D render in? Well thats not your code...is HARDWARE! Are you calling some highly optimized ASM code? (like DirectX API...)...Well that is not your code also!

I have done my whole game myself...i only call DirectX for setup ... try to do Alpha Blending Blt in OOP an let us live long to see it finish a screen redraw..

Most source code i have ever seen (the one released to the public and that compile and run fine) are at least 40% ASM (the core) and the rest of the code is non OOP not even without jumps to labels!

Yes some AI scripts (they are HLL languages them self) are written using OOP....but they rely heavyly on some optimized ASM blocks to do the interpreted tricks...and they can have o fps of about..."now and then" or "once every 2 secconds"


If the OOP ONLY disadvantages are (you say):
=============================================
1.slow
2.ineficient

and let me add:
=================
3. complicated

Then i will consider removeing it from programming totally!... ...just kidding....but guys...dont forget its all about SPEED in games....(think at AI, GFX)


Games are very demanding to a PC, and if i can squeeze even 10% more using ASM and droping OOP i will gladly do it! But i get more then 200%....

Even if OOP has decent speed today (1Ghz Micros do the trick ) you can add enormouse more AI and GFX to a game by using ASM or even non OOP code and killing some OOP...

Yes there are advantages to OOP but those are more likely to be used in database visual programming rather then fast games.

I just wanted to kindly say: take care OOP can ruin your game speed...and generated a flame...ooops...not my intention...but if u want i can give you more arguments....just dont think i have to...


Bogdan



Edited by - bogdanontanu on December 22, 2000 5:36:06 PM
0

Share this post


Link to post
Share on other sites
((Even if OOP has decent speed today (1Ghz Micros do the trick ) you can add enormouse more AI and GFX to a game by using ASM or even non OOP code and killing some OOP...

Yes there are advantages to OOP but those are more likely to be used in database visual programming rather then fast games.))

IMHO most of us dont have 20-30 years for writing tons of ultra-fast ASM code. And what about debugging? You`ll surely have lots of fun looking for 5-years-old typo in thousands of lines of as code...
0

Share this post


Link to post
Share on other sites
Well,

My RTS game is full ASM and it only took about 6 months until now...(just 2ppl but esentialy one working at at time, besides the artist)

we have big Grafix FX, units AI, Patfinding, Formations, some Network,etc you can even dl a working demo at:

www.gdarchive.net/bogdanontanu/index.html
or
www.angelfire.com/games3/bogdanontanu/

I wonder how many full OOP or even full HLL (no ASM) games are out there...because i am makeing the full ASM (no HLL) game

Things are easy today with ASM, modern processors and OS's make it very easy for us also...not only for OOP...

Simple fact that you think its hard to write ASM (or just non OOP) code for you dosent make it real for other people. (*but it may be true for you)

I can do (esp in games) many things in ASM..and i can do i faster than many OOP programmers (just not menus )

Told you our game compiles in a second (just one) for the whole project...didnt I ? (150.000 lines of code)

Now i just want to say that:
=============================
- both "design patterns" : full OOP and full non-OOP are still valid ones today...think about them open-minded and choose the one, or a mixture of both, that best fits your game .. ok?


Bogdan

Edited by - bogdanontanu on December 23, 2000 9:28:22 PM
0

Share this post


Link to post
Share on other sites
PS.
debugging? who needs debugging

You may need advanced degugging in using OOP or HLL...to check methods ona object inheritance...class etc...

but why me?

i only use about a handfull of instructions (90% 10% rule)
what can i go whorng usihg the same very simple blocks again and again...

We did not have even one hard to find error from a very long time...

i mean our hardest errors are the logical ones, but no debugger or syntax checking will help you find those..only your brain...and again because its more simple in ASM and non OOP languages we find any error very quickly...

Most of our "hard errors" are "copy and paste errors". Copy and paste is our best enemy...problem is it helps also!

And last:have you heard of Softice? we can debug the Windows Core and ring 0 rutines with it....surely your debuggers cant do that

Bogdan
0

Share this post


Link to post
Share on other sites
are u nuts?

i went to Pitt for computer engineering and got a lot of hands on w/ asm... before that, though, i cloned the entire wolfenstein 3d graphics engine in asm on a i286. i''d consider that a medium sized asm background, but i still think oop is one of the most useful tools in development there are.

i''m in the school that you write code oo-ly, then tune the bottlenecks using any tricks you can, including asm.

you say that the whole program compiles in 1 sec, and that it''s 150,000 lines of code, right?

1 line of c++ >= maybe 50 lines of asm, so your code is more around 3000 in terms of complexity.

and besides, who cares how long it takes to compile? as long as you program modularly enough, you won''t ever compile the whole thing more than 2x per day!

and you say oo is more complex than asm?

what? did i read that correctly?

oo is more abstract than asm. that is all. you seem very biased against oop. have you done much work w/ oop or are you going on what other people have told you?

besides, asm is 100% the most UNportable source there is, excluding 0100111010100101101010

dunno,just my opinion...



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
Hi

Yes ASM is much simpler than OOP
and OOP is very complex compared to ASM...

If u think you can get by just recompile your work every 2x a day...then you didnt make many games?...we do it at least a 100 times a day....and it matteres how long it takes...yes i know you can compile just the modified code and then link modules, but i just wanted to make a fair compare between compilers speed

Now you dont know how complex our game is...do you?
i really hope (for your sake) that 1 line of C/C++ dose not translate into 50+ lines of ASM...it will be too much slow

I am not against OOP...just against too much OOP in games in every position...

I also think it is a good "design pattern" to write HLL code and then speed it up with ASM....but i wanted to mention that today you can also do ALL just in ASM...esp in games...

Because in games OOP is usefully just for Menu systems and maybe some AI scripts....you will have to use a lot of ASM in a game today...

OOP also moves you away from the CORE of programming ...slowly moveing you to the USER side...if thats what you want FINE

I dont

Bogdan



0

Share this post


Link to post
Share on other sites
A few things:

1) According to Code Complete, 1 line of C translates to 1 to 2.5 lines of assembly. I imagine C++ would be about from 1 to 5 or so.

2) Umm... you compile only twice a day? I compile dozens of times, and I think I''m pretty normal...

3) Are a few extra seconds of compile time really that bad?

Visit my site!
0

Share this post


Link to post
Share on other sites
Well, I do a lot of work with Delphi (and its inline assembler). I also use VC++ but I try not to Delphi compiles in 1 or 2 seconds. VC++ takes forever...

Edited by - morfe on December 28, 2000 2:02:02 AM
0

Share this post


Link to post
Share on other sites
Umm go to GT interactives UT site and find out why they used OOP... Sorry folks this isnt the early eighties were a little miscoding could give you a huge perfomance hit. And we dont really need painstakingly optimized assembly code. Which in case anyone doesnt know is very different from now then it was 15 years ago. It used to be VERY processor specific, but i dont think people remember that now....
0

Share this post


Link to post
Share on other sites
Yep, C++ does compile slow in Visual C++.
But who cares?
Any selfrespecting professional programmer has a fast computer and knows how to setup their code to prevent unnecessary rebuilds.

I have my workspace of my 3D engine (650kb sourcecode spread over ~175 files compiling into 3 dll''s and 2 executables) configured as such that most rebuilds take less than 3 seconds and a complete rebuild takes about 20 seconds.

Visual C++ compile Tips:
- Use precompiled headers
- Use incremental linking
- Make static librarys dynamic wherever possible.
- Most importantly: NEVER include windows.h when you don''t have to. Also, if you really need to use it insert this code before the #include:

// Skip everything except the kernel functions
#define WIN32_LEAN_AND_MEAN
#define NOGDICAPMASKS
#define OEMRESOURCE
#define NOATOM
#define NOCLIPBOARD
#define NOCTLMGR
#define NONLS
#define NOMB
#define NOMEMMGR
#define NOMETAFILE
#define NOOPENFILE
#define NOSERVICE
#define NOSOUND
#define NOCOMM
#define NOKANJI
#define NOHELP
#define NOPROFILER
#define NODEFERWINDOWPOS
#define NOMCX
#include

This speeds up compiling a lot.

Also, buying a fast AMD Athlon or Pentium3 processor is really worth it.

I think its crazy to use assembler all the time.
You make your code unmanagable, unportable and give other people a really hard time reading it.

0

Share this post


Link to post
Share on other sites

1.Who cares that VC++ compile slow?...not me i use ASM, but i think everybody shold care

2.Buy P3 and Athlon....hmm this VC++ and OOP makes us buy again and again lots of hardware... that was the intention...

I will just like to use my P3 like a P3 and not like a 286 because of slow OOP and people''s urge to finish a project faster with less work...

3. "a little miscoding could give you a huge perfomance hit"

This is true today as it was yesterday...

Today PC''s are not so fast as they "tell" you...sure not so fast to tolerate even minor performance errors in your code...
0

Share this post


Link to post
Share on other sites
quote:

1.Who cares that VC++ compile slow?...not me i use ASM, but i think everybody shold care


If you would''ve read my post you must have seen that the difference in compile time is about a second after some tweaking.
Do you really care about 1 second?
You will lose a lot more time by doing everything in assembler instead of C or C++.

quote:

Today PC''s are not so fast as they "tell" you...sure not so fast to tolerate even minor performance errors in your code...



Thats simply not true.
Do you know how inefficient for example Unreal Tournament is with CPU cycles?
Nonetheless, it still runs very smooth because todays bottleneck is not really the CPU anymore but videomemory bandwidth.

Also, thinking about a problem in an abstract way is rather hard if your code is pure assembler. You try to squeeze the most out of the CPU but while doing so you can forget what the code was all about. That can cause you to code a tweaked algorithm that is not as fast as a nontweaked algorithm (e.g. using an optimized bubblesort in assembler instead of using a quicksort in C++ is way slower).

Anyway, arguing with you seems rather pointless because I don''t think I can ever convince you. I just don''t want newbies to think that they should forget about learning C++ and only learn assembler because ''its faster''.
0

Share this post


Link to post
Share on other sites
Concerning 'how many lines of C++ == how many lines of ASM' I think it really matters how you code.

My game loop looks something like (this is pseudocode, too lazy to look it up):



if (no messages)
{
GameC.Main();
}



How many lines do you think that translates to?

The point here is that there is no point. You can argue this to the moon and back because it depends how 'high' in the implementation you are. At the top level, you run the game with a function call. At the lowest you're... programming ASM?

I'd rather type



pObjectC->Move();



than cut and paste three pages of code.

I would be very disappointed if your ASM game took so long to compile... especially seeing that even though I cannot program in ASM (although I know how it works), I happen to know, like everybody else, that .exe's are just piles and piles of ASM. So basically, we have one massive copy.

And what was that about 'cut & paste' earlier? What decade are you living in, dude? The only good programmer is a lazy programmer; never, EVER, repeat a line of code, unless that line is calling other lines. Both are quotes. Learn them.

Have you ever played Half-Life? Unreal Tournament? Any game developed within the last five years? You guessed it: object-orientated programming.

'Big deal,' you say. Within a meagre 10+ years you could hand-crafted the entire thing from scratch. Congratulations. You're using technology dated 10 years with no hope of incorporating it.

Ever make a mod for a game? Notice how these tend to prolong the games live's by years? How popular do you think Half-Life would be without TFC and Counter-Strike? And where do the royalties go when the mods start selling?

Planning to sell your engine? Good luck. You'll need it. I'd rather make my own than try and figure out what the hell you where doing. And then when they figure out, try and work with it.

I could carry on, but I won't. I hope that you will at least take what I say into consideration.

If any of the above information is wrong, please correct me! I hate being incorrect and not knowing it.

Thank you for your time.

The_Minister
1C3-D3M0N Interactive

Edit: Aah screw the source tags, I prefer HTML

Edited by - The_Minister on December 31, 2000 10:14:07 AM
0

Share this post


Link to post
Share on other sites
A full rebuild of my C++ game takes 35 minutes. That is mainly due to the high level stuff I use, especially templates/Standard Template Library. I dread to think how long it would take if I moved over to the templatised iostream libraries too. I can''t use precompiled headers as I change some of the headers too often, and it needs to be portable (ie. compile under systems that may not support precompiled headers too). Compile times are perhaps the thing that drives me away from the really high level stuff and want to play with void pointers etc.
0

Share this post


Link to post
Share on other sites
Kylotan, modules are the way to go. Develop each part of your game separately and individualy, and join them together with the final game code when you finish them. While developing them, test them completely.

That way, no module ever gets too big, and if one module is starting to become truly massive, break it down into smaller modules.

This is, as I''m sure you know but for those who don''t, known as the test harness or ''testbed'' developing method.

The_Minister
1C3-D3M0N Interactive
0

Share this post


Link to post
Share on other sites
quote:
Original post by The_Minister

Kylotan, modules are the way to go. Develop each part of your game separately and individualy, and join them together with the final game code when you finish them. While developing them, test them completely.

That way, no module ever gets too big, and if one module is starting to become truly massive, break it down into smaller modules.


I wish it were that easy. My game is split into
142 source files (including 66 header files). Generally, it is 1 class = 1 source file + 1 header file, but some smaller classes are grouped together. Nearly all of my game data structures are STL containers of pointers to objects. Now, the main problem here, is that in order to use a container of pointers to type XYZ, that file needs the entire class definition of XYZ. It shouldn''t , but this is a template implementation limitation / STL bug. So, a lot of source files include headers that they shouldn''t need to, just so it will compile without errors.

Secondly, about 3 or 4 of these classes are so integral to the system, that nearly everything needs to include the header file. And these classes get added to on a fairly regular basis: it''s not bad design - it''s just iterative design If I wish to add a feature, generally one of the main 3 or 4 classes needs to get altered, which will result in having to recompile 60-80% of the code.

It isn''t a ''normal'' game where you could separate out a SoundFX module, a Music module, a GameWorld module, and so on. This is a text-based multiuser game which doesn''t lend itself too well to modularisation. It''s kind of hard to explain any better than that, since obviously any design can be well encapsulated, it''s just that this kind of program revolves around several important classes which change as the design progresses. (The game will never be ''finished'', it''s always in a state of evolution).
0

Share this post


Link to post
Share on other sites
Kylotan:
quote:

Now, the main problem here, is that in order to use a container of pointers to type XYZ, that file needs the entire class definition of XYZ. It shouldn''t , but this is a template implementation limitation / STL bug. So, a lot of source files include headers that they shouldn''t need to, just so it will compile without errors.



What version of STL & compiler are you using? I always used forward declarations when I''m storing pointers in a container, and I''ve never had any problems. I normally use STLport, but I''ve just tried it with the default VC6 STL at it works fine. Borland''s compiler & STL also have no problems with it.
0

Share this post


Link to post
Share on other sites
quote:

My whole project is now about 150.000 lines of code, about 1000 files and it re genereates an exe from scratch (compile,link with resouces add) in about 1 (ONE) second on a P2/400 computer



That''s great, but with incremental linking I only generally need to recompile one file when I''m going to run it, which means that I can compile and run my stuff in about 1 second, as well.

Besides, I actually like the wait between compiles. It gives me time to think about what I''m going to do next and what I should perhaps change.

quote:

dont forget its all about SPEED in games....(think at AI, GFX)



Speed is actually one of the lesser things on the list of importance. Obviously, you don''t want to write bloated software, but you should always put robustness, maintainability, and functionality first.

quote:

today most "optimized" compilers only make about 100% up to 300% slower programs then ASM



Can you actually back that up with some proof? I''ve never seen anything near the stats you''re mentioning.

quote:

If the OOP ONLY disadvantages are (you say):
=============================================
1.slow
2.ineficient

and let me add:
=================
3. complicated



It''s only more complicated if you can''t design properly. OOP code is almost always simpler if it''s designed right, and generally much more robust (stable) as well.

quote:

Yes there are advantages to OOP but those are more likely to be used in database visual programming rather then fast games.



Are you kidding? Games are almost the perfect domain for object oriented programming. You''re creating worlds which contain, you guessed it, a lot of objects.

quote:

I just wanted to kindly say: take care OOP can ruin your game speed...and generated a flame...ooops...not my intention...but if u want i can give you more arguments....just dont think i have to...



Once again, can you actually back up that statement?

quote:

Yes ASM is much simpler than OOP
and OOP is very complex compared to ASM...



Assembly is simpler in that there is less to learn, but programming wise, it isn''t "easier". OOP is very simple in most respects. Which parts of OOP do you find to be "complex"?

quote:

I am not against OOP...just against too much OOP in games in every position...



You should always be consistent in your design. If you''re using different programming methodologies all over your source, it''s a sign of poor design.

quote:

I will just like to use my P3 like a P3 and not like a 286 because of slow OOP and people''s urge to finish a project faster with less work...



First off, that''s a giant exageration. OOP doesn''t kill that much speed (and if you want to argue that point, at least give some numbers from real projects to prove that, not just "well in my experience"). Second, what''s wrong with wanting to finish a project faster with less work? The quicker you can get something out, the better. If you want to spend fiveyears on a project in ASM only to have it dated by the time you release it, fine, but I''d much rather keep up with everyone else.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Wilka

What version of STL & compiler are you using?


MSVC5, with supplied Dinkumware STL, all publicly available STL patches applied. No service pack applied to MSVC5, since it doesn''t work on the ''cheap'' version.

quote:
I always used forward declarations when I''m storing pointers in a container, and I''ve never had any problems.


It gags on the destructors, because there is no explicit destructor defined for user-defined pointer types (ie. there is no MyType*::~MyType*() {} ). Errors in the destroy function in <xmemory> if my memory serves me correctly.

There are supposedly some workarounds available, including doing your own specialisation of the destroy function, etc etc, but I never found enough info on how to do that.

quote:
I normally use STLport, but I''ve just tried it with the default VC6 STL at it works fine. Borland''s compiler & STL also have no problems with it.


I can''t use STLPort, since my compiler chokes with a "Too many nested #IFDEFs" error. Probably because it''s the ''standard'' edition rather than one of the Big Money editions.

Borland C++ Builder 4 has exactly the same problem with the pointers in containers, as I tried it there with the same results. I don''t remember if I tried it with v5 or not.

Apparently it''s a common problem, since 1 or 2 STL sites have described it, and either suggested the explicit instantiation workaround, or the more fascist answer "don''t use pointers in containers: they''re not designed for it".
0

Share this post


Link to post
Share on other sites
quote:
Original post by SiCrane

Well, when you come to the cloaked ship issue, there are a couple of ways to approach it. The first is to say that a cloaked ship is a special kind of ship. Another is to say a cloaked ship is a ship that has a cloaking device. So the choice becomes encapsulate or inherit.



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. The CModification class would look somewhat like this:

class CModification
{
private:
char* name = NULL; // the name of the modification (for engineering
// displays and menus and such
public:
// constructor takes the name of the modification
CModification(const char* newname)
{
name=new char[strlen(newname)];
Initialise();
}

~CModification()
{
delete name;
Destroy(owner);
}
virtual void Initialise();
virtual void Destroy();
virtual void AllocatePower(int amount);
virtual void Activate(bool activation = true);
}


You would then have in the CShip class an array like this:
*CModification modifications[MAX_MODS];
and you could assign elements of this array to classes which inherit from CModification, and implement the pure virtual methods.

PS. What is this design pattern called? I see it often in Java games and the like.



''Smile, things could get worse.''
So I smiled, and they did.


sharewaregames.20m.com

0

Share this post


Link to post
Share on other sites
You''ve a got a virtual function call in the constructor for CModification, it works in Java but it''s a no-no in C++. I realise it''s not real code cos there''s a few other things that won''t work, but virtual functions in ctor/dtor can lead to nasty bugs so I thought I''d mention it.
0

Share this post


Link to post
Share on other sites
what about calling a super class''s virtual destructor from a subclass?

like

  
class foo
{
protected:
virtual ~foo() {};
};

class subfoo: public foo
{
public:
~subfoo(){ foo::~foo(); }
};




~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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:

what about calling a super class''s virtual destructor from a subclass?



In that bit of code you posted, you''re not calling the function virtually so the function call is safe. But the fact that you''re calling the function isn''t safe. The destructor of base class is automatically at the end of the derived class dtor, so you''re calling it twice here which could make very bad things happen.
0

Share this post


Link to post
Share on other sites