Hooptie Level Editor

[Pazolli]

This thread refers to a thread originated by John Nikolai here (http://www.idevgames.com/cgi-bin/UltraBoard/UltraBoard.cgi?action=Read&BID=18&TID=836&SID=103044).

[Pazolli]

Firstly I'm really keen on not burdening the project's lead graphics artist, DaFalcon, with more work. As he's already got a mammoth task to complete here (http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=49892&group_id=31218&group_project_id=13463), that being the case I think the editor should use Hooptie's existing graphics and essentially allow the player to recreate the look of the starting configuration of the board identically.

However because there will be no animation (a good thing which will make life easier). You should only need a fraction of the "x.tiff" files used by Hooptie. If I was to list what ".tiff"s you should use I would suggest:

[list=1]
30.tiff and 190.tiff for Hooptie
55.tiff and 56.tiff for the Ice Blocks
60.tiff for the teleporter
100.tiff and 140.tiff for the ScoutBots
skyline.jpg for the skyline
0.tiff and 1.tiff for the tiles (note 0.tiff should be drawn to imply a blank tile that is, blank tiles are not actually blank they're specified by 0.tiff)
[/list=1]

These images should then be loaded (with no name change) in essentially the same manner as they were loaded in GameView's - (id)initWithFrame: method. This loading procedure caches the images.

An array of values should then be set-up to symbolize the map's tile matrix (see level1.txt) such as in the GameMap source where they were defined int tiles[15][12]; (except obviously you'd need to account for multiple levels). You'd then need to work out how to save these to a "document bundle". If you don't know what I mean a "document bundle" please ask. Also I really, really would like you to use NSDocument for this task.

The editor I believe should be "click 'n' place" and so users would manipulate these tile values by their selection in a palette and where they clicked on the map editor's view. For speed, a click should change the tile value and also change a Boolean value such as stored in the data member BOOL needsUpdate[15][12]; or BOOL skylinedNeedsUpdate; as appropriate. A procedure such as GameView's - (void)quickDraw should then be called to update only the tiles that need it and draw the heads of sprites and bases of sprites which may lie on those tiles. You would still need to implement a - (void)drawRect: method for full updates (possibly requested by the System) but you should only really need to call - (void)quickDraw most of the time.

Finally remember to set the view's - (BOOL)isOpaque to return YES.

Also I should briefly now explain of why sprites are divided up into heads and bases. When it was decided Hooptie would allow sprites to be up to two tiles high, drawing a single sprite caused a dominoes effect because the head of the sprite would require the base of the sprite above it to be updated which would do the same to the sprite above it and so on. To avoid this sprites were divided up into heads and bases, hence if a sprite was changed, both its head and base were updated as was the head of the sprite below it and the base of the sprite above it but the rest of the tiles could remain unchanged. This concept is important in updating for the following reasons:

[list=1]
A single sprite being changed should mark two tiles, one on which it is on and one above it, as needing an update.
Considering that, updates should be handled by the updater by updating the bases and heads of all sprites on or below the tile requesting an update.
A special case occurs with the skyline which must update all heads on it when an update is requested.
[/list=1]

You should also never bother about creating a sprite type. All the information that can be saved by the map editor about a sprite is a distinct character. Hence just store what the tile value is and don't create an array of sprites as in Hooptie.

Well they're my ideas (ignore them if you really don't like them). Also I expect they could be quite difficult to understand so tell me if you want me to clarify any of them.

Good luck,
Mark

[Pazolli]

jnikolai wrote on the old web board
I agree with you that the top down view would be the best option, for now. Maybe if Hooptie goes to 2.0 we could enhance the code and get the first option working. In the mean time I will work on the top down level editor and see what comes up. =)

On a separate note, is it possible to add a "Load level" menu item to the Hooptie game? All the default levels are currently bundled up in the Hooptie.app directory. Once the level editor is working people may want to have the ability to load a user created level without having to re-bundle the whole application.

I hope to start some coding tomorrow after I search for a new job for a few hours... Anyone live in the Seattle area and have need for a dedicated and hard working Java software engineer? Or perhapes a newbie Cocoa developer? ;-)

Thanks for your input and have a great evening,
- John


