Prliminary level editor available...

[flipflop]

A preliminary version of the level editor is up on my iDisk. First of all, this is not complete and still has quite a bit of functionality to add. Please keep this in mind when you run it. :)

Some things to note before using the editor:

- Currently we can only read and write a level.txt file from the file system. The file package --.hlvls is not operational yet.

- There is no way to modify the level details -- "Time Limit", "Speed Adjustment", "Bubble Period", etc... You will have to add these to the files manually. Rest assured that this is a feature which will be added soon! ;)

- "new", "open", and "save" are the only functioning menu items right now. Be careful, the editor currently is not smart enough to warn you to save a file before you quit , create a new level, or open an existing one.

Other then that, the editor should allow you to create a quick and dirty level. Feel free to send your thoughts and feedback!

Thanks and enjoy!
- John

You can get it from my iDisk:
Editor (http://homepage.mac.com/WebObjects/FileSharing.woa/wa/default?user=jnikolai&templatefn=FileSharing4.html&xmlfn=TKDocument.4.xml&sitefn=RootSite.xml&aff=consumer&cty=US&lang=en)

Or by opening up my Public folder using the web iDisk (http://itools.mac.com/WebObjects/Tools.woa?destination=idisk&aff=consumer&cty=US&lang=en&identifier=qRAZPEFtUUsQz4r9) tool. My username is jnikolai.

[flipflop]

OK, you may want to mount my iDisk to get the editor -- the second option mentioned in my previous post. The web page thinks the editor.app is a directory. Guess I should have stuffed it... :P

Sorry about that!
- John

[DaFalcon]

I tried changing Hooptie's icon or something, and then sometime after some restart, it became a directory .. I had to re-install it! Is this a "common" problem with packages????

Anyway, the editor is looking great, and even my little sister had fun making a level. Very easy to make levels now, and very well done so far :-)

[flipflop]

I'm glad to see someone else having trouble with icons too and it's not just me! :)

One thought I had in regards to the level editor. It would be nice to be able to "test" a new level file package as it's being created in the editor. Do you think we could have a menu item or button to launch the Hooptie game from the editor with the currently opened level package? Also it might be nice if the user could select a specific level in the package while running the game. Maybe a command line thing...

Just a thought!

We are off to go see Spiderman kick some Green Goblin butt! :)

Have a good weekend!
- John

[Pazolli]

Could you post it as a ".sit" file, I'm having trouble accessing your public folder.

Regarding the icons, Mac OS X determines icons, document types, etc. when it first encounters the application, changing this information after the Mac OS X has already been encountered can cause problems. BobbyWatson's method may be of interest:

None of the methods posted here worked for me, so here's what I did (the method isn't mine, it's the one described in Aaron Hillegass's excellent book, "Cocoa Programming for Mac OS X") :
-build Hooptie
-Grab the Hooptie.app file and drop it in your Applications folder
-Log out then log in

It worked for me. I also set the OS type to "hlvls", maybe that helped.

But I expect all problems should be resolved when we set the icon and document information and allow the application to be installed from a disk image.

Mark.

[flipflop]

A .sit version has been put on my iDisk. If you downloaded a .sit version from the server BEFORE this post, please download it again. I accidently packaged up an older version of the code.

Hope this helps!
- John

[Pazolli]

Cool editor. Tell me when you have a code base you want to upload to the CVS.

Mark

[Pazolli]

Actually, judiging by the binary the code is ready to be put on the CVS. All I ask is that you make sure the code is well-commented.

Thanks for all your work,
Mark.

[flipflop]

I don't feel comfortable putting the code into CVS just yet. Trust me, the code is a mess! ;) It's more of a hack as I'm learning the ropes of Objective-C and the Cocoa API. During next week I plan to clean up the code and, if all goes well, we can submit the code to CVS by the end of next week. If the team feels more comfortable adding the code to CVS right now I certainly can do that. Let me know!

