hi - i want to program a tetris-like full-screen game on a mac which runs on MacOS9 and X - my question (specially to the ambrosia-people): what programming language shall i choose...
<strong>hi - i want to program a tetris-like full-screen game on a mac which runs on MacOS9 and X - my question (specially to the ambrosia-people): what programming language shall i choose...
thx.
krassy</strong><hr></blockquote>
Your best choices are:
C++ - Blech
Java - Better
Objective-C - Even better
C++ can suck it, Java is nice but slow, and Objective-C is simply wonderful. Although if you wanted to be really cool you'd program your game in C for the term.
Objective C won't allow him to run it under Mac OS 9 though, right? Isn't that what Cocoa programs are written in?
I guess you'd have to write you app for Mac OS 9 and make it carbon so it will run in OS X too.
I hate the way Java runs. I haven't seen a decent client side application run well in Java yet. Example: LimeWire. yuck. I'd only use Java for server side components and that sort of thing. But thats just me.
<strong>hi - i want to program a tetris-like full-screen game on a mac which runs on MacOS9 and X - my question (specially to the ambrosia-people): what programming language shall i choose...</strong><hr></blockquote>
Go for straight C. For such a simple application there just isn't any reason to put up with the hassle of OOP.
<strong> How is OOP a hassle?In my experience it is a lot easier to code in OO style than procedurally.Code is much better organized and concise.</strong><hr></blockquote>
For large applications perhaps. But for anything with less than 20,000 lines or so I have found that procedural code is much easier to write, debug, and understand... especially for new programmers. Just pound it out and don't worry about designing objects with proper access methods, don't worry about reusability, data abstraction, inter-object communication, etc. By avoiding objects the programmer also resists the temptation to add every possible "cool" method that he can think of for "future expansion", even if they have no use. Objects also tend to be written in a more general manner, solving problems that don't need to be solved, making trade-offs that may not be relevant to the problem or objective at hand. But the main problem with OOP is that it is extremely difficult to write an application without careful planning beforehand. Need to add a few variables to a data structure? With an object it requires a complete rewrite of much of the object, or a new subclass. With procedures you simply add it and reference it where needed. It is much easier to just sit down and write a procedural program, which is what most hobbyists want to do. There is just so much complexity in setting up an OO design that in this case it should probably be avoided.
<strong>I cringe whenever someone brings something to me over a couple hundred lines that isn't done OOP. It's a lot easier to debug when the bug is already somewhat corralled, not to mention integrate into anything else</strong><hr></blockquote>
Sure, but any project that has more than one programmer usually needs some pretty strict quidelines and established coding style to begin with. For joint efforts, OOP by its very nature enforces a stricter style than procedural, and in that environment it can be a useful tool. However I was advocating the procedural style for hobbyists who are more interested in immediate results and enjoyment than anything else. I know for a fact that I enjoyed programming in BASIC on my Apple II and Mac 512Ke far more than I enjoy writing Cocoa apps on X.
But for anything with less than 20,000 lines or so I have found that procedural code is much easier to write, debug, and understand... especially for new programmers.
<hr></blockquote>
Good OOP design can cut those 20,000 lines of code to a couple thousand.OOP is actually a more natural way of thinking-your primary concern in what you are doing rather than how you are doing it,and as far as complicated inheritance structures are concerned,you can just use a very flat inheritance hierarchy,either inheriting directly from the root,or one of the built in classes.
<strong>Good OOP design can cut those 20,000 lines of code to a couple thousand.</strong><hr></blockquote>
How? The same routines are still needed, plus accessor methods and extra code for communication. If anything (in the absence of a really great OO framework like Cocoa, of course) OOP produces larger (albeit compartmentalized) programs. Being object oriented doesn't magically eliminate the need for algorithmic implementation. I will admit that a well written OO program can be shorter than a poorly written procedural one, but again we are speaking in the context of a novice programmer writing his first game.
[quote]<strong>OOP is actually a more natural way of thinking-your primary concern in what you are doing rather than how you are doing it</strong><hr></blockquote>
I must disagree with that, but perhaps it is just my way of thinking. Procedural programming is far more natural and goal oriented. Start at the beginning and write to the end, and when a procedure is needed... write it. You are always focused on the final product. OOP by its very nature forces the programmer to think of each little data structure as its own program, completely separate from the overall project. The same algorithms must be designed and written, but in procedural code they are fitted into the grand scheme immediately and in a state of flux. In OOP they are beaten to death with extraneous methods and implementation details before they can even be utilized by the main program.
thank you all for your interesting comments. i have no problems writing OOP code - if i would choose C++ - where can i get my knowledge about using OpenGL and sound-implementation? the only apps i have written by now have simple text input and output. all additional goodies (graphics, sound) are very, very new for me...
<strong>where can i get my knowledge about using OpenGL and sound-implementation? the only apps i have written by now have simple text input and output. all additional goodies (graphics, sound) are very, very new for me...</strong><hr></blockquote>
Are you familiar with event-driven and general mac programming? If not, <a href="http://www.mactech.com/macintosh-c/"; target="_blank">this pdf series</a> should help you out. (Be forewarned, it is well over 1000 pages!)
Good luck... it's not as easy as it sounds! Start by reading the first few chapters of the Macintosh C series to get a basic overview of what programming on the Mac entails. If all you've done is some console apps then there is much to learn.
<strong>Are you familiar with event-driven and general mac programming? If not, <a href="http://www.mactech.com/macintosh-c/"; target="_blank">this pdf series</a> should help you out. (Be forewarned, it is well over 1000 pages!)
</strong><hr></blockquote>
wow. seems to be very much what i've to learn. have you heard of the o'reilly book (Learning Carbon)? if so - is it a good read? but i think the macintosh c is a must, right? ...
have you learned all that already yourself? or just parts of it? anyway - i have 2 month to learn this stuff - hope that is enough.
<strong>wow. seems to be very much what i've to learn. have you heard of the o'reilly book (Learning Carbon)? if so - is it a good read? but i think the macintosh c is a must, right? ... </strong><hr></blockquote>
I've never read the o'reilly book, but I've heard that "Macintosh C" is better. (Never read it either). I can't comment on which would be better for a new programmer though.
[quote]<strong>have you learned all that already yourself? or just parts of it? anyway - i have 2 month to learn this stuff - hope that is enough.</strong><hr></blockquote>
Um... well, I've been programming on the Mac for nearly 15 years. To be honest with you I don't remember how I started learning the toolbox, and I certainly don't have it memorized. OpenGL is pretty simple though, and I normally don't need the Redbook handy (oh yeah, if you want to program with OpenGL, pick up a copy of the Redbook.) If you're a very hard worker and truly love programming then I think 2 months is possible, but perhaps a less ambitious project would be better.
If you want to give it a shot, you should probably find some source for a Mac game and try to understand what it is doing. Visit <a href="http://www.idevgames.com/"; target="_blank">iDevGames</a> and look in their source archive for some decent code. Most of it seems to require Project Builder, so if you don't have that just download it from Apple.
If you want to give it a shot, you should probably find some source for a Mac game and try to understand what it is doing. Visit <a href="http://www.idevgames.com/"; target="_blank">iDevGames</a> and look in their source archive for some decent code. Most of it seems to require Project Builder, so if you don't have that just download it from Apple.</strong><hr></blockquote>
Comments
<strong>hi - i want to program a tetris-like full-screen game on a mac which runs on MacOS9 and X - my question (specially to the ambrosia-people): what programming language shall i choose...
thx.
krassy</strong><hr></blockquote>
Your best choices are:
C++ - Blech
Java - Better
Objective-C - Even better
C++ can suck it, Java is nice but slow, and Objective-C is simply wonderful. Although if you wanted to be really cool you'd program your game in C for the term.
-DisgruntledQS733Owner
I guess you'd have to write you app for Mac OS 9 and make it carbon so it will run in OS X too.
I hate the way Java runs. I haven't seen a decent client side application run well in Java yet. Example: LimeWire. yuck. I'd only use Java for server side components and that sort of thing. But thats just me.
<strong>hi - i want to program a tetris-like full-screen game on a mac which runs on MacOS9 and X - my question (specially to the ambrosia-people): what programming language shall i choose...</strong><hr></blockquote>
Go for straight C. For such a simple application there just isn't any reason to put up with the hassle of OOP.
If you know OpenGL then things become even easier. Use <a href="http://developer.apple.com/samplecode/Sample_Code/Graphics_3D/Carbon_SetupGL.htm"; target="_blank">SetupGL</a> to get your context and switch to fullscreen, load all of your sprites as textures, draw them onto quads and move 'em around!
<strong>Objective C won't allow him to run it under Mac OS 9 though, right? Isn't that what Cocoa programs are written in?</strong><hr></blockquote>
Wait, you're saying there's a version of Mac OS that people should be using previous to X?
-DisgruntledQS733Owner
Im learning at the moment, so if anyone knows any RB forums, point'em out
For such a simple application there just isn't any reason to put up with the hassle of OOP.
<hr></blockquote>
How is OOP a hassle?In my experience it is a lot easier to code in OO style than procedurally.Code is much better organized and concise.
<strong> How is OOP a hassle?In my experience it is a lot easier to code in OO style than procedurally.Code is much better organized and concise.</strong><hr></blockquote>
For large applications perhaps. But for anything with less than 20,000 lines or so I have found that procedural code is much easier to write, debug, and understand... especially for new programmers. Just pound it out and don't worry about designing objects with proper access methods, don't worry about reusability, data abstraction, inter-object communication, etc. By avoiding objects the programmer also resists the temptation to add every possible "cool" method that he can think of for "future expansion", even if they have no use. Objects also tend to be written in a more general manner, solving problems that don't need to be solved, making trade-offs that may not be relevant to the problem or objective at hand. But the main problem with OOP is that it is extremely difficult to write an application without careful planning beforehand. Need to add a few variables to a data structure? With an object it requires a complete rewrite of much of the object, or a new subclass. With procedures you simply add it and reference it where needed. It is much easier to just sit down and write a procedural program, which is what most hobbyists want to do. There is just so much complexity in setting up an OO design that in this case it should probably be avoided.
<strong>I cringe whenever someone brings something to me over a couple hundred lines that isn't done OOP. It's a lot easier to debug when the bug is already somewhat corralled, not to mention integrate into anything else</strong><hr></blockquote>
Sure, but any project that has more than one programmer usually needs some pretty strict quidelines and established coding style to begin with. For joint efforts, OOP by its very nature enforces a stricter style than procedural, and in that environment it can be a useful tool. However I was advocating the procedural style for hobbyists who are more interested in immediate results and enjoyment than anything else. I know for a fact that I enjoyed programming in BASIC on my Apple II and Mac 512Ke far more than I enjoy writing Cocoa apps on X.
But for anything with less than 20,000 lines or so I have found that procedural code is much easier to write, debug, and understand... especially for new programmers.
<hr></blockquote>
Good OOP design can cut those 20,000 lines of code to a couple thousand.OOP is actually a more natural way of thinking-your primary concern in what you are doing rather than how you are doing it,and as far as complicated inheritance structures are concerned,you can just use a very flat inheritance hierarchy,either inheriting directly from the root,or one of the built in classes.
<strong>Good OOP design can cut those 20,000 lines of code to a couple thousand.</strong><hr></blockquote>
How? The same routines are still needed, plus accessor methods and extra code for communication. If anything (in the absence of a really great OO framework like Cocoa, of course) OOP produces larger (albeit compartmentalized) programs. Being object oriented doesn't magically eliminate the need for algorithmic implementation. I will admit that a well written OO program can be shorter than a poorly written procedural one, but again we are speaking in the context of a novice programmer writing his first game.
[quote]<strong>OOP is actually a more natural way of thinking-your primary concern in what you are doing rather than how you are doing it</strong><hr></blockquote>
I must disagree with that, but perhaps it is just my way of thinking. Procedural programming is far more natural and goal oriented. Start at the beginning and write to the end, and when a procedure is needed... write it. You are always focused on the final product. OOP by its very nature forces the programmer to think of each little data structure as its own program, completely separate from the overall project. The same algorithms must be designed and written, but in procedural code they are fitted into the grand scheme immediately and in a state of flux. In OOP they are beaten to death with extraneous methods and implementation details before they can even be utilized by the main program.
thx. krassy.
<strong>where can i get my knowledge about using OpenGL and sound-implementation? the only apps i have written by now have simple text input and output. all additional goodies (graphics, sound) are very, very new for me...</strong><hr></blockquote>
Are you familiar with event-driven and general mac programming? If not, <a href="http://www.mactech.com/macintosh-c/"; target="_blank">this pdf series</a> should help you out. (Be forewarned, it is well over 1000 pages!)
In addition to the SetupGL code linked in my first post, look at NeHe's <a href="http://nehe.gamedev.net/"; target="_blank">OpenGL tutorials.</a> They include Mac source code, if you scroll down to the bottom of the tutorial page. Sound demo code is available at <a href="http://developer.apple.com/samplecode/Sample_Code/Sound.htm"; target="_blank">Apple's site</a>, and documentation for the sound manager is <a href="http://developer.apple.com/techpubs/quicktime/qtdevdocs/INMAC/SOUND/imsoundmgr.htm"; target="_blank">also available.</a>
The entire <a href="http://developer.apple.com/techpubs/macosx/Carbon/carbon.html"; target="_blank">carbon API</a> is available on Apple's site as well.
Good luck... it's not as easy as it sounds! Start by reading the first few chapters of the Macintosh C series to get a basic overview of what programming on the Mac entails. If all you've done is some console apps then there is much to learn.
<strong>Are you familiar with event-driven and general mac programming? If not, <a href="http://www.mactech.com/macintosh-c/"; target="_blank">this pdf series</a> should help you out. (Be forewarned, it is well over 1000 pages!)
</strong><hr></blockquote>
wow. seems to be very much what i've to learn. have you heard of the o'reilly book (Learning Carbon)? if so - is it a good read? but i think the macintosh c is a must, right? ...
have you learned all that already yourself? or just parts of it? anyway - i have 2 month to learn this stuff - hope that is enough.
greets,
krassy
<strong>wow. seems to be very much what i've to learn. have you heard of the o'reilly book (Learning Carbon)? if so - is it a good read? but i think the macintosh c is a must, right? ... </strong><hr></blockquote>
I've never read the o'reilly book, but I've heard that "Macintosh C" is better. (Never read it either). I can't comment on which would be better for a new programmer though.
[quote]<strong>have you learned all that already yourself? or just parts of it? anyway - i have 2 month to learn this stuff - hope that is enough.</strong><hr></blockquote>
Um... well, I've been programming on the Mac for nearly 15 years. To be honest with you I don't remember how I started learning the toolbox, and I certainly don't have it memorized. OpenGL is pretty simple though, and I normally don't need the Redbook handy (oh yeah, if you want to program with OpenGL, pick up a copy of the Redbook.) If you're a very hard worker and truly love programming then I think 2 months is possible, but perhaps a less ambitious project would be better.
If you want to give it a shot, you should probably find some source for a Mac game and try to understand what it is doing. Visit <a href="http://www.idevgames.com/"; target="_blank">iDevGames</a> and look in their source archive for some decent code. Most of it seems to require Project Builder, so if you don't have that just download it from Apple.
<strong>
If you want to give it a shot, you should probably find some source for a Mac game and try to understand what it is doing. Visit <a href="http://www.idevgames.com/"; target="_blank">iDevGames</a> and look in their source archive for some decent code. Most of it seems to require Project Builder, so if you don't have that just download it from Apple.</strong><hr></blockquote>
thank you very much, fluffy....
[ 03-11-2002: Message edited by: alcimedes ]</p>