Proposed Changes

[Kjurtyl]

Hooptie: The Story Thus Far

I've made some changes than enter in conflict, specifically in the controller.

Previously, we've had a Quartz Extreme Check that was buggy and kept making < 10.2 computers crash. Therefore, I replaced it with a Quartz Extreme Warning that unfortunately makes no actual check to see if QE is on or off but does at least warn that it should definitely be turned on.

The other item is how the music muting works. I've made it so once music is muted, all pieces are affected because I really couldn't fathom why we should make exceptions without offering a new option to mute the rest of it. I concluded that putting in two mute settings for music: one for in-game and one for "important" was a little strange and decided against it. However, I realized that having to wait for the HooptieDied music to end when it's muted was a bit ridiculous. I changed that aspect so that if music is muted, the wait is no longer than a few seconds instead of the full length of the piece.

Now, since these changes are conflicting with previously established code, we'll have to decide which ones work best for what we want to achieve.

I think we have little choice about QE; it's either we check for it and raise the requirements to 10.2 or we just warn about it which may irritate some people who already have it activated. I'd rather live with the latter than the former.

With these changes in place however, it would settle all outstanding issues with Hooptie proper and all that would be left is the Editor which I am currently looking into. I'll discuss that later.

- Kjurtyl.

[Chris Burkhardt]

> I'd rather live with the latter than the former.

I agree, 10.2 is expensive.

[igame3d]

Originally posted by Chris Burkhardt
> I agree, 10.2 is expensive.

A moot point since 10.3 is due within months.

If you are going to build an editor, I think you should revive this project, so long dormant, with a Cocoa tutorial on how to build and code it, step by step. It would teach Cocoa while getting your editor built.

I've been waiting for my Cocoa Programming book for like 7 months, and all the tutorials on the web are for useless applications. I'd like to learn something practical, like a level editor!

[Josh]

I'm confused. Why not just check the OS version?

[DaFalcon]

There are a ... few ... editors floating around out there for Hooptie.

I just want to see Hooptie released :-) I don't care how :-) :lol:

[Kjurtyl]

A moot point since 10.3 is due within months.

I don't see how that makes it a moot point for people sticking with 10.1. The upgrade pricing from 10.1 all the way to 10.3 has not been released and might certainly end up being just as if not more expensive.

If you are going to build an editor,

I am not. Although I said I would mention it later, I guess this is indeed later.

There are a ... few ... editors floating around out there for Hooptie.

I am aware of that fact. Indeed I have two on my hard drive that I am looking at to see how they can be merged into an actually functional level editor.

I'm confused. Why not just check the OS version?

I did, then it wouldn't compile because I am not on 10.2, presumably someone with 10.2 could have compiled those changes and sent it back to see if that worked for 10.1. I didn't try that. The point is the following, are we gonna go with checks or warnings, knowing that checks have to be fixed later potentially breaking 10.1 compatibility and that warnings can be done now?

I just want to see Hooptie released :-) I don't care how :-)

I too, but I do care a little tiny bit how.

- Kjurtyl.

[Carlos Camacho]

I need a re-fresher.

Hooptie is based on Quartz. QE is a must to run the game? I didn't know that. If QE isn't on, how is performance (ie screen draws)? Is the game playable? If it is indeed very playable, then it would be my hope that the game can run on at least OS 10.1. If the game is a too slow on non-QE systems, then I understand why you went with QE-required.

I can't answer your question, but my advice is to code it so that the game works well on future OS updates. We need to teach good programming methods with Hooptie, rather than trying to find the quick solution. This is especially true because people new to Cocoa or game dev will use Hooptie to learn from and we want them to learn good methods.

As for music, my question is... Is the the music just ear-candy or does it play an important part of the game. For example, does a certain piece get played when the ultimate bad-guy is about to appear and kill you for sure? If so, turning off all music affects the gamer's play, doesn't it? Can a visual method of providing "warnings" be used so that if all music is off, the gamer can still enjoy it? Not sure here because it has been so long since I played Hooptie. Most games have a toggle for SFX and BGM only.

A functional level editor would be very good for the masses. While the goal of the project is to help game devs, I see having an easy to use editor as a great way to get more people to enjoy the game, and perhaps hook a few into learning Cocoa.

It would have been really nice to have Hooptie in two versions for learning purposes, Quartz and OpenGL based. But that is a mute point now, though perhaps someone will try to bring a OpenGL version out at some point.

