nv89-nun@dront.nada.kth.se (Nicklas Ungman) (04/16/91)
There are many different languages to programm in. Some are imperative (like Asm and C), some are declarative (like Prolog). And some are object oriented, like C++, Simula and Eiffel. Each type of language has advantages and disadvantages. But for games, I think that the object oriented approach is the best. The advantages of object oriented languages is many, but the most important is Modularity and Resusability of Code. What makes them so great for games is how consider the data and the code. In object oriented programming you modulate objects which consist of both data and code tied together as an entity. You form these objects very much like reality. This lets the game designer focus on game design, not on programming. After all, many components in a computer game are often objects or entities. One disadvantage of object oriented programming is speed. The overhead is a few percents and can be cruisal in some action games. But in many cases the advantage is greater (I've experimenting with and Asteroids- like game in Object Pascal on Macintosh so I know it works). I also hope for better compilers in the future (many C++ compilers are actually pre-compilers) /My $0.47 /Nixxon
beust@mimosa.unice.fr (Cedric Beust) (04/16/91)
In article <NV89-NUN.91Apr16020559@dront.nada.kth.se>, nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: >Each type of language has advantages and disadvantages. But for games, I think >that the object oriented approach is the best. Mmmh... Yes and no. As you say below, this can be a very expensive price to pay for pure arcade games. I can hardly imagine Psygnosis games written in something else than ASM. But it is always possible to write most of the game in C++ and write critical parts in ASM. The real question for me is "Is there any interest in reusability for games?". Isn't there a risk to see bunches of clones invade the market, that are just different by the colors chosen and their titles? Of course, companies re-use part of their code previously written when they develop a new game, but would it be a large gain if these portions were written in C++ instead of just being simply callable ASM functions? NOTE: I like OOP, and I like ASM as well. I'm just trying to open the debate. +------------------------------------------------------------------------+ | Cedric BEUST University of Nice | | INET: beust@mimosa.unice.fr $whoami | | UUCP: llaor.unice.fr!arkonis!beust god (personal alias) | | -- "To be, or not to be...", | | That is illogical, captain! | | -- Spock | +------------------------------------------------------------------------+
nv89-nun@dront.nada.kth.se (Nicklas Ungman) (04/17/91)
In article <67@taloa.unice.fr> beust@mimosa.unice.fr (Cedric Beust) writes: The real question for me is "Is there any interest in reusability for games?". Isn't there a risk to see bunches of clones invade the market, that are just different by the colors chosen and their titles? Of course, companies re-use part of their code previously written when they develop a new game, but would it be a large gain if these portions were written in C++ instead of just being simply callable ASM functions? In this article I write: One advantage of reusability is developing time. The reusability is easier to achive in OOP, but for games I think the gain is minimal. Another advantage of reusability is Interface Consistence. In MacApp you can program a text editor with menus, dialogs, windows etc. in less than hundred lines of code. All you have to think about is what your program should do, and MacApp takes care of the interface. This is an advantage also in games, but not as much as in Word Processors, Paint Apps etc. What makes OOP so suitable for games is the view of life. You can create objects and send messages to them, and they can send messages to other objects if they want to. These messages can be any form of action (eg. shoot, hit, talk, run etc.). When an object sends messags to other object these actions become interactions. And interaction is VERY important in games (interaction actually separates games from other forms of media). And the best thing is that objects inherit beheivior of their super classes and hence get many attributes automaticly. Another thing is that if everybody could hack up a perfect Asteroids game in a couple of hundreds of lines of code, we would be spared from all these lousy games that some people make, and even sell for too high prices! (I'm not accusing anyone, 'cause I don't know that you'we made one :-) +------------------------------------------------------------------------+ | Cedric BEUST University of Nice | | INET: beust@mimosa.unice.fr $whoami | | UUCP: llaor.unice.fr!arkonis!beust god (personal alias) | | -- "To be, or not to be...", | | That is illogical, captain! | | -- Spock | +------------------------------------------------------------------------+ /Nixxon
soh@shiva.trl.oz (kam hung soh) (04/17/91)
beust@mimosa.unice.fr (Cedric Beust) writes: > Mmmh... Yes and no. As you say below, this can be a very expensive price >to pay for pure arcade games. I can hardly imagine Psygnosis games written >in something else than ASM. But it is always possible to write most of >the game in C++ and write critical parts in ASM. That is a sensible approach. Writing any major program involves a lot of money and / or time, and there is no reason to write in assembly unless there is an advantage. > The real question for me is "Is there any interest in reusability for >games?". Isn't there a risk to see bunches of clones invade the market, that >are just different by the colors chosen and their titles? Reusable code does not necessarily mean that cloning is any easier. Unless the source code for a program is available, there is no AUTOMATED way of generating a duplicate (short of copying). > Of course, companies re-use part of their code previously written when >they develop a new game, but would it be a large gain if these portions >were written in C++ instead of just being simply callable ASM functions? That is a long drawn argument that erupts once in a while in various comp.lang.* groups. My impression is that a purely functional paradigm is often not sufficient to abstract essential features of a tool. While the algorithms for manipulating say, a list, are usually fixed, the callable functions you've described will have to be rewritten for different types of lists. Regards, ------------- Soh, Kam Hung email: h.soh@trl.oz.au tel: +61 03 541 6403 Telecom Research Laboratories, P.O. Box 249, Clayton, Victoria 3168, Australia
comeau@ditka.Chicago.COM (Greg Comeau) (04/18/91)
In article <NV89-NUN.91Apr16020559@dront.nada.kth.se> nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: >The advantages of object oriented languages is many, but the most important is >Modularity and Resusability of Code. What makes them so great for games is how >consider the data and the code. I don't know much about game technology, but I do agree with your statement. Individuals must be shown examples of it though. I know for myself, I had scorned both C++ and OOP before I got involved with it because at the time I didn't have the time to sit with it for even a few seconds and hence was an opponent since "I was a good C programmer" and what did I need this "hyped garbage" for. >In object oriented programming you modulate objects which consist of both >data and code tied together as an entity. You form these objects very much >like reality. This lets the game designer focus on game design, not on >programming. After all, many components in a computer game are often objects >or entities. I wouldn't go so far as to say that one doesn't have to not be concerned with the programming. One *does* have to beinvolved with that aspect. However, what it offers is that the focus in the right places can be more intense and proper. >One disadvantage of object oriented programming is speed. The overhead >is a few percents and can be cruisal in some action games. But in many >cases the advantage is greater (I've experimenting with and Asteroids- >like game in Object Pascal on Macintosh so I know it works). That is NOT a disadvantage of OOP. That is a disadvantage of some OOP/OOL implementations which is a totally different story. In the case of something like C++, it has been proven time and time again that C++ is no more in/efficient as C is. >I also hope for better compilers in the future (many C++ compilers are >actually pre-compilers) You imply translating compilers (not pre-compilers) != better compiler. The truth of the matter is that something like AT&T cfront, which Comeau C++, is based on, is the most robust C++ compiler technology around. And it's up-to-date too. I don't want to sound rude, but I don't see the merit in that analogy. If you meant that you want to see a nice C++ environment, then, yes, I drool for it myself, but I think that a different issue than what you mentioned. - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
comeau@ditka.Chicago.COM (Greg Comeau) (04/20/91)
In article <67@taloa.unice.fr> beust@mimosa.unice.fr writes: >In article <NV89-NUN.91Apr16020559@dront.nada.kth.se>, nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: > >>Each type of language has advantages and disadvantages. But for games, I think >>that the object oriented approach is the best. > > Mmmh... Yes and no. As you say below, this can be a very expensive price >to pay for pure arcade games. I can hardly imagine Psygnosis games written >in something else than ASM. But it is always possible to write most of >the game in C++ and write critical parts in ASM. True, C++ is on average as in/efficient as C is. > The real question for me is "Is there any interest in reusability for >games?". Isn't there a risk to see bunches of clones invade the market, that >are just different by the colors chosen and their titles? Well, reuse is only one part of the C++ formula. There are slews of other advantages to be gained, even if reusability is dommed for a specific project. (For instance, strong typing, encapsultation, data hiding, inheritance, etc). > Of course, companies re-use part of their code previously written when >they develop a new game, but would it be a large gain if these portions >were written in C++ instead of just being simply callable ASM functions? Certainly is ASM speed is needed it's the only choice. If it's not, then C++, as well as other languages, are viable choices. - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
davidm@uunet.UU.NET (David S. Masterson) (04/20/91)
>>>>> On 18 Apr 91 15:25:05 GMT, comeau@ditka.Chicago.COM (Greg Comeau) said: Greg> In article <NV89-NUN.91Apr16020559@dront.nada.kth.se> Greg> nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: Nicklas> I also hope for better compilers in the future (many C++ compilers Nicklas> are actually pre-compilers) Greg> You imply translating compilers (not pre-compilers) != better compiler. Greg> The truth of the matter is that something like AT&T cfront, which Comeau Greg> C++, is based on, is the most robust C++ compiler technology around. Greg> And it's up-to-date too. I don't want to sound rude, but I don't see Greg> the merit in that analogy. If you meant that you want to see a nice C++ Greg> environment, then, yes, I drool for it myself, but I think that a Greg> different issue than what you mentioned. On that different issue, though, from what I've seen, there are generally two reasons that a C++ to object file compiler is preferred over a C++ to C compiler. I'd like your comments on the two: 1. Optimization. C compilers *may* not have the knowledge to optimize out some of the things a C++ compiler might leave lying around (outlined inlines?). This is one of the reasons for NewCode Technologies CBACK program. 2. Debugger support. Debugging translated C++ code is very difficult because of name mangling and (often) lack of C++ source (the debugger shows C code). -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
dege@cs.umn.edu (Dege Jeffrey Charles) (04/20/91)
In <CIMSHOP!DAVIDM.91Apr19131513@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>>>>> On 18 Apr 91 15:25:05 GMT, comeau@ditka.Chicago.COM (Greg Comeau) said: >On that different issue, though, from what I've seen, there are generally two >reasons that a C++ to object file compiler is preferred over a C++ to C >compiler. I'd like your comments on the two: >1. Optimization. ... >2. Debugger support. ... And here I thought the biggest gain would be in compile time. I see no fundamental reason why a C++->C translator would produce poorer code than a C++->object compiler. I also see no fundamental reason why a C++->C translator could not be used in a source-level debugger (It's all a matter of where the debugging info gets put and who puts it there.) The increased compile time involved in scanning and parsing the code twice, though, cannot be removed. (I know, so buy a faster machine... ;) ---------------------
nv89-nun@dront.nada.kth.se (Nicklas Ungman) (04/22/91)
In article <37046@ditka.Chicago.COM> comeau@ditka.Chicago.COM (Greg Comeau) writes: In article <NV89-NUN.91Apr16020559@dront.nada.kth.se> nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: >In object oriented programming you modulate objects which consist of both >data and code tied together as an entity. You form these objects very much >like reality. This lets the game designer focus on game design, not on >programming. After all, many components in a computer game are often objects >or entities. I wouldn't go so far as to say that one doesn't have to not be concerned with the programming. One *does* have to beinvolved with that aspect. However, what it offers is that the focus in the right places can be more intense and proper. What I mean is that with OOP the game design is implemented (almost) in the way it is designed, and the game designer doesn't have to be a hacker (although there's nothing wrong about that). It's like the director who must concentrate on directing, not on acting or film-shooting, although a good director must know about these things. >I also hope for better compilers in the future (many C++ compilers are >actually pre-compilers) You imply translating compilers (not pre-compilers) != better compiler. The truth of the matter is that something like AT&T cfront, which Comeau C++, is based on, is the most robust C++ compiler technology around. And it's up-to-date too. I don't want to sound rude, but I don't see the merit in that analogy. If you meant that you want to see a nice C++ environment, then, yes, I drool for it myself, but I think that a different issue than what you mentioned. I imply better compilers in general, not just C++ but eg. Eiffel compilers. I didn't mean pre-compilers are bad, but I think with real compilers, its easier to do things like optimization and debugger support. And compile time is also usually twice with a translating compiler (A friend of mine took an Eiffel course, and the Eiffel->C translator was up to eight (8) pass). I also want better enviroments. I currently use THINK Pascal and think it's superior to most systems around (all I've seen). It has a built in symbolic debugger, intelligent Make (which the user dont even notice), and an interactive editor, all integrated in one application. - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310 /Nixxon
comeau@ditka.Chicago.COM (Greg Comeau) (04/23/91)
In article <CIMSHOP!DAVIDM.91Apr19131513@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>>>>> On 18 Apr 91 15:25:05 GMT, comeau@ditka.Chicago.COM (Greg Comeau) said: > >Greg> In article <NV89-NUN.91Apr16020559@dront.nada.kth.se> >Greg> nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: > >Nicklas> I also hope for better compilers in the future (many C++ compilers >Nicklas> are actually pre-compilers) > >Greg> You imply translating compilers (not pre-compilers) != better compiler. >Greg> The truth of the matter is that something like AT&T cfront, which Comeau >Greg> C++, is based on, is the most robust C++ compiler technology around. >Greg> And it's up-to-date too. I don't want to sound rude, but I don't see >Greg> the merit in that analogy. If you meant that you want to see a nice C++ >Greg> environment, then, yes, I drool for it myself, but I think that a >Greg> different issue than what you mentioned. > >On that different issue, though, from what I've seen, there are generally two >reasons that a C++ to object file compiler is preferred over a C++ to C >compiler. I'd like your comments on the two: Sure, no problem. >1. Optimization. C compilers *may* not have the knowledge to optimize out >some of the things a C++ compiler might leave lying around (outlined >inlines?). This is one of the reasons for NewCode Technologies CBACK program. As I believe I've mentioned here before, the issue of optimization is not a thing that in inherently a problem with generating C object code vs native object code. Either way has it's nuances as well as quirks in implementation. On average: the difference is not noticable across a series of applications. As to CBACK, yes, that has the potential for improving things (and we are currently in the process of evaluating it's usefulness), nevertheless, the significance of it is just as strong as an extra step or two of optimization of C code that is only done with an extra command line switch of two. Hence, all we've got in the same C situation in C++, regardless of whether C object code is being generated or direct object code is being generated. >2. Debugger support. Debugging translated C++ code is very difficult because >of name mangling and (often) lack of C++ source (the debugger shows C code). Again, there is nothing inherent in C++ prohibiting debugging (again, whether a C object code generator or a direct object code generator is being used). The lack of C++ source has never been a problem in a single port of Comeau C++ we've done and we've done quite a number at this point. I have heard of other implementations suffering this fate, and without trying to be rude, those vendors obviously did not know what was going on and/or didn't care and/or something. As to name mangling, I addresses this in another message a day or two ago (I will readdress it if it needs to be). - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310