Next Project

[Carlos Camacho]

As it stands, (http://inkubator.idevgames.com/index.php?option=com_poll&task=results&id=2)

A Side Scroller game is the next project for Inkubator. In 2nd place is the Lemmings game.

Since we want to provide not only good code, but thorough docs/tutorials, I think that a shooter would indeed be a good project. Better yet, I already have the draft models for a killer side-scroller, which I have been keeping for a rainy day. :) (hopefully they are not lost.)

So, I would like to open discussions and a side-scroller. We can start at zero, or look to one of the uDG games for code.

Ideally, I would like the project to work something like this.

Chapter 1
Creating the display/viewport/setting resolution and other pre-game setups.
Also, perhaps discuss the basic concepts of the game loop.

Chapter 2
How to create a scrolling background
* explain the pros/cons of one large map vs tiles, etc.
* loading the background
* insuring flicker-free scrolling
* scrolling the screen in various directions

Chapter 3
Sprites
* drawing a sprite to the screen (the player)
* moving the player
* moving the missisle/laser/bomb

Chapter 4
Bad guys
* Storing bad guys movement patterns or using some sort of AI/algo.
* Collision detection

Chapter 5
* Creating levels
* Adding score

Chapter 6
Working with sound and music


Anyhow, the above is a QUICK draft. The idea is to set the Chapters in a logical progression, and set the objectives for each chapter. Each chapter builds on what is learned. So we have a project for each chapter, and of course the main project for the final game.

One consideration is this. This shoot'em has a defined game doc, and lesson plan (the above), etc. However, people may form study groups based on a certain technology...

Group 1
Using OpenGL to accomplish each chapter

Group 2
Using SDL to accomplish each chapter

Each "mentor" or shall I say the "key mentors" select which technologies they will use. We try not to get too much overlap, so that every study group offers something unqiue. I think this would be very powerful. Example: Someone comes here and often says, should I use Carbon, or Cocoa/which system for drawing/ and so on and so on. In the future, we can refer these people like this, "if you want to learn mac game dev with Cocoa and OpenGL, check out Group 3's files. The other advantage I could see is that it doesn't shut out any mentors. What I mean is, some mentors may prefer a certain set of APIs, etc. If we say, ONLY use this and that, then we might lose those mentors. Anyhow, I think you get my arguments.

Again, let me be clear in that the next project will be a game, that is distinct, and any study group will need to follow the design docs and lesson plans.

I'm interested to here comments on the above. Also, I would like to wrap up the decision to indeed go with a side-scroller. We need to of course start thinking of what type of game it will be.

Last but not least. Hooptie still could use work. So I would really like to see some interest in updating it, and documenting the process of creating it, as I did with the lesson plan approach.

Cheers,

[OneSadCookie]

That might be a logical chapter ordering in terms of dependencies, but it would be a very boring tutorial to read. Chapter 1 would be very very long, and you'd have nothing to show at the end.

Instead I think it would be better to break it down into a long series of very much smaller steps, starting with getting something playable (very basic window set up, very basic drawing, very basic keyboard handling).

As to doing this with several APIs, there's really only one drawing API on the Mac (OpenGL), so that just leaves which of Carbon and Cocoa to use for the windowing and events. Perhaps there's scope there to show both paths, but I wouldn't stress about it. Either will be as good as the other.

Last, without leadership this project will stagnate as it has done since Mark Pazolli left. Unless someone else is willing to provide that level of drive and commitment, we might as well just call the whole inkubator project a failure and try some other approach to mentoring.

[Carlos Camacho]

Yes, that is good advice. I am hoping that hytma can play a strong role in this. But if he just wants to code, etc.. Then I nominate OSC. Who better?

Small steps sounds good. Anyone else have a comment on which way?

[Josh]

IIRC, last time Keith was nominated he turned it down because of the usual "no time" thing.

[Duane]

Yes! Side Scroller has overcome the evil Lemmings!

What the :billgates: is that, anyway?