Firstly I strongly protest against the top-down view. It could well look tacky and DaFalcon's time is really, really valuable to the project. As for the load level option in Hooptie it is already a task here (http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=49878&group_id=31218&group_project_id=13463), so rest assured once the level editor is built there ought to be a load level function available (programmatically if you use document bundles external level loading is a piece of cake which is why I offer it as a good task for a newbie). But in the mean time simply substitute in your work to Hooptie's resources directory. The file format is so simple errors shouldn't really be too hard to spot in the output.

Mark.

Also please advise me whether you know what a document bundle is, it's fairly important.

[DaFalcon]

Screens...

I am open to input for ideas for the various screens needed... do you think that there should be pictures of the aliens in, for example, the game over screen? Yeah, those little robots were created by an alien race, and with any luck, the actual aliens will appear in the game as baddies, instead of just their mindless drones. For example, the game over screen would show Hooptie being blasted by an alien ray, or on an alien's "disection" table, or something like that . . . Another idea I've always liked is that of multiple game over screens, dependent on your mode of death, or just randomly selected from a few options. That wouldn't be done right away, but I'd like input on that idea in general anyway :-) Thanks for your input, and all ideas are welcome! I know this probably isn't really the place for it though...

[Pazolli]

DaFalcon,

All those ideas sound pretty good to me. I'm happy for you to design whatever you like with respect to Hooptie. We (the programmers) will try to accomodate your requests. Multiple game over screens are certainly no problem, but obviously it'd be nice to get all the screens done first before we start generating multiple versions of a single screen. As always I feel we should focus on the simple stuff first because I'd rather play a feature-complete simple game than a feature-lacking complex game.

Back 9 months when the Inkubator project was started Hooptie was going to be a simple 3 month project, it didn't work out that way, but it has allowed to establish a really solid base on which we can build future projects. Right now, I think it's important for the group's morale we get Hooptie out before the end of this year and in my eyes that requires a focus on simple things. Plus I'm looking forward to the next project.

Oh and one last thing, the game field has a white background which looks pretty good in MacOS X. So if you are creating screens you might consider keeping the white background and perhaps even going for a "less is more" approach. That however is strictly a suggestion, don't give it too much weight as graphics are not my area. But if someone out there does feel they know a bit about graphics jump in and tell us whether you agree or disagree (don't worry it's cool if you're not a member).

Mark.

[flipflop]

Originally posted by Pazolli
[B]Firstly I'm really keen on not burdening the project's lead graphics artist, DaFalcon, with more work. As he's already got a mammoth task to complete here (http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=49892&group_id=31218&group_project_id=13463), that being the case I think the editor should use Hooptie's existing graphics and essentially allow the player to recreate the look of the starting configuration of the board identically.


I agree that we shouldn't burden DaFalcon with more images. My original idea for the top down view was to take the existing images and combined the "head" and "bodies" by hand in Photoshop to create a single image. This was the one big drawback to doing the top down version of the level editor. I like the idea of recreating the look of the editors board to be identical with the actual game board, but I thought it would be too much work for something that we may have wanted to be simple.


[list=1]
30.tiff and 190.tiff for Hooptie
55.tiff and 56.tiff for the Ice Blocks
60.tiff for the teleporter
100.tiff and 140.tiff for the ScoutBots
skyline.jpg for the skyline
0.tiff and 1.tiff for the tiles (note 0.tiff should be drawn to imply a blank tile that is, blank tiles are not actually blank they're specified by 0.tiff)
[/list=1]


Hehehe, I made this exact same list last night after I sent last nights message. The "pit" tiles are not listed though and I'm not sure what the status is for these tiles. They are in a separate directory called "waiting".


You'd then need to work out how to save these to a "document bundle". If you don't know what I mean a "document bundle" please ask. Also I really, really would like you to use NSDocument for this task.


I will read up on the NSDocument class and will ask questions as needed.


The editor I believe should be "click 'n' place" and so users would manipulate these tile values by their selection in a palette and where they clicked on the map editor's view.


Exactly what I was thinking...


Finally remember to set the view's - (BOOL)isOpaque to return YES.


Is this for performance reasons?


You should also never bother about creating a sprite type. All the information that can be saved by the map editor about a sprite is a distinct character. Hence just store what the tile value is and don't create an array of sprites as in Hooptie.


We will need some kind of mapping between the NSImage and its value that will be stored/read to/from a level file. A simple HashMap... uh... NSDictionary may be all that is needed.


Well they're my ideas (ignore them if you really don't like them). Also I expect they could be quite difficult to understand so tell me if you want me to clarify any of them.