As for tutorial. I think once the game has all outstanding issues addressed and the code pretty much set, then it will be time to write up tutorials. No since writing something if after the first release you find a major bug.

Unless I am wrong, Mark is very busy these days and Kjurtyl is the person who seems to have taken up the torch. Thus my feeling is, if he takes up the torch, then let's allow him to get Hooptie ready for the masses.

Please disregard anything from above that makes no sense. It is 9:15am in Japan and I just walk into work... and it is Monday and my body hurts all over from playing soccer yesterday.

Cheers

[Feanor]

Hooptie should not care in the slightest whether Quartz Extreme is present. Hooptie should be written (and as far as I know, is written) to run on Mac OS X 10.1 or later, being that it uses only only pure Cocoa classes. Moreover, it should work fine on 10.0 (and probably an executable compiled on 10.1 will run on 10.0 and vice versa). Or did I miss something along the way?

[Kjurtyl]

QE is a must to run the game?

No. But it was established to be much better performing with it.

If QE isn't on, how is performance (ie screen draws)? Is the game playable?

Yes.

[...]why you went with QE-required.

I did not. Mark inserted a check for QE, let me re-emphasize what that means: In the source code, there is some code that checks whether or not QE is on and *suggests* that it should be for performance reasons. Now that code once compiled as is makes 10.1 computers crash because 10.1 doesn't recognize QE.

Allow me to reiterate, the problem isn't one of requiring QE or not, it is with code that makes non-QE capable computers crash. We also have the problem of the source code itself refusing to compile on 10.1 which is what I am experiencing. So in short, I might be able to fix the bug, but I won't be able to compile the fix.

We need to teach good programming methods with Hooptie, rather than trying to find the quick solution.

The proper way would most likely be to have it check for QE with all sorts of fancy version checking, however, I won't be able to compile that even if it's done right. Therefore anyone trying to compile the source on 10.1 will also hit a few blocks.

As for music, my question is... Is the the music just ear-candy or does it play an important part of the game. [...] If so, turning off all music affects the gamer's play, doesn't it? Can a visual method of providing "warnings" be used so that if all music is off, the gamer can still enjoy it? Not sure here because it has been so long since I played Hooptie. Most games have a toggle for SFX and BGM only.


There is no music that when turned off will hamper the player's experience. Right now we have a toggle for SFX and Music but Mark had transformed it to SFX and BGM which left some music playing all the time - that was the part that annoyed me personally. I thought we didn't have enough music throughout to justify such fanciness and that including three toggles, SFX, BGM and Other Music was just a little too convoluted for 4 music pieces.

Hooptie should not care in the slightest whether Quartz Extreme is present.

I agree, but it does today because it checks whether its there or not.

Hooptie should be written (and as far as I know, is written) to run on Mac OS X 10.1 or later, being that it uses only only pure Cocoa classes.

It is. Except for the Check, as I've said which is exclusively something > 10.1.

Or did I miss something along the way?

Maybe you did, maybe I wasn't clear enough.

I understand everybody's concerns, but the issue is a lot simpler than it seems. Before asking anything else, make sure you've read the replies and that it wasn't clearly answered already.

- Kjurtyl.

[Chris Burkhardt]

Kjurtyl, I think the QE check should be done away with. That way it will both run and compile on 10.1 AND 10.2, and anybody with QE disabled in 10.2 has it like that for a reason and I'm sure they know turning it on might help the performance of a game -- nobody likes a game telling them what to do. Just add to the ReadMe "Runs better with Quartz Extreme enabled" or something.

Thanks for all your work,

[OneSadCookie]

It seems an absurd thing to check for -- it's not like a user can do anything about it (other than upgrade either the OS or their hardware), so why nag them about it?

[Josh]

Originally posted by OneSadCookie
It seems an absurd thing to check for -- it's not like a user can do anything about it (other than upgrade either the OS or their hardware), so why nag them about it? Correct. Besides, it would be easy enough to check the OS version and if the user has Mac OS X 10.2 or higher THEN check to see if QE is enabled or maybe just say "Hey, QE really makes the game faster" or something.

[Kjurtyl]

Good, I see a consensus forming around what I planned to do. It shall be done.

Please realize that I've asked everyone's opinion because the check was already present in the code and my change basically goes against what another developer thought was best. This way I feel more justified in doing what I am about to, instead of feeling like I am slighting someone else's point of view without prior consultation.

