Ok so i think i want to make a side scroller game were a player has the option to make his own levels, the only problem is ihave no idea how i would make a level editor for him. Like how would i make a gui for it? I was thinking of after the player placed the backround, objects like enimies, stairs, items, ect. the information would be stored in a file using numbers for every object, such as a chair being equal to 1, a table equal to 2, an a toaster equal to 3 and so on. I just have no idea how i plan on doing this. Being a little new to programing i know it might not be easy but i want a challange but a little help isnt bad right?

As you are new to it, I wouldn't even bother making a game that the user can edit. I would worry about getting the game done and working, then work on the editor for a future version. You might find that while you move on the main game you will find ideas on how to make the editor for your game.

I agree with Glenn. Games are difficult enough to make, but trying to make one with an integrated editor is even harder. If you are new to this, you are guaranteed to end up with a mess of code that will be a blend of game and editor and you won't be able to tell what is what.

Much better to write a game first, learn how you will manage the objects in the game, then after it's done, look at how to do an editor - and if you do make an editor, be sure to do it in a separate assembly from the game, if you don't, you will pay. ;)

I kind of disagree with above posters. How is he (the developer) gonna make the levels without an editor?  Ofcourse depends on a game and complexity of levels but usually it saves time to create a editor, rather than make levels with notepad or such. Maybe if the editor does not have to be accessible on xbox, you would be better of using something other than xna, something that offers ready made gui-components and you are possibly already familiar using.

I think if you are creating a windows based editor that will not be included in the final xbox build, it is somewhat easier to keep the separation.

But the OP stated he wanted to make an editor that the player can use on the xbox, and in this case it is harder to keep that separation, particularly if it is your first attempt at making a game, which I think the OP is saying.

The temptation to forget about separation and just throw everything into the same mix of code is high, and when this happens, the distinction between public interfaces and private implementation is lost, with the resulting mess being difficult to refactor, debug and extend.

This problem is compounded even further when you have not done it before - you will make wrong design choices - everybody does it, even the pro's, and these will need to be fixed, and it's just that much harder to fix when you also have to take an editor into account.

I'm not saying it shouldn't be attempted, I'm just trying to offer some words of caution that it is not an easy undertaking. I recommend making the game first, or at least a good chunk of it, getting your game data structures sorted out first, your game algorithms sorted out, before attempting to write an in game editor. Writing the editor at the same time will just pollute design decisions that should have no relevance to an editor.

Then again, if the OP just wants to make a very simple game, with a very simple editor, then what I just wrote is probably over cautious :D

Craig Martin:

I recommend making the game first, or at least a good chunk of it, getting your game data structures sorted out first, your game algorithms sorted out, before attempting to write an in game editor.

True.

Anyways try to plan ahead a bit, so you don't hardcode anything level-dependant too tightly or it will be a pain in the butt to make it suddenly load from file.

u551:

Anyways try to plan ahead a bit, so you don't hardcode anything level-dependant too tightly or it will be a pain in the butt to make it suddenly load from file.

Definately, data is data, and editor or no editor, data should not be in code files, it should be in data files.

As with any game you should plan ahead, but there is too much planning.
With new developers and some that have been doing it for a while, I find that too many people spend too much time playing around with supporting applications, artwork, and engine design....

Get a couple of small games under your belt, while doing these the engine and esgin patterns that will become your style will come to the surface.

Also spending too much time on those supporting systems will make you get bored of the game and move onto the next title with out finishing the first. For new developers.. get something finished and working that follows the basic principles and then grow up the games and supporting applications as you go.

The game I am currently working on is a platformer with time trials and a map maker.

Given this is only my second game and I am very little experienced, here is what I have done:

1) Created the 'engine'. Made sure everything was working. Physics, animations, gameplay elements.
2) Created some levels in code to test out stuff. 
3) Created the Map Maker.
4) Created temporary (will be deleted after) saving code that saves the maps directly into a format that I can import into the game.
5) Created my time trials using my own ingame map maker.

As the game is very simple I used the same assembly for everything. The code did get very fuzzy, but it works fine. I can see how expanding would be a problem, however there is no plan for such and the way I made it was way faster, easier and is saving alot of time when creating the time trials.

Hope this helps,
Alexandre

Even though you are new to this and people have said you probably should just make a game, and forget the editor for now. I think the editor could be very helpful in the creation of your own levels. Because of this, I'm going to propose a system. This is just a quick dash of an idea so forgive me if I leave design holes you should fill.

First of all you need a definition of your level objects. Each probably consists of a texture, a collision polygon, and maybe even some logic that plays a part in gameplay. But we aren't going to process that in the editor, all we really need is the texture information for the purpose of visual feedback to the level editor's user.

Then you need something to describe everything's position relative to the origin. So you might store this information in a scenegraph, that can be serialized into an xml structure or something for the purpose of saving and loading the level.

Once you have all this stuff you could either make your levels by hand in xml or you can actually make your editor. Which will accept controller input to select a level object from the list, and position it, load a level save a level, etc.

That would effectively be what you want to do. Granted, this post is likely to spawn MANY more questions, but at least it's a start.