Random squad generation

[stepitfast]

Sorry if this has been brought up before. I haven't had all the time I'd like here, or playing, etc. But I was curious if anyone has tried to write an intelligent/random team builder utility that could list, say hundred point teams, of your available figs. Every time I work on it, the logic gets away from me.

Certainly we could all assemble the BEST hundred point team, arguably, ourselves, but I thought it would be fun to have a program that suggested teams, opponents, etc. in combinations that work well, but that may not have occured to us.

I started writing one in VB, after getting all my SW tix figures in a a database file (and I only collect Sw, for now). I felt like it was working well, but it never satisfied this need I have to play faction agains faction. Right now, it just looks for complimentary abilities. And I never solved the "effect" figure problem of whether to select, for example, R2Q5 simply because there was a trooper already in the randomly selected list.

It basically randomizes the list of figs I have, and takes the first one. Then it does its best to find the next figure in the list that complements it somehow. And it does so on and on until 100 points.

I think the idea has potential, and I probably won't rest until I'm satisfied, but if anyone else is thinking about this stuff, please let me know. I'd love to get a fresh perspective.

[ionicdesign]

Sounds interesting, if not familiar with it do check out Malform's TixTool: attacktix.proboards22.com/index.cgi?board=generalattacktix&action=display&thread=1186093198&page=3
which may prove helpful to what you want to do.

[malform]

This is definitely something I have had in mind for TixTool. A squad builder much like the hasbro one, but much more intelligent.

If you would be interested in helping to develop such a tool in TixTool (there is already a very stable foundation developed) just let me know, I personally wouldnt mind the extra help, and Im sure Chris wouldnt mind either.

[stepitfast]

Thanks for the offer to collaborate. I don't know how much time I have to commit to something like that, but I thought it would at least be cathartic to distill the lessons I've learned here, and if it's useful to anyone, great. I definately hit a wall and hope to hear from someone down the road that they had a breakthrough.

The problem in the way I was doing it was that it was tempting to build so much logic into it that the random element was essentially gone. Let's say the first randomly selected figure is an S4 Vader. There is one more S4 Vader is your collection. And several great supporting troopers, like AT-ST drivers. Is the program smart enough to select the BEST supporting trooper? Or is this where the random part of it is simply willing to select ANY trooper as the next figure. I mean, if making a killer team is the goal, then there are probably better figures to accompany S4 vader than 6 random troopers. Like for instance, another S4 vader and 2 AT-ST drivers?

As I got deeper and deeper, I realized that I was just training a program to pick what any decent human team builder would pick. Then it became this question of "why don't I just build a database of great 100 point teams from my collection and have a program that simply grabs two of them randomly and I use that as a basis for my battle?" So I did that for a while, not just 100-point teams, but every value imaginable. And it got to be a pretty big list. But A) the fun was gone because the computer wasn't telling me anything that hadn't already occurred to me and B) the list always needed updating as I added new figures.

So now I am back to my first idea, which is to simply select a figure at random as the first. Then run through the list looking for any figure that supports that first one in some way. Then for the next figure, same deal, but looking for a figure that supports EITHER the first or second one. But it was never smart enough to look for the IDEAL figure that would support BOTH of the already-selected figures. That logic got to be too much for me.

And that's how the program works now. Although it makes okay teams, I never really get excited about playing them because they are almost TOO random. I know, what the hell do I want, right? I guess I like the idea of faction battles. Maybe that could be a check mark on the user interface screen. So it could give me a team of rebels that support one another, vs. a team of whatever. If it's imperials, maybe the program could be smart enough to lean towards figures that are good AGAINST rebels, like the Royal Guard, etc. I don't know. The whole point of writing this was to put this all to rest, not to get me thinking about it again!

Thanks for listening.

[Whiz Kid]

It's definitely and interesting idea, and potentially something I'd use, but the mechanics of it are WAY over my head, so I'm of no help. To echo the other advice, do try TixTool. It's pretty sweet.