Do we have someone working on the level loading code? As I clean up the code I was going to start breaking out the level I/O into another class or two and also get the file package stuff working properly. The goal, as I uderstand it, is to create a general level I/O class or classes which can be used by Hooptie the game as well as the level editor. I have a good idea where to go and can ake the API really easy. :)

How many more tiles/characters are we thinking of adding to Hooptie? The current palette panel is fine for the few tiles and characters we currently have but if we add several more the palette will have to change. I'm thinking of adding a tab bar with two or more tabs, one for the tiles (ie. icecubes), another for hazards (ie. pits) and one for the characters (ie. Hooptie, scouts). It would be overkill right now with the limited tile set. Just thinking about the future... ;)

It's sunny is Seattle! Finally! 75 degrees and I already have a sun burn... sure hurts when I take a shower... owie! owie! owie!

Have fun!
- John

[BobbyWatson]

I am working on the custom levels loading thing. I had it up and running just a few minutes ago, and it worked the first time.

Here's a screenshot (http://homepage.mac.com/mlesperance/images/hoopLoading.jpg)

It crashed after two or three bundle switches, I still don't know why, but I'll probably work on that tomorrow. The code is a mess too (I fooled around quite a bit), I'm not very proud of the way I did it, so I'll probably spend some time on it in the next few days to make sure everything is well commented and well organized. I haven't added any new class, I just used what was already there mostly. I will make a summary of what I did once the code is clean (which shouldn't take too much time).

And it's really cold here, when I woke up yesterday there was snow everywhere. Some days I really hate Canada :)

[flipflop]

Sounds good, thanks Bobby.

Please let me know when you have commited the working code into CVS so that I can incoporate what you have coded into the level editor. The current level loading code in the editor is an exact copy of what is used in the game code and it should be an easy transition to the new code once you get it complete.

Snow?! Bummer! I hope you get some sun soon!

Thanks for your help and good luck!
- John

[Carlos Camacho]

Keep this in the back of your minds. Once you guys are ready, let me know and I will sponsor a small contest for the BEST HOOPTIE level created.

[DaFalcon]

Ooh, a Hooptie Contest :-) I think we may want to have more tiles (at least an immovable tile) before that time .. but that sounds wonderful :) Would it be a contest for the best Hooptie Level or the best Hooptie Level Set? ...and would this be open to current Hooptie developers? :-) [Nothing like a little friendly competition to spark some great new ideas, eh?]

[Carlos Camacho]

Once the game has enough game play, polish, and game assets then it would be a good way to attract media/Mac user attention on the game/Inkubator. Should be open to all I think. Anyhow, you guys just tell me when you are ready and the ground rules, and i will make it so.

[Pazolli]

Originally posted by BobbyWatson
It crashed after two or three bundle switches, I still don't know why, but I'll probably work on that tomorrow.

Often crashes are related to memory allocation/deallocation problems. When dealing with the "filePath" string you may specify its contents a number of ways. If you write:

filePath = @"/usr/levels/path"

Then that string will always be available to you throughout the program, you should never call "retain" or "release" or "autorelease" on it.

If you write:

filePath = [NSString stringWithString:@"/usr/levels/path"];

Then that string will be automatically released (i.e. accessing it will cause problems) at the next available oppertunity after the method in which it was allocated/used finishes executing. To prevent this from happening call:

[filePath retain];

And then when you finish dealing with the object:

[filePath autorelease];

Make sure you only call "release"/"autorelease" on an object as many times as you call "alloc"/"retain" and no more.

If you are going to allocate a new string to filePath (e.g. by calling "filePath = [NSString stringWithString:@"New String"]") you should call:

[filePath autorelease];

Before allocating the new string unless you have already ordered for the string to be released or have never asked for the string to be retained or allocated it using "alloc".

You can also allocate a string by calling:

filePath = [[NSString alloc] initWithString:@"The String"];

Which is pretty much the same as calling:

filePath = [[NSString stringWithString:@"The String"] retain];

