I'm creating a map, and some things are turning out more sloppy than I'd like. I'm arranging things as best I can, using records to store similar variables, creating functions and actions to handle common tasks, encapsulating existing functions to get specific consistent results out of them, etc. But I'm still getting long, confusing is/else or switch statements, occasionally changing my variable data's structure, etc. This often is something I'll just deal with, but I expect to include new people on this project if its going to be finished, and I need them to be able to understand what's going on when they join.
I'd like to know if somebody who is good at making really clean code could help me out, either through just general suggestions, or directly answering some of my issues.
Your title is a bit misleading, I reckon. I know plenty of stuff about project design, but barely anything about triggering - yet I can't really answer your opening post, I think.
Galaxy has some notable limitations when it comes to OOP, specially the fact that you can't pass neither structs nor function pointer/references at all, which makes certain design patterns more complicated than they should. Thankfully some galaxy preprocessors help alleviate this.
For multiple ifs/switch case statements, usually you can replace it with an observer pattern. Here is an example with a faux elemental damage system:
//rather than a potnetially huge amount of conditional statements....fixedGetElementalDamage(fixedamount,damagetyped,armortypeat){fixedtotal=0;if(d==FIRE){if(at==WATER)total=amount*2;if(at==FIRE)total=-amount;if(at==EARTH)total=amount*0.5;//etc}elseif(d==ICE){//etc}//etc...returntotal;}// you could have a more robust and third party scalable Damage HandlervoidRegisterDamageVSArmor(damagetyped,armortypeat,fixedpercentage){DataTableSetFixed(d,at,percentage);}fixedGetDamageVSArmor(damagetyped,armortypeat){returnDataTableGetFixed(d,at);}fixedGetElementalDamage(fixedamount,damagetyped,armortypeat){returnamount*GetDamageVSArmor(damagetyped,armortypeat);}fixedElementalDamageSystemInit(){RegisterDamageVSArmor(FIRE,ICE,2);RegisterDamageVSArmor(FIRE,FIRE,-1);RegisterDamageVSArmor(FIRE,EARTH,0.5);RegisterDamageVSArmor(FIRE,AIR,0.1);RegisterDamageVSArmor(FIRE,DIVINE,0);RegisterDamageVSArmor(ICE,ICE,-1);RegisterDamageVSArmor(ICE,FIRE,2);//ETC}
Good project design will still alleviate my problem of regularly changing my data structure.
If I'm changing the parameters a function takes a couple times a day, there's definately some lack of planning going on. How much should I plan out before beginning to do any work? There's some balance to achieve, because if I have no plan my work will be sloppy and disjointed. If I plan the entire project before working on it, and find 5 hours in that Plan System 3 isn't something I know how to make, I'm not going to be able to fit the design.
@Alevice:
I haven't really noticed Data Tables before. Is there any general situation where I should consider using them?
@OutsiderXE:
Initialization code is a lot simpler than most other triggers. Do you have any pictures of more complicated but well ordered triggers?
Good project design will still alleviate my problem of regularly changing my data structure.
If I'm changing the parameters a function takes a couple times a day, there's definately some lack of planning going on. How much should I plan out before beginning to do any work? There's some balance to achieve, because if I have no plan my work will be sloppy and disjointed. If I plan the entire project before working on it, and find 5 hours in that Plan System 3 isn't something I know how to make, I'm not going to be able to fit the design.
I think you're mixing up terms. I see where you're coming from, but project design is "What kind of map am I making? What will the players be doing for the majority of the time? What tools are at their command? How should I balance this map? Do I have any lore behind it?". What you need is to trigger in a more orderly fashion - not a lot of trigger changes should make place if you change the answers you've given to the questions I just asked, unless of course you decide to radically throw your map around every other day (start off as a hero defense, then decide for DOTA gameplay, then focus on ORPG instead, etc), and nobody really does that.
The trigger organization OutsiderXE has is the same as Blizzard's in the campaign, you should (at least briefly) look at every map in there.
I had the problem of constantly redesigning and changing stuff. I learned that I was doing it with bottom-up design and that (the whole lecture is great). it basically means that if you look at your design like a tree - start with the top branches, not with the roots.
The scope of your query has more to do specifically with software devlopment methodology, project design overall expand waaay further than just the scope of programming.
Development process on non professional projects is quite mutable and often involves finding a best practice you are comfortable with. That said, developing a complex system should normally entail a model you evaluated and designed first, either on paper, pseudocode, a proof of concept prototype, etc. There are tools and language paradigms that intend to help out with this stuff. OOP features, UML tools, etc, etc.
Please note that a moderatedly good familiarity with the language and its APIs you are developing with will help make less design changes, because you clearly grasp its capabilities. It is normal that your first projects will be prone to rewritings due to uncontemplated limitations.
Data Tables in Galaxy are normally useful when you need to store data (orly?) that needs to survive the scope it was created from and need a way to index/categorize them where a standard array (which just uses numbers as indices) is not ideal. For example, say you are making a country simulator and you have countries and need to store their population and other elements, you could do something like this:
DataTableSetInteger("Italy","Population",10000);//...DataTableSetInteger("France","Wealth",25);//...DataTableGetString("Spain","Capitol");// would return Madrid, assuming you had stored it before
It's important to organise things not just in your map, but in your head too. I find that if I work on a map for too long in one session, parts of it get muddled in my mind. When I take a break, it helps sort the muddle out mentally and after that I have a clearer picture of the whole project. Basically, my advice is to make sure you understand your map every step of the way, and take frequent breaks to reflect on what you've done in your session.
Comment the shit out of your code, use a lot of whitespace, and don't make a function extremely confusing to shorten it slightly. Typically I write everything out that I'm programming in a kind of flow chart... although I have doubts as to whether or not other people understand it. You just need to find a method so you know what everything is doing (or rather, SHOULD be doing), at any given time.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I'm creating a map, and some things are turning out more sloppy than I'd like. I'm arranging things as best I can, using records to store similar variables, creating functions and actions to handle common tasks, encapsulating existing functions to get specific consistent results out of them, etc. But I'm still getting long, confusing is/else or switch statements, occasionally changing my variable data's structure, etc. This often is something I'll just deal with, but I expect to include new people on this project if its going to be finished, and I need them to be able to understand what's going on when they join.
I'd like to know if somebody who is good at making really clean code could help me out, either through just general suggestions, or directly answering some of my issues.
When triggering, Use Comments and folders. It can make life so much easier, especially if something is broken, and you have 100's of triggers.
@A52BcE: Go
Your title is a bit misleading, I reckon. I know plenty of stuff about project design, but barely anything about triggering - yet I can't really answer your opening post, I think.
This is more related to programming design patterns than to project design.
Galaxy has some notable limitations when it comes to OOP, specially the fact that you can't pass neither structs nor function pointer/references at all, which makes certain design patterns more complicated than they should. Thankfully some galaxy preprocessors help alleviate this.
For multiple ifs/switch case statements, usually you can replace it with an observer pattern. Here is an example with a faux elemental damage system:
Go play Antioch Chronicles Remastered!
Also, coming soon, Antioch Episode 3: Thoughts in Chaos!
Dont like mapster's ugly white? Try Mapster's Classic Skin!
http://1.bp.blogspot.com/_zZn3BwjLi4g/TSylu7z1v5I/AAAAAAAAAco/ZmJDBt4XI3I/s1600/sotx01editor04.jpg
@Mozared:
Good project design will still alleviate my problem of regularly changing my data structure.
If I'm changing the parameters a function takes a couple times a day, there's definately some lack of planning going on. How much should I plan out before beginning to do any work? There's some balance to achieve, because if I have no plan my work will be sloppy and disjointed. If I plan the entire project before working on it, and find 5 hours in that Plan System 3 isn't something I know how to make, I'm not going to be able to fit the design.
@Alevice:
I haven't really noticed Data Tables before. Is there any general situation where I should consider using them?
@OutsiderXE:
Initialization code is a lot simpler than most other triggers. Do you have any pictures of more complicated but well ordered triggers?
I think you're mixing up terms. I see where you're coming from, but project design is "What kind of map am I making? What will the players be doing for the majority of the time? What tools are at their command? How should I balance this map? Do I have any lore behind it?". What you need is to trigger in a more orderly fashion - not a lot of trigger changes should make place if you change the answers you've given to the questions I just asked, unless of course you decide to radically throw your map around every other day (start off as a hero defense, then decide for DOTA gameplay, then focus on ORPG instead, etc), and nobody really does that.
The trigger organization OutsiderXE has is the same as Blizzard's in the campaign, you should (at least briefly) look at every map in there.
I had the problem of constantly redesigning and changing stuff. I learned that I was doing it with bottom-up design and that (the whole lecture is great). it basically means that if you look at your design like a tree - start with the top branches, not with the roots.
The scope of your query has more to do specifically with software devlopment methodology, project design overall expand waaay further than just the scope of programming.
Development process on non professional projects is quite mutable and often involves finding a best practice you are comfortable with. That said, developing a complex system should normally entail a model you evaluated and designed first, either on paper, pseudocode, a proof of concept prototype, etc. There are tools and language paradigms that intend to help out with this stuff. OOP features, UML tools, etc, etc.
Please note that a moderatedly good familiarity with the language and its APIs you are developing with will help make less design changes, because you clearly grasp its capabilities. It is normal that your first projects will be prone to rewritings due to uncontemplated limitations.
Data Tables in Galaxy are normally useful when you need to store data (orly?) that needs to survive the scope it was created from and need a way to index/categorize them where a standard array (which just uses numbers as indices) is not ideal. For example, say you are making a country simulator and you have countries and need to store their population and other elements, you could do something like this:
Go play Antioch Chronicles Remastered!
Also, coming soon, Antioch Episode 3: Thoughts in Chaos!
Dont like mapster's ugly white? Try Mapster's Classic Skin!
It's important to organise things not just in your map, but in your head too. I find that if I work on a map for too long in one session, parts of it get muddled in my mind. When I take a break, it helps sort the muddle out mentally and after that I have a clearer picture of the whole project. Basically, my advice is to make sure you understand your map every step of the way, and take frequent breaks to reflect on what you've done in your session.
Comment the shit out of your code, use a lot of whitespace, and don't make a function extremely confusing to shorten it slightly. Typically I write everything out that I'm programming in a kind of flow chart... although I have doubts as to whether or not other people understand it. You just need to find a method so you know what everything is doing (or rather, SHOULD be doing), at any given time.