excuse the bad language...

[flipflop]

What I mean is, some mentors may prefer a certain set of APIs, etc. If we say, ONLY use this and that, then we might lose those mentors. Anyhow, I think you get my arguments.

This could make the project a LOT more complex. I can see creating a simple plug-in architecture for the rendering engine so one group could use Open GL while another group uses SDL or Cocoa / Carbon API's. This way the game logic, enemy AI, etc... would be the same no matter what rendering engine is used.

Again, let me be clear in that the next project will be a game, that is distinct, and any study group will need to follow the design docs and lesson plans.

Do you mean the lesson plan should be done first before the shot'em up game is started? Or would the lesson plan be worked on in parallel with the game development?

I do have some more comments... but we are leaving the office and I will have to continue a little later.


P.S. Please excuse my poor spelling skills... I'm on a windows box with out a spell checker handy. :p

[Feanor]

I would like to try to help out with this. Now that school is over and done with, I might be able to find three or four hours per week to contribute. That's not very much but I suppose if I can set aside that time regularly it will keep the project alive.

My specialty is Cocoa but I know OpenGL (somewhere between beginner and intermediate), have lots of interest in AI, and can certainly learn something about sound. I've wanted to do an Inkubator project for a long time now.

So I just need to know if we're still hosting on SourceForge or what's what.

So who's the art director? Carlos?

-B

[Carlos Camacho]

Art Director? Hmmm... I suppose if I want the game to look great. I better start helping out. So, sure, I can work on graphics assets.

>Or would the lesson plan be worked on in parallel with the game development?
Depends on what OSC says ;)

based on my teaching experience, you want to create the lesson plan before teaching it to the students. ;) So they can be worked on at the same time, but ideally you want to make sure it is peered reviewed by mentors before the masses get it.

Cheers

[Feanor]

So it's a question of module-by-module or iterative development. I agree that iterative is way more fun. Start with a bit of everything, and add complexity in layers. But there is a contradiction. If teaching is the primary objective, it's (arguably) best to have a completed program and then design an iterative re-creation. Alternately, by creating the game "live", the student gets to see the real development process, warts and all, which is also valuable.

I think we might want to sketch out a slightly different cycle, with an initial game which has simple scrolling graphics and a "hero" icon that has no animation and just floats around, then we add simple sound, then enemies, then death and multiple lives, weapons (if required), more sound effects, etc., etc. Basically start with a useless do-nothing side-scroller and grow it up into a mature kick-ass one.

But a game without content is utterly useless even when starting at zero, so maybe we need some kind of rough backgrounds and boxy or otherwise simple geometric stand-in tiles and entity images that can be animated even at the most basic level, just to see something. It doesn't matter if it looks like ass as long as it serves as a template.

[cloke]

I'd be interested in helping with a scroller. My area of expertise is is C++ and Carbon. I've actually been working on a side scroller for a few years, but with very little art work I've been looking for other projects to contribute too. My OpenGL knowledge is very limited as my game used primarily core graphics, but I'm sure I could get up to speed pretty quickly.

Also, if the game uses tiles rather than a large background file another cool thing would be to create some sort of game editor. It could be a basic point and click map editor. Rather than creating an editor in C/C++/Cocoa it might be cool do use something like AppleScript Studio (I have a ton of expertise in this area) just to show another simple coding language.

[kelvin]

so... as is my understanding, inkubator is not an actual code project, just a collaborative effort? In which case, each project can be built with different tools or libraries?

If this is the case, I might want to volunteer some of my new CocoaGranite code for people to build on. As it stands right now, CocoaGranite isn't as functional as CocoaBlitz, but the lowerlevel OpenGL stuff is pretty snappy.

[Duane]

you might want to take the poll down, carlos.

[hytmal]

So when do we start? ^_^

-- hytmal

[Carlos Camacho]

Poll is down.

[aarku]

My proposal for the side-scroller is as follows:

1. Utilize SpriteWorld as the main engine to handle the game. It would be in charge of drawing graphics, through OpenGL, and sound/music through SWSounds. I have a new SpriteWorld demo that shows off setting up things "the correct way" for Mac OS X and also shows that it is possible to draw using regular ole OpenGL commands instead of built-in SpriteWorld drawing procedures. Combine SpriteWorld with something like glAArg and the results are awesome. :-D

SpriteWorld should be updated to 3.0.1 soon, which will make things a lot smoother for beginners using XCode and may even have a binary installer for those who want it. Remember, SpriteWorld has supported pretty much every IDE, and XCode is just the latest one to be officially added.

2. Use Squirrel Physics Kit by Scott Lembcke for the physics engine. I have successfully knit it together with SpriteWorld and glAArg, and the results are stunning.

3. Update the Amelio Game Input Library and squash its few bugs. This site, iDevGames, used to host Amelio. It seems to have faded away, however Amelio is a great tool for those who want awesome yet simple input management using HID in their game. I think a new Inkubator project would be perfect time to ressurect it. Gamepad support is something that would be cool in a game like this, and possibly even adding Force Feedback to Amelio.

4. Use existing loosely licensed Open Source libraries and kits for the Mac and just STRENGTHEN them rather than go and reinvent something. It'll be worth it. These things I mentioned were practically designed for a sidescroller!

In summary, use these kits/libraries:

SpriteWorld 3.0.1
Squirrel Physics Kit
glAArg
Amelio Game Input Library

This would offer TONS of flexibility, great speed, and would help contribute back to existing projects and show beginners how to tie these all together! This combination seems steely strong to me.

-Jon

[arekkusu]

"knit it together"? Anything sharable? :)

[aarku]

"knit it together"? Anything sharable? :)

I'll put together a demo showing glAArg, SpriteWorld, and SPK working together to show what I mean.

-Jon

[arekkusu]

Gr¸vy.

[Carlos Camacho]

If we hosted Amelio Game Input Library, which was made by calum, if I am correct, I should (or someone should) still have it. Of course, when our download section goes back online, I will host it.

I like how aarku has put forth his ideas for kits/libraries. I would hope others with a difference of opinion, on what should be used will offer their alternatives, as well as the reasons for "why." If we get a few different suggestions, then we can put it to a poll.

[hytmal]

Since Carlos is asking, I'll put forward my ideas for the supporting engine(s) for the game.
Obviously, OpenGL is my choice (this glAArg thing looks pretty nifty, IMO...). For input, I am a fan of using Carbon events, though I have no experience with the Amelio library. i am also interested in trying out OpenAL for sound. if anyone has some experience with these technologies, let me know. As for the physics engine, Squirrel sounds good to me, the only other physics engine i can name off the top of my head is Havok, but obviously that's a little over-complex for our project.
Basically, what i am aiming at, in terms of technologies, is to try to teach novice programmers things that can help them in other fields -- in this case using Carbon events instead of Amelio and staying away from 3rd-party graphics libraries.

well, that's just my two cents.
also -- i'm opening two new threads as per carlos's request, one on the state of Hooptie (killing the last few bugs, getting some more screenshots, etc) and one concerning features for the new project.

-- hytmal

[PowerMacX]

OpenAL is very easy to use. I made a simple C++ wrapper class for playing 3D positional sounds with it in just 10 minutes. Will this project use C/C++ or Obj-C?

