I'm making a random dungeon generator, I've had this Idea knocking around my head and I decdied to actually make it, ONe thing I can't decide though is how to place the code. what i mean is, Should I place the code that generates and modifies data inside the object so in essence it modifies it's self or should I create a function that modifies the object that holds all the data.
My current idea is to have a class called Map and any dungeon generated has it's own map object that holds all data about the map, currently my idea is when i want to modify the map data it modifies it's self like so:

Map IceCave = Map.Create("IceCave01", "Ice Cave Entrance");

Icecave.Generate( 1, "cavern", 2, Cave_Ice,)

The other way would be to create an Ice cave object that only holds data and then use a function outside to modify, I'm not sure but one advantage would less memmory ussage, as It wold have to create entire copies of code inside the object for every object, but using the second way means only one set of code to modify data from outside the object.

Better style to have it as an external function if not the object's constructor imo. It's not like you're going to use the method again after the map has been generated
.

True,but i'm intending to create a full game, dungeon crawler with unlimited dungeons, that spawn each time you finish it, high score is how far u go, if i finish it.

I think it makes more sense to call map.Generate(blahblah blah) than GenerateMap(map). 1 is object oriented and cool, 2 is procedural and old.

as It wold have to create entire copies of code inside the object for every object

No, the objects do not hold copies of the methods inside them, unless you're using a weird language because most of them do not do that at all.

Calling a function isn't inherently procedural programming. Unless you think functional programming is procedural programming? (It's not.) Mixed paradigm is about being able to throw down whatever is appropriate. Strict OO is stuffy and weak.

I think strict OO is more empowering to the objects, so they're active and command their own destinies rather than passively accept whatever is imposed upon them. It's all about ideology.

Why would you want to empower objects? Programmers should do things that make life easy for them and other programmers or the end users of the program (possb the same people). Objects don't ever act in and of themselves. The different programming paradigms are different formal representations of the same underlying subject - turing computer software. The question at hand is whether or not strictly adhering to OO ideals is a good practice. I and many others think it's a mediocre practice. You'll get somewhere with it, but unless you can see the strengths and weaknesses of the different paradigms, there's only so many ways you can approach a problem. Some of the more elegant solutions won't be available to you. Writing parsers using a combinator library, for example.

Well Whats the advantage of using an external function instead of an internal one?

No, the objects do not hold copies of the methods inside them, unless you're using a weird language because most of them do not do that at all.

here's the answer. I think swords was worried about memory issues?

so it's really up to you how you do it.  advantage of external fucntion would be, other shit could access it. flexibilit or whatever but that depends on the game you're making so putting it inside the class is safer and cleaner i guess.

There's not much difference between the two. I think the external function is better stylistically because it makes the usage clearer, but it's a pretty minor distinction.

Well, that's one problem out of the way, The other is how to do create my own file type that stores all the data and how to make a tile based map editor (not to edit maps, at least not yet).

To make your own file type, just use file I/O. Ideally you'd make a spec for the file type and then implement a loader and saver for the spec, but you don't have to work that way. Here's a simple map data format:
CSV is shorthand for comma-separated value.
An example of this would be :
It's not what I'd call a good format, but it has the advantage of being very very easy to implement. All of the parsing can be done using knowledge from a one-semester intro to programming or a basic programming tutorial. Here's how:
1. To get the key/value pairs split lines on "=" and store in an appropriate data structure. If you know how to use a hash or dict, use that. Otherwise, either learn how or make an associative array of some sort. If you take my advice to strip spaces, do that before storing. If you think you can handle stripping spaces everywhere but inside quotes, do that instead.
2. Do the above until you reach a line that matches "## BEGIN MAP ##". You could use a nicer separator if you want, but this one has the advantage of being hard to fuck up.
3. Keep going, reading the lines, split by commas, into a 2D array. If you use an array and not a list, you'll have to do an initial pass to determine the max width and max height of the array.
4. Hooray you did it.
5. Writing is the reverse process of the above.

It's not the best format, but I'm pretty sure it's one of the easier ones.

Thanks, I can probably work out the editor on my own but I only have a minor idea on creating my own file type, Would if be possible to use a resource file to store multiple things together as one file? the idea i had for my map files would store multiple things, such as 3 layers (back, middle and for) a layer for event nodes and so on. I had the idea to store it all in one file but as seprate parts, like a small data archive with seprate files for each layer, then after each file is loaded into memmory I can access each part of the file as a  funtion like:

icecave.layer[1];

icecave.node[ID023123](blah blah blah);

I'm still documenting it but i'll get to writting a file spec later, need to go out right now.

Also what's this about? there's a lot I still don't know about when it comes to programming

That's my bullshit made up file spec shorthand. What I mean by that is as many rows as you like containing as much "X=Y" information as you like, ignoring spaces. This is so filetype users can store whatever information their program needs aside from tile IDS to make the map work.

If you want to have multiple layers, you could change ## BEGIN MAP ## to ##BEGIN LAYER ## and then when already loading tiles (as opposed to metadata), if you encounter another ## BEGIN LAYER ##, go to the next layer up. You'd then load the files into a 3D array instead of a 2D one.

The basic idea is that anything you can print on the console can go in a file and anything you can read as user input can be read from a file. In practice, this means there isn't much you can't save. The real problems come in the efficiency of storage, and those arise with much, much greater volumes of data (or volumes of data modification) than you're likely to deal with here.

I was thinking of using somthing like this as a file structure:
My idea is store each part as a seprate file but store all of them in one main file called a .map like an archive i think i could use a resource file for this, then i just access each file when i need it.

the Reason as to why i want to store it sepratelay is becuase i don't know How much of things will be stored, how many nodes, how big the map is, etc, a lot of those will be decided on runtime and generated as is.

The reason I' m storing relationships Is becuase I want to be able to link multiple things together and how they intereact is decided by a node type, that's defined seprately, so if i want i can create a chain of switchtches that need to be filmed or on a certain order and so on. I can do that becuase some of that maps will be generated from pre-made structures (rooms with puzzles) and some are random (with pre made puzzles randomly placed). some of the nodes arn't viable to the player, like gates and such, not, and, or, xor, etc, using those i can create interesting switch puzzles like for example like one that needs to be hit in the right order and so on.

you could put all of those in a single file, it's basically a matter of preference. i'm not a big fan of using lots of files personally but if you think it works for you then go for it. the only advice I can provide is that fiddling with the disk too frequently will make your program slow. this can occur in a single-file design just as much as a multiple file design though. also xml can be a bit of a waste / not fun to deal with. several languages have jquery-like libraries for dealing with xml. if you're familiar with css, I suggest giving one of those a shot.

I think i'll actuyally start coding this on the weekend, too busy during the week.

I think strict OO is more empowering to the objects, so they're active and command their own destinies rather than passively accept whatever is imposed upon them. It's all about ideology.

lol