Wouldnt it be easier to just copy script from GE to program ... Use syntax checker in program fix syntax errors copy code again, and paste back into GE?
I dont use the GE scripting personally. Havent found a need for it since The Trigger GUI handle everything Ive Tried to do so far.
I'm going to make the assumption here that most people who write large amounts of Galaxy do so in an outside editor and then import it. The internal text editor is pretty lousy, and pasting anything into it causes it to lock up while it checks the code.
Do you know that there exists point functions that should (at least when reading their names, haven't used them yet) return things you may need.
I'm not sure about the function name right now, but this one function returns the "pathingcost" (?) between two points. So have a try if this is the distance between the two points or some value which can be used as the distance. It's the same problem like we had in WC3 scripting, after several iterations you simply exceed the operation limit and you would need to use a wait.
I did some testing on the operation limit in WC3 and found a formula where you could simply calculate how often a loop will be executed in its own thread until the game breaks it down. As a basic you can say that more function calls, variable references and operations (like +-*/ ||) drastically decrease the limit. Will post more details later if someone wants to know this. :D
I'm aware of the function but it doesn't help the situation I described because the movement costs are customized and not determined by the actual in game terrain. Also that function will not constrict itself to operate on a very specific grid and instead will find return the cost that starcraft determines is the fastest path between two points.
The best way I've found to get around this is to put all of your stuff in a .galaxy file and import it into your map. You'll need to get it included in your main mapscript.galaxy file somehow though - you could probably do this with a custom script in the GUI editor if you are still using triggers for other things as well. This way you get around that very slow line by line checking that happens when you paste.
Will there be some sort of "cutscene" battle short that occurs when units wants to engage combat with each other? There needs to be more map that does this, maybe risk maps would be interesting with turns, and cutscenes for infantry vs infantry etc. Making the waiting more bearable if you get to watch cutscenes.
I'm debating whether the map will include anything like that. Most people I know end up turning these kind of features off eventually when they play these types of games, so if it is included there will definitely be a way to turn it off. The intention of this is also to basically create a style of playing were you do a very minimal amount of waiting, since all players will be able to act out their "turn" at the same time.
It has a few bugs which can be easily worked around and that are patched relatively quickly. I'm finding it a easy to use and very stable overall. The standard library is still a little lacking but covers most things you could need already.
@ChromiumBoy: Go
How are you recognizing your gestures? Is it more or less hard coded or do you train certain gestures and then match against them in some way?
I just finished the general animations for the events list. Took a while longer than I wanted it to because I ran into some bugs where the events would shoot off the screen at really high velocity. Anyway, I'm really pleased with how it came out:
As you cans see in the video, dismissing an event causes the other events to scroll up to replace it. New events show up at the bottom most empty spot, fading in. If the user clicks on a bunch of events, they take this into account and all adjust position at an appropriate rate to compensate for that.
In the final version, the events will actually correspond to things going on in the game - so clicking on one will take the player to that event location. Clicking the X will exhibit the behavior shown here.
So far I have implemented a lot of the data structures that are hidden behind the scenes. The map is entirely written using Andromeda, an OOP extension to Galaxy. Here's a pretty screenshot of what developing this map looks like most of the time:
Though I've written a ton of code, there isn't enough done to actually play the game yet. I ran into some interesting problems which might be useful to others:
Triggers have an execution limit, which is probably based on a certain number of instructions they can execute. I have a few complicated functions that iterate over a lot of data, so they were exceeding this limit. It turns out that the Wait() function causes the trigger to sleep (all triggers are run in their own thread) and when it resumes, it has a fresh execution limit. So by putting in things like:
Wait(0.0,c_timeGame):
You can make your trigger force a context switch and reset its execution limit. This does of course slow down the code a little bit (since even the minimum wait - 0.0, is at the mercy of the trigger scheduler to resume execution), but in my experience it can be optimized by carefully testing and seeing how often to insert these Wait() commands.
Another issue that is actually a big deal for this map is the 2MB memory limit. Maps in Starcraft can only reference up to 2MB of memory which means that the sum of all global variables and text (actual program code) in your map cannot exceed this. The way I do shortest paths right now, I need an N by N array of integers which represent the weight between any two nodes in the graph. Using a hexagonal graph, there are N = 169 nodes in the maximum unit range (7) in the map. Not only do I need one of these, I actually need one of these for each player in the game if I want them to be able to act at the same time. I'm aiming for an 8 player limit, so this set of weights alone takes up 913952 bytes, or almost half of the memory I have to work with. If someone can think of a good way of chopping this down - I'm all ears. I can't move it into local memory because local memory is limited to only 32k. I'll probably try and figure this out sometime in the future.
Side note - working with hexagons created a few cool problems to solve, such as:
How many hexagons are there within a radius r of some point?
What are the positions of them in game
User Interface
I've started creating a custom UI for the game. The UI is once again done in code and I have a pretty nice class hierarchy going on that makes creating new things relatively painless, but as many of you probably know, working with dialogs is a bit of a pain.
That's the current work in progress. The textures are all placeholders until I can do or select better.
The upper right part of the screen will display the player's resources, income, army count, and how many turns have elapsed in the game.
Below that is the event log. When one of your units takes damage, is killed, a building takes damage or is captured, or an enemy comes into your vision, it generates an event. The event log shows the first 8 events in your event queue. These can be clicked on to center your vision at the event epicenter and have a small description in the tooltip of what happened. This makes it easy to track what's going on in big battles as the game gets more complicated.
Clicking on an event or clicking on the "X" button will dismiss it, making new events fill the list if they exist. I'm working on some cool animations for these - right now the events fade in when they show up, and I plan on having them slowly move up to replace removed events.
The bottom right contains the minimap and end turn button. There's nothing special about the minimap going on. The end turn button will actually change functionality when you have units that can be commanded - it will bring you to the units that still need instructions before it allows you to end your turn.
Still to be created and not in the picture: the bottom left will contain information on the unit you currently have selected and contain a list of its available commands. Highlighting a unit will cause another display to pop up, showing combat stats if you already had something selected.
Other Random Things
I had to disable smart clicking for the map because I don't want people to be able to move units without going through the new UI, and I didn't want to do anything fancy with creating movement behaviors and such. However, this led to the problem that right clicking on the minimap still gave a unit a move order and circumvented the smart click disable. I got around this by creating a trigger that makes sure that only units that are allowed to move can move.
I'd like to introduce a map/framework I am working on called Reckoning. At its core Reckoning is a framework for turn based strategy games, though the initial implementation is heavily catered towards the map I am making. To make this post more sensible, I'll just refer to the map and framework as the same thing.
I'm going to log progress towards the map here.
Concept Overview
Reckoning is loosely based off of turn based strategy games such as Civilization and Advance Wars. It will feature a customizable turn based system where a game can be run in different speeds of one of two modes: traditional turn based, where each player must wait for all others to complete their turn, or pseudo-real time, where all players perform their turn at the same time.
It uses a hexagonal grid system like that seen in Civilization 5 and supports different types of in game terrain. Each grid cell in the game can have a different type of "terrain," with its own vision, movement costs, and other various attributes. Units are given a movement maximum per turn and the game solves a shortest path problem to figure out the optimal path for your unit to get to location:
The terrain system is designed such that the terrainer does not need to have knowledge of the workings of the game to make terrain. After doing traditional terrain design, the terrainer simply places regions or special units to distinguish in game terrain types on the map. This way multiple maps can be created for the same general game.
The game will play a lot like Advance Wars, with many different unit types available that are produced from various buildings on the map. The overall objective will be to capture all enemy capital.
The ability to do that does not exist in Galaxy. You'll have to write a function to copy from one to the other, and have the records as global variables in some array such that you can pass their index to this function.
Trigger destroy only removes the events bound to a trigger variable - it won't do anything to the actual code that the triggers point to. So you can use
triggert1=TriggerCreate("myfunc");triggert2=TriggerCreate("myfunc");TriggerAddEvent(t1,...);TriggerAddEvent(t2,...);TriggerDestroy(t1);// will not affect t2
Does anyone know if there is a way to disable generating a move command from a right click on the minimap? I'm already disabling smart click to disable normal right click commands, but this doesn't prevent clicking on the minimap to move a unit.
@crutex: Go
169 nodes is small in reality but it's more actions per trigger than starcraft wants to deal with. I was a little misled because I was testing with the trigger debugger which slows everything down a little bit as well (especially if you have debug output).
0
I'm going to make the assumption here that most people who write large amounts of Galaxy do so in an outside editor and then import it. The internal text editor is pretty lousy, and pasting anything into it causes it to lock up while it checks the code.
0
There's Moonlite, but it's not in great condition yet. http://www.sc2mod.com/board/index.php?page=Board&boardID=43&s=8b9591b80842eb716b23430671b2d049488142f4
0
I'm aware of the function but it doesn't help the situation I described because the movement costs are customized and not determined by the actual in game terrain. Also that function will not constrict itself to operate on a very specific grid and instead will find return the cost that starcraft determines is the fastest path between two points.
0
The best way I've found to get around this is to put all of your stuff in a .galaxy file and import it into your map. You'll need to get it included in your main mapscript.galaxy file somehow though - you could probably do this with a custom script in the GUI editor if you are still using triggers for other things as well. This way you get around that very slow line by line checking that happens when you paste.
0
I'm debating whether the map will include anything like that. Most people I know end up turning these kind of features off eventually when they play these types of games, so if it is included there will definitely be a way to turn it off. The intention of this is also to basically create a style of playing were you do a very minimal amount of waiting, since all players will be able to act out their "turn" at the same time.
0
@Colawaffle: Go
It has a few bugs which can be easily worked around and that are patched relatively quickly. I'm finding it a easy to use and very stable overall. The standard library is still a little lacking but covers most things you could need already.
@progammer: Go
I hope they both turn out pretty differently.
0
@ChromiumBoy: Go How are you recognizing your gestures? Is it more or less hard coded or do you train certain gestures and then match against them in some way?
0
October 2nd - UI Events Update
I just finished the general animations for the events list. Took a while longer than I wanted it to because I ran into some bugs where the events would shoot off the screen at really high velocity. Anyway, I'm really pleased with how it came out:
As you cans see in the video, dismissing an event causes the other events to scroll up to replace it. New events show up at the bottom most empty spot, fading in. If the user clicks on a bunch of events, they take this into account and all adjust position at an appropriate rate to compensate for that.
In the final version, the events will actually correspond to things going on in the game - so clicking on one will take the player to that event location. Clicking the X will exhibit the behavior shown here.
0
Oct 1st - What's been done to date
Coding Stuff
So far I have implemented a lot of the data structures that are hidden behind the scenes. The map is entirely written using Andromeda, an OOP extension to Galaxy. Here's a pretty screenshot of what developing this map looks like most of the time:
Though I've written a ton of code, there isn't enough done to actually play the game yet. I ran into some interesting problems which might be useful to others:
Triggers have an execution limit, which is probably based on a certain number of instructions they can execute. I have a few complicated functions that iterate over a lot of data, so they were exceeding this limit. It turns out that the Wait() function causes the trigger to sleep (all triggers are run in their own thread) and when it resumes, it has a fresh execution limit. So by putting in things like:
You can make your trigger force a context switch and reset its execution limit. This does of course slow down the code a little bit (since even the minimum wait - 0.0, is at the mercy of the trigger scheduler to resume execution), but in my experience it can be optimized by carefully testing and seeing how often to insert these Wait() commands.
Another issue that is actually a big deal for this map is the 2MB memory limit. Maps in Starcraft can only reference up to 2MB of memory which means that the sum of all global variables and text (actual program code) in your map cannot exceed this. The way I do shortest paths right now, I need an N by N array of integers which represent the weight between any two nodes in the graph. Using a hexagonal graph, there are N = 169 nodes in the maximum unit range (7) in the map. Not only do I need one of these, I actually need one of these for each player in the game if I want them to be able to act at the same time. I'm aiming for an 8 player limit, so this set of weights alone takes up 913952 bytes, or almost half of the memory I have to work with. If someone can think of a good way of chopping this down - I'm all ears. I can't move it into local memory because local memory is limited to only 32k. I'll probably try and figure this out sometime in the future.
Side note - working with hexagons created a few cool problems to solve, such as:
User Interface
I've started creating a custom UI for the game. The UI is once again done in code and I have a pretty nice class hierarchy going on that makes creating new things relatively painless, but as many of you probably know, working with dialogs is a bit of a pain.
That's the current work in progress. The textures are all placeholders until I can do or select better.
The upper right part of the screen will display the player's resources, income, army count, and how many turns have elapsed in the game.
Below that is the event log. When one of your units takes damage, is killed, a building takes damage or is captured, or an enemy comes into your vision, it generates an event. The event log shows the first 8 events in your event queue. These can be clicked on to center your vision at the event epicenter and have a small description in the tooltip of what happened. This makes it easy to track what's going on in big battles as the game gets more complicated.
Clicking on an event or clicking on the "X" button will dismiss it, making new events fill the list if they exist. I'm working on some cool animations for these - right now the events fade in when they show up, and I plan on having them slowly move up to replace removed events.
The bottom right contains the minimap and end turn button. There's nothing special about the minimap going on. The end turn button will actually change functionality when you have units that can be commanded - it will bring you to the units that still need instructions before it allows you to end your turn.
Still to be created and not in the picture: the bottom left will contain information on the unit you currently have selected and contain a list of its available commands. Highlighting a unit will cause another display to pop up, showing combat stats if you already had something selected.
Other Random Things
I had to disable smart clicking for the map because I don't want people to be able to move units without going through the new UI, and I didn't want to do anything fancy with creating movement behaviors and such. However, this led to the problem that right clicking on the minimap still gave a unit a move order and circumvented the smart click disable. I got around this by creating a trigger that makes sure that only units that are allowed to move can move.
0
Reckoning (Working Title) - Progress Log
I'd like to introduce a map/framework I am working on called Reckoning. At its core Reckoning is a framework for turn based strategy games, though the initial implementation is heavily catered towards the map I am making. To make this post more sensible, I'll just refer to the map and framework as the same thing.
I'm going to log progress towards the map here.
Concept Overview
Reckoning is loosely based off of turn based strategy games such as Civilization and Advance Wars. It will feature a customizable turn based system where a game can be run in different speeds of one of two modes: traditional turn based, where each player must wait for all others to complete their turn, or pseudo-real time, where all players perform their turn at the same time.
It uses a hexagonal grid system like that seen in Civilization 5 and supports different types of in game terrain. Each grid cell in the game can have a different type of "terrain," with its own vision, movement costs, and other various attributes. Units are given a movement maximum per turn and the game solves a shortest path problem to figure out the optimal path for your unit to get to location:
The terrain system is designed such that the terrainer does not need to have knowledge of the workings of the game to make terrain. After doing traditional terrain design, the terrainer simply places regions or special units to distinguish in game terrain types on the map. This way multiple maps can be created for the same general game.
The game will play a lot like Advance Wars, with many different unit types available that are produced from various buildings on the map. The overall objective will be to capture all enemy capital.
0
@Sneakervek: Go
The ability to do that does not exist in Galaxy. You'll have to write a function to copy from one to the other, and have the records as global variables in some array such that you can pass their index to this function.
0
@weihrnachtsmann: Go
Something along the following:
Events - Unit takes damage
Local Variables - real, initial value = triggering damage amount
Actions - create a text tag on that unit and do whatever with it you'd like.
That's pretty vague but covers the most important parts.
0
Trigger destroy only removes the events bound to a trigger variable - it won't do anything to the actual code that the triggers point to. So you can use
0
Does anyone know if there is a way to disable generating a move command from a right click on the minimap? I'm already disabling smart click to disable normal right click commands, but this doesn't prevent clicking on the minimap to move a unit.
0
@crutex: Go 169 nodes is small in reality but it's more actions per trigger than starcraft wants to deal with. I was a little misled because I was testing with the trigger debugger which slows everything down a little bit as well (especially if you have debug output).
Anyway, I got it working, it looks like this: