Language considerations

[diordna]

The current tally with regards to knowledge is as follows.
C - 6
C++ - 5
Java - 5
Obj-C - 3
Ruby - 3
Python - 2

Does anyone have any serious objections to using C and Chipmunk Physics? We have a number of people well-versed in both, so this is an excellent opportunity to both create an engine that experienced coders understand and that could be used to teach the less experienced. Anyone who codes but does not know C could learn it if copious comments were used.

[wyrmmage]

that's what I would vote for...I'm also very interested to see what a large-scale C project will look like, since I use C++ for big projects :)
-wyrmmage

(are we going to use SDL, GLUT, or code our own interface through Carbon or Cocoa?)

[diordna]

(are we going to use SDL, GLUT, or code our own interface through Carbon or Cocoa?)
That's Joseph's decision, I hope he'll find this topic. I'll point him at it.

[BeyondCloister]

are we going to use SDL, GLUT, or code our own interface through Carbon or Cocoa?

I mentioned this in one of the many threads but I think it is worth repeating here.

Is one of the aims of the project to have something that can be commercially released? If it is then are there not issues with some of the above not being up to the job? I seem to remember mention that SDL and GLUT both are not up to that task.

[Joseph Duchesne]

SDL certainly is up to the task for commercially released software, however a cocoa interface would make more sense for better integration with the Mac OS.

As much as I don't like ObjC, I have a feeling that a C main() function called from an ObjC events wrapper and window/fullscreen handler would be much better for the project in the end.

This is primarily because SDL has difficulty switching between fullscreen and windowed, and adding normal GUI (for startup options for example) isn't built in, we'd be working in Cocoa for that anyway.

I would also like to suggest that Carbon isn't a good idea? Do I have any objections? It's a technology that seems to be on its way out the door. Cocoa is the replacement.

[Blacktiger]

How about using ruby to script parts, and doing the rest of the code in c++? We could use ruby native (http://www.gaffer.org/archives/ruby-native-2).
Edit: Or we could use the ruby cocoa bridge if we went with objective-c.

[AnotherJake]

SDL certainly is up to the task for commercially released software, however a cocoa interface would make more sense for better integration with the Mac OS.

As much as I don't like ObjC, I have a feeling that a C main() function called from an ObjC events wrapper and window/fullscreen handler would be much better for the project in the end.

This is primarily because SDL has difficulty switching between fullscreen and windowed, and adding normal GUI (for startup options for example) isn't built in, we'd be working in Cocoa for that anyway.

I would also like to suggest that Carbon isn't a good idea? Do I have any objections? It's a technology that seems to be on its way out the door. Cocoa is the replacement.
I completely agree that Carbon would be a complete waste of time.

SDL would be okay except it does give up some Macness and there are a few minor functionality issues as you mentioned. Although I should note that I am not entirely opposed to going the SDL route either -- it just wouldn't be my first choice for this project.

Coding a Cocoa base for a C project really isn't very hard at all. As you said, it would merely need to handle events and full screen, but also the animation timers. But that's about it. The rest of the project can be purely C beyond that. As I've done in my own projects, I would suggest having the Cocoa base call the C stuff via three functions: Init(), Update(), and Draw(). You can implement a thin layer of glue code to call back into the Cocoa base for any needed services beyond that, although that isn't usually needed in my experience.

Oh yeah, and GLUT is NOT a good idea for this project.

[Joseph Duchesne]

The problem with ruby is that the majority of those interested in programming in this project do not know it, and thus I think it would be a serious setback to use it as the primary language for the game mechanics.

I am open to the possibility of using it as a scripting language for in game events (item collisions etc). In my opinion it is a must to have a scripting language for such things in a modern game.

The decision for which scripting language we will use will be made later. Likely choices seem to be Ruby and Lua. (Everyone here seems to like Ruby, or want to learn it, so that's probably our best bet)

Edit: I didn't see jakes message. I agree with everything you said and your experience with this model will be valuable.

[ThemsAllTook]

Core game code in C with a Cocoa GUI layer sounds great to me. Maybe we could even use Keith's GameShell (http://www.onesadcookie.com/trac/browser/GameShell)?

[AnotherJake]

Core game code in C with a Cocoa GUI layer sounds great to me. Maybe we could even use Keith's GameShell (http://www.onesadcookie.com/trac/browser/GameShell)?
Yeah, that should work just fine.