For a good map 5 years start to finish using a team of 5+ map makers.
I'm glad the video games industry doesn't work as slowly as you do. :D
Seriously though, any kind of project in SC2 shouldn't take more than 3 months to be done (if made alone), it doesn't mean it cannot be improved later. The core should be done pretty quick, what takes the most time is usually visual effects and polishing (gameplay, pathing, performance,...).
@Mozared: Go
There is no boreing part to terraining :D
Not true, unfortunately. Just talking about SC2 here but pathing is a pain, when you have to manage where air units can or cannot go it's boring as hell. When you have to move and/or remove props to make sure the way is clear where it needs to be, it's a pain (especially for melee maps, the whole balance depends on it). When you have to put path and/or sight blockers in your map by hundreds (if not thousands), it's also very boring. When you have to reduce the number of doodads so that the map won't lag on BNet, it's even a suicide. :D
Making a map doesn't require a team; it requires patience and time. If time is at a premium, the prudent thing to do is to form a team, which permits the delegation of tasks to better distribute labor and lower development time. But often when someone says "I need a team", the person lacks the character to complete the project on its own (and probably won't complete the project even with a team) and would rather employ the specialties of others than learn to use the tools available.
I agree with Mozared that there is no boring part of terraining. Good terrain has its own narrative, a subtle story in its arrangements. Telling that story through the terrain is the responsibility of the terrainer, and you'll only find boredom if you have no story to tell; what could be more dull than a directionless random assortment of terrain features?
I agree with Mozared that there is no boring part of terraining. Good terrain has its own narrative, a subtle story in its arrangements. Telling that story through the terrain is the responsibility of the terrainer, and you'll only find boredom if you have no story to tell; what could be more dull than a directionless random assortment of terrain features?
You mean you agree with TaintedWisp; he's the one who said that in a reply to my post. I disagreed with him somewhere at the end of page 1 :)
Making a map doesn't require a team; it requires patience and time. If time is at a premium, the prudent thing to do is to form a team, which permits the delegation of tasks to better distribute labor and lower development time. But often when someone says "I need a team", the person lacks the character to complete the project on its own (and probably won't complete the project even with a team) and would rather employ the specialties of others than learn to use the tools available.
Hmm, I don't think I agree with this per se. I'm sure that anyone with enough intellect to actually look into the SC2 editor is mentally capable of learning all the tools. As in: if you put a gun to their heads, they'd be able to make use of all tools and create a map by themselves. Whether a map 'requires' a team or not is a question of semantics - I've got technically enough time to make a map, but prefer working in a team so I can do specialized stuff. Simply because I don't care enough for stuff that isn't terraining to get into it. Theoretically I could do that other stuff, but since I simply don't like it I don't want to, making a team fairly mandatory for me to ever finish a project.
Projects in SC2 very well cab and some should take more than three months to complete. I've been working on "Rise of Nigma" for about 5 months now, and we're still not at beta yet.
Which is why I said it is prudent to form a team, but not necessary. When people say they need a team, they're often using the idea of a team as a crutch to support their self-image as a competent developer, evidence to the contrary. Instead of accepting fault for the inability to complete projects, some would-be developers make assertions that absolve them of responsibility for self-improvement. Similar to how pansies say "girls don't like nice guys," while completely overlooking their own faults that make them undesirable.
As the topic has changed to "teams" I do wonder...
I have never had another person directly help with my map. The biggest barrier for me is that; while I am working on something, if there is a problem, I know exactly how I triggered everything, everything I changed in the data editor, and every doodad I placed. I can easily track down a problem. Or even, if I were to want to change a system around. If someone else implemented it with all of their variables, I would need to study the whole thing for a while before I could safely dismantle it and recreate something that could do the same thing.
It just seems like it would take entirely too much faith in another person to be on the same page as you and work the same way you would to accomplish something.
You "team players" do you ever run into anything like that? or is it usually broken up so no one is actually touching someone else's work? One guy makes units, one guy makes abilities, one guy makes the terrain, another makes triggers? Which then would seem less like a "team" and more like an "assembly line"
Well sure, but you're making it sound like any mapper who says he wants to work in a team is either too lazy or sucky to learn the other tools of the editor. A lot of people (like me) make a conscious decision to focus on one aspect so they can A) perfect that and B) don't have to bother with aspects of the editor they don't like. That's all I wanted to point out, really. I think most of the types you're talking about are folks who couldn't really make a good map alone either.
While I agree Focusing on ONE aspect is the BEST thing to do, I also think people should try to learn the Basics of the data and triggers,
Because everytime I terrain Edit I have to open the data editor, and the triggers(sometimes) Weather it is Importing new Textures, or simply changing the music(i count music as terrain)
No matter which one you pick you will NEED the others too.
Map making in the video games industry is teamwork. It's not only to meet deadlines and reduce development cost, it's also because we expect each guy in the team to be specialized in what he does (Mozared is right about that). If you have an interview with a pro for a job in level design, the first thing he'll ask is "are you more of a world builder, more into placing props, or more into scripting?" (real life experience here). There is no such thing as a "level designer god" who's able to handle the 3 parts on its own (OK, as far as I can tell there are 2 or 3 of them... in the entire world, and I'm not kidding). I really suck at scripting so I'm really glad someone could do this part for me and/or help in case I need something.
I have never had another person directly help with my map. The biggest barrier for me is that; while I am working on something, if there is a problem, I know exactly how I triggered everything, everything I changed in the data editor, and every doodad I placed. I can easily track down a problem. Or even, if I were to want to change a system around. If someone else implemented it with all of their variables, I would need to study the whole thing for a while before I could safely dismantle it and recreate something that could do the same thing.
That's also true. But the thing is it's not only about teamwork. There is also a magic tool called NOMENCLATURE. You can't work efficiently as a team in the example you just gave, because it's not really a team. It's more like everyone in your so-called team is trying to do it his own way, which ends up in a pretty messy work obviously. It happens a lot with amateurs, but it's because they are not organized enough. And amateurs are probably too proud of themselves, not really willing to work as a team... As I said many times, level design is a job, not anybody can do it and it's not as easy as it seems... I know how to cook noodles, it doesn't mean I can open a restaurant tomorrow.
Working as a team means planning things, prior to making them. When everyone is OK with what they have to do, there's no trouble and it goes fluently. No such thing as "hey, who the hell changed the name of my variable? I lost 2 days of work here!"... When a version goes wrong, we know exactly which day it happened, so we know who was in charge, and what is messed up. It sometimes look like an "assembly line" indeed, but who told you level design is not repetitive in the first place? Every job has its flaws. You have no choice but to repeat the same tasks again and again, in fact you have 3 times more of them when you work alone... Your dedication (hell yeah, I'm back on topic!) is more likely to fade when you work alone, you'll be overwhelmed at some point with tons of things to do that you don't really know how to handle. Sorry about the wall of text (again). :)
Yep, you need to know a little bit of all the aspects of course, but what matters when you're in a team is to be the best in the group for at least one particular task. People need to be able to rely on you when it's needed.
Haha, my point of contention is not the legitimate formation of teams, but rather those who pretend that forming a team will compensate for their character faults, mainly their inability to complete their projects. One would do well to not mischaracterize my position; I include a number of caveats that acknowledge the value of team development.
If you don't like any part of mapmaking, plan your map to avoid these parts.
For example, I hate creating dialogs, so I made my last map without. Some ppl don't like to use triggers, so they work hard to create everything with data.
If you hate polishing, make everything polished at once. Don't add raw features, add totally completed things which you won't need to return to. If you don't like balancing, create balance system before implementing everything in data.
Creating a map without the most essential part of the genre is pretty counterintuitive, wouldn't you say? (;
-As someone said above, it seems to me as if teams, to some extent, make mapmaking more complicated. I started working in a team myself with a couple of others (taintedwisp included), and it seems as if the disorganization will still be there even if you're as organized as possible.
Maps that take under 3 months come and go like seeds on fallow earth. Quality = man hours so the longlevity of a map is proportional to the number of hours invested in making it and having a good unique idea that is not a new dota/aos/modified melee.
Also as for long development times with real game developers, Final Fantasy and Duke Nukem spring to mind among others.
As for not bothering to learn or at least understand other parts of the data editor, you often end up lacking tools that could improve your area of speciality. To pick on you Mozared, you have not yet realized the potential of custom tile sets with unique foliage, and your mastery of actors is near nonexistant. You have lost out on some of the most fundamental parts of exceptional terraining (eg conditional scale changers, texture swaps, animations, hidden models that animate other visible ones, colour tints and more).
I couldn't have said it better myself. Basically Tofu has hardly changed from nearly a year ago when we made _that_ video, but all the work we have done since then is just polishing graphics, spell effects, making the code more efficient etc ... it still plays the same but looks 100 times better. There is no faster way to do this, because you are constantly looking for bugs, thinking of ways to make it better, it takes time. No map made in 3 months will ever be the quality of a map which has had a solid year just for polishing. (As the doctor said; anything with a new idea that isn't a clone).
I run into the problem of not being able to think outside the box when it comes to mixing the world of data with the trigger editor. Many times I have been talking to Dryeyece about a new idea, and he has said, "You know I can do that in Data right?" ... Tofu is such a mix of data and scripting it isn't funny. So many events require a specific built data side to function, without Dryeyece knowing what he is doing, we couldn't have done all the shit we have. So I agree with Mozza lacking the required skills to really take his terraining to the next level, because of a lack of data knowledge ... but not to worry, I probably have less data knowledge than him.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I'm glad the video games industry doesn't work as slowly as you do. :D
Seriously though, any kind of project in SC2 shouldn't take more than 3 months to be done (if made alone), it doesn't mean it cannot be improved later. The core should be done pretty quick, what takes the most time is usually visual effects and polishing (gameplay, pathing, performance,...).
Quoted for truth, words of wisdom award.
Not true, unfortunately. Just talking about SC2 here but pathing is a pain, when you have to manage where air units can or cannot go it's boring as hell. When you have to move and/or remove props to make sure the way is clear where it needs to be, it's a pain (especially for melee maps, the whole balance depends on it). When you have to put path and/or sight blockers in your map by hundreds (if not thousands), it's also very boring. When you have to reduce the number of doodads so that the map won't lag on BNet, it's even a suicide. :D
Making a map doesn't require a team; it requires patience and time. If time is at a premium, the prudent thing to do is to form a team, which permits the delegation of tasks to better distribute labor and lower development time. But often when someone says "I need a team", the person lacks the character to complete the project on its own (and probably won't complete the project even with a team) and would rather employ the specialties of others than learn to use the tools available.
I agree with Mozared that there is no boring part of terraining. Good terrain has its own narrative, a subtle story in its arrangements. Telling that story through the terrain is the responsibility of the terrainer, and you'll only find boredom if you have no story to tell; what could be more dull than a directionless random assortment of terrain features?
You mean you agree with TaintedWisp; he's the one who said that in a reply to my post. I disagreed with him somewhere at the end of page 1 :)
Hmm, I don't think I agree with this per se. I'm sure that anyone with enough intellect to actually look into the SC2 editor is mentally capable of learning all the tools. As in: if you put a gun to their heads, they'd be able to make use of all tools and create a map by themselves. Whether a map 'requires' a team or not is a question of semantics - I've got technically enough time to make a map, but prefer working in a team so I can do specialized stuff. Simply because I don't care enough for stuff that isn't terraining to get into it. Theoretically I could do that other stuff, but since I simply don't like it I don't want to, making a team fairly mandatory for me to ever finish a project.
@ZealNaga: Go
Projects in SC2 very well cab and some should take more than three months to complete. I've been working on "Rise of Nigma" for about 5 months now, and we're still not at beta yet.
Which is why I said it is prudent to form a team, but not necessary. When people say they need a team, they're often using the idea of a team as a crutch to support their self-image as a competent developer, evidence to the contrary. Instead of accepting fault for the inability to complete projects, some would-be developers make assertions that absolve them of responsibility for self-improvement. Similar to how pansies say "girls don't like nice guys," while completely overlooking their own faults that make them undesirable.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumAs the topic has changed to "teams" I do wonder...
I have never had another person directly help with my map. The biggest barrier for me is that; while I am working on something, if there is a problem, I know exactly how I triggered everything, everything I changed in the data editor, and every doodad I placed. I can easily track down a problem. Or even, if I were to want to change a system around. If someone else implemented it with all of their variables, I would need to study the whole thing for a while before I could safely dismantle it and recreate something that could do the same thing.
It just seems like it would take entirely too much faith in another person to be on the same page as you and work the same way you would to accomplish something.
You "team players" do you ever run into anything like that? or is it usually broken up so no one is actually touching someone else's work? One guy makes units, one guy makes abilities, one guy makes the terrain, another makes triggers? Which then would seem less like a "team" and more like an "assembly line"
Skype: [email protected] Current Project: Custom Hero Arena! US: battlenet:://starcraft/map/1/263274 EU: battlenet:://starcraft/map/2/186418
@JademusSreg: Go
Well sure, but you're making it sound like any mapper who says he wants to work in a team is either too lazy or sucky to learn the other tools of the editor. A lot of people (like me) make a conscious decision to focus on one aspect so they can A) perfect that and B) don't have to bother with aspects of the editor they don't like. That's all I wanted to point out, really. I think most of the types you're talking about are folks who couldn't really make a good map alone either.
@Mozared: Go
While I agree Focusing on ONE aspect is the BEST thing to do, I also think people should try to learn the Basics of the data and triggers,
Because everytime I terrain Edit I have to open the data editor, and the triggers(sometimes) Weather it is Importing new Textures, or simply changing the music(i count music as terrain)
No matter which one you pick you will NEED the others too.
@JademusSreg: Go
Map making in the video games industry is teamwork. It's not only to meet deadlines and reduce development cost, it's also because we expect each guy in the team to be specialized in what he does (Mozared is right about that). If you have an interview with a pro for a job in level design, the first thing he'll ask is "are you more of a world builder, more into placing props, or more into scripting?" (real life experience here). There is no such thing as a "level designer god" who's able to handle the 3 parts on its own (OK, as far as I can tell there are 2 or 3 of them... in the entire world, and I'm not kidding). I really suck at scripting so I'm really glad someone could do this part for me and/or help in case I need something.
That's also true. But the thing is it's not only about teamwork. There is also a magic tool called NOMENCLATURE. You can't work efficiently as a team in the example you just gave, because it's not really a team. It's more like everyone in your so-called team is trying to do it his own way, which ends up in a pretty messy work obviously. It happens a lot with amateurs, but it's because they are not organized enough. And amateurs are probably too proud of themselves, not really willing to work as a team... As I said many times, level design is a job, not anybody can do it and it's not as easy as it seems... I know how to cook noodles, it doesn't mean I can open a restaurant tomorrow.
Working as a team means planning things, prior to making them. When everyone is OK with what they have to do, there's no trouble and it goes fluently. No such thing as "hey, who the hell changed the name of my variable? I lost 2 days of work here!"... When a version goes wrong, we know exactly which day it happened, so we know who was in charge, and what is messed up. It sometimes look like an "assembly line" indeed, but who told you level design is not repetitive in the first place? Every job has its flaws. You have no choice but to repeat the same tasks again and again, in fact you have 3 times more of them when you work alone... Your dedication (hell yeah, I'm back on topic!) is more likely to fade when you work alone, you'll be overwhelmed at some point with tons of things to do that you don't really know how to handle. Sorry about the wall of text (again). :)
@Taintedwisp: Go
Yep, you need to know a little bit of all the aspects of course, but what matters when you're in a team is to be the best in the group for at least one particular task. People need to be able to rely on you when it's needed.
Haha, my point of contention is not the legitimate formation of teams, but rather those who pretend that forming a team will compensate for their character faults, mainly their inability to complete their projects. One would do well to not mischaracterize my position; I include a number of caveats that acknowledge the value of team development.
Creating a map without the most essential part of the genre is pretty counterintuitive, wouldn't you say? (;
-As someone said above, it seems to me as if teams, to some extent, make mapmaking more complicated. I started working in a team myself with a couple of others (taintedwisp included), and it seems as if the disorganization will still be there even if you're as organized as possible.
@Neonsz: Go
Yeah Disorganization is a problem, but Im working on that.
Get 'er done.
-
View User Profile
-
View Posts
-
Send Message
Moderators@ZealNaga: Go
Maps that take under 3 months come and go like seeds on fallow earth. Quality = man hours so the longlevity of a map is proportional to the number of hours invested in making it and having a good unique idea that is not a new dota/aos/modified melee.
Also as for long development times with real game developers, Final Fantasy and Duke Nukem spring to mind among others.
@Mozared: Go
As for not bothering to learn or at least understand other parts of the data editor, you often end up lacking tools that could improve your area of speciality. To pick on you Mozared, you have not yet realized the potential of custom tile sets with unique foliage, and your mastery of actors is near nonexistant. You have lost out on some of the most fundamental parts of exceptional terraining (eg conditional scale changers, texture swaps, animations, hidden models that animate other visible ones, colour tints and more).
@JademusSreg: Go
Yeah, I put my project on hiatus because I realized how little I knew about the editor. The process of learning still continues.
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
@DrSuperEvil: Go
I couldn't have said it better myself. Basically Tofu has hardly changed from nearly a year ago when we made _that_ video, but all the work we have done since then is just polishing graphics, spell effects, making the code more efficient etc ... it still plays the same but looks 100 times better. There is no faster way to do this, because you are constantly looking for bugs, thinking of ways to make it better, it takes time. No map made in 3 months will ever be the quality of a map which has had a solid year just for polishing. (As the doctor said; anything with a new idea that isn't a clone).
I run into the problem of not being able to think outside the box when it comes to mixing the world of data with the trigger editor. Many times I have been talking to Dryeyece about a new idea, and he has said, "You know I can do that in Data right?" ... Tofu is such a mix of data and scripting it isn't funny. So many events require a specific built data side to function, without Dryeyece knowing what he is doing, we couldn't have done all the shit we have. So I agree with Mozza lacking the required skills to really take his terraining to the next level, because of a lack of data knowledge ... but not to worry, I probably have less data knowledge than him.