community project + contest idea

[hytmal]

hi all...

I've been toying around with the idea of combining a community project that would help novices with a game design contest. given that inkubator is currently kind of defunct, i think it would be reasonable to start up a project in which we create a very bare bones game engine*. the contest portion would be that people would have to use the engine we created in their games.

i mentioned the idea to carlos, and he seemed to think it was a pretty good idea, as did the people on the irc channel. though (as should be expected) specific implementation details are still very debatable.

the idea behind the creation of an engine (and not just the contest) would that it would allow people who are new to game development (but not programming) to get into it, and would also allow them to create a complete game without having to muck around in all the minutae. I know others have released their personal engines before, but i think their respective codebases aren't nearly as useful for the community, because they're either poorly documented (or written! *gasp!*), or they are too end-product-specific.

anyway, let me know what you think! :-)


-- david


* note that by "bare bones", i mean that the engine should support
- importing images (and using them as textures/static images etc)
- importing and using sounds
- basic sprite animation
- basic physics modelling (collision detection algorithms, particles, etc)
- basic 2D graphics

[Carlos Camacho]

As I said to you, I would support this initiative as it helps me/us on several fronts:

1) Gives the community a contest to fill the void of uDevGames. This would allow be to shift uDevGames to start in early summer (i.e. June), while using this yearly contest to fill up the Fall community schedule.

2) It allows for a way to re-start Inkubator -- the concept was commendable, however without a strong leader, Inkubator couldn't be sustained. In a way, this contest can become the "new" Inkubator. (i.e. The Inkubator Contest - Helping to Hatch New Games)

3) Provides a means to help beginners, which I am always in favor.

I could see such a contest being in-between a 21 Days Later and uDevGames event. Perhaps two months is ideal, start to finish. Along with under six sponsors.

Methinks the most difficult part is having developers agree on the "engine." As some of you know, such a topic was brought up in our iDG Book discussions. If such a framework/engine could be completed, then it could help in that endeavor as well.

Cheers,

[Duane]

I vote it to be in C, as not to offend anyone, and in either GLUT or SDL, because they are so much simpler then Carbon. I'm talking about OpenGL, of course :p

[BeyondCloister]

I vote it to be in C, as not to offend anyone, and in either GLUT or SDL, because they are so much simpler then Carbon.

This also has the added benefit of being cross platform which is not a bad thing.

[Duane]

I agree, though I beleve it should be centered on mac instead of being crossplatform. That's whole 'nother topic.

[hytmal]

I'm going to agree with the mac-only-ness. though i'm not a ~professional~ mac game programmer, i think it would be good for newbies to have a complete piece of "bare-bones "* code that demonstrates the correct way to design and implement image importing with quicktime (or whatever we using), carbon events, and structuring the OpenGL graphical bits of the engine.

anyway, that's just my $0.02.

-- david

* sorry to overuse the phrase, but i kind of envisioned the engine as an alternative to learning from apple's sample code (which is ANYTHING BUT minimalistic, unfortunately).

[hytmal]

ok, uhm to actually RESPOND to the GLUT post, I don't think that bulding an engine around GLUT (which IS already an engine in its own regard) would be nearly as educational to the newbie programmer as one built around Quicktime, Carbon events, etc would be.

-- david

[unknown]

Why does it need to be educational to a newbie?
There will be ways anyone can get involved aside from understanding the entire engines code.
GLUT is an OpenGL utility toolkit not a game engine, for the game engine to use glut would be fine.

[ThemsAllTook]

GLUT isn't really suitable for production code. We should build this around something more solid. I'm sure I'll have people loudly disagree with me, but my suggestion would be Cocoa internally, with a public C API. If we'd do it right, it would still be possible for it to be cross-platform; we'd just have to write a separate implementation for each platform. However, we wouldn't have to worry about that right off the bat, other than in the design of the public API.

- Alex Diener

[BinarySpike]

To much talk about GLUT lately :sneaky:

From GLUT alot of my initial problems learning OpenGL spawned (not to mention some event code)

I say GLUT is a memory garbling cross-platfrom shmo.


to the main subject though.
1) Gives the community a contest to fill the void of uDevGames. This would allow be to shift uDevGames to start in early summer (i.e. June), while using this yearly contest to fill up the Fall community schedule.