The only thing that needs attention (http://www.createmacgames.org/forum/viewtopic.php?t=311) is how to bundle the OpenAL framework on the finished app :blush: .

I'll upload my source code to my site (see below) in a couple days, it's not ready for human eyes yet...

[cloke]

I agree with hytmal using Carbon events would be better than an external library. I would prefer to see as many built-in functions of the OS used rather than an external library. Using carbon events would not only be useful for other games, but it would give users a better idea on how to use them in other applications.

Techs that I would like to see used:
HID Manager
At least a branch of the event code using carbon events.
Just using Carbon in general as it seems lately carbon demo code is hard to come by.
OpenAl - Looks like Apple will be pushing this tech in 10.4.
Quicktime - Since it looks like this is a 2D game, the data formats for graphics could be any QT supported format. Would allow users to use a wide variety of graphic types for content creation.
AppleScript Studio- I mentioned this before, but utilizing this in a level editor would be cool. I've been able to achieve some pretty cool stuff with it.

I guess I would like to see as much Apple technology used as possible rather than general/portable libraries.

[PowerMacX]

Finally! My OpenAL wrapper C++ class is now available at:

http://www28.brinkster.com/ignacio3d/downloads.html

Scroll down to FailedSrc.zip (no, the code works... long story ;) )

The class is "SoundFX3D", and is pretty similar to my old SoundFX class (it used SDL_Mixer).

To start up OpenAL:

SoundFX3D::Init();

To load a sound:

SoundFX3D *mySound = new SoundFX3D("mySound.wav");

To play it:

mySound->Play();

To set the sound position:

mySound->SetPos(3.0f,5.0f,2.0f); // x,y,z

or, if you want doppler fx calculated,

SoundFX3D::SetTimeObject(myTimeObject); // Only once, inits SoundFX3D global timer system
mySound->MoveTo(3.0f,5.0f,2.0f); // x,y,z

To shutdown OpenAL:

SoundFX3D::Shutdown();

Easy, right?

[geezusfreeek]

This is getting off track.

We are steering this too much toward the technical side. The first goal should be to determine what exactly the project is, shouldn't it? The second goal should be to work out exactly what needs to be done for it. After all that, then we should talk about APIs and frameworks and stuff.

[blobbo]

Also, at this point, this project is useless to those who can't even possibly imagine what OpenAL is... Keep it simple! Do a tiny little game that's easy to understand, and do it well.

[PowerMacX]

This is getting off track.

We are steering this too much toward the technical side. The first goal should be to determine what exactly the project is, shouldn't it?

I thought that it was already decided to do a Side Scroller game (http://inkubator.idevgames.com/inde...sk=results&id=2)

Also, my post was motivated by:

I like how aarku has put forth his ideas for kits/libraries. I would hope others with a difference of opinion, on what should be used will offer their alternatives, as well as the reasons for "why." If we get a few different suggestions, then we can put it to a poll.

Maybe this thread should be split in Inkubator project APIs, Inkubator project storyline, Inkubator project graphics, or something like that?

[PowerMacX]

- Knock-knock
- Who's there?
- Nobody
:blink:

[arekkusu]

I'll put together a demo showing glAArg, SpriteWorld, and SPK working together to show what I mean.

Any update? I see a pic on your site, no download.

[aarku]

Any update? I see a pic on your site, no download.

I'll have one up in 13 hours. . . left iBook with me girl. . :blush:

-Jon

[aarku]

http://www.tc.umn.edu/~czec0035/files/SWSPKglAArg.tar.gz

-Jon

yeah that's an acronym: SpriteWorld Squirrel Physics Kit OpenGL Anti-Aliased Rendering Glue or something

[arekkusu]

All right! Your gravity seems a bit, err, upside down though. ;)

[aarku]

All right! Your gravity seems a bit, err, upside down though. ;)

Yeah I'd have to modify SPK's terrain collider so you can define the terrain "solid" to be either positive or negative. I'm having a hell of a time understanding some of the code though. Note: in general. . . endless M a b x II variable names lead to unreadable code. In my opinion, going nuts with longVariableNames is a good thing in the long run.

-Jon

[Skorche]

Sweet another project that is using SPK. Score! :)

Yeah, you're right about the naming thing. For the longest time I knew C, but had never really done anything with it. SPK was my first project that started to get more than a few hundred lines, and even though it's still fairly small, I had huge naming problems myself.

I'm trying to rewrite it in C++, so that should force me to clean it up.

NOTE:
aarku IMed me while writing this post. It's already sorted out. Never got around to commenting that part, could barely figure it out myself.