Level Editor discussion is forthcoming, look for a new thread soon.

Patience, patience!

- Kjurtyl.

[Pazolli]

Originally posted by Kjurtyl
Hooptie: The Story Thus Far

I've made some changes than enter in conflict, specifically in the controller.

Previously, we've had a Quartz Extreme Check that was buggy and kept making < 10.2 computers crash. Therefore, I replaced it with a Quartz Extreme Warning that unfortunately makes no actual check to see if QE is on or off but does at least warn that it should definitely be turned on.


If you look in the CVS the Quartz Extreme Check has already been commented out and I have no objection to any reminents of it being removed. Use "cvs update" on your code and CVS will produced a merged version of the code which you can then adjust in a suitable manner to get the final version which you can commit using "cvs commit".


The other item is how the music muting works. I've made it so once music is muted, all pieces are affected because I really couldn't fathom why we should make exceptions without offering a new option to mute the rest of it. I concluded that putting in two mute settings for music: one for in-game and one for "important" was a little strange and decided against it. However, I realized that having to wait for the HooptieDied music to end when it's muted was a bit ridiculous. I changed that aspect so that if music is muted, the wait is no longer than a few seconds instead of the full length of the piece.


I feel Hooptie really gets a boost from having those lesser music pieces playing and also doesn't suffer the performance hit that the in-game music causes. But I agree that the muting at the moment is a bit confusing. If you were really adventurous you could maybe move muting to the preferences dialog and have a pop-up with three options: "All sounds and music", "All sounds and some music" or "No music". But I don't think it's something we've got to be intensely focused on at the moment because there are still other things that need to be done for Hooptie. A few more game elements, for example, might be nice. We can always change these things later.

Oh and one last thing, 4 weeks ago I submitted a patch that allowed music to play with QuickTime 6, this involved commenting out the MusicPlayerPreroll() function. If the MusicPlayerPreroll() function is not left out some pieces won't play on some Macs.


Now, since these changes are conflicting with previously established code, we'll have to decide which ones work best for what we want to achieve.


I'm happy to go with your changes for the time being (and probably longer). If they don't work out we can always change them at a later date. It's just nice to see Hooptie on the move again.


With these changes in place however, it would settle all outstanding issues with Hooptie proper and all that would be left is the Editor which I am currently looking into. I'll discuss that later.


Feel free to build on Hooptie more. Take it where you want it to go. I appreciate Hooptie is not without weaknesses, very little is perfect. But I think there is some good work and good code in Hooptie. If ever you need assistance, don't hesitate to e-mail me pazolli AT idevgames DOT com. I'll also try to check this forum occassionally and answer any questions that arise. I have exams at the moment but I will be happy to offer more help later where I can.

Mark.

[Kjurtyl]

If you were really adventurous you could maybe move muting to the preferences dialog and have a pop-up with three options: "All sounds and music", "All sounds and some music" or "No music".

That is exactly what I had in mind, but at this point it's either I do it myself, or I take a step back and add it in the Tasks document and hope we hook someone new with it.

A few more game elements, for example, might be nice.

I agree, I have some ideas, but I'd wanted to see what clever things level designers come up with using what we have now. Always felt the flybot wasn't being used to max potential. Get the ball rolling in this way: they make some levels, we make some more elements, they make more levels, etc.

this involved commenting out the MusicPlayerPreroll() function.

Noticed, should we not simply remove it?

Hooptie, as it is now, is a pretty darn solid piece of code. Though it has potential to grow, we should not forget that it has achieved a lot and has come a long way from where it began. Remember the coder art? I do too.

The emphasis today is on getting the next milestone out that will be released to a wider audience.

- Kjurtyl.

[DaFalcon]

hehehe, I remember the coder art, that is half of what got me to jump on board; the game looked like it had potential but I couldn't stand to look at it :-) Of course I didn't have OS X at the time so I couldn't play it *anyway*, but still. The other half of what got me to join was the departure of the previous artist and his very inspirational psuedo 3D concept art.

If someone game me a good easy to understand editor, I would crank out about 25 new levels for Hooptie to help it get released. I think I designed all my levels in TextEdit :sneaky: -- it was cool that I *could* do that, but it was a pain to test levels and change them and test them some more. I would love to be able to push a button and change from edit mode right into being able to play the level I was editing. That would be a huge boon.

I second Mark's comment: It's just nice to see Hooptie on the move again.