I probably don't know much about triggers but I can learn. I'm just wondering what order do you guys create your triggers. Does UI come last or do you do the major parts first or what. Do you start easy and build your way up? Also what are some good habbits to pick up?
I start with the core game mechanics first. These are the triggers you make before you even touch the Terrain Editor; before you have pre-placed points, regions, and units. e.g. do you have a hero-based attack or special controls that requires triggers? This is how I'm doing it.
I do it wrong way :l. Countless times I've told myself : "First, plan out everything, plan out all systems and how they will interact with each other, it'll save countless hours of needless code remaking/reforming ."
I usually don't have the patience. When I plan specific part of map I find myself coding it to see how it will be, to see if reality will meet my expectations. If it doesn't have the feeling that I'm searching for then I'll plan some more and try again. So I'd say I just spontaneously trigger things that I'm interested in ( try to make code as flexible as possible).
super pretty and fitting dialogs, text messages, catch triggers for leaving players, auto balance missing players etc are not important, they are created later usually
I'm currently in recreating 9 month old triggers to a new, better system :)
Order i make triggers in (and to what detail/Completion)
Testable version of the map (Most basic spawning system, hero selection, defeat conditions, victory conditions, etc.)
Any triggers i need to continue testing the map without having everything in place (i.e. "Cheat codes" or things like unit spawns, resources, etc.)
Work my way through all systems i have to set up (in my current map it would be buying attributes, handling ability levels, handling other variables, etc.)
Finishing core mechanics (that i started in the first point) and other things important for gameplay (just to have it work, whether anyone understands the map isnt important)
User-friendlyness (Tutorials, help messages, understandable UI elements, everything a noob needs to be able to play)
Polishing everything
Basically the way i do it is i get the map into a state I can use it in so that i can develop the data and other aspects of it and test it properly, once i'm done with that, i complete the basic triggers and start making the map playable by other people by adding texts and dialogs and whatnot. So first priority is me being able to test, last priority is it being playable by other people.
Triggers will continuously change over the course of the map no matter which part you start with.
But like everyone else the fundamental parts of the map need to be designed first.
I also like creating my dialogs/leader boards and setting them up too.
But really it comes down to what you feel comfortable doing, code the parts you enjoy, your more likely to continue working on your project if your at least enjoying the work your doing.
It's not necessarily the wrong way. Complex programs start out as simple programs that work, not complex programs that don't work. If you implement one simple feature that works, you can build on top of it to make it more complex.
Some UI work may be necessary to make sure you can test things. But if you do need it, just get the dynamic information and buttons in there so you can make sure everything is working, don't worry about making it look nice till later.
When mapping in general it is often a good idea to do that hardest parts first. Because thats the time when you would either lose interest or encounter a fatal flaw which will prevent you from continuing. Best to not have a ton of other work already done, which would then go to waste. For that reason I've lately been trying to do my triggering first, before things like terrain, and cosmetic data editing.
I don't believe there is a specific order in which your triggers should be created, unless there is one dependant on another (Try to avoid this to reduce the risk of modding one system and breaking another). But yes, planning does help. Try make a list of all the systems you intend the map to have? Usually they would be independent of each other, and thus, it shouldn't really matter what order you code them in.
Group your systems nicely so its less confusing when you want to modify a specific one. Try not to put all your variables for all systems in the same place as it gets very confusing when you have many systems. Instead, use folders to arrange your systems in a way that all the triggers, functions and variables relevant to the system are in the same place. Instead of global arrays, use records to store player exclusive information, they are much more manageable as everything is within one block, as opposed to multiple lines.
Last and most importantly, have a player record that tracks player exclusive information. Store any variables that are shared across systems here. Such as player score, that might be used for your leader-board, and at the same time the level spawn for individual players. You would of course need to look at the big picture and try to identify what variables are shared between the systems on your map.
In summary:
Organize your systems such that they are independent of each other
Try to ensure systems remain independent of each other so that modifying one does not break another.
Have a player record for storing variables that are shared by multiple systems.
Makes things a lot cleaner when you want to debug/read your code.
Do the UI last. The most important stuff should come first, like movement and combat related triggers (all depends on the type of game). You will be doing a lot of tweaking, so it's good to make sure the main gears work.. and you can build new ideas as you're testing. Then once you have all of the variables you need, you can plug them into the UI.
I suppose UI does tend to have a dependency on many of the other things. So yeah, you have a good point. Noted.
That was directed to the OP actually, just my take on things. I like a lot of the points you made in your post.. especially because I still don't understand the point of arrays.
@Keyeszx: Go
I kind of just randomly build things as they catch my attention, which is probably why I don't have more than one map released. At least I'm having fun.
I generally do my map (Not just triggers) in this order:
Very rough terrain. As in, one texture, a cliff and a ramp
Data editing. I make my data stuff first because it makes it a lot easier to do triggers if you have all of it done (At this point I also make any hero specific triggers such as the zealot chef hat trigger)
First part of my core triggers (Mostly action definitions and map inits such as a TD wave spawning action)
Basic UI. Stuff like scoreboards and dialogs. Any SC2Layout files I would do after my map is mostly done unless It's really important
Make the terrain. I do this before finishing my core triggers so I have all the points and regions laid out when doing the triggering
Finish all core triggers. This is the point I usually release an alpha because it is halfway done (If I release an alpha then I do the loading screen and map variants now)
SC2Layout files if I need them
Finish auxiliary triggers. There are things like achievement stuff and bank saving
Loading Screen and Game Variants (If not already done)
Beta release
Bug fixes and balance changes
Full release
Updates such as new heroes, balance changes and bug fixes.
Not all triggers, but that's how I make my maps :).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I probably don't know much about triggers but I can learn. I'm just wondering what order do you guys create your triggers. Does UI come last or do you do the major parts first or what. Do you start easy and build your way up? Also what are some good habbits to pick up?
I start with the core game mechanics first. These are the triggers you make before you even touch the Terrain Editor; before you have pre-placed points, regions, and units. e.g. do you have a hero-based attack or special controls that requires triggers? This is how I'm doing it.
I do it wrong way :l. Countless times I've told myself : "First, plan out everything, plan out all systems and how they will interact with each other, it'll save countless hours of needless code remaking/reforming ."
I usually don't have the patience. When I plan specific part of map I find myself coding it to see how it will be, to see if reality will meet my expectations. If it doesn't have the feeling that I'm searching for then I'll plan some more and try again. So I'd say I just spontaneously trigger things that I'm interested in ( try to make code as flexible as possible).
First thing i do is remove default defeat trigger, it's so damn annoying if not dealt with early xD.
@DuckyTheDuck: Go
So I should plan it out first?
@SentryIII: Go
And core game mechanics should come first?
I think I'm going to start jotting down what exactly I need so I don't waste time.
Anything that defines gameplay and functionality comes first.
For example, when I made my RPG, the first thing I triggered was hero selection and the skill tree system. Then came hero abilities, items, etc.
super pretty and fitting dialogs, text messages, catch triggers for leaving players, auto balance missing players etc are not important, they are created later usually
I'm currently in recreating 9 month old triggers to a new, better system :)
Order i make triggers in (and to what detail/Completion)
Basically the way i do it is i get the map into a state I can use it in so that i can develop the data and other aspects of it and test it properly, once i'm done with that, i complete the basic triggers and start making the map playable by other people by adding texts and dialogs and whatnot. So first priority is me being able to test, last priority is it being playable by other people.
Triggers will continuously change over the course of the map no matter which part you start with.
But like everyone else the fundamental parts of the map need to be designed first.
I also like creating my dialogs/leader boards and setting them up too.
But really it comes down to what you feel comfortable doing, code the parts you enjoy, your more likely to continue working on your project if your at least enjoying the work your doing.
@DuckyTheDuck: Go
It's not necessarily the wrong way. Complex programs start out as simple programs that work, not complex programs that don't work. If you implement one simple feature that works, you can build on top of it to make it more complex.
Some UI work may be necessary to make sure you can test things. But if you do need it, just get the dynamic information and buttons in there so you can make sure everything is working, don't worry about making it look nice till later.
When mapping in general it is often a good idea to do that hardest parts first. Because thats the time when you would either lose interest or encounter a fatal flaw which will prevent you from continuing. Best to not have a ton of other work already done, which would then go to waste. For that reason I've lately been trying to do my triggering first, before things like terrain, and cosmetic data editing.
@Keyeszx: Go
I don't believe there is a specific order in which your triggers should be created, unless there is one dependant on another (Try to avoid this to reduce the risk of modding one system and breaking another). But yes, planning does help. Try make a list of all the systems you intend the map to have? Usually they would be independent of each other, and thus, it shouldn't really matter what order you code them in.
Group your systems nicely so its less confusing when you want to modify a specific one. Try not to put all your variables for all systems in the same place as it gets very confusing when you have many systems. Instead, use folders to arrange your systems in a way that all the triggers, functions and variables relevant to the system are in the same place. Instead of global arrays, use records to store player exclusive information, they are much more manageable as everything is within one block, as opposed to multiple lines.
Last and most importantly, have a player record that tracks player exclusive information. Store any variables that are shared across systems here. Such as player score, that might be used for your leader-board, and at the same time the level spawn for individual players. You would of course need to look at the big picture and try to identify what variables are shared between the systems on your map.
In summary:
Makes things a lot cleaner when you want to debug/read your code.
O.o
@deathtorn: Go
LOL, I was really sleepy when I wrote that. Thanks for pointing it out, Edited xD
@FuzzYD: Go
Do the UI last. The most important stuff should come first, like movement and combat related triggers (all depends on the type of game). You will be doing a lot of tweaking, so it's good to make sure the main gears work.. and you can build new ideas as you're testing. Then once you have all of the variables you need, you can plug them into the UI.
@voodude2008: Go
I suppose UI does tend to have a dependency on many of the other things. So yeah, you have a good point. Noted.
That was directed to the OP actually, just my take on things. I like a lot of the points you made in your post.. especially because I still don't understand the point of arrays.
@Keyeszx: Go
I kind of just randomly build things as they catch my attention, which is probably why I don't have more than one map released. At least I'm having fun.
Force yourself to do Top-down design or get ready for frustration and rewriting a lot of stuff :]
I generally do my map (Not just triggers) in this order:
Not all triggers, but that's how I make my maps :).