Skip to Content
 

Computer Assisted Play Testing

17 replies [Last post]
Thu, 05/20/2004 - 19:39
DarkDream
Offline
Joined: 12/31/1969

Working with my "Chariots of War" board game, I thought of writing a rough and dirty program to go ahead play test certain features of the game under certain circumstances. For example, given two chariots with X amount of energy with a max speed of Y with a given strategy Z, who will win the most times? How many ties will there be?

By running the scenario thousands of times, I can get a feel for whether the game is properly balanced or not (does the ramming produce enough damage, is the skidding working properly). As my game has the random element of dice rolls, I can statistically get a feel whether a rule is working or not.

Has anyone else gone this route? I know quite a few of you guys are programmers.

The idea is iterating 1000s of times over a scenario to see the results of the game rules. From it I think you can glean some good information. While it may not help in all areas of playtesting, it can help in maybe balancing some elements properly.

--DarkDream

Top
Thu, 05/20/2004 - 19:55
#1
Anonymous
Computer Assisted Play Testing

That's a great idea, and would help a lot when playtesting certain mechanics rather than an entire game (few non-game designers would be willing to playtest a mechanic, let alone a protoype from my experience which is quite limited, but hey)

Top
Thu, 05/20/2004 - 21:19
#2
GeminiWeb
Offline
Joined: 07/31/2008
Computer Assisted Play Testing

I've been tempted a few times, but my programming skills aren't up to it.

Instead, I've had to use by statistics degree for things like expected number of actions to do something given a certain card distribution and the like. The next step, which probably wouldn't be too hard, would be to set up 95% confidence intervals along with it. I then use that to evaluate the card distribution and modify it accordingly.

Of course, simulation does exactly the same thing by brute force and, as such, can better handle more complex scenarios where the theory gets tricky ...

Top
Thu, 05/20/2004 - 22:07
#3
Fos
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

I've used rudimentary statistics to find average draws in El Cid, but that was simple enough to pen and paper it.

My biggest hurdle in computer assisted playtesting has been finding scenarios and testing conditions within my games that are devoid of human choice; my decisions seem too complicated to write a few "quick and dirty" if...then statements. Unfortunately, my programming ability only allows quick and dirty tests (although my code is clean, I've been told), and I can't very well do a neural net black box solution to have the computer pick moves without my input of what I feel is appropriate and correct strategy in given a situation (which kinda ruins the point).

I'm a little depressed about it because I enjoy brute forcing answers and, for instance, I got a tingle of joy when I wrote a program to turn bitmaps into html colored text for the sheer hell of it. I'm constantly looking for scenarios that could be mechanically tested, if only to combine my programming hobby with my game design hobby, but so far it hasn't shown up.

Top
Thu, 05/20/2004 - 23:03
#4
DarkDream
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

I did a post on testing out the different results of rolling my outcome dice (Need Help with Ramming Die Roll Mechanic): http://www.bgdf.com/modules.php?name=Forums&file=viewtopic&t=1088

I think I ended up rolling 3 dice two hundred times and tallied the results. When I think about it, I laugh. A computer program is a excellent alternative to rolling dice like this and tallying results, plus it needs fairly little computer expertise to write a little program to do this.

Granted, most randomizer algorithms you use are pseudo-random, but are random enough in my opinion to give you fairly accurate results.

Isn't using a program a lot easier than rolling 200 times and tallying results? A program can do this 2,000,000 times and tally the results in seconds if not microseconds.

The general point I'm trying to make, is if you have time to invest in writing a program to simulate aspects of your game or even a specific mechanic, I think it is well worth it.

--DarkDream

Top
Thu, 05/20/2004 - 23:22
#5
Fos
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

DarkDream wrote:
The general point I'm trying to make, is if you have time to invest in writing a program to simulate aspects of your game or even a specific mechanic, I think it is well worth it.

I fully agree, especially if the mechanic is dice rolling. :) In fact, I almost wrote a little program myself for your game in that thread, until I realized I had a simple math error that made the probabilities seem much more complex than they were.

Top
Fri, 05/21/2004 - 10:27
#6
Brykovian
Brykovian's picture
Offline
Joined: 07/21/2008
Computer Assisted Play Testing

I haven't done it yet, since I usually have more problems working through the things that are human-decision related ... and, as you mentioned, that's not quite the area that a Q&D mass-simulator will help too much.

However, the computer version of "Castle Danger" initially started out as a simple proof of concept of the game, to allow me to play it through without having to physically make a game board and pieces. The first public computer version was around about a year before I even prototyped a physical version of it.

-Bryk

Top
Fri, 05/21/2004 - 17:15
#7
FastLearner
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

I've simulated dealing hands of cards in order to figure out how to balance my deck design... in my Cow Tipping game rewrite I used a little web app to deal tens of thousands of hands of certain deck combinations to determine the odds of various hand combinations (sets and runs in various sizes). While it took a bit to program (about 4 hours), it was way easier than learning and figuring out how to program combinatorics, at least for me. And now it's completely reusable for future games.

Maybe at some point I'll add some error checking and make it public. Since it doesn't access a database or read/write any files, there's not a lot of security to worry about.

I wrote it as a web app so that others could use it, but the dealing mechanism is extremely inefficient (it builds a deck of cards as an array and then starts selecting them randomly -- once selected they're flagged as having been dealt... as such it takes a lot of attempts to deal that last card in the deck ;)) and the page can timeout if you deal too many hands, so... I guess PM me if you'd like the URL (or if you have a superior method of eliminating dealt cards from a mult-dimensional array in VBScript :)).

-- Matthew

Top
Fri, 05/21/2004 - 23:59
#8
DarkDream
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

FastLearner,

Thanks for the input. It is good to hear that someone else is using a simulation technique to enhance their game design.