The skyline graphic is NOT a part of the [15][12] grid. Correct? Of course I will probably find out for my self today as I dig deeper into the code.

Thanks for the help!
- John :)

[flipflop]

Originally posted by Pazolli
Also please advise me whether you know what a document bundle is, it's fairly important.


OK, let me take a stab at what a document bundle is. Here is a link (http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Bundles/Anatomy_of_a_Bundle.html) I found which explains about the "Anatomy of a Bundle". Listing 5-1 "A minimal bundle" seems to be what we may be after.

Like an application bundle the document bundle should not look like a directory when viewed in the finder. Rather it should look like a file. Double clicking on the "level" document bundle in turn should either launch the Hooptie game application or the level editor application - most likely it would launch the Hooptie game application.

Please correct me if I am wrong!
- John :)

[Pazolli]

Originally posted by jnikolai

I agree that we shouldn't burden DaFalcon with more images. My original idea for the top down view was to take the existing images and combined the "head" and "bodies" by hand in Photoshop to create a single image. This was the one big drawback to doing the top down version of the level editor. I like the idea of recreating the look of the editors board to be identical with the actual game board, but I thought it would be too much work for something that we may have wanted to be simple.


I think you'll probably find it's not too difficult to just recreate the game's look.


Hehehe, I made this exact same list last night after I sent last nights message. The "pit" tiles are not listed though and I'm not sure what the status is for these tiles. They are in a separate directory called "waiting".


Yeh they're unimplemented at the moment in the Hooptie game, if you want you can implement them now ahead of their implementation in the game, but I wouldn't. Not implementing them, keeps everything in line with the game and means each single tile value corresponds to a single tile image, or a single tile image, sprite base image and sprite head image (above that tile). Making things easier for you.


Is this for performance reasons?


Yes, setting isOpaque to return YES is necessary for peformance reasons.


We will need some kind of mapping between the NSImage and its value that will be stored/read to/from a level file. A simple HashMap... uh... NSDictionary may be all that is needed.


Yes, you do need that mapping and it can be provided by Int mapTiles[15][12]; An NSDictionary could be used (I know they make things easier in one respect because you can never access an out of range value and stuff up your entire program) but it may be harder to record that data to file afterwards. Also note that a tile value doesn't necessarily represent just a tile, it can represent a sprite on to of a tile.


The skyline graphic is NOT a part of the [15][12] grid. Correct? Of course I will probably find out for my self today as I dig deeper into the code.


Yes. The skyline graphic is for the heads that rest above the first row of tiles. Otherwise we'd have headless sprites running around, not very professional looking. :D


Thanks for the help!
- John :)


No problem thanks for taking an active interest in our humble project.

Cheers,
Mark

[Pazolli]

Originally posted by jnikolai

OK, let me take a stab at what a document bundle is. Here is a link (http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Bundles/Anatomy_of_a_Bundle.html) I found which explains about the "Anatomy of a Bundle". Listing 5-1 "A minimal bundle" seems to be what we may be after.

Like an application bundle the document bundle should not look like a directory when viewed in the finder. Rather it should look like a file. Double clicking on the "level" document bundle in turn should either launch the Hooptie game application or the level editor application - most likely it would launch the Hooptie game application.

Please correct me if I am wrong!
- John :)

Yep, except a document bundle doesn't even have that "Contents" directory typically. Find a Project Builder project in the Finder. Control-click on it and select "Show Package Contents" and that is what I mean as a document bundle. Except in your case, the document bundle should contain "level1.txt" to "leveln.txt" files.

Thanks again for you interest in the project,
Mark

[flipflop]

Originally posted by Pazolli
Yep, except a document bundle doesn't even have that "Contents" directory typically. Find a Project Builder project in the Finder. Control-click on it and select "Show Package Contents" and that is what I mean as a document bundle. Except in your case, the document bundle should contain "level1.txt" to "leveln.txt" files.


So we will have a directory structure like this:

- HooptieLevels
- PkgInfo
- Info.plist
- level1
- level2
....
- leveln

Is this enough for the finder to consider this a bundle? Or will we need to progammaticly twiddle the Bundle bit to "on" after the directory structure is created?


Thanks again for you interest in the project,