The idea is very good.
The main reason behind me not entering udev this year is because of the gap.

[Duane]

ok, uhm to actually RESPOND to the GLUT post, I don't think that bulding an engine around GLUT (which IS already an engine in its own regard) would be nearly as educational to the newbie programmer as one built around Quicktime, Carbon events, etc would be.

I don't knwo about everyone else, but when I started, I took one look at carbon and ran screaming. I don't think it's really appropriate for "newbies". If not GLUT, SDL (which I was leaning toward in the first place).

[hytmal]

i've done most of my stuff in GLUT, too. I really don't think that Carbon is THAT hard... at least it wouldn't be if there were some decent examples out there. that's one of the points of the community-developed engine.

the engine should be developed by people who already know what they are doing, and be an example of the "right thing to do". why would we want an engine created by people who don't know what they're doing? :-)

re: GLUT, i'm going to agree with BinaraySpike. i think it's great for prototyping, but AFAIK, Carbon is a lot better structured and a lot more efficient, performance-wise.

-- david

[ss2 cire]

I agree with Alex on this one, Cocoa would be nice, with a public C API, I could possibly help with the Cocoa part because I already use it and it's easy to understand (mostly)

just my opinion :)
Eric

[Duane]

so in other words, we could reinvent SDL and GLUT :p both of them use Cocoa internally.
I think it's decided that we're NOT using GLUT, how about we concentrate more of what's gonna be in the engine, instead of what it uses.

[hytmal]

ok, nayr, go ahead :-)

seriously though, what do we want to see in terms of features provided by this engine?

keep in mind that nothing should be too type/genre specific. i think the biggest question that comes to mind is whether it will be just 2D, or allow people to go 3D as well...

other than that i'd say that we should force the developer into one image format and one audio format. i have no idea what are good choices for these, given that the end result has to be open source. i usually go with PNG for image assets, myself.

anyway, back to packing. i'm moving back up to school tomorrow :-)