Also in a similar vein, if anyone knows Java and is interested in code dealing with rolling dice (I have a die class) and the type of stuff I'm doing (moving chariots on a board and stuff), I'm more than welcome to share the code (I'm no way saying that its great or their is not already something similar out there). There is no graphic component to it at all, and it is very rudimentary.

--DarkDream

Top
Sat, 05/22/2004 - 07:06
#9
Anonymous
Computer Assisted Play Testing

FastLearner
You could speed up you algorithm by moving "cards" in the array up one place and then reducing the array size by 1.

eg (imagine the * are cards and the o are spaces)
initial array:
**********

select card
****o*****

move cards
*****o****
******o***
*******o**
********o*
*********0

then select from the first 9. repeat with each card selected (or every X cards selected, etc).

Hope that helps.

Top
Sat, 05/22/2004 - 14:49
#10
FastLearner
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

That's a good idea, and one I've considered. I think resizing the array will be sufficiently time-consuming that it might not speed anything up, but it's worth a definite try. Thanks!

Top
Sat, 05/22/2004 - 14:57
#11
Fos
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

Pointers and linked lists could help (not sure if they're called that in VBScript...).

Move to node x, where x is a random number between 0 (starting node) and i (# of last node)
Record card info at node x.
Delete node x and link node x-1 to node x+1
Subtract 1 from i (# of last node)
Move to node x.... etc.

I'm not sure how much that'll help in total speed. It'll be slower to begin with (to traverse the list each time), but towards the end it'd be far faster than the current method. It also has the ability to be quite flexible, as each node could contain any information you wanted on the cards.

Top
Sun, 05/23/2004 - 23:14
#12
Brykovian
Brykovian's picture
Offline
Joined: 07/21/2008
Computer Assisted Play Testing

Another way to do it, FL, is to actually have your array simulate a deck -- shuffled and all.

1) Setup the array as a list of all cards in the deck
Example 9-card array: 1 2 3 4 5 6 7 8 9

2) Run through a large loop
2a) Pick random array element X, (example: 3)
2b) Pick random array element Y, where X <> Y (example: 7)
2c) Swap the values in elements X & Y
Example array after the swap: 1 2 7 4 5 6 3 8 9

3) "Deal" cards from the top of the array, using a pointer to keep track of where you are in the "deck" ... when you reach the end, "shuffle" again

-Bryk

Top
Sun, 05/23/2004 - 23:47
#13
Anonymous
Computer Assisted Play Testing

FastLearner,

Here's another (possibly) simpler way to do it. You've already got an array with your cards and an array indicating which cards have been seen. Rather than generate random numbers, hoping to get a number you haven't yet seen (which is what it sounds to me like you're doing), simply use a pointer to mark where you are, generate a random integer, and march through your array until you reach the Nth card that you haven't seen yet, where N is the random number you got. Of course, when you reach the end of your array, you'll have to wrap around and continue from 0, but that is a standard thing to do. This method has the advantage that you will always find the card you want in a fairly short time and you won't have to go back to the generator for another random number. Did that make sense?

I hope this helps.

Captain Sky

Top
Sun, 05/23/2004 - 23:52
#14
Fos
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

Hmm... would that still work if the array is innitialized in order? Perhaps I haven't fully understood, but it sounds like if you start from a random position and go sequentially from there, there will only be 52 hand combinations (in a regular card deck as an example) instead of the thousands and thousands of combinations from a more random draw.

Top
Mon, 05/24/2004 - 07:59
#15
Anonymous
Computer Assisted Play Testing

With my algorithm you could speed it up by only compacting the array when you get too many hits on prieviously selected array locations. Just keep track of how many have been selected and use that to adjust the size of the array.

Top
Mon, 05/24/2004 - 23:25
#16
Anonymous
Computer Assisted Play Testing

Fos wrote:
Hmm... would that still work if the array is innitialized in order? Perhaps I haven't fully understood, but it sounds like if you start from a random position and go sequentially from there, there will only be 52 hand combinations (in a regular card deck as an example) instead of the thousands and thousands of combinations from a more random draw.

Yes, it works with an initialized, in-order deck.

Suppose you're working with a 10 card deck, and you've already drawn (at random) the 1,3, and 7. So, you'd have your two arrays (with the X's indicating you've already seen the card):
1X 2 3X 4 5 6 7X 8 9 10
Say that you just picked the 7, so that's where your pointer points. To draw your next card, you call your random number generator and it says "6". You would move your pointer to the 8, 9, 10, (skip 1 because it was seen), 2, (skip 3 because it was seen), 4, then 5. You stop at 5 because that is the 6th "unseen" number you've passed. You would then update your array to be:
1X 2 3X 4 5X 6 7X 8 9 10
with your pointer now pointing to 5. If your next call to the random number generator returned an 8, you'd pass over 6, 8, 9, 10, 2, 4, 6, and end at 8. This would be your card drawn. If instead your random number generator gave you a 1, then your next number would have been 6.

This is the basic idea, anyway, and there are definitely ways to speed this up -- like picking a random number between 1 and the number of cards not yet seen. That way, you wouldn't do the extra wrapping around that I showed in my example above.

(By the way, I'm not claiming that this is the best way to do this kind of thing. I'm simply tossing out another way to solve the problem. Look at your problem before deciding which method is best for you.)

Does this make more sense? I hope it helps.

Captain Sky

Top
Tue, 05/25/2004 - 00:00
#17
Fos
Offline
Joined: 12/31/1969
Computer Assisted Play Testing

Oh, I got you now. All the array positions are in a circle and the random number is how many positions you move to get your next card. You just skip cards you've already drawn. This is sorta like hashing in reverse, if I remember correctly. (It's been a long time...)

Top
Syndicate content


forum | by Dr. Radut