Level editor creation - Cocoa or Carbon

-Rice-
Unregistered
 
Post: #1
I have just finished reading/studying Mark Szymczyks excellent book on Mac game programming, and am ready for the next step. This would seem to be writing a level editor. I have never done this nor known the need to until now, and I am clueless as to how to proceed. Over the summer I plan on writing an editor to accompany the source code/game he developed in the book, as an educational project to keep my brain sharp over the holidays (organic chemistry, physics and calculus are looming on the horizon for falls class line up). Any advice would be greatly appreciated as I am totally ignorant of the subject.
Questions:
1. Cocoa or Carbon? I programmed the old toolbox in the mid 90's and just recently (since I picked up Marks book) looked into programming in Carbon. Doesn't seem much different than those days - quit subscribing to Mac tech at the time they were discussing this move to Carbon as it was moving into too much networking info. I bought and read Aaron's book on cocoa and love it. Heck of a lot easier to build an interface than with numerous switch statements (getting lazy in my old age, and this old iMac keyboard is NOT a pleasure to type on). A resource is a resource, right?
2. Other than that I have no idea of where to begin, as I have never programmed a graphic creation program before. Quite sure along the way I shall have many questions if you all will just humor me in my mad ravings with assistance, it sure will be appreciated.

thank you for your input and advice,

Rice

(continuously proving that you can teach an old dog new tricks)
Quote this message in a reply
Member
Posts: 177
Joined: 2002.08
Post: #2
Cocoa. It's FAR easier to develop a GUI in Cocoa, if you're not biased in either direction before and don't care about portability. Although you won't be using resources any more, you'll be using nib files made with Interface Builder, which beats the pants off ResEdit's dialog editor.

Have you done any sort of graphics before? If you want to work with 3D maps or OpenGL, you'll need linear algebra, vector operations, and trig. Anything more advanced than that I usually figure out on a piece of paper and implement the simplified version.
Quote this message in a reply
Mars_999
Unregistered
 
Post: #3
Use Cocoa with OpenGL.
Quote this message in a reply
Member
Posts: 164
Joined: 2002.04
Post: #4
Maybe this is a ridiculously stupid way to do it, but what I always do is incorporate the level editor in the game. I.e. in Lugaru you can just turn on the map editor in game and place/delete objects and set up AI paths and all that
Quote this message in a reply
Member
Posts: 715
Joined: 2003.04
Post: #5
Welcome to iDevGames.
I've posted the evolution of the T3D Editor to help guide you in your level editor building quest.

OverView

When I met Tobi everything in the engine was hard coded, there was only a full screen view, and the editor worked in a blind kind of way. as you can see in Generation1

My background is design so I managed to convince him to move on over to a visual method and thus was born Generation2
Which added a scripting engine and poses and continued to evolve until all work on it stopped so we could make Antack! for uDevGame 2002.

Since uDevGame Tobi has been busy with school and life and when he has the time he's been most exceptionally developing Generation3
Which is so far superior to the previous generations its hard to imagine they came from the same person in less than 12 months.

One thing I always felt was missing was a 2D editor like in Marathon or dim3. So I went ahead and made a level like that by using the 3D editor and the scripting engine. It simply plugs your model into the same spot as a selected quad on a 10x10 grid, getting me started for more detailed placement outside of the play mode.

Hope this helps. Keep asking questions. Maybe you can develop the killer rapid game editing application. When I came here last year I was told it couldn't be done.

There are 3 in development here at the moment!! Grin
Quote this message in a reply
Member
Posts: 111
Joined: 2002.06
Post: #6
For a 2D level editor, the best thing to do is divide the job into many small tasks and add one feature at a time until you have a level editor. Below is one way to begin making a level editor:

1. Write a program that creates a window when you select New from the File menu.
2. Add the ability to close, minimize, zoom, and size the window. This will be a lot easier to do in Cocoa than Carbon.
3. Draw a tile-sized rectangle in the window when you click the mouse inside the window. In the level editor, you're going to have windows containing levels and windows containing tiles you will place in your levels. You're going to need the ability to select an individual tile from the tile window in your level editor, and drawing a tile-sized rectangle in the window will simulate this.
4. Write tile ripping code that takes a graphics file and breaks it up into tile-sized pieces. This will give you the tiles you need to make levels. If you already have a list of tiles, you can delay this step, but you'll eventually want this feature in your editor.
5. Add the ability to place tiles in the level.

Once you have this down, you will add features like scrolling, saving and loading levels, cut and paste (building levels one tile at a time is tedious), setting tile attributes (which tiles are walls, floors, etc.), and placing enemies in the level. Soon, you will have a working level editor.

Mark Szymczyk
http://www.meandmark.com
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #7
I just began writing a level editor for a platformer a few days ago, and also finished an animation editor just now (Hi Gatti!) and from where I'm standing, I've learnt a few things:

I write the game in Carbon C++, and write the editors in Cocoa Obj-C. This gives me one problem, since the game classes are in a language which is not directly compatible with the editor. With the animation editor, I used the C++ classes and wrote the editor in Obj-C++. That wasn't a very wise descision, since I initally lost Cocoa's excellent saving capabilities. It also stopped me from using Cocoa's takeValue:forKey: (or whatever it's name is) for the GUI. So, I ended up making the GUI talk to wrapper classes around my game classes, and then converting the wrapper data into the proper data for my C++ classes. That, in turn, ended up into a nightmare where I had two versions parallelly in the program at once, and making sure that they were equal, up-to-date and head-to-head with each other, and that also doubled debugging bothers. NOT the way to go. Had I just taken two hours of work to rewrite my game classes into Obj-C equivalents, things would have been easier.

So, now, with the level editor, I'm doing just that. I've written lightweight classes which contain just what I need for the editor, and then I'll coerce these into game files for the Carbon version.

Of course, this forced me to have two file formats to save to - one for the editor, which I just can save and restore easily with Cocoa, and one for the Carbon version (which could have been taught to open Cocoa files, but I didn't want that hassle too.) that just exported the data into text files. Check this thread for more info on it.

So, if you can assume that all users will run Mac OS X, then you can use Cocoa's saving/loading capabilities from Carbon, but that's not very easy, I think. There's documentation on it in Project Builder.

Do EVERYTHING right. Don't leave something when it seems to work, make sure that it works right. This is of course true with any software development.

If you are going to use a tool bar, I set it up as an NSMatrix of square buttons, and set the matrix' selection mode to Radio - that gave me the desired result.

I also recommend defining a protocol (interface) called LevelEntity or something, and then let all your classes that need to be moved around in a level implement it. That way, you always have a common entry point for all your entities to communicate with the editor. For instance, my protocol now defines a method that takes a click position and the active tool, so that all level entities can handle a click in their own way, with zero hassle on your side.

I'll post back here if I can offer some more tips... Smile
Quote this message in a reply
-Rice-
Unregistered
 
Post: #8
Thanks for all of the advice. It is all well taken and hopefully I can start work on this soon after finals are over.

thank you,

Rice
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #9
Oh, yes, another one I forgot. Make sure that you set your file handling straight as soon as possible. That's the kind fo thing you don't want to tack on in the last few hours, bur rather keep around for the entire development.
Quote this message in a reply
Founder
Posts: 1,138
Joined: 2002.04
Post: #10
I can't believe no has mentioned this....

If you are talking about a 2D level editor, PLEASE consider "Level Creator." The souce code was released to the community. It is classic only if I recall. I would love to see it Carbonized. Also, it outputs resource files or PICT. I'd like to see that changed to PNG or TIFF. There are some bugs that also need to be cleaned up. If you're not interested in taking on the job -Rice-, I hope someone else is. By the way, welcome to the site.

Carlos A. Camacho,
Founder
iDevGames
Quote this message in a reply
AJ Infinity
Unregistered
 
Post: #11
There's a popular Flash-based level editor which exports levels and tiles as mulidimensional array maps. It even does three dimensional arrays. If you want a slick looking POWERFUL, drag-n-drop, tilebased, map editor, then give me an email and I'll send it to you.

Level editors definitely speed up the dev time of a game.
Quote this message in a reply
Patrick
Unregistered
 
Post: #12
Quote:Originally posted by Camacho
I can't believe no has mentioned this....

If you are talking about a 2D level editor, PLEASE consider "Level Creator." The souce code was released to the community. It is classic only if I recall. I would love to see it Carbonized. Also, it outputs resource files or PICT. I'd like to see that changed to PNG or TIFF. There are some bugs that also need to be cleaned up. If you're not interested in taking on the job -Rice-, I hope someone else is. By the way, welcome to the site.
Here's the link for Level Creator:
http://www.swarming.net/levelcreator/
Quote this message in a reply
AJ Infinity
Unregistered
 
Post: #13
OH WOW LEVEL CREATOR ROCKS!!! Makes me wish I didn't write the H2O Editor. BTW, it has an interface similar to the Flash based map editor I'm talking about. BTW, here's the link (note: this editor REQUIRES the Flash MX authoring environment to work. I could modify it to work for people who don't have MX though):

