In the first image you see the first playable version of amap. At that stage all gameplay was implemented, but far from being polished. Basically no work on terrain (the temple area was copied from another map).
In the second image you'll see the same map but many versions later. There is better spacing, the allies now are at seperate bases, the temple is closer and so on and I did tons of work on triggers.
In the third image you'll see the final version with terrain. Gameplay is almost the same, except for the small protoss base at the right side. I added some minerals and changes the space to support an additional player expansion. I made this change after "finishing" the terrain; and you can imagine that it took more than just a few minutes to fix that base. It would have been easier if that was done prior to adding any terrain.
What I mean to say is, if you work on terrain before gameplay, you make it very hard to refine any gameplay elements that are based on the layout...
Strongly agreed. We certainly learned this lesson (over and over) working on Episode 3. There are several maps that experienced significant reorganizations that required scrapping terrain work. :-(
I see your point but I think the more important tenet you're trying to get at here is "plan your map before you make it."
For me, it just doesn't make sense to terrain first because it takes WAY longer to load the map if there are tons of doodads everywhere, and because I do a lot of data work that needs fine-tuning, I'd spend half my time staring at the loading screen. I spent probably 5 total hours sketching out ideas on paper though before I finalize a design.
Quote from Bilxor:
I see your point but I think the more important tenet you're trying to get at here is "plan your map before you make it."
Not even that. Sure, you should have all features planned somehow, but I also think some people might overplan things. I mean, not every idea that sounds good on paper actually is good. So my goal is to get a prototype/playable version out as quickly as possible and then refine that. Having something to play with also helps staying motivated to work on the rest.
Also, I suck at drawing. If you want something to laugh at look at these crudes drawings for SotX Chapters 6 (child's stuff) and 7 (improved child's stuff). And then the notes I took for some things in Chapter 2 (the point and click adventure): http://imgur.com/a/TXshI
As a painter using galaxy i hate this.. for me it is "how long can i refrain from doing terrain".. i know i should leave it and chastise myself until it is time, but i never manage :D .
And to go further .. there is always something wrong with the terrain.. you have to test gameplay/events/layout for hours/weeks before any "eye candy" should be added! this to simply "see" the map working (or not :) ).
Since it is very long to do the core of the map.. i always indulge before it is time..
because lets face it.. a super fun game gives you the game itself, but making up a world visually is the best game in itself ever.. no?
ps: my advice? Make "terrain map where you do paint your ideas (enables you not to forget them or to never get frustrated, always paint when you feel like painting, doing it when you feel like it is the best recipe for success (at least personal success).. and then, when the time is right copy paste it in or watch your "template" closely and re do.
pps: as i draw to the close of my map, i am in the process of adding "clues" "cues" that lead the users on to event areas (propelling story/objectives etc) and these are the knot of the issue..
because there i HAVE to do all the layers concurrently and test and re arrange etc, until the gameplay works itself WITH the terrain (some like me would say "despite" it :D )
Since i am aiming to hide stuff in plain sight the terrain tools' potential/assets are vital as gameplay features as well!
Seriously though; you make a good point, but I think it differs person to person. I've often found myself coming up with storylines and gameplay based exactly on what I end up creating with terrain (both in SC2 as well as other games). I rarely work on a more solid plan than "this terrain should consist of an X on planet Y, featuring perhaps some Z". Some folks plan and work when it comes to this, some work and plan as they go along. I don't think one way is necessarily better than the other, though guarding for a playable map is nevertheless a good thing to be reminded of.
The primary thing to remember is that, whatever main area one starts with first (mechanics, storyline scripting, triggers, terrain), tends to couple everything else to it. Now, one SHOULD strive to have as much decoupling as possible, but I recognize that is hard even for software engineers, let alone those who are simply looking to making a fun game. So usually one tends to work on the thing they know best and everything else revolves around that.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
(having this discussion every so often. Maybe someone will listen if I shout it out :D)
STOP WORKING ON TERRAIN FIRST!
Please look at the images here: http://imgur.com/a/xkM10
In the first image you see the first playable version of amap. At that stage all gameplay was implemented, but far from being polished. Basically no work on terrain (the temple area was copied from another map).
In the second image you'll see the same map but many versions later. There is better spacing, the allies now are at seperate bases, the temple is closer and so on and I did tons of work on triggers.
In the third image you'll see the final version with terrain. Gameplay is almost the same, except for the small protoss base at the right side. I added some minerals and changes the space to support an additional player expansion. I made this change after "finishing" the terrain; and you can imagine that it took more than just a few minutes to fix that base. It would have been easier if that was done prior to adding any terrain.
What I mean to say is, if you work on terrain before gameplay, you make it very hard to refine any gameplay elements that are based on the layout...
If you are interested in more, read this: http://www.worldofleveldesign.com/categories/level_design_tutorials/art_of_blocking_in_your_map.php
Strongly agreed. We certainly learned this lesson (over and over) working on Episode 3. There are several maps that experienced significant reorganizations that required scrapping terrain work. :-(
I see your point but I think the more important tenet you're trying to get at here is "plan your map before you make it."
For me, it just doesn't make sense to terrain first because it takes WAY longer to load the map if there are tons of doodads everywhere, and because I do a lot of data work that needs fine-tuning, I'd spend half my time staring at the loading screen. I spent probably 5 total hours sketching out ideas on paper though before I finalize a design.
<Click Here> To See My Epic Single Player Campaign (LifeForceCampaign.com)
Quote from Bilxor:
I see your point but I think the more important tenet you're trying to get at here is "plan your map before you make it."
Not even that. Sure, you should have all features planned somehow, but I also think some people might overplan things. I mean, not every idea that sounds good on paper actually is good. So my goal is to get a prototype/playable version out as quickly as possible and then refine that. Having something to play with also helps staying motivated to work on the rest.
Also, I suck at drawing. If you want something to laugh at look at these crudes drawings for SotX Chapters 6 (child's stuff) and 7 (improved child's stuff). And then the notes I took for some things in Chapter 2 (the point and click adventure): http://imgur.com/a/TXshI
This is actually quite useful.
I keep making that mistake by terraining before doing triggers.
As a painter using galaxy i hate this.. for me it is "how long can i refrain from doing terrain".. i know i should leave it and chastise myself until it is time, but i never manage :D .
And to go further .. there is always something wrong with the terrain.. you have to test gameplay/events/layout for hours/weeks before any "eye candy" should be added! this to simply "see" the map working (or not :) ).
Since it is very long to do the core of the map.. i always indulge before it is time..
because lets face it.. a super fun game gives you the game itself, but making up a world visually is the best game in itself ever.. no?
ps: my advice? Make "terrain map where you do paint your ideas (enables you not to forget them or to never get frustrated, always paint when you feel like painting, doing it when you feel like it is the best recipe for success (at least personal success).. and then, when the time is right copy paste it in or watch your "template" closely and re do.
pps: as i draw to the close of my map, i am in the process of adding "clues" "cues" that lead the users on to event areas (propelling story/objectives etc) and these are the knot of the issue..
because there i HAVE to do all the layers concurrently and test and re arrange etc, until the gameplay works itself WITH the terrain (some like me would say "despite" it :D )
Since i am aiming to hide stuff in plain sight the terrain tools' potential/assets are vital as gameplay features as well!
I can't condone this advice :P
Seriously though; you make a good point, but I think it differs person to person. I've often found myself coming up with storylines and gameplay based exactly on what I end up creating with terrain (both in SC2 as well as other games). I rarely work on a more solid plan than "this terrain should consist of an X on planet Y, featuring perhaps some Z". Some folks plan and work when it comes to this, some work and plan as they go along. I don't think one way is necessarily better than the other, though guarding for a playable map is nevertheless a good thing to be reminded of.
@Mozared: Go
This is a very good point.
The primary thing to remember is that, whatever main area one starts with first (mechanics, storyline scripting, triggers, terrain), tends to couple everything else to it. Now, one SHOULD strive to have as much decoupling as possible, but I recognize that is hard even for software engineers, let alone those who are simply looking to making a fun game. So usually one tends to work on the thing they know best and everything else revolves around that.