Hello everyone! Recently I decided to start sc2 mapmaking by making a TD. I've decided on my map, gamestyle etc. Currently I've my player bases, spawn system, paths... But I don't know where to go next.
I'm planning on many stuff but technically I've no idea how to, or if even they are possible. Stuff that I know that is possible.. I'm not sure where to start! Is this a common feeling?
Not creating the thread to get an idea on what I exactly should do next (although feel free to suggest), but talk about how you approach your design and how it evolved over time.
Personally I like working on paper alot, I've currently written lots of stuff. I just don't have the technicality to make them happen:) But I guess persistance is a good solution for that.
Technically it doesn't really matter where your start, but I recommend beginning with the terrain. Find yourself a tutorial to start with (here is mine and here is Blizzards) and make sure you get the basic lay out done first.
Then you can probably go with data editing, for which tutorials probably are a good place to start as well. Once that's done, all that's really left is the triggering, where you actually implement the wave spawns, score counter and that jazz. When you've finished that, you can get to polishing and balancing, if you so desire.
Generally these three professions are musts for every map you create, with the only exceptions being melee maps, and custom maps that use melee balance/units (i.e. maps where you don't need to create any new custom units; think "micro arena"-style maps).
The order doesn't matter too much (and larger projects often have multiple people working on all of them at the same time), but as a basic rule of thumb, go Terrain>Data Editing>Triggers. This means you first create an area to work with, then the units to place in this area, and then the triggers that actually places them there. Sticking to this order prevents small annoyances where you've got half your map triggered but can't set the right unit for your "spawn unit of unit type X" because "unit type X" simply hasn't been created yet.
In larger projects, modeling/skinning/voice acting, cinematics and/or storyline creation are generally added as needed, but for a single map these processes tend to be so small that you can either skip them completely (modeling/skinning/voice acting & cinematics) or simply do them yourself in a couple of minutes (storyline creation).
The order doesn't matter too much (and larger projects often have multiple people working on all of them at the same time), but as a basic rule of thumb, go Terrain>Data Editing>Triggers.
QFT
There are certain work-arounds to not being able to reference a certain data object, like creating the variables, and then referencing the variables instead of the objects, and once you have the objects created you set the variables, which takes up a lot of variables space. This allows for easy customization, because if you want to change the unit/spell/whatever you can just modify the variable instead of finding each and every object.
You should jump around so that you have as much playable at any one time as possible. Don't just do all the triggers, then all the data, then all the terrain.
If it's a TD, make the terrain for a single lane, the triggers for a single level, the data for a single level, etc.
Don't sit around and try and think of ideas. Only add ideas that come to you spontaneously. If you have to look for content to add, it will probably suck. You just have to hope you get lucky and the ideas that pop into your head turn out to be good.
Technical knowledge helps a lot. Most ideas for edited data and gameplay are variations of existing ideas. The mind is structured like a graph, and information is accessed by traversing it. New ideas are always connected to existing information in your head.
A good grasp of irony and sarcasm helps a lot. The ability to analyze elements and construct ironic responses is similar to the ability to come up with unique gameplay. It is a very similar process. For example, most players have preconceptions of what an object or unit would do based on its appearance, stats, etc. Constructing an ironic or sarcastic statement is similar in the sense that you are taking the listeners' assumptions and turning them upside down. The same goes for unique units and gameplay. You start with something familiar and distort and twist and play with the players' assumptions.
For terrain, especially for a TD: It must be simple and memorable. Symmetric and well-defined. The natural cliffs are much worse for TD terrain because their edges are not well-defined; they are rough. Rough edges do not leave as much an impression as defined edges. Having terrain that sticks in the head of players is very important for TD's.
Lastly, don't stick to conventions or order. It makes development slow and bad. I'm sure you'll see many people forcing themselves as well as berating others to use data whenever possible and never triggers. Ignore this. These people are stupid. Do whatever it is that makes development absolutely easiest unless there is a noticeable performance hit. It is extremely rare for any triggers to cause lag (mouse / keyboard triggers do not cause lag; they merely suffer from lag). You're only going to script the map in a laggy fashion if you are stupid.
The most important: Add content in an order such that every addition increases the playability. Don't add more units when the map's playability is limited by a lack of triggers. If you wisely pace yourself, you can release the map publicly when you are 1/4 or 1/5 complete. If the map becomes popular, it will give you the motivation you need to continue to update. If not, and you don't foresee any major changes, then give up. If your idea or skill is bad, minor incremental additions won't help anything.
I think I get you Maelstrom. It is so much easier to just let the ideas flow than have them all drift away because there's a technical detail I need to investigate and get working for me.
So yes, I write down everything I could when the moment of inspiration comes. Sometimes they strike while I zombie paint a map, or texture something.
It is also easier to plan, and revamp ideas while they're still on paper.
Then comes the implementation.
Sometimes, I go with what I have, having no ideas more to write, and refine. Next day, there comes ideas again.
I guess what I'm saying is go with your own rhythm. But the most valuable warning we could get, when it comes to these, is to not get swamped by too many things to do and think of, and going too much into detail that the big picture is missed.
It is well and good for some to have each day something finished and working. It doesn't matter what they are, they may as well be just concepts. The important thing is you find satisfaction every day from what you are doing.
Rollback Post to RevisionRollBack
Whatever you do, wholeheartedly, moment by heartfelt moment, becomes a tool for the expression of your very soul.
as a basic rule of thumb, go Terrain>Data Editing>Triggers
From my experience as terrain artist (read: level designer) for an MMORPG it actually makes sense to make rough terrain at first, then you do scripting (triggering) and after that is done you are left doing 2 things in the same time: polishing terrain and polishing scripts.
The thing is you might spend days/weeks/monthes... on terrain and suddenly it appears that you have to change a lot of stuff losing a lot of time. Been there, done that. Bad planning ruins stuff, motivation, takes too much time to fix.
I tend to go for the most technically challenging aspects because those have the highest risk of not working as planned or outright failing. You may have to modify everything else to fit these unforeseen changes. On the flip side, you may discover something cool that you want to implement while playing with the editor, but you have to change all your terrain or units to take advantage of it. No point in putting a lot of effort into terrain or units early on if they end up not working with the final version.
I use placeholders until I get the game working properly, then I start adding everything else to take advantage of my strengths and cover up the weaknesses. I also use a ton of dialogs to display data for debugging purposes since you don't really need a UI at this point. If it's an ambitious project then odds are that your final product will be a bit different than what you initially set out to do. One of the hardest things to do is stop improving the map because learning the editor has a snowball effect of opening up more and more cool things that are simply too awesome not to do, even if you have to go back and rework things to accommodate them.
Thats really not good because some complex things require combinations of data, Triggers and Terrain. Plus when you have it, you then have to change it as you add more things in. It's best to do things like that later so you can fit it around your map rather than having to change your map design to fit that one idea.
Because it seems the majority of people end up shying away from data editing after using the editor for a while. Yes, it's complicated and often just plain stupid, however it's the most essential part of the editor.
Triggers are easy to learn, and terraining is more about perfectionism and reiteration than any kind of acquired skill.
i think it's best to decide what you're going to do on paper.. then facepalm on the most useful part of galaxy (useful for a td= triggers)
terrain/camera/lights and models/actors are what music is to arts in general: muses
You get a visual interface with what you are doing ;) and boy is it much more rewarding quickly: you get a "tangible" appeasing moral boost by seeing what your involvement/passion made)
coding is awful... you have lines upon lines upon.. once in a while you testplay and that's great ;)
you spend lot's of time manufacturing code and the result of your work is "displaced" (you get the result through an already savory interface ie the game)
so to sum up:
@themaelstorm
focus on what you need and relax with what you have (personally i relax with writing, painting (so texturing and terraining in sc2) and while i hate coding, i still think it's the most interesting thing to loose eyesight (or sanity) over...
May your galaxy be polished and original
(not necessarily in that order)
All in all, as with (I would argue) everything, I reckon the truth is probably in the middle. While I'd argue for going Terrain>Data>Triggers simply to keep things chronological, people like Vexal make a good point in that jumping about creates the most creativity and makes it less boring. Not so much of an "I finished terraining, up next is a full week of boring data editing to do, god help me T_T" feeling. I reckon in a perfect world where you'd have endless time and no real 'emotions', going terrain>data>triggering would be 'optimal' in terms of never having to use placeholders and just getting the map done as fast as possible. In the real world, it's probably more of a case of 'what you feel like doing'.
All in all, as with (I would argue) everything, I reckon the truth is probably in the middle. While I'd argue for going Terrain>Data>Triggers simply to keep things chronological, people like Vexal make a good point in that jumping about creates the most creativity and makes it less boring. Not so much of an "I finished terraining, up next is a full week of boring data editing to do, god help me T_T" feeling. I reckon in a perfect world where you'd have endless time and no real 'emotions', going terrain>data>triggering would be 'optimal' in terms of never having to use placeholders and just getting the map done as fast as possible. In the real world, it's probably more of a case of 'what you feel like doing'.
well said imo.
Rollback Post to RevisionRollBack
Random Information
Tutorials - Map Development - Galaxy wiki
|Issues? PM me|
I don't understand why anyone would do data before triggers. You can have placeholder units for testing gameplay, but you can't have placeholder triggers.
The sooner you get the map playable, the better. I released my TD with only 5 towers and made more towers over the course of the next few days. I would never have been able to finish making towers without the motivation from seeing the map popular.
I also wouldn't have been able to release it if I made all the data but only 5 triggers.
I don't understand why anyone would do data before triggers.
It's mostly because this; "The sooner you get the map playable, the better." isn't true for everyone. In your case, you maybe 'needed the motivation' or 'wanted to get it out there quickly'. Some people tackle a project by getting the whole thing as close to done as possible, and then alpha/beta testing it for another month to work out all the little ripples before they finally release it. The pro of doing data before triggers is the same as doing terrain before any of those - you already have something to work with and expand upon that, rather than beginning 'somewhere halfway' and having to use your imagination and placeholders by saying "yeah I've got a rough idea of what I'll put here sooner or later, but for now that'll do". If you end up changing stuff, you might have to redo a lot of this. That chance is lessened if you go brainstorming > terrain > data > triggers. If you know exactly what your triggers are going to look like, it's just a 'quick job that needs to be done'.
Compare it to Blizzard not starting the production of a game by programming an engine, but by drawing sketches and making up the lore for it first - once that's laid out, then they'll start the engine to run all of it.
My favorite advice from this thread (Not in order):
Technically it doesn't really matter where you start - (As long as you get it all done efficiently)
Bad planning ruins stuff like motivation, and takes too much time to fix
It is also easier to plan, and revamp ideas while they're still on paper. Then comes the implementation.
Rough Terrain -> Game Functionality -> Polish
Simply, some things will require you to do other parts before you do them - and theres no rule about this. Its different in different situations. Because of this, despite any pre-made plans you'll have you'll wind up jumping from place to place.
In my opinion, theres two things that are most important when approaching map creation: Avoiding losing motivation, and planning.
If you lose motivation - blaaaah.. All of you work comes to nothing, because you can't make yourself work on it. There are lots of things that can cause it, such as:
1. No more inspiration, or a general lack of enthusiasm you had when starting. (It might help to plan more extensively so you have something to go by once you lose inspiration. Either way, its sort of bad to rely purely on your first sense of excitement, because once that wears off you may have trouble finishing your project.)
2. Fear of the more difficult parts (such as data editing). The best way to avoid this is - and nobody wants to hear it - spend a lot of time just learning the editor before you actually start on the project.
3. Having doubts anyone will want to play it, etc. I think planning (or critically thinking over the core mechanics of your map) before starting could help with this - you need to actually think if the "cool idea" you had will actually work out as a fun map.
4. Seems like too much work, too big of a task - you have too little time, and its slow - going. Well, you might just be aiming to big and have to trim back your plans and just expand on it later.
For the second point, planning: Simply, if you don't think about the core of your map before starting it, theres a big chance that eventually its design flaws will cause it to come crashing down around you. Even if the map appears to have come out fine, you may have failed to look at it from the point of your common player, who might just plain not find the map appealing.
As for actually creating it, I usually do a) what I feel is most important and b) what I have the best idea of how I want it to be. Theres no point in making something you'll have to entirely recreate later - or get rid of, if you decide it isn't good. c) Chronologically - the core of the map first.
In other words, I don't do it by category - triggers, data, terrain - but just what I think best for arriving at my goals.
Even if it isn't the first thing, though, I usually create a rough terrain as far as pathing goes, so I can place other things down around it. (Regions, Points, Units) Its sort of sloppy to have them in utterly random places, even if you can move them later.
Also would like to note its different depending on the type of map your making. Some simply revolve around, or depend on, different things more then others.
Just my 2 cents. =) I agree with Mozared, an interesting topic - I meant to reply earlier
@Mozareds latest post: Ehh, its important to get it playable so you can test it for more major flaws that are only apparent in a "playable version" - just how the map as a whole works out. Of course, too soon and so much is missing that you won't really help you even if it is playable.
Hello everyone! Recently I decided to start sc2 mapmaking by making a TD. I've decided on my map, gamestyle etc. Currently I've my player bases, spawn system, paths... But I don't know where to go next. I'm planning on many stuff but technically I've no idea how to, or if even they are possible. Stuff that I know that is possible.. I'm not sure where to start! Is this a common feeling?
Not creating the thread to get an idea on what I exactly should do next (although feel free to suggest), but talk about how you approach your design and how it evolved over time.
Personally I like working on paper alot, I've currently written lots of stuff. I just don't have the technicality to make them happen:) But I guess persistance is a good solution for that.
Technically it doesn't really matter where your start, but I recommend beginning with the terrain. Find yourself a tutorial to start with (here is mine and here is Blizzards) and make sure you get the basic lay out done first.
Then you can probably go with data editing, for which tutorials probably are a good place to start as well. Once that's done, all that's really left is the triggering, where you actually implement the wave spawns, score counter and that jazz. When you've finished that, you can get to polishing and balancing, if you so desire.
Generally these three professions are musts for every map you create, with the only exceptions being melee maps, and custom maps that use melee balance/units (i.e. maps where you don't need to create any new custom units; think "micro arena"-style maps).
The order doesn't matter too much (and larger projects often have multiple people working on all of them at the same time), but as a basic rule of thumb, go Terrain>Data Editing>Triggers. This means you first create an area to work with, then the units to place in this area, and then the triggers that actually places them there. Sticking to this order prevents small annoyances where you've got half your map triggered but can't set the right unit for your "spawn unit of unit type X" because "unit type X" simply hasn't been created yet.
In larger projects, modeling/skinning/voice acting, cinematics and/or storyline creation are generally added as needed, but for a single map these processes tend to be so small that you can either skip them completely (modeling/skinning/voice acting & cinematics) or simply do them yourself in a couple of minutes (storyline creation).
Nobody but me? I thought the post had a fairly interesting subject :(
QFT
There are certain work-arounds to not being able to reference a certain data object, like creating the variables, and then referencing the variables instead of the objects, and once you have the objects created you set the variables, which takes up a lot of variables space. This allows for easy customization, because if you want to change the unit/spell/whatever you can just modify the variable instead of finding each and every object.
I think you pretty much covered the subject. =P
I disagree with a systematic approach.
You should jump around so that you have as much playable at any one time as possible. Don't just do all the triggers, then all the data, then all the terrain.
If it's a TD, make the terrain for a single lane, the triggers for a single level, the data for a single level, etc.
Don't sit around and try and think of ideas. Only add ideas that come to you spontaneously. If you have to look for content to add, it will probably suck. You just have to hope you get lucky and the ideas that pop into your head turn out to be good.
Technical knowledge helps a lot. Most ideas for edited data and gameplay are variations of existing ideas. The mind is structured like a graph, and information is accessed by traversing it. New ideas are always connected to existing information in your head.
A good grasp of irony and sarcasm helps a lot. The ability to analyze elements and construct ironic responses is similar to the ability to come up with unique gameplay. It is a very similar process. For example, most players have preconceptions of what an object or unit would do based on its appearance, stats, etc. Constructing an ironic or sarcastic statement is similar in the sense that you are taking the listeners' assumptions and turning them upside down. The same goes for unique units and gameplay. You start with something familiar and distort and twist and play with the players' assumptions.
For terrain, especially for a TD: It must be simple and memorable. Symmetric and well-defined. The natural cliffs are much worse for TD terrain because their edges are not well-defined; they are rough. Rough edges do not leave as much an impression as defined edges. Having terrain that sticks in the head of players is very important for TD's.
Lastly, don't stick to conventions or order. It makes development slow and bad. I'm sure you'll see many people forcing themselves as well as berating others to use data whenever possible and never triggers. Ignore this. These people are stupid. Do whatever it is that makes development absolutely easiest unless there is a noticeable performance hit. It is extremely rare for any triggers to cause lag (mouse / keyboard triggers do not cause lag; they merely suffer from lag). You're only going to script the map in a laggy fashion if you are stupid.
The most important: Add content in an order such that every addition increases the playability. Don't add more units when the map's playability is limited by a lack of triggers. If you wisely pace yourself, you can release the map publicly when you are 1/4 or 1/5 complete. If the map becomes popular, it will give you the motivation you need to continue to update. If not, and you don't foresee any major changes, then give up. If your idea or skill is bad, minor incremental additions won't help anything.
I think I get you Maelstrom. It is so much easier to just let the ideas flow than have them all drift away because there's a technical detail I need to investigate and get working for me.
So yes, I write down everything I could when the moment of inspiration comes. Sometimes they strike while I zombie paint a map, or texture something.
It is also easier to plan, and revamp ideas while they're still on paper.
Then comes the implementation.
Sometimes, I go with what I have, having no ideas more to write, and refine. Next day, there comes ideas again.
I guess what I'm saying is go with your own rhythm. But the most valuable warning we could get, when it comes to these, is to not get swamped by too many things to do and think of, and going too much into detail that the big picture is missed.
It is well and good for some to have each day something finished and working. It doesn't matter what they are, they may as well be just concepts. The important thing is you find satisfaction every day from what you are doing.
Whatever you do, wholeheartedly, moment by heartfelt moment, becomes a tool for the expression of your very soul.
From my experience as terrain artist (read: level designer) for an MMORPG it actually makes sense to make rough terrain at first, then you do scripting (triggering) and after that is done you are left doing 2 things in the same time: polishing terrain and polishing scripts. The thing is you might spend days/weeks/monthes... on terrain and suddenly it appears that you have to change a lot of stuff losing a lot of time. Been there, done that. Bad planning ruins stuff, motivation, takes too much time to fix.
..... Terrain should be last in my book.
Terrain has no effect on game play other then pathing...
from a technical stand point....
Personally I think it should go Data>Triggers>Terrain, although it's all really preference.
Like unit187 said, Rough Terrain -> Game Functionality -> Polish
You need a general layout before you can script everything, and the game needs to function before it makes sense to add the bells and whistles.
I tend to go for the most technically challenging aspects because those have the highest risk of not working as planned or outright failing. You may have to modify everything else to fit these unforeseen changes. On the flip side, you may discover something cool that you want to implement while playing with the editor, but you have to change all your terrain or units to take advantage of it. No point in putting a lot of effort into terrain or units early on if they end up not working with the final version.
I use placeholders until I get the game working properly, then I start adding everything else to take advantage of my strengths and cover up the weaknesses. I also use a ton of dialogs to display data for debugging purposes since you don't really need a UI at this point. If it's an ambitious project then odds are that your final product will be a bit different than what you initially set out to do. One of the hardest things to do is stop improving the map because learning the editor has a snowball effect of opening up more and more cool things that are simply too awesome not to do, even if you have to go back and rework things to accommodate them.
@Foolish_Fool: Go
Thats really not good because some complex things require combinations of data, Triggers and Terrain. Plus when you have it, you then have to change it as you add more things in. It's best to do things like that later so you can fit it around your map rather than having to change your map design to fit that one idea.
I would start with the data editor.
Why?
Because it seems the majority of people end up shying away from data editing after using the editor for a while. Yes, it's complicated and often just plain stupid, however it's the most essential part of the editor.
Triggers are easy to learn, and terraining is more about perfectionism and reiteration than any kind of acquired skill.
@Mozared
i got turned off by the TD heading :(
i think it's best to decide what you're going to do on paper.. then facepalm on the most useful part of galaxy (useful for a td= triggers)
terrain/camera/lights and models/actors are what music is to arts in general: muses
You get a visual interface with what you are doing ;) and boy is it much more rewarding quickly: you get a "tangible" appeasing moral boost by seeing what your involvement/passion made)
coding is awful... you have lines upon lines upon.. once in a while you testplay and that's great ;)
you spend lot's of time manufacturing code and the result of your work is "displaced" (you get the result through an already savory interface ie the game)
so to sum up:
@themaelstorm
focus on what you need and relax with what you have (personally i relax with writing, painting (so texturing and terraining in sc2) and while i hate coding, i still think it's the most interesting thing to loose eyesight (or sanity) over...
May your galaxy be polished and original
(not necessarily in that order)
;)
All in all, as with (I would argue) everything, I reckon the truth is probably in the middle. While I'd argue for going Terrain>Data>Triggers simply to keep things chronological, people like Vexal make a good point in that jumping about creates the most creativity and makes it less boring. Not so much of an "I finished terraining, up next is a full week of boring data editing to do, god help me T_T" feeling. I reckon in a perfect world where you'd have endless time and no real 'emotions', going terrain>data>triggering would be 'optimal' in terms of never having to use placeholders and just getting the map done as fast as possible. In the real world, it's probably more of a case of 'what you feel like doing'.
well said imo.
I don't understand why anyone would do data before triggers. You can have placeholder units for testing gameplay, but you can't have placeholder triggers.
The sooner you get the map playable, the better. I released my TD with only 5 towers and made more towers over the course of the next few days. I would never have been able to finish making towers without the motivation from seeing the map popular.
I also wouldn't have been able to release it if I made all the data but only 5 triggers.
Do triggers first.
It's mostly because this; "The sooner you get the map playable, the better." isn't true for everyone. In your case, you maybe 'needed the motivation' or 'wanted to get it out there quickly'. Some people tackle a project by getting the whole thing as close to done as possible, and then alpha/beta testing it for another month to work out all the little ripples before they finally release it. The pro of doing data before triggers is the same as doing terrain before any of those - you already have something to work with and expand upon that, rather than beginning 'somewhere halfway' and having to use your imagination and placeholders by saying "yeah I've got a rough idea of what I'll put here sooner or later, but for now that'll do". If you end up changing stuff, you might have to redo a lot of this. That chance is lessened if you go brainstorming > terrain > data > triggers. If you know exactly what your triggers are going to look like, it's just a 'quick job that needs to be done'.
Compare it to Blizzard not starting the production of a game by programming an engine, but by drawing sketches and making up the lore for it first - once that's laid out, then they'll start the engine to run all of it.
My favorite advice from this thread (Not in order):
Technically it doesn't really matter where you start - (As long as you get it all done efficiently)
Bad planning ruins stuff like motivation, and takes too much time to fix
It is also easier to plan, and revamp ideas while they're still on paper. Then comes the implementation.
Rough Terrain -> Game Functionality -> Polish
Simply, some things will require you to do other parts before you do them - and theres no rule about this. Its different in different situations. Because of this, despite any pre-made plans you'll have you'll wind up jumping from place to place.
In my opinion, theres two things that are most important when approaching map creation: Avoiding losing motivation, and planning.
If you lose motivation - blaaaah.. All of you work comes to nothing, because you can't make yourself work on it. There are lots of things that can cause it, such as:
1. No more inspiration, or a general lack of enthusiasm you had when starting. (It might help to plan more extensively so you have something to go by once you lose inspiration. Either way, its sort of bad to rely purely on your first sense of excitement, because once that wears off you may have trouble finishing your project.)
2. Fear of the more difficult parts (such as data editing). The best way to avoid this is - and nobody wants to hear it - spend a lot of time just learning the editor before you actually start on the project.
3. Having doubts anyone will want to play it, etc. I think planning (or critically thinking over the core mechanics of your map) before starting could help with this - you need to actually think if the "cool idea" you had will actually work out as a fun map.
4. Seems like too much work, too big of a task - you have too little time, and its slow - going. Well, you might just be aiming to big and have to trim back your plans and just expand on it later.
For the second point, planning: Simply, if you don't think about the core of your map before starting it, theres a big chance that eventually its design flaws will cause it to come crashing down around you. Even if the map appears to have come out fine, you may have failed to look at it from the point of your common player, who might just plain not find the map appealing.
As for actually creating it, I usually do a) what I feel is most important and b) what I have the best idea of how I want it to be. Theres no point in making something you'll have to entirely recreate later - or get rid of, if you decide it isn't good. c) Chronologically - the core of the map first.
In other words, I don't do it by category - triggers, data, terrain - but just what I think best for arriving at my goals.
Even if it isn't the first thing, though, I usually create a rough terrain as far as pathing goes, so I can place other things down around it. (Regions, Points, Units) Its sort of sloppy to have them in utterly random places, even if you can move them later.
Also would like to note its different depending on the type of map your making. Some simply revolve around, or depend on, different things more then others.
Just my 2 cents. =) I agree with Mozared, an interesting topic - I meant to reply earlier
@Mozareds latest post: Ehh, its important to get it playable so you can test it for more major flaws that are only apparent in a "playable version" - just how the map as a whole works out. Of course, too soon and so much is missing that you won't really help you even if it is playable.
@Mozared: Go
Am I the only person who's released a popular map in the manner described in my previous post? Does no one else do it this way?
I personally can't even begin to comprehend the notion of planning and doing things in order.