http://www.geocities.com/ajinfinityx/downloads/

Note: The DL link is mapeditor.zip.

There is an actual website for this editor but I don't remember the link.
Quote this message in a reply
kattkieru
Unregistered
 
Post: #14
Above it was suggested that you build your level editor into your game, and that's been what's always worked best for me.

The first thing I do is decide on a level struct or class, and get that designed / implemented. I don't mean drawing, but simply class methods and properties. Then I use a test tile set to test scrolling and map drawing by passing a reference of the class or struct into a function, which in turn draws the map view.

Once you have all this going, it's easy to change tiles in the map while you're looking at it with the mouse or keyboard. I keep a second level map in memory whose contents are the current tile set (just in order -- so the first tile is tile 0, then tile 1, ... until tile N, the last tile; the tiles wrap to the screen or window width); with this map I can select a tile I want by switching to it and clicking with the mouse.

The above may be a bit confusing the way I've described it, so here's an example:

Code:
// tiles are 32x32
#define TILESIZE 32

class Map
{
public:
  // 2d array of tiles
  char *tiles;

  // map "camera" coordinates
  // mapx/y are tile coordinates, and tilex/y are
  // pixel offsets inside a tile (allowing for smooth
  // scrolling)
  int mapx, mapy, tilex, tiley;
};

So let's say you're 17 tiles in, and 17 tiles down on a large map. (We won't use pixel offsets; you don't need smooth scrolling in an editor.) First get mouse-coords:

Code:
mouse_tilex = mousex / TILESIZE + map->mapx;
mouse_tiley = mousey / TILESIZE + map->mapy;

From here you know what to do. ^_^;; The above is extremely rudimentary; you could extend the map class with a tile class, that holds layers of data, and have the editor edit different layers in different modes. You could react differently to different button presses. You could allow the creation of prefabs, whereby selecting an area of tiles allows the user to make a map by using many smaller maps. (Think all the rooftops and buildings in the FF games.)

But yeah. Start with the level class, then think up a file format once it's done, and move into writing the editor.

Also check this out: http://www.makegames.com/sidescroller/ . It's a 1994 book by Diana Gruber that taught me a lot, and despite the fact that most of it is irrelevent on today's modern machines (IE, working within the 640k barrier, using FastGraf), the theory behind most of what she does is quite solid.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Texture Editor / Box2D Custom Polygon Editor vladu.bogdan 0 5,296 Feb 9, 2011 07:30 AM
Last Post: vladu.bogdan
  Carbon or Cocoa? Pros and Cons Nick 12 5,762 Jul 7, 2004 10:05 PM
Last Post: Josh
  Picking Cocoa or Carbon Muffinking 2 3,710 Jan 29, 2003 03:24 PM
Last Post: skyhawk