-- david
(LET'S GO STATE)

[ThemsAllTook]

other than that i'd say that we should force the developer into one image format and one audio format. i have no idea what are good choices for these, given that the end result has to be open source. i usually go with PNG for image assets, myself.

I heartily suggest PNG and Ogg Vorbis. Also allowing JPEG images might be a good idea, because there are some situations where it's more suitable than PNG. If there's any reason to allow uncompressed audio, go with AIFF.

- Alex Diener

[OneSadCookie]

If we're writing a Mac-only engine, there'd be no reason not to use QuickTime or ImageIO for loading images (and therefore get support for everything under the sun), and AudioFile for loading sounds (and therefore get support for a very wide range of compressed and uncompressed audio formats).

If it's to be cross-platform, then I'd suggest using the http://freeimage.sourceforge.net/ FreeImage library -- it's a lot easier to use than either libpng or libjpeg in isolation, and it supports a few more formats, too.

[AnotherJake]

I agree with ThemsAllTook.

I'm starting to wonder why I even bother to question the value of PNG/JPEG vs. Quicktime (and whatever universal loader lib you might have). The PNG/JPEG combo seems to have all the answers. Virtually all software nowadays handles both of those formats without much trouble, and it's just a killer combo for all the stuff I've tried over the years. I think the primary path should be PNG/JPEG, but Quicktime is easy to include in a very small amount of code as well, so it can be added for robustness alongside.

Also, I second the "ditch GLUT/SDL/ExistingLib" idea. It just isn't all that difficult for many of us here to code a nice backend using Cocoa, and have far more flexibility and power because of it.

And more, for audio there should be four formats available. WAV, AIFF, Ogg Vorbis, and MP3. MP3 can only be made available through Quicktime because of licensing, but it is a convenient format for most people. WAV and AIFF are great for short sounds like gunshots since compressing them is usually a futile effort because of their shortness, and they're easy to export from all existing software (not recommended for music tracks of course). Ogg Vorbis is *the* way to go for music tracks, like MP3 is, except it's licensing fee free.

The best all-around combo IMHO is PNG/JPG/Ogg Vorbis for media, with a Cocoa backend to interface with OS X and a C public API for the engine. The only thing that I might suggest should be offered in two flavors would be a math library - one version in C and one version in C++ might be handy.

Other than that, the only thing I would shout out is, "Less is more!". Keep it simple. Maybe a project like this should be capped at 10k lines of code? I know many people would argue with that statement, but beginners have a tendency not to be able to easily consume mass amounts of code early on. OTOH, it could also be developed as a "black-box" library with no code cap and no remorse, just presenting simple functionality, but the underside could be wild and wooly.

Whatever, just some ideas from the Friday night pint. :wacko:

[Oblivion]

This is a sad day, my first post and guess what? I disagree with everyone out there ...

We do not need to write just another (simplier or not) support library, API, Engine or the like but rather create knowledge.
Let me explain: if I use a library/Engine which automatically handles and hides everything I will almost certainly learn nothing. Why don't we build a set of libraries, one for each aspect of game programming USING our beloved os instead of external resources? I mean, if I ask you:
How do I perform sound mixing with CoreAudio?
How do I Poll a Joystick with HID Manager?
I Fear that even Apple could not answer these questions, given the documentation available. Now, If we can build a CoreAudio Sound Mixer, a CoreAudio streamer, a HID Manager joystick reader, a CoreGraphics blitter, ... keeping them simple, separate and documented, the true beginner would have a really nice reference, sample code and a fully functional set of libraries. Need something more advanced? You have the code, go On.

Best regards,
Claudio "Oblivion" Russo

[hytmal]

I agree with most of what you say, Oblivion. However, I think that if we combine the elements you mentioned into one product, that it would be really great, and really show newbies how to correctly structure their OWN engines in their future projects. if all we give them is good sample code, well then they have that, but they still have a lot of work to do, to put it all together. i still think your idea is a very good one, i'll say that.

to everyone else, the idea here is that people should be able to actually look at the source code! so no black boxes! that would defeat the purpose, really.

i'd say the only reason the above wouldn't work in the end is that we want to be able to base a contest off of this, and therefore we need to give people a whole base to work from, not just a bunch of disconnected parts.

-- david

[Nick]

I'm a little late coming, but I love this idea.

Let me try and resurrect this thread because I'd like to see this happen. I can do some Objective-C (Cocoa) as well as C. I'm learning tons of stuff and know basic OpenGL (and some not so basic) techniques. Is that what we're going to use? I'd figure as much.

Personally I think a project like this would be the best for new comers. Even I, having only made games using Cocoa with Interface Builder, still have a basic view on engines, how they are structured, and how they do what they do.

As far as file types, why limit it? I think OSC has a point that if it's based on Cocoa (therefore relies on Mac OS X) let's just use Quicktime and such to get lots of file types. Sure everyone should use PNG or JPG for pretty much everything, but that's no excuse to make them use them.

I'm willing to help out if this project ever gets off the ground. Just let me know. I'm logged onto AIM 95% of the day so you can leave me a message there. Or email. Or post here. Or PM. :)

[ferum]

why not just write it in c with openGL and openAL ? aren't SDL and GLUT and all the rest of those just shortcuts?
i really want to get into making games but i have no clue how to.
even psuedo code would help me a ton. it would show me what i need to learn.
EDIT: never mind, now that I am learning openGL i realize that GLUT would definately be needed. :)

[ferum]

Is this going anywhere or is the idea dead?

[ardam the third]

What about for people who can't do programing and all that stuff?

[DoG]

This kinda project is doomed because there is no way in hell you can get more than 3 people to agree on anything. I tried myself. It can only work if somebody just starts it, and hopefully other people join in if they like what they see.

[Nick]

Maybe instead of trying to write the über-community-engine, maybe some people could set up a poll and decide on a specific game to make. Then go for it. Have some people take charge and others will join. Start with maybe a sidescroller. I remember that the Inkubator project was about to do a sidescroller when I first started at this forum, but that never took off either.

[OneSadCookie]

The Hooptie project is proof that very few people will contribute any worthwhile amount of help... Mark Pazolli ended up doing 90+% of the programming, and DaFalcon ended up doing 90+% of the art... and neither of them were the target audience for the project.

My advice is, if you want to do something, do it. If you want help, ask... but don't expect to receive any :p