(Notice the "retain").

Hope this helps,
Mark.

[BobbyWatson]

Can someone tell me exactly what this error means :

"Hooptie.app has exited dut to signal 10 (SIGBUS)" ?

[flipflop]

That error message could mean numerous things and all of them are not good. :)

I had a similar problem when I added the loading/saving code to the level editor -- That is to say that the bug happend every time I ran the code while yours only happens after a few trys. The problem was in my "savePanelDidEnd" callback or selector method. I received the same error message as you did. To me, that error message is very vague and not much help with finding the problem.

Have you stepped through the code with the debuger yet? This may give you a better idea where exactly the program is crashing. If all else fails, post the code you added somewhere like your iDisk and someone on the team can have a look. Fortunately I have a friend working at Apple and he helped me through some of the more difficult problems.

Good luck!
- John

[BobbyWatson]

I think I have found the line which causes the problem for me. Here's my method :

- (void)openCustomLevels:(NSWindow *)theGameWindow
{
NSOpenPanel *panel = [NSOpenPanel openPanel];

NSArray *fileType = [[NSArray alloc] initWithObjects:@"hlvls"];

NSLog(@"Array allocated");

[panel beginSheetForDirectory:nil
file: nil
types : fileType
modalForWindow : theGameWindow
modalDelegate : self
didEndSelector:
@selector(openPanelDidEnd:returnCode:contextInfo:)
contextInfo:nil];
}

The buggy line is
NSArray *fileType = [[NSArray alloc] initWithObjects:@"hlvls"];

The message (@"Array allocated") will appear the first time, but not the second. Instead, the game will crash. I tried commenting the line and sending nil as types for the beginSheetForDirectory, and everything worked fine. Any ideas how to solve this? I'm pretty puzzled...

(BTW : the commenting and cleaning of the code goes well, I should be able to commit the changes to the CVS as soon as I solve this bug).

BobbyWatson

[flipflop]

I forgot about this one too... I was using an NSArray as you are in your code but it didn't work properly for some reason. So I changed it to an NSMutableArray like this:

NSMutableArray *fileTypes;

fileTypes = [NSMutableArray arrayWithCapacity:2];
[fileTypes addObject: @"hlvls"];
[fileTypes addObject: @"txt"];

Not sure if this will solve your problem but it's worth a shot and easy to try...

- John

[BobbyWatson]

Thanks John, your trick works! I would still like to know what's wrong with NSArray though....

I just finished commenting and taking out all the "NSLog"s I left behind. I haven't commited my changes to the CVS in case someone finds a bug I missed or some comment that is not clear enough. The file (source and binairies) is available here :

http://homepage.mac.com/mlesperance/inkubator/hooptie.tgz

Enjoy!

BobbyWatson

[Pazolli]

Originally posted by BobbyWatson
The buggy line is
NSArray *fileType = [[NSArray alloc] initWithObjects:@"hlvls"];
...
I would still like to know what's wrong with NSArray though....


From Apple's Developer Documentation for NSArray's initWithObjects method:


Initializes a newly allocated array by placing the objects in the argument list in it. This list is a comma-separated list of objects ending with nil.


I never thought this mattered much, but you did forget the terminating "nil". That may have caused a problem (though it could have been something else.

Mark.

[flipflop]

OK, is it just me or does this seem kind of silly?

Why should we have to put a nil at the end of an NSArray object?! The code should know how large the array is and should be smart enough not to access anything out of bounds. Maybe I'm just spoiled by Java... :p

- John

[BobbyWatson]

Originally posted by Pazolli

I never thought this mattered much, but you did forget the terminating "nil". That may have caused a problem (though it could have been something else.

Mark.

You were right, I did forget to terminate the NSArray with "nil". Actually, I didn't forget, I simply didn't knew it. I do now :) I tried implementing it with an NSArray instead of an NSMutableArray, and it works perfectly if I end the NSArray with nil. Thanks for the tip!

BobbyWatson