You are welcome! It's nice to finally have a project to work on while I wait for a job... :p

Thanks for your being patient as well as your help,
- John :)

[flipflop]

Here is a quick feature list for the level editor. Feel free to add, subtract or modify any features. I would like to get this list finalized before I get too far with the code...

Say, Mark... Do we have a due date for this side project? Is Hooptie 1.0 going to be delayed until the level editor is done? Just curious! :)

------------------------------
Level Editor feature list
------------------------------

- Two seperate windows will be open. A palette window and a map window.

- Palette: contains all the tiles which can be added to the map as well as a simple delete tile tool. The workflow will act similarly to Photoshops palette - you select a tile from the palette and every time you click on the map window a new tile is added at that point.

- Map window: Looks identical to the Hooptie game view. This will make it easier for level designers to see the end result without having to leave the editor and play the game to view their work.

- Map window: Has a snap-to grid which is visible to the user. So when a user clicks within a certain element in the grid, the tile will "snap" to the proper position.

- Ability to read and save document bundles containing several levels.

- Smart level name saving. If you start a new bundle, the first level file will be named "level0", the next level file will be saved as "level1", etc... This will be handled behind in the code so levels can be quickly generated and saved. When an existing bundle is opened, the last "level" file number is checked and any new files created and saved will be based off that number.

Thanks!
- John

[Pazolli]

Originally posted by jnikolai
So we will have a directory structure like this:

- HooptieLevels
- PkgInfo
- Info.plist
- level1
- level2
....
- leveln

Is this enough for the finder to consider this a bundle? Or will we need to progammaticly twiddle the Bundle bit to "on" after the directory structure is created?

Actually, I don't think there's any bundle bit twidling and PkgInfo and Info.plist are not even required. What makes a MacOS X document bundle, I believe, is simply its extension. Go into the Finder and create a new folder. Then type "Jack.pbproj", click outside and press "Add" when the warning appears. Voil‡ you have a Project Builder project, albeit one that doesn't work (double click on it and you'll see PB responds). Likewise try "Jill.rtfd". Though I've never used document bundles in practice, in theory I believe what makes them are the settings you specify in your project's target where you list what documents your project responds to.

Tell me if you think I've got something wrong.

Hope this helps,
Mark

You're probably wondering why I didn't tell you this before the truth is I only just figured it out with your last post.

[Pazolli]

Originally posted by jnikolai
Here is a quick feature list for the level editor. Feel free to add, subtract or modify any features. I would like to get this list finalized before I get too far with the code...

Say, Mark... Do we have a due date for this side project? Is Hooptie 1.0 going to be delayed until the level editor is done? Just curious! :)

No due date, if you want an arbitrary random date to target for try the 23rd of May, 2002. (One day before Steve's clock hits 12 I believe). And yes, Hooptie 1.0 will be delayed until the editor is ready, but don't confuse Hooptie 1.0 with Hooptie Milestone II which is due out in a matter of hours.


------------------------------
Level Editor feature list
------------------------------

- Two seperate windows will be open. A palette window and a map window.

- Palette: contains all the tiles which can be added to the map as well as a simple delete tile tool. The workflow will act similarly to Photoshops palette - you select a tile from the palette and every time you click on the map window a new tile is added at that point.

- Map window: Looks identical to the Hooptie game view. This will make it easier for level designers to see the end result without having to leave the editor and play the game to view their work.

- Map window: Has a snap-to grid which is visible to the user. So when a user clicks within a certain element in the grid, the tile will "snap" to the proper position.

- Ability to read and save document bundles containing several levels.


All cool.


- Smart level name saving. If you start a new bundle, the first level file will be named "level0", the next level file will be saved as "level1", etc... This will be handled behind in the code so levels can be quickly generated and saved. When an existing bundle is opened, the last "level" file number is checked and any new files created and saved will be based off that number.


I'm not sure exactly what you're saying here, but "level1.txt" will be the first file Hooptie looks for and plays in the bundle (remember the '.txt' extension). "level2.txt", "level3.txt" and so on will then be played. Then when Hooptie reaches a number for which no level exists, Hooptie will display the "You Win" screen. We could change this behaviour to fit the editor, but I'd prefer it if you changed the editor to fit this beahviour. If you want to be really fancy and allow the user the option of having dormant levels, then you can store these under another name e.g. "unused1.txt", "unused2.txt", etc.

Oh and remember to use NSUndoManager. It's easy to use, allows multiple undos/redos and actually can help make using NSDocument easier. Feel free to ask any questions you might have in the forums.

To use NSUndoManager to allow an undo, call:

[[[document undoManager] prepareWithInvocationTarget:self] reverseAction:YES];

Where document is the current NSDocument, self is the object which contains the method to reverse the user's actions. And reverseAction is the method to reverse the user's actions along with any arguments it might require.

Then in the reverseAction: method to allow a redo, call:

[[[document undoManager] prepareWithInvocationTarget:self] redoAction:YES];

Oh and last but not least read and follow the "conventions.rtf" and make sure you're familiar with concepts in the "memory.rtf".

Cheers,
Mark

[flipflop]

Originally posted by Pazolli
Actually, I don't think there's any bundle bit twidling and PkgInfo and Info.plist are not even required. What makes a MacOS X document bundle, I believe, is simply its extension. Go into the Finder and create a new folder. Then type "Jack.pbproj", click outside and press "Add" when the warning appears. Voil‡ you have a Project Builder project, albeit one that doesn't work (double click on it and you'll see PB responds). Likewise try "Jill.rtfd". Though I've never used document bundles in practice, in theory I believe what makes them are the settings you specify in your project's target where you list what documents your project responds to.

