Some great suggestions, a1win, that ended up bearing some fruit. I ended up going away from the "undetectable" flag, and instead using detection to reveal units. It's a lot less "hacky" than trying to reveal units manually. The purpose of detection is to reveal units, it just needed a few tweaks.
The changes are posted in the original post. The changelog at the beginning itemizes these changes.
Well the differences in "the problem" section can all be worked around using data.
Individual cooldowns can't be though as far as I know.
A great deal of what I did is done in data. Most of the code I posted above are comments. There's really only about 20 lines of code. Even if it could be done in data, I haven't found a way and that solution isn't posted anywhere. I came up with a solution and I wanted to share it with people who might want to use it. It feels like you're trolling. You're just saying that it can be done, but not offering any actual solutions. By contrast, I offer an actual solution.
I've been a long way down that road, tried a lot of things, and asked a lot of people. I'm not nearly as convinced as you are that it actually can be done in data. However you think it could be done in data, I've probably already tried.
Saying "it can be done in data" is a lot different than spending hours building a tutorial to try and help people. There isn't a good solution out there, so I shared mine. If you have alternatives, help people out and post them. Otherwise, you have no right to try and take this away from me or any one else.
Also, the difference is minimal if at all. My triggers were built with performance in mind. They do little, if anything, more than what a data solution would do. The game still needs to scan objects and check conditions. It just does that in triggers instead of data in a few cases. My triggers were designed to only fire when they need to, and quickly dismiss if the conditions aren't meant. How much performance can that really take? There are no periodic triggers.
The other problem with the data editor is that a lot of times it requires a great deal of redundant work. Even setting up the requirements for this solution is quite redundant, for example. It's likely that any solution you offer would require several objects for each specific type of unit. Since I wanted to use my solution on every type of unit producing structure in the game, I want to avoid large amounts of redundant work. I still kept the redundant work on the requirements because that's what worked best. Keep in mind though, redundant work means redundant changes later down the road, which introduces the possibility of error. From a programmer's perspective, this is very bad.
I don't understand the advantage of using this over the regular data interact ability?
Would you mind clarifying?
You can use creative target filters and buff applications to ensure that, while a neutral building remains neutral, it will still only sell items to one team.
All of the differences are listed in the section "the problem". I needed it to work with more than one player at a time - simulataneously. I needed warp gates to work. I got a few extra benefits as well, like individual queues/cooldowns. Believe me, I wouldn't have gone to all this trouble if the interact ability did what I needed it to.
Even if I could find a data solution, I've come to really like the individual queues that are actual visible. I don't think I'd use a data solution that didn't offer this functionability as well.
11/23/2010 - Added sample map. Removed the triggers for brevity and so I don't have to maintain them in two different spots.
11/23/2010 - The ally interact ability needs to set the uncommandable flag on the unit, and the detector needs to require uncommandable units. Otherwise, multiple enemy buildings can be seen. Changes made to behaviors section only.
11/22/2010 - Greatly improved invisibility done through detection. The solution section contains a new synopsis of these changes. Changes have been made to the behaviors and units sections, as well as the action definition "Create Fake Building". The triggers "Select Shop", "Find Fake Buildings" and the constant "Fake Building Check Radius" have been dropped. Added triggers "Sync Energy" and "Share Vision". This new solution solves several of the remaining problems, which we listed in the conclusion section. These were dropped.
The Problem
The ability type "Interact" is used to allow computer controlled building to sell items, units, upgrades, or whatever to all players. It's a great ability that allows you to do a great number of things with very little work. The problem is, this ability only works with neutral units. If the unit is anything other than neutral, you'll receive a message "cannot spend another player's resources". If you need the unit to be allied to certain players, this is a show stopper.
Some people have gotten around this by changing control of the building to the player who's interacting with it. This solution would not work for me, because I needed multiple people to be able to interact with the building at once. I also needed the building to act like an allied building in every way. I needed it to be destructible and say "our allies base is under attack".
On the finer details side of things, you can't see the queue on a building with interact, nor does it work with warp gates. The units pretty much have to come out instantly, or the player is confused. The queue is shared for each player, making it even less useful. There's also one rally point per building. Ability interact also doesn't tell the player that his unit is too far away; again, leading to confusion. I could probably live without most of those things, but I ended up finding ways around all of them.
The Path
A lot went into find the solution. I'm not going to bore you with the gory details, but a lot of the people in IRC helped me through this, and in the end I think the solution is very elegant. It's also not much code, which is great. I spent a great deal more time finding the solution and theorizing in IRC than I actually did programming anything.
Once I worked through all of that, I thought I should share my solution with the community. I know this is a common problem, and we are short on solutions. Feel free to use mine, and let me know if you find any better ways of doing it.
The Solution
So the way everything ended up working was this: I create a new "invisible" unit on top of the real unit. I do this once for every player I want to be able to interact with my shop building. Each copy is owned by the player that can interact with it. So they actually own it, and can interact with it normally. The clones are invulnerable, so that units don't attack them, but their life (and shields) are linked to the real building.
The invisible units are handled via detection. The units themselves are set to cloaked and buried, and detectors are used to give vision to the correct players. The default detectors need to be modified so that you can't see your allies fake buildings. All units in the game need to be given a behavior so that they can see the enemy buildings. Normal shared vision can no longer be used; vision must be shared on a unit-by-unit basis, which can be done when the unit is created.
A behavior with a validator can tell if the player's hero unit is within a certain radius. The validator disables the behavior if there's no heroic unit within the speicfied radius. A requirement on the train ability checks for the behavior, and provides a nice message "Hero character must be within range". This works very nicely for the hero requirement, and allows the building to be hoykeyed, and the hotkey is retained but it can't be used out of range.
Finally, a simple trigger syncs the health and shields of the real buildings with the fake ones. Since I use some energy-based abilities, and wanted allies to share energy pools, I synced their energies with another trigger.
This solution meets all of my requirements and then some. Seperate buildings for each units means seperate queues/cooldowns and rally points. It seems a little weird, but it's really quite elegant in practice.
The Data
Behaviors
You'll need 3 behaviors, all buffs. I'm a big fan of editor prefixes (use them!), so I gave all of them the editor prefix "Building -". The behavior names I used were:
Building - Ally Interact
Building - Fake Building
Building - Hero In Range
So go to the behaviors tab, Add Object..., and give it he name "Ally Interact". Change the behavior type to "Buff" and leave everything else as defaults. Hit OK. Change "Editor - Editor Prefix" to building. Repeat these steps for the other two items on the list above.
The behavior "Ally Interact" requires a slight modification. Under Behaviors - Modification, in the Behavior tab, near the bottom, find State Flags. Set Uncommandable to enabled. This behavior will be removed from the clones, but the uncommandable flag will help our detection later.
You may want to check the hidden flag (Stats - Flags) for all of these behaviors.
We also need to modify a few behaviors that already exist. They are "Detector (10)", "Detector (11)", and "Detector (12)". For each of these behaviors, double click on Behavior - Modification. In the Unit tab, under Detect Filters, uncheck "Ally" and "Player". We no longer want normal detectors to detect allied and player units. Instead, we will be revealing these units via shared vision. I believe all of the detectors use "Detector (11)", but it can't hurt to hit the other two as well.
Finally, duplicate "Detector (11)." I called mine "Detector (Ambient)". Under Behavior - Modification then Detect Filters, set "Buried", "Cloaked" , "Structure", and "Uncommandable" all to "Required". Leave "Ally" and "Player" unchecked. Set the Radius to 20. This will be the behavior we give to all normal units, that will allow them to see these enemy buildings.
Validators
Jump to the validators tab and create a new object. I called mine "Hero in Range." Set the validator type should be "Enumerate Area". Leave everything else at default and hit OK. I then changed the editor prefix to "Building -".
This validator will return false if the criteria is met, and we actually want it to return true to disable our behavior. So we need to work a little backwards. We want to set it so that the criteria is that the hero is in range (thus the name). When the criteria are met, it returns false and doesn't disable the behavior. It's confusing, I know, but it's the way it works.
So click on Search - Areas and click the green X to add an area. Arc should be 360 already. Set Compare to "Greater Than", and Count to 0. Set Radius to whatever radius you want to use. I used 20 because I wanted a little room to move for my units. You may choose something different.
Close the dialog by hitting OK.
Set Target - Location + to "Caster Unit". Set Validator - Compare to "Greater than". I don't know why you have to do it again there, but you do. Finally, set your Search - Search Filters. I set Heroic to "Required", and unchecked the boxes next to Ally, Enemy, and Neutral. Having only Player checked means it will only look for heroic units owner by the owner of the shop. Since each player has his/her own shop, this works perfectly.
The validator is complete. Go back to the behaviors tab, and find "Behavior - Hero In Range". Set the Behavior - Validators (Disable) to the validator you just created.
Requirements
The requirement does the real work, preventing the player from buying when the hero unit is out of range. Fortunately, it's also fairly simple. Create a new requirement. I called mine "Hero In Range" (for consistancy). There's only one kind of requirement, so leave everything default and click OK. I then set the editor prefix to "Building -" (again).
Double click next to Requirements +, and then right click on the Use node, and click Add Requirement Node. Change the Type to "Count Behavior". Change the Alias to our behavior - "Building - Hero in Range". The State should be "Completed at Unit". Finally, set the Tooltip to "Hero character must be within range", or whatever you want it to say. Leave the Show node blank.
So now our requirement expects the building to have our behavior, otherwise we can't use whatever ability the requirement is attached to. The show node is blank, so it will show the ability no matter what, which is the behavior you expect. We also set the tooltip that will show up when the ability is greyed out, which is just plain good user interface.
One last note about requirements: you can only use one requirement per ability (at least with train abilities). If you're using an ability that already has a requirement, and you want to keep it, or if you want to use another ability, you'll need to combine the two requirements. Duplicate the pre-existing requirement, and add the same requirement we just set up to that requirement. It will now have both requirements.
Abilities
For the purposes of this tutorial, I will assume your ability already exists. It's most likely a train or upgrade ability. Either you've built it already, or you're using a pre-existing ability. Either way, I'm not going to go over the bazillions of ways an ability can be set up. If it doesn't exist already, stop now and make it.
If you need your ability for something else (like if you're going to make normal units of the same type), then duplicate the ability. If there are any actors, duplicate those with it. If you don't need to use the ability for anything else, you can just edit it as-is.
Both the ability types train and research have a section called Ability - Info. Double-click it. For each ability in this list, you need to add the requirement "Building - Hero In Range" to it. As I said before, if there's already a requirement that you want to use, you'll need to combine it with the hero in range requirement and use the combined requirement instead.
That's all you need to do for abilities.
Units
Finally, we get to our shop. Find whatever unit you're using as a shop, and add the following behaviors: "Building - Ally Interact" and "Building - Hero in Range". If you duplicated the ability, double click next to Ability - Abilities + and swap the old one for the duplicate. Make sure the command card buttons have the new ability as well.
Under Stats - Flags, check "Buried" and "Cloaked" for your shop. Don't worry, vision will be handled through detection.
Now, the semi-tedious part is applying the behavior "Detector (Ambient)" to every non-detector unit that will be in your game. Without this, the enemy shops simply won't show up at all. Make sure you get all of your units.
The rest of the work is done in triggers.
The Triggers
All of the code is located in the sample map. It's really only a few triggers, and they're really quite simple. I've also commented them well. I encourage you to take a look and see what they do, but the premise is pretty simple:
Initialize Fake Units [Action Definition] needs to be called at map initialization. It creates the duplicates of all the buildings on the map.
Find Fake Buildsings [Function] locates the duplicate building for a specific player.
Create Fake Building [Action Definition] creates a single fake building. It is called multiple times by initialization.
Sync Health [Trigger] and Sync Energy [Trigger] do exactly what they say they do. They are very short.
Share Vision [Trigger] shares vision of newly created units with their allies. This function would be disabled if shared vision isn't used. It is not used on the sample map, because of the strange alliances.
The Conclusion
If everything went properly, you should have yourself some really nice-looking allied shops, that feel just like regular allied buildings. There are a few small exceptions:
Pylons
Protoss buildings require power. We all know this. The problem is that the fake buildings don't have this power. There are a couple ways around this: First, You could just remove the power restriction. This wouldn't work in my game, but it may be fine in another type of game.
What did work in my game was just giving the behavior "Building - Ally Interact" to Pylons as well. Pylons don't need "Hero in Range", becase they don't have abilities. The ally interact ability causes clones to be created, which will provide power to the cloned buildings. Since the healths are synced, if the pylon is destroyed, neither building will be powered.
There is, however, some weirdness if you allow the player to build pylons. He can power the building for himself without powering it for the computer. I'm going to overcome this by disallowing building in near the computer's base. It could also be overcome by cloning the pylon back to the computer player somehow, then they would truly share power matrices. This could be done fairly easily in a trigger.
There's also the issue of supply. In my game, I don't use pylons for supply in my game, so I had no problem setting Stats - Supplies to 0 for my Pylons. If that doesn't work for you, you might need to add a behavior that removes the supply from the Pylon. I don't know of another way to remove supply from a unit in a trigger. You'd probably have to specifically check for unit type Pylon in the "Initialize Fake Buildings" action, and apply the behavior if true.
Shared Vision
The method listed above requires that vision be shared (through triggers) to allied players. If we didn't do this, players would never be able to see allied cloaked units.
Thanks for the info. I like the format of staredit.net better than the wiki here. Also, the staredit also has some of the groundwork laid out. Unfortunately, it has almost no exposure, so we might need to help it with that. I think we should start working together to fill some of that information out. Please, everyone take a look at http://www.staredit.net/starcraft2/Required/Unfinished_Wikis to see what areas need contribution (frankly, every one of the triggers and data sections needs some revisions at the very least). Declare your intentions here. I think I'll look at modifying the triggers - banks and triggers - custom UI sections. My knowledge falls short with the data editor, so if you have anything to add there, please do.
Glad to have everyone's support. It's good to see that something like this will be well-received. Can some help grab the attention of the admins so we can start talking about hosting? I'd really like to host this information here - I think it's the right place.
@BDMon: any amount of contribution is welcome. Just stating that you would use a resource like this helps lay the groundwork for getting everything started. Even a novice developer can add information to this document. There probably are some areas of the editor that you do know fairly well. Contribute to those. There will also be some areas that require documentation that aren't used very often. Someone is going to need to figure out what those do. You can help by figuring out what individual things do and feeding that information to a documentor, or grabbing and entire section and documenting it. When the time comes, you'll probably find an area that you can contribute, no matter how small the contribution. It all adds up.
I think we can all agree that it is an understatement to say that the Galaxy editor is poorly documented. Triggers has some decent (but far from ideal) documentation, but there is almost no documentation for the data editor. This lack of documentation, I feel, is the number one barrier for new developers. We've all spent hours trying to figure out what individual fields mean and do. I think it's time for us to share and collect this accumulated knowledge, so that future developers don't have to jump the same hurdles.
I'm talking about a community documentation project for the galaxy editor. Tutorials are great, and definitely have a place in the commuinity and are needed. However, we need references as well. If I just want to know what one specific field or trigger is for, I'd like to have somewhere that I can look. I can add a lot of information to this documentation, but I can't add it all. Together, I think we can. I think it's easily conceivable that we could document the whole frickin' editor in just a short amount of time. Who's with me?
Step one is hosting and format. My perference is to work with the admins and host it here. My format thoughts are wiki-like format, but the individual page format needs to be laid out. After that, we can start doling out sections of the editor for individuals to document.
Unfortunately, all the checksums and encryption in the world don't prevent a user from copying his bank file and redeploying it at will. This can have a number of unfair benefits depending on the game. You could duplicate items by giving them to a friend and then reloading your old bank. You can bypass an auto-save if something bad happened to your character. You can backup your bank before editting it, preventing bank deletion when/if the game realizes you've edited your bank. I'm sure there's a few other tricks I haven't thought of, and they're all bad. If I wanted features like this, I'd program them in.
Now, I'm already considering not using items because, frankly, they don't work very well. They feel like an afterthought, and hotkeys for items are horrible. I'm also considering avoiding auto-saving, or at least giving the player options if something bad happens that they'd rather not save. Still, I'd like to immediately save a blank character over their bank if I detect a modification. I'd also like to avoid any other unwanted consequences of bank duplication.
The problem is, there really isn't any way to tell if a bank has been duplicated. None that I know of at least. Is there any way that others can think of that might avoid this pitfall? Everything I can think of falls short. Saving to another bank is just as vulnerable as the first. Timestamps really don't mean anything without relative information (like knowing when the last time the player saved was). As far as I can tell, there's no way to prevent a player from reloading a bank from a backup.
If I might offer a suggestion, external hashes would make a nice addition. In my example above, I have 20 keys for unit storage. There's nothing stopping anyone from duplicating a key onto another one. The hash won't notice the difference because it's saved to the string itself and gets copied along with it. So if a player can figure out where his good units are in the bank, he could copy them over on top of his bad units. Even storing a unit count wouldn't prevent this as long as they are replacing one key with another.
I'd like to be able to save a seperate string of unit hashes, but right now STARCODE hashes only work as part of the string. This sort of protection would prevent key duplication, and would be very difficult to circumvent.
Since I need this feature, I'll probably be coding it in the next week or two. If you'd like, I can submit it back to you so that it can be made available to the public.
Now if I could only prevent bank duplication... That's another problem entirely.
I guess I misread the README, and I deleted it to save map space, so I actually thought the limitation was much higher than 100. Not a huge deal. Six units per string isn't bad. I was able to break up the unit group into multiple strings at 6 units each, enabling me to save more than 6 units. With the lifted bank limitation, I should be able to save a descent number of units. I'll have to try and push the limits once I have the multi-player truly working.
I really appreciate this library and the contribution you've made to the community. Your library makes compression and encryption so much easier, and it really removes any hurdles to implementation. I think STARCODE is just as important now as it ever was, even with the less strict bank limitations. More space means we can store more data, not that we can be beligerantly inefficient with our data storage.
I just wish Blizzard had let us save in true binary in the first place. Giving us limited storage space and then wasting most of it with XML markup and text-based saving is just... well... it's stupid. They're programmers, they should know better.
EDIT: I was able to save 120 units plus a hero in a 3.3kB bank. Not bad. I'm pretty sure 10 players loading 120 units won't work on BNet, but up to 80 might. Couldn't have done it without your library. For the record, saving 120 units takes about a second (I did have to add a wait of 0.0 seconds). Loading takes considerably longer, but I think most of that is unit creation.
My intentions are a little different than that. I used to play an old game "Monopoly Party" for the XBox. In that game, everyone took their turn at the same time. It changed very little about the game, except that it went by a lot faster (If two people landed on the same spot at the same time, and auction occurred between them). I don't want the games to last for hours, no one will play. But if you can get a decent online game of Monopoly that takes about a half an hour, people will play. Rolling, moving and buying are only part of Monopoly. The game gets much more interesting when trading is implemented.
I chose Monopoly because: 1) people like the game, and they will play it. 2) It's my favorite game, and I want to see it done in StarCraft II. I think it would be a lot of fun. 3) It's fairly simple, while still being challenging. As you said, it's good to cut my teeth with. 4) Unlike and RPG or a TD game, it requires almost no messing with the data editor. It's almost all triggers. I'm really good with triggers, but I hate the data editor. But this could be said about just about any board game. 5) It hasn't been done yet.
I didn't specificly pick Monopoly because it's a board game. I picked it because it's a fun game and I can immediately think of ways to build it with the map editor. I can't really think of many other board games that would translate well to StarCraft II. Obviously, Risk, because it's been done dozens of times already. Chess could be done, but I'm pretty sure it already has, and I'm pretty sure I wouldn't want to (too slow). The only other board game I think I'd even consider translating to SCII would be Axis & Allies. I don't believe that's been done either. I'd almost be willing to switch to A&A, but then there still wouldn't a Monopoly. Also, a lot of people would compare A&A to Risk. It would have to be an incredible game for people to play it. Monopoly would just have to be Monopoly, and people would play it.
of all the good boardgames out there, everyone is just picking monopoly or risk. and monopoly is really one of the shittiest boardgames i played. so why everyone picks that?
More correctly, everyone is choosing Risk. No one has made a Monopoly game in SC2 to completion, and it appears that only Alcoholix and myself have tried. Search for Risk on BNet - 20+ results. Now search for Monopoly - 0 results. I don't know what you're talking about. Risk is fairly easy to program. Monopoly is quite a bit harder.
You assesment of Monopoly is only your opinion, and most of the rest of the world likes the game. It is, afterall, the most popular board game in existance.
Is this a dead project? The same idea occurred to me, but I don't want to step on anyone's toes. I'd be interested in working with you if your still interested in this project. If you're not, would you consider passing along what you've got so far? Credit would be given.
I've run into an instance where <StarCode> Decompress String is generating "Execution took too long". It is being run inside a loop (for each player), but the length of the string to decompress is only 79 characters? Is there anything I can do about this? I am certain that this is the step that is failing.
EDIT: I can duplicate this error at will. I am saving units at 11 characters per unit (2 characters for a unit identifier, 3 for experience, 2 for health, 2 for shields, 2 for energy), plus 2 characters for a unit count, and 4 for a hash (which is removed before the decompress). If I save 6 units (68 characters), everything works fine. As soon as I try to save 7, the save runs fine but it times out trying to load them. More correctly, it times out trying to decompress the 79 character string. I suppose I could make a new key for every 6 units, but I was hoping I could get the strings much larger than that. I'd like to be able to store upwards of 80 units in as few strings as possible.
I am in the process of building an RPG that retains some of the pre-built RTS elements of StarCraft. The general idea is that you get a hero, and your hero can buy or train units to assist him. RPG elements like items and abilities will also exist, but I really think the added RTS elements will give it some extra depth.
Your hero will have a positive supply number (he gives you supply instead of taking it away), which will go up with level or with abilities like leadership. There will be a maximum cap based on save file limitations. Units will be saved with the hero, and restored when you re-enter the map. To keep normal units viable, they will level up with experience. They will gain automatic stat bonuses with each level, but no additional abilities or the ability to carry items (too much micro-management). Normal unit abilities (like blink, stimpack, et cetera) will be researched normally. Mercenaries will also be available, allowing you to buy units which are already of a certain level, or even cross racial lines (which will not normally be possible).
Each race will have it's own starting point on the map, and a single starting hero. Every 10 levels, you may upgrade ("tech") your hero to a new type. There will be a tree structure to this hero teching. You will retain all abilities, and still be able to research them, while adding new abilities of the new hero type. Due to saving limitations, there is a limit of one save per race. This is why I didn't want to have a bunch of starting heroes. I also means there's no confusing hero selection menus at the beginning of the game, you just get a hero and are dropped right into the action. I want to introduce the game elements organically, hopefully making the game easy to learn. The starting heros are: Zealot Champion, Veteran Marine, and Evolved Zergling.
The story will play out like a story about the game. I want it to feel like you're a hero inside an epic 1v1v1 of StarCraft. The 1v1v1 is actually occuring between the computers, and the heros are added to try and turn the tides.
You can't control the comptuers directly, but they can be used to your advantage. In ally controlled areas, much fiercer units will spawn against your enemies, so retreating to such an area would be effective if you were being harassed by a higher level hero. In all, the random spawns are scaled to each hero, so the game should remain balanced even if the heros themselves are not. That's actually a big goal of mine. The game should be balanced for all players even if the teams are not. The game supports up to 11 players, and all of them can be the same race or different races. The computer scales to these heroes to balance this all out. This is also huge on BNet because a player quitting doesn't matter, which is a problem that plagues other games like Nexus Wars. In invasion on an enemy stronghold should be challenging regardless of the hero composition. I'm thinking the map will support up to level 20, with the end boss designed for level 20 (scaled for the number of heros attacking it). A second map would allow you to go past level 20, plus have new quests and challenges.
Those are my core ideas so far. I am currently focusing on the engine itself, making everything work with less focus on heros, units, items, and quests. Those will be added with time, but the core functionality needs to exist first. I've actually come a long way on the core functionality: items and abilities are working overall. Buying of units and supply cap works. Hero revival is working. The random spawns are working, and are based on territories, determined by number and placement of structures. If anything, the random spawns are actually too strong right now, but I think that is largely because hero abilities are not yet fleshed out. I am in the process of working on saving, which works on some levels but requires some more work. Once the core functionaility is in place, the game will be playable, but will be missing some "polish", which will be added over time.
0
Some great suggestions, a1win, that ended up bearing some fruit. I ended up going away from the "undetectable" flag, and instead using detection to reveal units. It's a lot less "hacky" than trying to reveal units manually. The purpose of detection is to reveal units, it just needed a few tweaks.
The changes are posted in the original post. The changelog at the beginning itemizes these changes.
0
A great deal of what I did is done in data. Most of the code I posted above are comments. There's really only about 20 lines of code. Even if it could be done in data, I haven't found a way and that solution isn't posted anywhere. I came up with a solution and I wanted to share it with people who might want to use it. It feels like you're trolling. You're just saying that it can be done, but not offering any actual solutions. By contrast, I offer an actual solution.
I've been a long way down that road, tried a lot of things, and asked a lot of people. I'm not nearly as convinced as you are that it actually can be done in data. However you think it could be done in data, I've probably already tried.
Saying "it can be done in data" is a lot different than spending hours building a tutorial to try and help people. There isn't a good solution out there, so I shared mine. If you have alternatives, help people out and post them. Otherwise, you have no right to try and take this away from me or any one else.
Also, the difference is minimal if at all. My triggers were built with performance in mind. They do little, if anything, more than what a data solution would do. The game still needs to scan objects and check conditions. It just does that in triggers instead of data in a few cases. My triggers were designed to only fire when they need to, and quickly dismiss if the conditions aren't meant. How much performance can that really take? There are no periodic triggers.
The other problem with the data editor is that a lot of times it requires a great deal of redundant work. Even setting up the requirements for this solution is quite redundant, for example. It's likely that any solution you offer would require several objects for each specific type of unit. Since I wanted to use my solution on every type of unit producing structure in the game, I want to avoid large amounts of redundant work. I still kept the redundant work on the requirements because that's what worked best. Keep in mind though, redundant work means redundant changes later down the road, which introduces the possibility of error. From a programmer's perspective, this is very bad.
0
All of the differences are listed in the section "the problem". I needed it to work with more than one player at a time - simulataneously. I needed warp gates to work. I got a few extra benefits as well, like individual queues/cooldowns. Believe me, I wouldn't have gone to all this trouble if the interact ability did what I needed it to.
Even if I could find a data solution, I've come to really like the individual queues that are actual visible. I don't think I'd use a data solution that didn't offer this functionability as well.
0
Advanced Building Interaction
Sample map available at bottom of post.
Changelog
The Problem
The ability type "Interact" is used to allow computer controlled building to sell items, units, upgrades, or whatever to all players. It's a great ability that allows you to do a great number of things with very little work. The problem is, this ability only works with neutral units. If the unit is anything other than neutral, you'll receive a message "cannot spend another player's resources". If you need the unit to be allied to certain players, this is a show stopper.
Some people have gotten around this by changing control of the building to the player who's interacting with it. This solution would not work for me, because I needed multiple people to be able to interact with the building at once. I also needed the building to act like an allied building in every way. I needed it to be destructible and say "our allies base is under attack".
On the finer details side of things, you can't see the queue on a building with interact, nor does it work with warp gates. The units pretty much have to come out instantly, or the player is confused. The queue is shared for each player, making it even less useful. There's also one rally point per building. Ability interact also doesn't tell the player that his unit is too far away; again, leading to confusion. I could probably live without most of those things, but I ended up finding ways around all of them.
The Path
A lot went into find the solution. I'm not going to bore you with the gory details, but a lot of the people in IRC helped me through this, and in the end I think the solution is very elegant. It's also not much code, which is great. I spent a great deal more time finding the solution and theorizing in IRC than I actually did programming anything.
Once I worked through all of that, I thought I should share my solution with the community. I know this is a common problem, and we are short on solutions. Feel free to use mine, and let me know if you find any better ways of doing it.
The Solution
So the way everything ended up working was this: I create a new "invisible" unit on top of the real unit. I do this once for every player I want to be able to interact with my shop building. Each copy is owned by the player that can interact with it. So they actually own it, and can interact with it normally. The clones are invulnerable, so that units don't attack them, but their life (and shields) are linked to the real building.
The invisible units are handled via detection. The units themselves are set to cloaked and buried, and detectors are used to give vision to the correct players. The default detectors need to be modified so that you can't see your allies fake buildings. All units in the game need to be given a behavior so that they can see the enemy buildings. Normal shared vision can no longer be used; vision must be shared on a unit-by-unit basis, which can be done when the unit is created.
A behavior with a validator can tell if the player's hero unit is within a certain radius. The validator disables the behavior if there's no heroic unit within the speicfied radius. A requirement on the train ability checks for the behavior, and provides a nice message "Hero character must be within range". This works very nicely for the hero requirement, and allows the building to be hoykeyed, and the hotkey is retained but it can't be used out of range.
Finally, a simple trigger syncs the health and shields of the real buildings with the fake ones. Since I use some energy-based abilities, and wanted allies to share energy pools, I synced their energies with another trigger.
This solution meets all of my requirements and then some. Seperate buildings for each units means seperate queues/cooldowns and rally points. It seems a little weird, but it's really quite elegant in practice.
The Data
Behaviors
You'll need 3 behaviors, all buffs. I'm a big fan of editor prefixes (use them!), so I gave all of them the editor prefix "Building -". The behavior names I used were:
So go to the behaviors tab, Add Object..., and give it he name "Ally Interact". Change the behavior type to "Buff" and leave everything else as defaults. Hit OK. Change "Editor - Editor Prefix" to building. Repeat these steps for the other two items on the list above.
The behavior "Ally Interact" requires a slight modification. Under Behaviors - Modification, in the Behavior tab, near the bottom, find State Flags. Set Uncommandable to enabled. This behavior will be removed from the clones, but the uncommandable flag will help our detection later.
You may want to check the hidden flag (Stats - Flags) for all of these behaviors.
We also need to modify a few behaviors that already exist. They are "Detector (10)", "Detector (11)", and "Detector (12)". For each of these behaviors, double click on Behavior - Modification. In the Unit tab, under Detect Filters, uncheck "Ally" and "Player". We no longer want normal detectors to detect allied and player units. Instead, we will be revealing these units via shared vision. I believe all of the detectors use "Detector (11)", but it can't hurt to hit the other two as well.
Finally, duplicate "Detector (11)." I called mine "Detector (Ambient)". Under Behavior - Modification then Detect Filters, set "Buried", "Cloaked" , "Structure", and "Uncommandable" all to "Required". Leave "Ally" and "Player" unchecked. Set the Radius to 20. This will be the behavior we give to all normal units, that will allow them to see these enemy buildings.
Validators
Jump to the validators tab and create a new object. I called mine "Hero in Range." Set the validator type should be "Enumerate Area". Leave everything else at default and hit OK. I then changed the editor prefix to "Building -".
This validator will return false if the criteria is met, and we actually want it to return true to disable our behavior. So we need to work a little backwards. We want to set it so that the criteria is that the hero is in range (thus the name). When the criteria are met, it returns false and doesn't disable the behavior. It's confusing, I know, but it's the way it works.
So click on Search - Areas and click the green X to add an area. Arc should be 360 already. Set Compare to "Greater Than", and Count to 0. Set Radius to whatever radius you want to use. I used 20 because I wanted a little room to move for my units. You may choose something different. Close the dialog by hitting OK.
Set Target - Location + to "Caster Unit". Set Validator - Compare to "Greater than". I don't know why you have to do it again there, but you do. Finally, set your Search - Search Filters. I set Heroic to "Required", and unchecked the boxes next to Ally, Enemy, and Neutral. Having only Player checked means it will only look for heroic units owner by the owner of the shop. Since each player has his/her own shop, this works perfectly.
The validator is complete. Go back to the behaviors tab, and find "Behavior - Hero In Range". Set the Behavior - Validators (Disable) to the validator you just created.
Requirements
The requirement does the real work, preventing the player from buying when the hero unit is out of range. Fortunately, it's also fairly simple. Create a new requirement. I called mine "Hero In Range" (for consistancy). There's only one kind of requirement, so leave everything default and click OK. I then set the editor prefix to "Building -" (again).
Double click next to Requirements +, and then right click on the Use node, and click Add Requirement Node. Change the Type to "Count Behavior". Change the Alias to our behavior - "Building - Hero in Range". The State should be "Completed at Unit". Finally, set the Tooltip to "Hero character must be within range", or whatever you want it to say. Leave the Show node blank.
So now our requirement expects the building to have our behavior, otherwise we can't use whatever ability the requirement is attached to. The show node is blank, so it will show the ability no matter what, which is the behavior you expect. We also set the tooltip that will show up when the ability is greyed out, which is just plain good user interface.
One last note about requirements: you can only use one requirement per ability (at least with train abilities). If you're using an ability that already has a requirement, and you want to keep it, or if you want to use another ability, you'll need to combine the two requirements. Duplicate the pre-existing requirement, and add the same requirement we just set up to that requirement. It will now have both requirements.
Abilities
For the purposes of this tutorial, I will assume your ability already exists. It's most likely a train or upgrade ability. Either you've built it already, or you're using a pre-existing ability. Either way, I'm not going to go over the bazillions of ways an ability can be set up. If it doesn't exist already, stop now and make it.
If you need your ability for something else (like if you're going to make normal units of the same type), then duplicate the ability. If there are any actors, duplicate those with it. If you don't need to use the ability for anything else, you can just edit it as-is.
Both the ability types train and research have a section called Ability - Info. Double-click it. For each ability in this list, you need to add the requirement "Building - Hero In Range" to it. As I said before, if there's already a requirement that you want to use, you'll need to combine it with the hero in range requirement and use the combined requirement instead.
That's all you need to do for abilities.
Units
Finally, we get to our shop. Find whatever unit you're using as a shop, and add the following behaviors: "Building - Ally Interact" and "Building - Hero in Range". If you duplicated the ability, double click next to Ability - Abilities + and swap the old one for the duplicate. Make sure the command card buttons have the new ability as well.
Under Stats - Flags, check "Buried" and "Cloaked" for your shop. Don't worry, vision will be handled through detection.
Now, the semi-tedious part is applying the behavior "Detector (Ambient)" to every non-detector unit that will be in your game. Without this, the enemy shops simply won't show up at all. Make sure you get all of your units.
The rest of the work is done in triggers.
The Triggers
All of the code is located in the sample map. It's really only a few triggers, and they're really quite simple. I've also commented them well. I encourage you to take a look and see what they do, but the premise is pretty simple:
The Conclusion
If everything went properly, you should have yourself some really nice-looking allied shops, that feel just like regular allied buildings. There are a few small exceptions:
Pylons
Protoss buildings require power. We all know this. The problem is that the fake buildings don't have this power. There are a couple ways around this: First, You could just remove the power restriction. This wouldn't work in my game, but it may be fine in another type of game.
What did work in my game was just giving the behavior "Building - Ally Interact" to Pylons as well. Pylons don't need "Hero in Range", becase they don't have abilities. The ally interact ability causes clones to be created, which will provide power to the cloned buildings. Since the healths are synced, if the pylon is destroyed, neither building will be powered.
There is, however, some weirdness if you allow the player to build pylons. He can power the building for himself without powering it for the computer. I'm going to overcome this by disallowing building in near the computer's base. It could also be overcome by cloning the pylon back to the computer player somehow, then they would truly share power matrices. This could be done fairly easily in a trigger.
There's also the issue of supply. In my game, I don't use pylons for supply in my game, so I had no problem setting Stats - Supplies to 0 for my Pylons. If that doesn't work for you, you might need to add a behavior that removes the supply from the Pylon. I don't know of another way to remove supply from a unit in a trigger. You'd probably have to specifically check for unit type Pylon in the "Initialize Fake Buildings" action, and apply the behavior if true.
Shared Vision
The method listed above requires that vision be shared (through triggers) to allied players. If we didn't do this, players would never be able to see allied cloaked units.
0
Thanks for the info. I like the format of staredit.net better than the wiki here. Also, the staredit also has some of the groundwork laid out. Unfortunately, it has almost no exposure, so we might need to help it with that. I think we should start working together to fill some of that information out. Please, everyone take a look at http://www.staredit.net/starcraft2/Required/Unfinished_Wikis to see what areas need contribution (frankly, every one of the triggers and data sections needs some revisions at the very least). Declare your intentions here. I think I'll look at modifying the triggers - banks and triggers - custom UI sections. My knowledge falls short with the data editor, so if you have anything to add there, please do.
0
Glad to have everyone's support. It's good to see that something like this will be well-received. Can some help grab the attention of the admins so we can start talking about hosting? I'd really like to host this information here - I think it's the right place.
@BDMon: any amount of contribution is welcome. Just stating that you would use a resource like this helps lay the groundwork for getting everything started. Even a novice developer can add information to this document. There probably are some areas of the editor that you do know fairly well. Contribute to those. There will also be some areas that require documentation that aren't used very often. Someone is going to need to figure out what those do. You can help by figuring out what individual things do and feeding that information to a documentor, or grabbing and entire section and documenting it. When the time comes, you'll probably find an area that you can contribute, no matter how small the contribution. It all adds up.
0
I think we can all agree that it is an understatement to say that the Galaxy editor is poorly documented. Triggers has some decent (but far from ideal) documentation, but there is almost no documentation for the data editor. This lack of documentation, I feel, is the number one barrier for new developers. We've all spent hours trying to figure out what individual fields mean and do. I think it's time for us to share and collect this accumulated knowledge, so that future developers don't have to jump the same hurdles.
I'm talking about a community documentation project for the galaxy editor. Tutorials are great, and definitely have a place in the commuinity and are needed. However, we need references as well. If I just want to know what one specific field or trigger is for, I'd like to have somewhere that I can look. I can add a lot of information to this documentation, but I can't add it all. Together, I think we can. I think it's easily conceivable that we could document the whole frickin' editor in just a short amount of time. Who's with me?
Step one is hosting and format. My perference is to work with the admins and host it here. My format thoughts are wiki-like format, but the individual page format needs to be laid out. After that, we can start doling out sections of the editor for individuals to document.
0
Unfortunately, all the checksums and encryption in the world don't prevent a user from copying his bank file and redeploying it at will. This can have a number of unfair benefits depending on the game. You could duplicate items by giving them to a friend and then reloading your old bank. You can bypass an auto-save if something bad happened to your character. You can backup your bank before editting it, preventing bank deletion when/if the game realizes you've edited your bank. I'm sure there's a few other tricks I haven't thought of, and they're all bad. If I wanted features like this, I'd program them in.
Now, I'm already considering not using items because, frankly, they don't work very well. They feel like an afterthought, and hotkeys for items are horrible. I'm also considering avoiding auto-saving, or at least giving the player options if something bad happens that they'd rather not save. Still, I'd like to immediately save a blank character over their bank if I detect a modification. I'd also like to avoid any other unwanted consequences of bank duplication.
The problem is, there really isn't any way to tell if a bank has been duplicated. None that I know of at least. Is there any way that others can think of that might avoid this pitfall? Everything I can think of falls short. Saving to another bank is just as vulnerable as the first. Timestamps really don't mean anything without relative information (like knowing when the last time the player saved was). As far as I can tell, there's no way to prevent a player from reloading a bank from a backup.
Ideas?
0
If I might offer a suggestion, external hashes would make a nice addition. In my example above, I have 20 keys for unit storage. There's nothing stopping anyone from duplicating a key onto another one. The hash won't notice the difference because it's saved to the string itself and gets copied along with it. So if a player can figure out where his good units are in the bank, he could copy them over on top of his bad units. Even storing a unit count wouldn't prevent this as long as they are replacing one key with another.
I'd like to be able to save a seperate string of unit hashes, but right now STARCODE hashes only work as part of the string. This sort of protection would prevent key duplication, and would be very difficult to circumvent.
Since I need this feature, I'll probably be coding it in the next week or two. If you'd like, I can submit it back to you so that it can be made available to the public.
Now if I could only prevent bank duplication... That's another problem entirely.
0
I guess I misread the README, and I deleted it to save map space, so I actually thought the limitation was much higher than 100. Not a huge deal. Six units per string isn't bad. I was able to break up the unit group into multiple strings at 6 units each, enabling me to save more than 6 units. With the lifted bank limitation, I should be able to save a descent number of units. I'll have to try and push the limits once I have the multi-player truly working.
I really appreciate this library and the contribution you've made to the community. Your library makes compression and encryption so much easier, and it really removes any hurdles to implementation. I think STARCODE is just as important now as it ever was, even with the less strict bank limitations. More space means we can store more data, not that we can be beligerantly inefficient with our data storage.
I just wish Blizzard had let us save in true binary in the first place. Giving us limited storage space and then wasting most of it with XML markup and text-based saving is just... well... it's stupid. They're programmers, they should know better.
EDIT: I was able to save 120 units plus a hero in a 3.3kB bank. Not bad. I'm pretty sure 10 players loading 120 units won't work on BNet, but up to 80 might. Couldn't have done it without your library. For the record, saving 120 units takes about a second (I did have to add a wait of 0.0 seconds). Loading takes considerably longer, but I think most of that is unit creation.
0
My intentions are a little different than that. I used to play an old game "Monopoly Party" for the XBox. In that game, everyone took their turn at the same time. It changed very little about the game, except that it went by a lot faster (If two people landed on the same spot at the same time, and auction occurred between them). I don't want the games to last for hours, no one will play. But if you can get a decent online game of Monopoly that takes about a half an hour, people will play. Rolling, moving and buying are only part of Monopoly. The game gets much more interesting when trading is implemented.
I chose Monopoly because: 1) people like the game, and they will play it. 2) It's my favorite game, and I want to see it done in StarCraft II. I think it would be a lot of fun. 3) It's fairly simple, while still being challenging. As you said, it's good to cut my teeth with. 4) Unlike and RPG or a TD game, it requires almost no messing with the data editor. It's almost all triggers. I'm really good with triggers, but I hate the data editor. But this could be said about just about any board game. 5) It hasn't been done yet.
I didn't specificly pick Monopoly because it's a board game. I picked it because it's a fun game and I can immediately think of ways to build it with the map editor. I can't really think of many other board games that would translate well to StarCraft II. Obviously, Risk, because it's been done dozens of times already. Chess could be done, but I'm pretty sure it already has, and I'm pretty sure I wouldn't want to (too slow). The only other board game I think I'd even consider translating to SCII would be Axis & Allies. I don't believe that's been done either. I'd almost be willing to switch to A&A, but then there still wouldn't a Monopoly. Also, a lot of people would compare A&A to Risk. It would have to be an incredible game for people to play it. Monopoly would just have to be Monopoly, and people would play it.
0
More correctly, everyone is choosing Risk. No one has made a Monopoly game in SC2 to completion, and it appears that only Alcoholix and myself have tried. Search for Risk on BNet - 20+ results. Now search for Monopoly - 0 results. I don't know what you're talking about. Risk is fairly easy to program. Monopoly is quite a bit harder.
You assesment of Monopoly is only your opinion, and most of the rest of the world likes the game. It is, afterall, the most popular board game in existance.
0
Is this a dead project? The same idea occurred to me, but I don't want to step on anyone's toes. I'd be interested in working with you if your still interested in this project. If you're not, would you consider passing along what you've got so far? Credit would be given.
0
I've run into an instance where <StarCode> Decompress String is generating "Execution took too long". It is being run inside a loop (for each player), but the length of the string to decompress is only 79 characters? Is there anything I can do about this? I am certain that this is the step that is failing.
EDIT: I can duplicate this error at will. I am saving units at 11 characters per unit (2 characters for a unit identifier, 3 for experience, 2 for health, 2 for shields, 2 for energy), plus 2 characters for a unit count, and 4 for a hash (which is removed before the decompress). If I save 6 units (68 characters), everything works fine. As soon as I try to save 7, the save runs fine but it times out trying to load them. More correctly, it times out trying to decompress the 79 character string. I suppose I could make a new key for every 6 units, but I was hoping I could get the strings much larger than that. I'd like to be able to store upwards of 80 units in as few strings as possible.
0
I am in the process of building an RPG that retains some of the pre-built RTS elements of StarCraft. The general idea is that you get a hero, and your hero can buy or train units to assist him. RPG elements like items and abilities will also exist, but I really think the added RTS elements will give it some extra depth.
Your hero will have a positive supply number (he gives you supply instead of taking it away), which will go up with level or with abilities like leadership. There will be a maximum cap based on save file limitations. Units will be saved with the hero, and restored when you re-enter the map. To keep normal units viable, they will level up with experience. They will gain automatic stat bonuses with each level, but no additional abilities or the ability to carry items (too much micro-management). Normal unit abilities (like blink, stimpack, et cetera) will be researched normally. Mercenaries will also be available, allowing you to buy units which are already of a certain level, or even cross racial lines (which will not normally be possible).
Each race will have it's own starting point on the map, and a single starting hero. Every 10 levels, you may upgrade ("tech") your hero to a new type. There will be a tree structure to this hero teching. You will retain all abilities, and still be able to research them, while adding new abilities of the new hero type. Due to saving limitations, there is a limit of one save per race. This is why I didn't want to have a bunch of starting heroes. I also means there's no confusing hero selection menus at the beginning of the game, you just get a hero and are dropped right into the action. I want to introduce the game elements organically, hopefully making the game easy to learn. The starting heros are: Zealot Champion, Veteran Marine, and Evolved Zergling.
The story will play out like a story about the game. I want it to feel like you're a hero inside an epic 1v1v1 of StarCraft. The 1v1v1 is actually occuring between the computers, and the heros are added to try and turn the tides.
You can't control the comptuers directly, but they can be used to your advantage. In ally controlled areas, much fiercer units will spawn against your enemies, so retreating to such an area would be effective if you were being harassed by a higher level hero. In all, the random spawns are scaled to each hero, so the game should remain balanced even if the heros themselves are not. That's actually a big goal of mine. The game should be balanced for all players even if the teams are not. The game supports up to 11 players, and all of them can be the same race or different races. The computer scales to these heroes to balance this all out. This is also huge on BNet because a player quitting doesn't matter, which is a problem that plagues other games like Nexus Wars. In invasion on an enemy stronghold should be challenging regardless of the hero composition. I'm thinking the map will support up to level 20, with the end boss designed for level 20 (scaled for the number of heros attacking it). A second map would allow you to go past level 20, plus have new quests and challenges.
Those are my core ideas so far. I am currently focusing on the engine itself, making everything work with less focus on heros, units, items, and quests. Those will be added with time, but the core functionality needs to exist first. I've actually come a long way on the core functionality: items and abilities are working overall. Buying of units and supply cap works. Hero revival is working. The random spawns are working, and are based on territories, determined by number and placement of structures. If anything, the random spawns are actually too strong right now, but I think that is largely because hero abilities are not yet fleshed out. I am in the process of working on saving, which works on some levels but requires some more work. Once the core functionaility is in place, the game will be playable, but will be missing some "polish", which will be added over time.
Please let me know what you think.