Jademus and I have talked about this a lot casually in IRC, but I don't think anyone's ever really made a post about it. The things that make Galaxy strong are it's speed of development, file-based modularity, and support for things such as constants in array declaration.
Probably the strongest plus-side of Galaxy is that we can export individual files as a library for a simple "include" statement, and have someone else using it in seconds. Also, since Galaxy is inherently plaintext, glancing over the library before importing is extremely easy. With the benefit of even the half-broken "static" modifier, we can hide library's internal mechanics and organize our code in a much cleaner fashion.
If we really want to showcase Galaxy like JASS was in WC3, we need to start making our own code in our maps modular, and uploading generic libraries to this forum, or the Assets section of Mapster (don't forget to leave a note here, too!).
So my challenge to you Galaxy programmers is over the next few weeks, to look at your map's code, improve it by modularizing it, and then post the modularized libraries in this forum.
I'll start by listing some libraries I've been working on.
We also need to start standardizing our code. What I've found works for me best is:
Library prefix: libLibraryName_
(Applied to all private/public functions, as well as any variables in the global scope. This prevents collisions with other libraries)
Ex:
Constant prefix: c_libNameVariableName
(Applied to any constants in the global scope. This method is consistent with Blizzard's Galaxy coding style.)
Ex:
In addition, if people agree, I think we should begin using typedef to suggest parameter values.
We could come up with a standard "Types.galaxy" which just has stuff like...
typedef int player_t;
typedef int unitflags_t;
Since this kind of shared dependency couldn't just be included in every library, we could implement a dependency notation, so that the map author knows to include these dependencies ahead of including your library.
Ex:
//#include <Types.galaxy>
This kind of commented C-style include is pretty distinctive and would be a heads up.
Oh, does static work? I thought it was as broken as custom GUI events.
Having a standard like we do with vJass would be a good idea, though I doubt we have a strong enough Galaxy base to begin with. Even neatly organized script won't bring more people to actually use it since GUI interfaces are quickly and easily written.
If Galaxy just had some more functionality it'd be easier to overcome the problems that appear with packing libraries..
GUI also lets you centralize your organization. For including outside libraries I just use custom script for the include part and everything else is managable from there. As it stands there's really no incentive to use galaxy over GUI for me.
GUI is also slow, contorted, and mangled with inefficiencies. In the time it takes me to write out some arithmetic in GUI, I could've written a whole function in Galaxy.
thats why i do all the arithmetic in custom script :p
I find GUI to be faster honestly. All the time I sit there writing the syntax could be spent actually writing the functions themselves. Not that it takes exorbitantly long but there's also the fact that GUI prevents typos, its just convenient. Then again I have a beast of a rig so the GUI runs smoothly and quick for me. I have little to no downtime with it, and like I said, I can organize things much more easily using the labels and whatnot. Then there's also the other editors right at my fingertips, data, terrain, etc.
I use the custom script function for things that are a little bit tedious to do in the GUI, but thankfully they do have the custom script option for value entry.
This isn't really a topic on GUI vs Galaxy anyways. For me, and most of the users of this forum, typing out a function name is just faster than finding it in that horrible GUI list, which makes Galaxy a win. Using SC2 Component Lists, you can edit your Galaxy right alongside the editor in real-time, too.
The problem this post tries to address extends to GUI, anyways, as well. There just aren't a whole lot of simple, standalone SC2 libraries, whether GUI or Galaxy. They're hardcoded, or imprecise, or just not usable outside of one specific use.
I propose a formatting standard for variables as well. Basically, naming conventions that make it easier to know what variables are.
Precede constant names with a 'c'
Precede global names with a 'g'
Constants and globals would have their type attached followed by an underscore before their actual name.
Example: const int ci_DummyInteger
Local variables have no precedence for convenience purposes.
Local variables should only be at most 1-3 alphabets long, to help distinct them from constants or globals.
Use pascal-case for naming conventions. (Or was it camel case? I can't remember. The one where first letter is always upper case)
Depending on the type of variable, always name with the following. (Trying to be minimalist)
int i
fixed f
string s
text txt
unit u
playergroup g
sound snd
trigger t
unitgroup ug
Multiple instances of the same type would of course be catered for either by using arrays or having i i2 etc. I personally find i,i2,...,in easier to track than using an array though.
Theres more but i can't remember them all. These of course would be combined with 'c' or 'g' if they are constants or globals.
Struct names should always suffixed with 'Info'
For example struct PlayerInfo
When declaring the size of the struct, always precede 's_' before the struct name for easier recognition at a later time.
PlayerInfo[ci_PlayerCount] s_pi;
When designing functions. Have the parameters follow the convention where possible. Alternatively add a comment above the function denoting what each of the types actually represent. For example, 'i' might be the player number.
I don't think we'll have any kind of success enforcing style as far as local variables go. As long as people follow some sense of convention with globals and functions though, we should avoid any trouble with conflicting variables.
Also with additional complexity comes additional mistakes, or it may reach a point where people simply don't want to follow a complicated standard and refuse to comply.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Jademus and I have talked about this a lot casually in IRC, but I don't think anyone's ever really made a post about it. The things that make Galaxy strong are it's speed of development, file-based modularity, and support for things such as constants in array declaration.
Probably the strongest plus-side of Galaxy is that we can export individual files as a library for a simple "include" statement, and have someone else using it in seconds. Also, since Galaxy is inherently plaintext, glancing over the library before importing is extremely easy. With the benefit of even the half-broken "static" modifier, we can hide library's internal mechanics and organize our code in a much cleaner fashion.
If we really want to showcase Galaxy like JASS was in WC3, we need to start making our own code in our maps modular, and uploading generic libraries to this forum, or the Assets section of Mapster (don't forget to leave a note here, too!).
So my challenge to you Galaxy programmers is over the next few weeks, to look at your map's code, improve it by modularizing it, and then post the modularized libraries in this forum.
I'll start by listing some libraries I've been working on.
Modified Melee Library based on Phantom Mode, with enhanced configuration options
https://github.com/Motive/LibPhantom
Dialog-based WoW-style action bar GUI drawing
https://github.com/Motive/CortexEngine/blob/master/Common/lib/libactionbar.galaxy
We also need to start standardizing our code. What I've found works for me best is:
Library prefix: libLibraryName_
(Applied to all private/public functions, as well as any variables in the global scope. This prevents collisions with other libraries)
Ex:
Constant prefix: c_libNameVariableName
(Applied to any constants in the global scope. This method is consistent with Blizzard's Galaxy coding style.)
Ex:
In addition, if people agree, I think we should begin using typedef to suggest parameter values.
We could come up with a standard "Types.galaxy" which just has stuff like...
typedef int player_t;
typedef int unitflags_t;
Since this kind of shared dependency couldn't just be included in every library, we could implement a dependency notation, so that the map author knows to include these dependencies ahead of including your library.
Ex:
//#include <Types.galaxy>This kind of commented C-style include is pretty distinctive and would be a heads up.
Oh, does static work? I thought it was as broken as custom GUI events.
Having a standard like we do with vJass would be a good idea, though I doubt we have a strong enough Galaxy base to begin with. Even neatly organized script won't bring more people to actually use it since GUI interfaces are quickly and easily written.
If Galaxy just had some more functionality it'd be easier to overcome the problems that appear with packing libraries..
GUI also lets you centralize your organization. For including outside libraries I just use custom script for the include part and everything else is managable from there. As it stands there's really no incentive to use galaxy over GUI for me.
@Mephs: Go
GUI is also slow, contorted, and mangled with inefficiencies. In the time it takes me to write out some arithmetic in GUI, I could've written a whole function in Galaxy.
@MotiveMe: Go
thats why i do all the arithmetic in custom script :p
I find GUI to be faster honestly. All the time I sit there writing the syntax could be spent actually writing the functions themselves. Not that it takes exorbitantly long but there's also the fact that GUI prevents typos, its just convenient. Then again I have a beast of a rig so the GUI runs smoothly and quick for me. I have little to no downtime with it, and like I said, I can organize things much more easily using the labels and whatnot. Then there's also the other editors right at my fingertips, data, terrain, etc.
I use the custom script function for things that are a little bit tedious to do in the GUI, but thankfully they do have the custom script option for value entry.
This isn't really a topic on GUI vs Galaxy anyways. For me, and most of the users of this forum, typing out a function name is just faster than finding it in that horrible GUI list, which makes Galaxy a win. Using SC2 Component Lists, you can edit your Galaxy right alongside the editor in real-time, too.
@MotiveMe: Go
Yea its just preference really. Just really saying its easy to just pop in an include line into your script if you want to use library structure.
The problem this post tries to address extends to GUI, anyways, as well. There just aren't a whole lot of simple, standalone SC2 libraries, whether GUI or Galaxy. They're hardcoded, or imprecise, or just not usable outside of one specific use.
I propose a formatting standard for variables as well. Basically, naming conventions that make it easier to know what variables are.
Depending on the type of variable, always name with the following. (Trying to be minimalist)
Multiple instances of the same type would of course be catered for either by using arrays or having i i2 etc. I personally find i,i2,...,in easier to track than using an array though.
Theres more but i can't remember them all. These of course would be combined with 'c' or 'g' if they are constants or globals.
When designing functions. Have the parameters follow the convention where possible. Alternatively add a comment above the function denoting what each of the types actually represent. For example, 'i' might be the player number.
I don't think we'll have any kind of success enforcing style as far as local variables go. As long as people follow some sense of convention with globals and functions though, we should avoid any trouble with conflicting variables.
Also with additional complexity comes additional mistakes, or it may reach a point where people simply don't want to follow a complicated standard and refuse to comply.