Tell me if you think I've got something wrong.


I'm going to put the document bundle problem on the back burner for the time being. I can get most of the level editor working with a simple saving (ie. save one level.txt file per level) and add the bundle stuff when we figure out exactly how it works.

NSBundle might be another place we can look...


You're probably wondering why I didn't tell you this before the truth is I only just figured it out with your last post.

Hehehe, it's a learning experience for everyone! :)
- John

[flipflop]

Originally posted by Pazolli
I'm not sure exactly what you're saying here, but "level1.txt" will be the first file Hooptie looks for and plays in the bundle (remember the '.txt' extension). "level2.txt", "level3.txt" and so on will then be played. Then when Hooptie reaches a number for which no level exists, Hooptie will display the "You Win" screen. We could change this behaviour to fit the editor, but I'd prefer it if you changed the editor to fit this beahviour. If you want to be really fancy and allow the user the option of having dormant levels, then you can store these under another name e.g. "unused1.txt", "unused2.txt", etc.


Sorry for the confusion... The only fancy thing I was going to add was the ability to open an existing level bundle and be able to save a new level to that bundle with the proper number.

Here's an example of an exitsing bundle:

- Hoopte.levels
- level1.txt
- level2.txt

A user opens this bundle in the level editor, creates a new level and saves it (without specifying a file name). The bundle should now look like this:

- Hoopte.levels
- level1.txt
- level2.txt
- level3.txt

I guess we will also need the ability to load ANY of the levels in a bundle for editing. Of course I have no clue how all of this will work in the code but it sounds resonable. ;)


Oh and remember to use NSUndoManager.


Added to the list :)

Thanks,
- John

[DaFalcon]

In the editor, would there be any way for it to redefine certain graphics? If someone wanted to create an object with the same properties as an iceblock, but make it look like a crate of monkeys, for example, would such functionality eventually be available? Just curious, not really requesting the feature though :-) I agree that we should concentrate on getting Hooptie to 1.0 in a complete, less complex program before complexities. But I figure that mentioning potential complexities never hurts :p

[flipflop]

Originally posted by DaFalcon
In the editor, would there be any way for it to redefine certain graphics? If someone wanted to create an object with the same properties as an iceblock, but make it look like a crate of monkeys, for example, would such functionality eventually be available? Just curious, not really requesting the feature though :-) I agree that we should concentrate on getting Hooptie to 1.0 in a complete, less complex program before complexities. But I figure that mentioning potential complexities never hurts :p

Introducing the concept of "themes" to the Hooptie tileset would be a bit of a chore. The current Hooptie game implementation doesn't have any concept of tile themes and would have to change quite a bit to accommodate for them. This might be beyond the 1.0 release though... :) I could add the functionality functionality to the level editor but the Hooptie game application would not know what to do with them.

None the less, this is a good idea. We may consider adding a tiles theme package to the level document bundle, which in turn could override the default Hooptie tile set when that level bundle is loaded.

My 2 cents worth!
- John :)