Flame on. This is the ENGINE development path. Once the game engine itself is finalized, priorities can move on to Battle.net 2.0, the campaign, arcade-style scripting (ie. Galaxy), the list goes on. You try making the followup to Starcraft 1 and let's see how that goes.
Bumping this as I'm fairly sure this could still be useful to the right project. There have been numerous updates to the code as far as functionality goes, but I haven't done too much more other than fix bugs. The code is now in another project's GitHub repository, but I can fork it if anyone is seriously interested in developing it.
Ultimately, I'd love to see someone take this and add a better targeting system to it, and maybe integrate it with the keyboard better. I'd love to see what the right mapper could do with it. :)
I figured we could use a thread to start documenting strange things about Galaxy that are undocumented by Blizzard. Some things I've noticed are below:
Galaxy scripts must end in a newline or else error line numbers will be significantly off or not work at all. This is a known issue by Blizzard, as their comments in the AI code confirm.
Bitwise operations cannot take place in a return statement. The safest way to perform these in Galaxy is in an if statement surrounded by parenthesis with a comparison to 0 outside of them.
Typedefs totally work! These work quite similar to how they would in Cxx, and let you make some 'custom' types which ultimately aid in readability, but don't affect how the compiler treats them.
Structs also work! They're great for organizing related blocks of data without having to duplicate arrays. These also work almost exactly like their Cxx counterparts.
New In Patch 1.5
All calls to StringTo<X> conversion native functions will result in exceptions if the input string is not already in the expected format. In the past you could rely on these returning the conversion type's default value, for example, 0 for int.
Past Behavior: StringToInt("marine") == 0
New Behavior: StringToInt("marine") throws a Galaxy runtime exception.
There are no documented methods of checking input prior to running the conversion natively.
I'd recommend not learning basic. A lot of what Taco Man said is frivilous, IMO. You don't need to know that << is the left bitshift operator in order to know that cout << "Hi" << cout::endl prints out stuff.
In this case, it's just an example of operator overloading for a buffer anyways, so knowing about left bitshifts wouldn't even help you. In fact, left bitshifts probably won't help you at all in your entire programming career unless you're doing something low level, or you want to save memory and use bit flags, but those are so way off it's just ridiculous to even concern yourself with them.
With that said, start simple. You're not going to be making games or anything like that any time soon. I'd recommend learning Ruby, or PHP, and starting on something you can easily see on your browser. Try making a website and add features to it. You can buy web hosting packages on the cheap. This will just teach you the basics of a programming language and how things flow. You don't have to use my suggestions for languages, I just don't recommend diving into Cxx or even C. Keep things simple for yourself. Hell, learn LUA. You can make WoW addons for practice. :P
Most importantly: explore. Don't be afraid to make mistakes, and use Google liberally to solve problems. The best programmers aren't the ones who can spit out 50 different cookie-cutter algorithms on demand, but the ones who know how to use the best solution for each problem, ie. with Google. :P
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.
Happy to help out. What you're doing is exactly what I did at first when figuring out Galaxy.
One minor point, you might want to change "while (i < 5)" to "while (i < array_count)". :)
You'll also want to change the declaration of "t" to be of type "point", not "int", as you're saving points in there.
You'll want to also keep your web browser open to this link: http://cortexrp.com/starcraft/natives.galaxy. That would be the SC2 Galaxy natives list. You'll find all the useful functions there.
I mean any kind of credentials at all, Author being one possible version. People coming in here and saying, "I heard x has problem with y" doesn't actually contribute any firsthand knowledge, and in a lot of cases, they're wrong.
There's a widespread belief in this community that any kind of mouse controls, key events, etc., instantly cause lag and make your map unplayable, which simply isn't the case at all.
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.
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.
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.
I wish people without the "Author" tag, or people who haven't actually worked on some kind of FPS engine wouldn't comment on how possible or not it is. There's a lot of misinformation out there on this subject.
My experience is that first person controls are perfectly do-able, and even bullets. You won't see perfect performance though, and you'll get a lot of people wondering why the controls aren't half as responsive as Counter-Strike's.
Personally, my problem with this project is just the originality. I don't think the idea will work on SC2. Technically though, I know that it's doable.
0
@Eiviyn: Go
Really impressive work, Eiviyn. Is that just a unit with a special footprint? I'd love to know how you accomplished that.
0
Flame on. This is the ENGINE development path. Once the game engine itself is finalized, priorities can move on to Battle.net 2.0, the campaign, arcade-style scripting (ie. Galaxy), the list goes on. You try making the followup to Starcraft 1 and let's see how that goes.
0
Bumping this as I'm fairly sure this could still be useful to the right project. There have been numerous updates to the code as far as functionality goes, but I haven't done too much more other than fix bugs. The code is now in another project's GitHub repository, but I can fork it if anyone is seriously interested in developing it.
https://github.com/Motive/CortexEngine/blob/master/Common/lib/libactionbar.galaxy
Ultimately, I'd love to see someone take this and add a better targeting system to it, and maybe integrate it with the keyboard better. I'd love to see what the right mapper could do with it. :)
0
I figured we could use a thread to start documenting strange things about Galaxy that are undocumented by Blizzard. Some things I've noticed are below:
New In Patch 1.5
Past Behavior: StringToInt("marine") == 0
New Behavior: StringToInt("marine") throws a Galaxy runtime exception.
There are no documented methods of checking input prior to running the conversion natively.
0
Yes.
0
@jangsy: Go
I'd recommend not learning basic. A lot of what Taco Man said is frivilous, IMO. You don't need to know that << is the left bitshift operator in order to know that cout << "Hi" << cout::endl prints out stuff.
In this case, it's just an example of operator overloading for a buffer anyways, so knowing about left bitshifts wouldn't even help you. In fact, left bitshifts probably won't help you at all in your entire programming career unless you're doing something low level, or you want to save memory and use bit flags, but those are so way off it's just ridiculous to even concern yourself with them.
With that said, start simple. You're not going to be making games or anything like that any time soon. I'd recommend learning Ruby, or PHP, and starting on something you can easily see on your browser. Try making a website and add features to it. You can buy web hosting packages on the cheap. This will just teach you the basics of a programming language and how things flow. You don't have to use my suggestions for languages, I just don't recommend diving into Cxx or even C. Keep things simple for yourself. Hell, learn LUA. You can make WoW addons for practice. :P
Most importantly: explore. Don't be afraid to make mistakes, and use Google liberally to solve problems. The best programmers aren't the ones who can spit out 50 different cookie-cutter algorithms on demand, but the ones who know how to use the best solution for each problem, ie. with Google. :P
0
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.
0
Happy to help out. What you're doing is exactly what I did at first when figuring out Galaxy.
One minor point, you might want to change "while (i < 5)" to "while (i < array_count)". :)
You'll also want to change the declaration of "t" to be of type "point", not "int", as you're saving points in there.
You'll want to also keep your web browser open to this link: http://cortexrp.com/starcraft/natives.galaxy. That would be the SC2 Galaxy natives list. You'll find all the useful functions there.
If you look closely, you'll find:
So it looks like you want...
...to spawn the unit itself.
Take a look at:
to actually tell the unit to do a specific order.
0
@sigmapl: Go
I mean any kind of credentials at all, Author being one possible version. People coming in here and saying, "I heard x has problem with y" doesn't actually contribute any firsthand knowledge, and in a lot of cases, they're wrong.
There's a widespread belief in this community that any kind of mouse controls, key events, etc., instantly cause lag and make your map unplayable, which simply isn't the case at all.
0
Since somebody's going to find out anyways...
0
God help us all.
0
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.
0
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.
0
@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.
0
I wish people without the "Author" tag, or people who haven't actually worked on some kind of FPS engine wouldn't comment on how possible or not it is. There's a lot of misinformation out there on this subject.
My experience is that first person controls are perfectly do-able, and even bullets. You won't see perfect performance though, and you'll get a lot of people wondering why the controls aren't half as responsive as Counter-Strike's.
Personally, my problem with this project is just the originality. I don't think the idea will work on SC2. Technically though, I know that it's doable.