[Cona Chris]

This is an interesting idea - I had always thought of a squad evaluator (so you pick the team and it tells you about it) but not one in which the team is chosen for you. That's better I think.

I would think you'd have to start with a figure (or more than one if you wanted) and then let the program fill it in with the rest. Weights would have to be given as far as defense and how important the specials are, and also how vulernable the figures you chose are to other teams (i.e. a team with all Warriors would hate facing the S2 Grievous with his Vengeance special).

It would be neat too if it knew how many figures of each you had (so it doesn't say to include 3 clones with OBK when you only had 2 clones).

[stepitfast]

Yeah, Chris I like the idea of a squad evaluator and that it woud be cool to have the computer suggest a good OPPOSING team to one you've selected manually. From your available figs.

I see a front-end filled with check boxes and buttons with which the user can fine tune the elements of figure selection. And it scares me! Too much programming for me.

I keep going back to the same thing; the more rules you build in, the less random. So whats the point?

And the other thing you mention is the balance between strikers and launchers (did you imply that or did I infer that!?). The current version of the program doesn't care about that balance at all, and I wouldn't know how to go about weighing that. Since the first figure is random, and the last figure selected will be based on how many points remain for the team, more than anything else, that often leaves only 1 or 2 figures to benefit from any random/intelligent team building logic. But I guess on the interface side, the user could select 200 pt or higher games. That would give the program a little more room to work its magic.

Tixtool looks great, btw. No doubt you have the resources and skill to do this, whatever it is.

Maybe we need another way to distinguish figures, by BATTLE, perhaps. We could create a new column in our figure databases with check marks indicating a characters inclusion in an epic battle. Let's say the ESCAPE FROM MOS EISLEY flag would be set to yes for S3 Han, Luke, Chewie, 3PO, Ben, Stormtrooper, Sandtrooper, etc. Or the BATTLE OF ENDOR with Ewoks, S4 Rebels, etc. But I digress.

[superflytnt]

I could write one in Qbasic 4.5 (I gave Malform my C++ suite).

The trick is to assign each Special power a classification number. You need to make a table of figures that has the 'complementary figure types' codes in it. Do it so that every faction and class of figure is loaded into it.

1=Jedi Warrior Recover Trooper
2= Jedi Warror Rescue Specialist
3=Jedi Warrior Yada Yada
4...and so on

Then for each figure in the Dbase of figures, assign a data point in each 'file' that has 1st 2nd and 3rd choice for "figure compatibility". You decide which ones work best with others. Then pop the numbers in the fields and the rest is a simple logic box.


Then, randomly select a figure, and capture that into a variable FIELD. From that FIELD read the "complementary figure types" data point, and that tells the program which figure is best suited. Then read and search each 'file' sequentially to look only for that specific number that matches the number on the "complementary figure types". Once one is selected, store that figure in the new FIELD as a second data point, then repeat the process by looking for figures that complement both #1 and #2. This is acheived by scanning the 'file' (database) for figures potentially compatible with the originally selected figure, making a list of candidates "X" long, and searching AGAIN for a figure complementary with the second figure. Once the list of #1 compatible and #2 compatible figures is created, scan them and try to make a THIRD list of those compatible with both. Once you've done that, randomly select that figure from the third list and check for points. If points are too high, then move to the next figure compatible with both. And so on....

If done right, this will be a "For X" or a "Do Until TotalFigurePoints% = SelectedUserPoints" that is nested about 7 levels deep, or will have a TON of calls to functions. I always create functions to do the dirty work to keep the massive number of global variables down. Up to you how you want to do it, but the logic is fairly simple.

[stepitfast]

Well, you must think I'm an idiot for struggling with the logic since, as you put it, it's fairly simple. I figured by posting here, I'd find some people more qualified than myself to make something of this. Apparently, you are, so I await your finished product!

[YodaBreaker]

superflytnt said:

If done right, this will be a "For X" or a "Do Until TotalFigurePoints% = SelectedUserPoints" that is nested about 7 levels deep, or will have a TON of calls to functions. I always create functions to do the dirty work to keep the massive number of global variables down. Up to you how you want to do it, but the logic is fairly simple.

And then there's me, who'd want to use a bunch of variables to avoid the nested code. In that way, you could use a "prototype matching" algorithm to find the "best" figure to put in (see the code I wrote for the Attacktix Personality Quiz for an example of this method). The more variables on which any figure in the database matches the prototype called for by a given figure (or combination of figures), the higher its overall "prototype match" rating. I think this was similar to what stepitfast described doing already.

It'd be really nifty to average prototype matches for the squad based on the composition of its individual members, perhaps weighted by their point costs. For example, in a seed squad of 40 point SW S1 Armored Vader and 3 different 10-point Troopers, figures matching Vader's preferred special power requirements (i.e., Trooper, and likely 10 points to crowd as many in as possible) would be weighted 4 times as much as any of the Troopers. If the Troopers were all the same, Vader would still be weighted 4/3 as much as the combined 30-point Trooper mass for any one prototypical attribute. An interface with TixTool could then make sure the random number generator (and initial selection) operates only on figures that a person has. This is the part that it sounds like stepitfast's program doesn't do - with a prototype matching system, all one would need to do is compute a point-weighted average of the prototypical special power requirements for each figure.

For example, in the squad above, "Trooper" would get an overall prototypical weight of 4/7 for the team mentioned above - (1*4 for Armored Vader's SP requirements + 0/3 for the Trooper requirements)/7 for the number of points on the squad divided by 10. Assuming the troopers are all SW S1 Republic Clone Troopers, the attributes "Republic" and "Launcher" would get weights of 3/7 because Darth Vader doesn't care about the faction or attack type of his support Troopers, but the SW S1 Republic Clone Trooper gives a Shootback only to Republic launcher figures. Thus, the subsequent choices would likely be biased toward Troopers of the Republic launcher persuasion (perhaps an Utapau Warrior, perhaps a Starter 2 Republic Clone Trooper, perhaps some other Republic launcher Trooper).

However, if one is a SW S3 Republic Clone Trooper, one is a SW S2 Grievous Bodyguard, and one is a SW S3 Stormtrooper, the attribute "Launcher" would get a 2/7 prototype weighting (Shootbacks are on the Clone Trooper and Grievous Bodyguard; the Stormtrooper's agnostic about the type of attack its Attackback grants); "Republic", "Droid Army", and "Empire" would each have a weight of 1/7. Thus, subsequent selection would likely be biased in favor of Trooper (remember Armored Vader's 4/7 contribution to "Trooper") launchers from either the Republic, Droid Army, or Empire factions. The subsequent random choice of trooper (Republic Clone Trooper? S1 Super Battle Droid? AT-ST Driver?) would then bias the selection further. It'd be even more interesting to seed a team with a figure that only requires "another figure in play", like SW S1 Yoda or SW S4 Darth Vader or Grand Moff Tarkin. Their special power requirements are completely agnostic about what other figures are required, so the choice of a second figure would be completely random!

The problem with this algorithm would be adjudicating between ties for each selection in the frequent case (especially with a seed figure) that different figures would have an equal overall match the prototype called for by an individual seed figure's special powers. I think this is where a call to the random number generator comes in. In this way, for a Jedi-centered squad with gold-based Ki-Adi-Mundi as the seed (whose special power yields 3 Attackbacks for Jedi), a 40-point Jedi Force blaster might get picked one time, a 30-point Jedi Clone Commander might get picked another time, a 20-point Agen Kolar might get chosen in another spin, and a 10-point Jedi Knight might get chosen in a last run. Each of these random decisions would then have substantial impacts on the composition of the subsequent team.

It would seem that all things being equal, the algorithm could be biased toward picking large point value figures when there's a lot of room left on the team and smaller point value figures when there are fewer points left to assign. In this way, you'd get a mix of large-point and small-point figures in each squad. Then again, this method would also bias squads toward having a mix of hihg- and low-point figures, which is an additional constraint on team formation. I suppose one could just let the random number generator fly without bias when faced with identical prototypically-matched figures

It's important to note that all these decisions would be made based on special power requirements, which don't often involve things like base size or attack type within figure (e.g., medium missile vs. small missile launcher; claw vs. prodder striker). However, you could also have a few sets of decision algorithms that might assign differential weights to the prototypical features, which would allow for amore specific squad selection. In fact, this way of programming it would allow you to select a certain "profile" for a team (e.g., "One heavy hitter with lots of support figures" would ask you to seed using a 30- or 40-point figure, then fill in 10-point weenie striker and launcher Troopers preferentially - as described in the points-remaining-weighted algorithm above, "Higher-cost stable heroes" would start with a 20-40 point seed figure and pick other 20-40 point figures with at least medium base sizes to round out the team, "Swarm" would start with a 10-point seed and fill in other 10- or 20-pointers that would be complementary to the seed figure). Heck, I've been talking about starting with a seed figure as if the player chose it - one could have the random number generator pick a seed figure just as easily and operate with no constraints besides special powers for a totally random team. To me, this is where the prototype matching algorithm would be superior to the multi-nested tabular "1 value per figure type" approach. It allows for flexibility in assigning the relative importance of different figure attributes during team selection, rather than collapsing all attributes into a single nominal value that can't really be changed.

I know how to code such a thing, but the time it would take would be...well, tremendous. I could try recycling the Attacktix Personality Quiz code for a lot of it, as it codes for just about any attribute one might care to have on Attacktix figures. However, until my grants and papers are written, along with code for something I actually use for work, I think someone else with the interest in it could try implementing it

[superflytnt]

The time is the problem, the complexities are not that bad. I would be able to do this if I had a vast amount of time.

And NO you're not an idiot. I used to do this stuff for a living when looking for voters in the state of CA to target for "Hey, Vote for 'X' because he paid a lot of money for us to find you!" I also coded applets and palm applications at one point.

So, in short, it's not that hard if you sit and think it out first, then set the conditions for success.

And YB, all that extra algorithmic work would be a lot of extra work that leads to the same end, IMO. It would be far easier for the programmer, in advance, to set keys in each figure's field as I illustrated before to take the "thinking" away from the machine, hence there would be predispositions already selected for the logic box to select from.

In the event of a tie (which would be pretty rare, I'd think) you could simply assign a random number to each of the 'tied' selections and pseudorandomly select one. The reason I say this would likely be a rarity would be that from the first pseudorandom choice you'd have the conditions set for predisposition based upon the special. In the case of say, Kit Fisto, who is pretty much universally usable, the figure would likely have had the 'complimentary figure' field set to "Jedi Specialists", "Jedi Warriors", "Droid Army Troopers", "Republic Leaders". This would look for KAMs, Agens, Tions, GBGs, and Destroyers who would either Rally him or reap a good benefit from the Battle Cry (2 shots from the Destroyer, yada yada yada). Then with those 2 selected, for giggles let's say that Gold KAM was selected, then the next selection would be someone based upon the commonality between the Kit's "complementary figs" field and the Gold KAM's field, which would end up with a likely hit on a Jedi Warrior or a Jedi Specialist.

One would also, now that I'm thinking about it, want to add in a "No-Go" field to set figures that should NOT be selected for any reason. In the Kit Fisto example, it would be good to include "Gold Plo Koon" as he would Recruit a Kit, which we know if Kit is in play, would be a waste of 40 points.

Also, it would be a good idea to have a "eligible backups" field in each character profile to call into play certain characters, either by class or by name, to help identify backups based upon the figure selection, and possibly a weight (1-10) for the named potential backup. Then, based upon the weight of the figures, when the logic box decides which backups to select, it can scan the characters' (selected team's) backup fields and look at the highest weighted backup and select it, then another....and so on down the line until it's all done.

Finally, the variables and the nested code are not mutually exclusive. The nests would be so that If/Then and Do/For loops can run through the file list without having to store the entire file in memory, thus creating a few hundred "field" data entires. Easier to define one "field" and then keep reusing it be loading the characters one at a time, scanning it, determining feasibility, and then moving onto the next.

Complex coding, at one point, was my spesh-ee-alitee!

[YodaBreaker]

superflytnt said:

And YB, all that extra algorithmic work would be a lot of extra work that leads to the same end, IMO. It would be far easier for the programmer, in advance, to set keys in each figure's field as I illustrated before to take the "thinking" away from the machine, hence there would be predispositions already selected for the logic box to select from.

I can't see it that way yet, especially if you want to set up team-choosing profiles. I'll admit, the table I'd set up would have more than two columns, but I don't believe that it'd be best to code every attribute of a figure in a single numerical value. For example, the way I'm thinking of things, there'd be a master table with as many rows as there are figures (+1 header), and as many columns as there are figure names and attributes associated with each figure. In your setup, I'd see a two-column table that the machine would use: one for the figure name and one for the "code" corresponding to the figure's attributes. You'd likely need to keep a human-readable table of what those codes correspond to, but the program wouldn't likely need to know what verbal descriptors you give to any of the codes mean.

The problem I see with the two-column table approach is that it's brittler than the multi-column table approach. In particular, what if you realize that the human-readable table doesn't have enough categories? For example, let's say that we were building this puppy before the advent of the MV S2 starter set, in which different point values weren't considered in special powers, so neither of us thought to include it in our scheme. In my case, I now just add a column of point values to the table (or a number of columns, one for each point value) and a line of code in the prototype matching scheme to evaluate the new column(s). Assuming that I use "if exist" sorts of statements for calculating each field, all versions of the program should be backwards-compatible with each other. However, earlier versions won't take full advantage of all the information in the data table.

In contrast, you'd have to rewrite the entire data table. Now, this could be done rather easily with a spreadsheet function that increments a counter if the current value of the "massed attribute" column is different from the previous value. However, you'd then be left with a new table that previous versions wouldn't be able to use. You'd have to maintain different versions of the table for different versions of the program because a given numerical code wouldn't correspond to the same cluster of attributes. You'd also have to update different "magic numbers" in your code for each revision to make sure that your coding scheme between the new code and new table is congruent. Not only is backward compatibility impossible, but there's a lot of work required to maintain the internal code that's presumably relying on the code numbers of each "massed attribute" column. That is, unless you knew that human-readable table of "massed attributes" and their corresponding codes, it'd be impossible to tell what a given numerical value in the code would correspond to. Even if instead of a numerical code, you had a human-sensible string that would correspond to the "massed attribute" column, you'd still have to do lots of finds and replaces in the old code to update it to the new table.

This problem becomes particularly evident to me when you consider letting users set different profiles of figures they want to have selected based on attributes that aren't . For example, let's say that a user might want to have a medium-based tosser and a large-based claw striker on the team. Neither base size nor the projectile launcher/tosser or striker/upper-downcutter distinction is built into special powers. In my scheme, you'd just weight a particular column's value to a certain degree. In yours, you'd have to weight a number of different codes (the identities of which would change between program versions) all at once.

In the event of a tie (which would be pretty rare, I'd think) you could simply assign a random number to each of the 'tied' selections and pseudorandomly select one. The reason I say this would likely be a rarity would be that from the first pseudorandom choice you'd have the conditions set for predisposition based upon the special. In the case of say, Kit Fisto, who is pretty much universally usable, the figure would likely have had the 'complimentary figure' field set to "Jedi Specialists", "Jedi Warriors", "Droid Army Troopers", "Republic Leaders". This would look for KAMs, Agens, Tions, GBGs, and Destroyers who would either Rally him or reap a good benefit from the Battle Cry (2 shots from the Destroyer, yada yada yada). Then with those 2 selected, for giggles let's say that Gold KAM was selected, then the next selection would be someone based upon the commonality between the Kit's "complementary figs" field and the Gold KAM's field, which would end up with a likely hit on a Jedi Warrior or a Jedi Specialist.

At least from my experience programming the Attacktix Personality Quix, in the prototype matching scenario, ties happen a lot more often than I'd thought they would when I started it. However, ties would be increasingly less likely as squad selection progressed - by the sixth figure, I'd agree that it'd be rare to have ties.

One would also, now that I'm thinking about it, want to add in a "No-Go" field to set figures that should NOT be selected for any reason. In the Kit Fisto example, it would be good to include "Gold Plo Koon" as he would Recruit a Kit, which we know if Kit is in play, would be a waste of 40 points.

For a purely random squad selector, I'd argue that a no-go field wouldn't be desirable. It very well may be fine and good to try out a squad that's pull a second Kit in - perhaps the first one is a target for early attacks, and the gold-based Plo Koon would allow for some ranged attacks early on that could knock some figures down until he gets offed, by which time your opponent's figures may be close enough to your starting line that a Kit coming in would be able to wipe them out...all of them

Also, it would be a good idea to have a "eligible backups" field in each character profile to call into play certain characters, either by class or by name, to help identify backups based upon the figure selection, and possibly a weight (1-10) for the named potential backup. Then, based upon the weight of the figures, when the logic box decides which backups to select, it can scan the characters' (selected team's) backup fields and look at the highest weighted backup and select it, then another....and so on down the line until it's all done.

Yep - though it'd probably good for that option not to be enabled if there are no conditions in which back-ups would help a player. SW S1 Anakin Skywalker made that a difficult condition to accept from the get-go, but MV S1 Mystique makes back-ups a particularly dangerous thing to have, if your own squad can't do anything with 'em. Offhand, I'd have it pick backups only if powers like Recruit were present on the squad. However, the backups would then be picked to be maximally synergistic with the entire squad and so would be picked as a second step in team selection.

Finally, the variables and the nested code are not mutually exclusive. The nests would be so that If/Then and Do/For loops can run through the file list without having to store the entire file in memory, thus creating a few hundred "field" data entires. Easier to define one "field" and then keep reusing it be loading the characters one at a time, scanning it, determining feasibility, and then moving onto the next.

I agree that the machine load is easier with your solution, so if memory footprint or computation speed are issues, your way would be better for those needs. However, assuming that a system can spare a couple of megs of memory for the whole table and has a reasonably fast processor (i.e., something like a 386),

Complex coding, at one point, was my spesh-ee-alitee!

Mine, too, until I realized that simpler code was much easier to debug and maintain If nothing else, this exchange demonstrates that stepitfast is hardly stupid - this is a problem with at least two solutions.

[superflytnt]

LOL. I agree, there are a multitude of equally interesting and probably equally effective outcomes. I guess I am still stuck on DOS and VM as I had to program predominantly on VAX, IBM VM for Mainframes, and other interesting machines. In my experience, though, the code is far shorter when you reuse a single field of data rather than read in upon startup the entire array of data and put each into it's own variable data array. I guess with C++ though it would not be too bad at all since you can create nice little entire datastructures calling one field ie. FIELD$ (Charname$, CharPoints$, Char...., 1-500) and each one ends up as a FIELD$(1), FIELD$(2) as arrays.

And we are actually in total agreement on the multicolumn approach, that was indeed what I was trying (apparently unsuccessfully) to illustrate - that every figure could have, let's say, up to 10 'possible best fits' for complementary figures, with each one having it's own 'weight' variable.

Great minds think alike! I still say that the true randomness of the entire squad will be based upon the first selected, the cornerstone so to speak, and the rest would be calculated for maximum collaboration. I truly believe that when looking to correlate the powers to one another should be simple if a table as we're describing is used, and there would be minimal issues with ties.

I think this model we're discussing is really TOO simple, though, now that I am really thinking about it. The better model would be where the user could input a favored Faction to start, or perhaps a number of different options (vis-a-vis Chris's ideas) such as using a certain SP or effect as a base starting point to randomly select figures that have a subset of "X" SP or effect, narrowing the field of possible starting seed figures to adapt the program to your choice.

I think if we all had more time and patience, we could come up with a real killer app, and if done in VB or C++ could pop right into the Access environment via a call and be a greatly utilized addition to TixTool 2.0!

[YodaBreaker]

superflytnt said:

LOL. I agree, there are a multitude of equally interesting and probably equally effective outcomes. I guess I am still stuck on DOS and VM as I had to program predominantly on VAX, IBM VM for Mainframes, and other interesting machines. In my experience, though, the code is far shorter when you reuse a single field of data rather than read in upon startup the entire array of data and put each into it's own variable data array. I guess with C++ though it would not be too bad at all since you can create nice little entire datastructures calling one field ie. FIELD$ (Charname$, CharPoints$, Char...., 1-500) and each one ends up as a FIELD$(1), FIELD$(2) as arrays.

Mmm...VAX. Yeah, if your main point of reference for programming is one that's not friendly to structures, I can see why you'd blanch at the notion. I've done most of my programming in Basic (C-64, TI-85, and Visual versions) and Matlab, with much more of the serious stuff in the latter, so my intuitions are toward data structures of exactly the form you're describing. That's how I'd anticipated a large table would be read in.

And we are actually in total agreement on the multicolumn approach, that was indeed what I was trying (apparently unsuccessfully) to illustrate - that every figure could have, let's say, up to 10 'possible best fits' for complementary figures, with each one having it's own 'weight' variable.

Gotcha

Great minds think alike! I still say that the true randomness of the entire squad will be based upon the first selected, the cornerstone so to speak, and the rest would be calculated for maximum collaboration. I truly believe that when looking to correlate the powers to one another should be simple if a table as we're describing is used, and there would be minimal issues with ties.

Absent the selection of a figure that can key off any figure for special power activation, I'd agree with your first point above. The first figures should have the largest effect on team selection because their stats will not only determine the selection of the second figure but will also remain influential throughout team selection. The more I think of this, though, the more I like the idea and have to restrain myself from doing it.

However, as I said above, the possibilties for ties in the second figure selection are tremendous, though they decrease in probability as a squad grows and becomes more synergistic. Think of how many Troopers there are in the Attacktix universe that, in a purely random selection, could be used to support Starter 2 Kenobi. Them's a lotta ties to break - absent other constraints, in the Droid Army faction alone, there'd be the S1 Battle Droid, S1 Super Battle Droid, S2 Destroyer Droid, and the S1 and S2 Grievous' Bodyguards

I think this model we're discussing is really TOO simple, though, now that I am really thinking about it. The better model would be where the user could input a favored Faction to start, or perhaps a number of different options (vis-a-vis Chris's ideas) such as using a certain SP or effect as a base starting point to randomly select figures that have a subset of "X" SP or effect, narrowing the field of possible starting seed figures to adapt the program to your choice.

Yep, that's what I was thinking of having with different "profiles". You might even specify a minimum special power percentage that you'd want for squad members (which could then be an attribute whose weight always stays at 1, no matter the current squad composition, or -1, if it's something that should be a knock against a particular figure, like having too low an SP probability). Of course, the hope would eventually be that users could have a "custom" selection with a bunch of checkboxes, like stepitfast was talking about. There are definitely a lot of possibilities for constraints to be placed on random squad selection that could generate faction-centric, special power-centric, effect-centric, or ec-centric squads

I think if we all had more time and patience, we could come up with a real killer app, and if done in VB or C++ could pop right into the Access environment via a call and be a greatly utilized addition to TixTool 2.0!

I agree. Of course, I'd prefer C++, just because it's not an MS-sponsored language And if you program under Linux, a C++ compiler comes free with most any distribution ;D