lots of programming classes have you deal with decks of cards. Lots of options for shuffling and managing them. It really depends on how you are using them and how you prefer to work with them... easiest way to randomize the cards is to make a second array of cards, loop through the first array and insert the card randomly into the second one inserting at a random point in the second array (aka, if you have 4 cards in the second array, you will insert the fifth element as element 0-5, when you get to the 6th element, insert it between 0-6, seventh between 0-7). This is nice if your deck is being shuffled when it is not full as you can skip empty elements. It runs in O=n time and isn't complicated. It's not a "truely random" shuffle however...
Another fun way if memory is a problem or just as an exercise, is to loop through the array of cards and swaping each card with a random card in the deck. it doesn't seem like random placement but it is (or at least close enough). this method doesn't work well if random members of the "deck" are missing when you shuffle, but is very quick and memory efficient. You can make modifications to the algorhythm to ensure the deck is "pushed' all the way to the beginning of the array very simply though.
These ways work well if you are doing something like creating a record and having it hold a suit and a rank. These "virtual decks" are fine, and intuitive, but a lot of the time it is easier to deal with a simulated card system.
Use an array of 52 bools (or even better a bit array), and simply use the mod 13 of the card for the suit, and the mod 4 of the card for the rank. When you put a card in a players hand, simply turn the bool off, and insert the array element # into the player's hand as an int. A bit rougher to get your head around, but just as simple and much lighter of a system in terms of coding. This method has it's advantages and disadvantages though.
Out of these three, I'd probably suggest the middle one... it seems the closest to what you are doing and need.
I have not yet done much modifying to units, but my suggestion is you simply make it an upgrade and "upgrade them" so they have it. it makes it easy to toggle it on/off as opposed to adding the ability and removing it (the engine probably likes it more too)
If you make them an upgrade you can set logic so that it only works if they don't have an ability in that slot... but what I'd do is build a "tech tree"...
Then, Skill 1-1-1 upgrades to skill 1-1-2 skill 1-2-1 upgrades to 1-2-2 etc
i.e. "Learn Skill 1" (Choices): (1) Fireball, (2) Shock, (3) Gust
THEN... The upgrade to Fireball is Fireball 2, and the upgrade to Shock is Shock 2 etc...
then you don't have to worry about overlap or anything
Nice ZeroAme, I think the problem people are having is getting that behavior while logged into bnet because I don't think bnet lets you d/l the 2nd map automatically... Although there are a handful of preload functions, I doubt you can pre-load a whole map... I'll have to check it out.
I'd use an event "unit enters region" and set it to a cirlce region within range of that unit.
I don't mean to place an actual circle region, you should use the function to generate a circle region around the unit, so it doesn' matter where that unit is.
Here's a map with all the code visible.
I forget that the exporting thing blanks out scripts for all but the originating computer.
There's a couple simple commands to see how it works
type -sp1 or -sp2 to spawn a wave for that player and -nxt1 and -nxt2 to step to the next wave
and forgive me throwing anth in front of everything... when i began I didn't have a label. I'll probably go through and clean out all the 'anth's when I get bored some day.
add wave for one player adds a wave to a single player, add wave for all players adds a wave to all active players. the All players, is just a shortcut so people don't need to loop through them. This way if all players have the same waves, you can add it to all, and if each player has different waves (say based on difficulty or otherwise) you can add them individually to each player.
Right now you can only add a wave to the end of the list, there is no insertion, but that's comming.
Like I said, this isn't even remotely complete, but I will definately comment each actioin, thanks Saki.
I will be adding a LOT of functions to let the user track the status of a wave (units left to spawn, killed units, alive units, next wave's unit, etc) as well as additional manipulation of the waves.
the event "any unit dies" needs to add a condition of owner of killing unit = player 1, otherwise it is simply adding up all units that have died, including player 1
Hey all, I've been working on a library for the past couple weeks and have hit a road block attempting to register a new event with the event manager... so while I decide on how to deal with that, i figured I'd post the library here for some preliminary feedback.
I haven't cleaned up the library at all and obviously haven't made the documentation yet, so forgive the mess...
I don't mess around with banks, but couldn't you save the data to a bank, then have the person "start" your next map online, and just load from that bank on the new map? it wouldn't be "smooth", aka, the player would have to find your next map, but I bet you could do it.
That's awesome, but you're not going to be going around mussing with other player's MPQ files and I believe bnet does a validation check on things like that every time you log in to prevent tampering... but I'm have no basis for that claim other than "I would guess"
I'm going to agree with S3rius, you would have less overhead with an actor as the base, but unless you are running out of memory or processing power, units are going to be a lot simpler (you technically should be able to do everything to an actor that you can a unit, but a lot of the behaviors will be built into a unit, and you'd have to code from scratch for an actor)
The only other idea in terms of simplicity I have is I know there's a "beam" type effect used for things like the Void Ray beam. If you can change properties of it, you would have it mostly done... but it may take you longer to figure out how to mess with it than it would coding up your custom unit chain.
0
lots of programming classes have you deal with decks of cards. Lots of options for shuffling and managing them. It really depends on how you are using them and how you prefer to work with them... easiest way to randomize the cards is to make a second array of cards, loop through the first array and insert the card randomly into the second one inserting at a random point in the second array (aka, if you have 4 cards in the second array, you will insert the fifth element as element 0-5, when you get to the 6th element, insert it between 0-6, seventh between 0-7). This is nice if your deck is being shuffled when it is not full as you can skip empty elements. It runs in O=n time and isn't complicated. It's not a "truely random" shuffle however...
Another fun way if memory is a problem or just as an exercise, is to loop through the array of cards and swaping each card with a random card in the deck. it doesn't seem like random placement but it is (or at least close enough). this method doesn't work well if random members of the "deck" are missing when you shuffle, but is very quick and memory efficient. You can make modifications to the algorhythm to ensure the deck is "pushed' all the way to the beginning of the array very simply though.
These ways work well if you are doing something like creating a record and having it hold a suit and a rank. These "virtual decks" are fine, and intuitive, but a lot of the time it is easier to deal with a simulated card system. Use an array of 52 bools (or even better a bit array), and simply use the mod 13 of the card for the suit, and the mod 4 of the card for the rank. When you put a card in a players hand, simply turn the bool off, and insert the array element # into the player's hand as an int. A bit rougher to get your head around, but just as simple and much lighter of a system in terms of coding. This method has it's advantages and disadvantages though.
Out of these three, I'd probably suggest the middle one... it seems the closest to what you are doing and need.
0
easiest way for me is to put Debug-msg in my trigger and have it output variables and other things
0
I have not yet done much modifying to units, but my suggestion is you simply make it an upgrade and "upgrade them" so they have it. it makes it easy to toggle it on/off as opposed to adding the ability and removing it (the engine probably likes it more too)
0
If you make them an upgrade you can set logic so that it only works if they don't have an ability in that slot... but what I'd do is build a "tech tree"...
Aka...
i.e. "Learn Skill 1" (Choices): (1) Fireball, (2) Shock, (3) Gust THEN... The upgrade to Fireball is Fireball 2, and the upgrade to Shock is Shock 2 etc... then you don't have to worry about overlap or anything
0
@ZeroAme: Go
Nice ZeroAme, I think the problem people are having is getting that behavior while logged into bnet because I don't think bnet lets you d/l the 2nd map automatically... Although there are a handful of preload functions, I doubt you can pre-load a whole map... I'll have to check it out.
0
I'd use an event "unit enters region" and set it to a cirlce region within range of that unit.
0
Know what... this will be easier...
Here's a map with all the code visible. I forget that the exporting thing blanks out scripts for all but the originating computer.
There's a couple simple commands to see how it works
type -sp1 or -sp2 to spawn a wave for that player and -nxt1 and -nxt2 to step to the next wave
and forgive me throwing anth in front of everything... when i began I didn't have a label. I'll probably go through and clean out all the 'anth's when I get bored some day.
0
@SakiSakurai: Go
add wave for one player adds a wave to a single player, add wave for all players adds a wave to all active players. the All players, is just a shortcut so people don't need to loop through them. This way if all players have the same waves, you can add it to all, and if each player has different waves (say based on difficulty or otherwise) you can add them individually to each player.
Right now you can only add a wave to the end of the list, there is no insertion, but that's comming.
Like I said, this isn't even remotely complete, but I will definately comment each actioin, thanks Saki.
I will be adding a LOT of functions to let the user track the status of a wave (units left to spawn, killed units, alive units, next wave's unit, etc) as well as additional manipulation of the waves.
0
the event "any unit dies" needs to add a condition of owner of killing unit = player 1, otherwise it is simply adding up all units that have died, including player 1
0
Ha! yeah, sry, I never been this far down the threads page, didn't realize there was a Libraries section. My bad, thanks Programmer.
0
This library is meant for creating and managing waves of units for games like Hero defense and tower defenses.
In it's current state (despite what documentation says) It can currently handle up to 4 players.
*NOTE: I added a link to a map with some samples a few posts down so you can see it since things are so rough right now!
0
Hey all, I've been working on a library for the past couple weeks and have hit a road block attempting to register a new event with the event manager... so while I decide on how to deal with that, i figured I'd post the library here for some preliminary feedback.
I haven't cleaned up the library at all and obviously haven't made the documentation yet, so forgive the mess...
0
I don't mess around with banks, but couldn't you save the data to a bank, then have the person "start" your next map online, and just load from that bank on the new map? it wouldn't be "smooth", aka, the player would have to find your next map, but I bet you could do it.
0
That's awesome, but you're not going to be going around mussing with other player's MPQ files and I believe bnet does a validation check on things like that every time you log in to prevent tampering... but I'm have no basis for that claim other than "I would guess"
0
I'm going to agree with S3rius, you would have less overhead with an actor as the base, but unless you are running out of memory or processing power, units are going to be a lot simpler (you technically should be able to do everything to an actor that you can a unit, but a lot of the behaviors will be built into a unit, and you'd have to code from scratch for an actor)
The only other idea in terms of simplicity I have is I know there's a "beam" type effect used for things like the Void Ray beam. If you can change properties of it, you would have it mostly done... but it may take you longer to figure out how to mess with it than it would coding up your custom unit chain.