Dream Makers

A shady trick

Thu, 15 May 2008 08:37:16 GMT

This isn't strictly about BYOND or development, but it's something heavy Internet users (like BYOND developers) might want to know about. The article also mentions the wonderful phenomenon of rickrolling. In fact, maybe the article IS a rickroll. You won't know unless you click.

http://blog.wired.com/27bstroke6/2008/04/ isps-error-page.html

upContainers - a stack of primitives

Fri, 09 May 2008 19:27:52 GMT

upContainers is a library that defines and implements primitive data structures used in everyday programming. Currently, the library defines stacks (/Stack), queues (/Queue), and sets (/Sets), and is easily implementable in your project. Documentation is located in the library.

upContainers

Link Roundup

Wed, 07 May 2008 07:28:40 GMT

Howdy chumps! I've been pretty busy this last week, doing some important game design studies. I apologize for the temporary "content drought." Here's some stuff to keep you occupied for several minutes.

BYOND stuff

Farewell to digitalBYOND: http://www.byond.com/members/DigitalBYOND?command=view_post &post=42598

Funny ASCII art on Dungeon Crawlers: http://www.byond.com/members/ DungeonCrawlers?command=view_post&post=42577

Other stuff

Dark secrets of the Chinese MMORPG (via http://www.penny-arcade.com/2008/5/5/): http://www.danwei.org/electronic_games/ gambling_your_life_away_in_zt.php

MADD vs. Rockstar: http://www.escapistmagazine.com/news/view/ 83597-MADD-Decries-GTA-IV-Drinking-and-Driving

...As the link points out, MADD may be barking up the wrong tree here. The game actually does a good job, IMHO, of making real-life drunk driving unappealing, by several methods: it makes walking, and driving, difficult; falling down on the sidewalk (which is inevitable) causes damage; your character vocally questions his own judgment if he gets into a vehicle while drunk; police give chase when they spot drunk drivers; and the visual effects may cause real-life seasickness.

But my favorite educational feature in GTA IV is that it makes the player wear a nice outfit to attend weddings and funerals. Can GTA IV heal the societal damage caused by two generations of slobs? Only time will tell!

Voronoi map generator

Mon, 28 Apr 2008 18:50:44 GMT

This month I bring you... another method of creating random maps! This one could be especially useful if you're thinking about entering the BYOBG contest (http://www.byond.com/members/DreamMakers?command=view_post &post=41489).

Let's skip the small talk. This demo is based on Voronoi diagrams. If you want to know what those are, take a look here:

http://en.wikipedia.org/wiki/Voronoi_diagram

And here's the demo:

http://www.byond.com/members/DreamMakers/files/ gughunter.2008%2D0428/voronoi_src.zip

As the article demonstrates, all you need to build a Voronoi diagram is a bunch of seed points scattered around a plane. Once you have that, you just look at every other non-seed point on the plane and figure out which seed it's closest to. Of course this could take a while, since a plane contains an infinite number of points. But a BYOND map is made of turfs, not points, so the job is a lot easier.

Or it would be -- except I didn't do it that way! Instead, I allowed the seed points to expand at the same rate. This is a pretty unscientific method, since the regions only grow one at a time, so the regions that grow first get any turfs that are equidistant from two or more seeds. Fortunately, this demo isn't about being scientific, but only about creating a viable random map.

The demo offers two basic methods of placing seed points. The first is a grid, in which the seeds are spaced in an orderly manner. This would create pretty dull maps, though, if that was all there was to it; you'd always end up with a uniform bunch of rectangles. So the grid method adds a little gimmick: you get to choose the probability that any given grid point won't get a seed. If you choose a reasonable number, you end up with something that looks kind of like a real city -- the grid is interrupted by irregular regions here and there.

The second method is to place the seeds entirely randomly. This creates much more organic-feeling maps, akin to the game board in Risk. The demo also creates a nice little body of water for you, by picking a base region and wandering around the adjoining regions, filling them with water as it goes.

You may be able to think of other applications. Here are some to get you started:

* Unknown Person, who got a sneak preview, noted "Personally, I don't know what I'd do with it, but it looks like something I'd use if I wanted to make a random anthill." I thought that was a pretty nifty remark, since one of the very first computer games I ever wrote, back in the early 1980's, was called "Anthill" and a little Voronoia might have done it good.

* You could try the old party trick known as "reversing figure and ground." Instead of seeing the borders as streets, what if they're walls? You could create a vast cavern network by digging out some doorways.

* You could give the regions more interesting shapes by randomly joining some of them together before you draw the borders.

* As the Wikipedia entry notes, a Voronoi diagram was famously used to analyze an outbreak of cholera in London (the book "The Ghost Map" tells this story, and is a good quick read). Perhaps you could make an interesting game by keeping the Voronoi diagram hidden, and requiring players to find clues to track down the seed points.

Suddenly, without warning, the article ended!

Mathtacular!

Sat, 26 Apr 2008 16:33:36 GMT

Here are two fun sites I haven't linked to before. The first is general math information. Wait! Don't go! It's pretty neat. Do a little browsing and see:

http://mathworld.wolfram.com/

The second is a music generator. It lets you download any generated music you especially like. The site's Terms of Use seem to preclude using the music in BYOND games, but an aspiring composer could still have fun playing around here and getting inspiration.

http://tones.wolfram.com/

It's a plot!

Thu, 24 Apr 2008 14:46:06 GMT

A plot to make you think about plots!

This will be of most interest to creators of RPGs and adventures. Puzzle games, perhaps not so much -- although there's no one stopping you from wrapping a series of puzzles in a plot structure (Puzzle Quest is supposed to be pretty decent). Each of the links below is a pretty short read. See if you get any ideas.

Top 10 Worst Plot Devices Ever
http://inkandthunder.blogspot.com/2007/03/ top-10-worst-plot-devices-ever.html

...And Then WHAT Happened? The Silliest Scifi Plot Twists
http://io9.com/376892/ and-then-what-happened-the-silliest-scifi-plot-twists

An Introduction to Plot, Plot Structure, and the M.I.C.E. Quotient
http://triton.towson.edu/~schmitt/311/pages/tsld001.htm

What a Plot Is
http://www.ifvchicago.com/process/ wr_structure_whataplotis.shtml

Improve your video game literacy

Mon, 21 Apr 2008 18:02:42 GMT

If you are at all interested in video games and game design (and if you're not, how did you get here?) you probably have a good-sized mental list of often-praised games you've never played but would like to. Maybe some of them are games you actually wouldn't want to play all the way through, but you'd like to get a taste of them, at least. Well, here's a good start for you:

http://www.letsplayarchive.com/

Warning: the "content rating" seems to vary widely on this site. You may encounter some rather rude language.

How To Cheat Players

Sat, 12 Apr 2008 20:20:08 GMT

Most people think that cheating is bad. But when the cheating is benefits you, and you think there�s no chance of being caught, is it such a bad thing? The question is, how can we make sure that, in the long run, we always win?

Let�s start with a simple example, flipping a coin. When a fair coin is tossed, it can be assumed that the probability of getting heads or tails is equal (in reality, it isn�t, because it depends on the way you flip it, the gravitational field strength, how far it falls before landing etc). A way of simulating this in DM would be to just say

var/flip = rand(0,1) //you can treat 1 as heads and 0 as tails

But what if we want to cheat our player? What if we want heads to be more likely than tails? Let me introduce my good friend, the prob() function. Let�s start by making the probability of getting heads 60% and, therefore, the probability of getting tails 40%. Well, this is just a simple matter of understanding the syntax and requires hardly any explanation:

var/flip = pick (
        prob(60)
            1,
        prob(40)	
            0,
    )

Not exactly riveting stuff, is it? Let�s move on to more complicated situations. Suppose we�re playing a board game where we roll a 6-sided cubical die to decide how many spaces we can move. So if I roll a 3, I can move 3 spaces. Let�s say there�s computer player (that�s us) and one other player (unaware what he�s got himself into). As programmers, we want our computer player to win because we�re evil. But how do we rig our die so that it�s more likely we�ll win? Well, the obvious solution would be

var/diceroll = 6

This would ensure we always roll a 6 as there�s no pick()ing involved! But this is too obvious and players would see through it. So how should we assign our probabilities so it�s not too obvious but we still give ourselves a nice advantage? The answer is to adjust the expectation of our random variable (the random variable being the number shown when the die is rolled). Readers who are already familiar with expectations need not read this, but for those who aren�t, it will only take a few minutes to familiarise yourself with it. The expectation of a random variable means what, on average, we expect it to return. If we were to roll a fair die over and over again and then took an average of all our results, we would expect this to be 3.5. Here�s a quick way for you to check that:

mob/verb/Stats()
    var/diceroll
    var/total
    for(var/i=1, i<= 1000000, i++)
        diceroll = rand(1,6)
        total += diceroll
    usr << "[total/1000000]"

That �rolls� a die 1,000,000 times and then works out the average of each roll. It should come out to be roughly 3.5. This is known as the expectation and written as E(X) where X = the number rolled by a fair die. The way of working out the expectation of discrete random variables (that is, random variables which can only take a certain value � for example, you can�t roll a 2.7 on a cubical die, can you?) is to write out what�s known as the probability density function (PDF). For a fair die, it would look like this:

For a fair coin, it would look like this

For the biased coin generated above, it would look this

An important thing to note about the PDF is that every outcome must be defined and, therefore, the probabilities have to add up to 1.

To work out the expectation, we just multiply the x value with its associated P(X=x) value. So for the die, it would be:

E(X) = 1 * 1/6 + 2 * 1/6 + 3 * 1/6 + 4 * 1/6 + 5 * 1/6 + 6 * 1/6 = 3.5 as demonstrated by the code above.

For this PDF

E(X) = 2*0.1 + 6*0.57 + 10 * 0.33 = 6.92

Let�s recall what we mean by this. If we had a random process which selected the number 2 with probability 0.1, the number 6 with probability 0.57 and the number 10 with probability 0.33, then over a large number of trials, on average, we�d expect to get 6.92. Don�t believe me? Try it:

mob/verb/Stats()
    var/randvariable
    var/total
    for(var/i=1, i<= 1000000, i++)
        randvariable = pick(
            prob(10)
                2,
            prob(57)
                6,
            prob(33)
                10,
            )
        total += randvariable
    usr << "[total/1000000]"

That should give you 6.92.

Right then, so back to our problem. We want the computer player to win the board game. If we were to roll a fair die, as demonstrated above, its expectation would be 3.5. In other words, we�d expect to move 3.5 places on our board on average. Let�s try to up its expectation to 4.5. Recall that

E(X) = 1*P(X=1) + 2*P(X=2) + 3*P(X=3) + 4*P(X=4) + 5*P(X=5) + 6*P(X=6).

We�ve chosen this to be 4.5. So we have

4.5 = 1*P(X=1) + 2*P(X=2) + 3*P(X=3) + 4*P(X=4) + 5*P(X=5) + 6*P(X=6).

4.5 = P(X=1) + 2P(X=2) + 3P(X=3) + 4P(X=4) + 5P(X=5) + 6P(X=6)

Now then, we need to decide on its PDF. We can essentially just choose whatever numbers we want, so long as the probabilities add up to 1. To make the player think we�re not cheating, we�ll make it somewhat likely that we can get a 1. This means we should roll a fair amount of 1s, but as our expectation is high, in the end, we will end up winning. We�ll also make the probability of getting a 6 not too high so it�s not obvious that it�s rigged. Let�s say P(X=1) = 0.1, P(X=2) = 0.05 and P(X=6) = 0.25. Now we have

4.5 = P(X=1) + 2P(X=2) + 3P(X=3) + 4P(X=4) + 5P(X=5) + 6P(X=6)
4.5 = 0.1 + 2*0.05 + 3P(X=3) + 4P(X=4) + 5P(X=5) + 6*0.25
4.5 = 0.1 + 0.1 + 3P(X=3) + 4P(X=4) + 5P(X=5) + 1.5
2.8 = 3P(X=3) + 4P(X=4) + 5P(X=5)

Remembering that the probabilities have to add up to 1, we note that P(X=3) + P(X=4) + P(X=5) must now equal 0.6. Next we have to make sure we actually cover all of the expectation. This will means making P(X=5) and P(X=4) quite high. Let�s try P(X=5) = 0.425 and P(X=4) = 0.15.

2.8 = 3P(X=3) + 4*0.15 + 5*0.425
2.8 = 3P(X=3) + 0.6 + 2.125
0.075 = 3P(X=3)
0.025= P(X=3)

And so we�re done. We can write the PDF as:

You can run a test on DM to check the expectation is working:

mob/verb/Stats()
    var/dieroll
    var/total
    for(var/i=1, i<= 1000000, i++)
        dieroll = pick(
            prob(10)
                1,
            prob(5)
                2,
            prob(2.5)
                3,
            prob(15)
                4,
            prob(42.5)
                5,
            prob(25)
                6,				
            )
        total += dieroll
    usr << "[total/1000000]"

This will make it more likely that our computer player will win than if he was using a fair die. The good thing about this is that we can adjust the expectation to whatever we like quite simply. 4.5 was just an example. We could even disadvantage someone by reducing the expectation to, say, 3.

Another method of giving the computer and advantage is to guess what the player will do. Let�s suppose we�re playing a game in which both the player and the computer player guess a number; either 1, 2 or 3. If the numbers differ by 2, the person who picked the largest number wins �2 from their opponent. If the numbers differ by 1, the person who picked the smallest number wins �1 from their opponent. If the numbers are equal, nothing happens. We want to try to maximise our winnings. Let�s predict that the player will pick his number randomly (in other words, we�ll assume it�s equally likely for the player to pick 1, 2 or 3). This means that the probability the players picks any number is 1/3. We now need to come up with a process to pick our number given this information. So, for example, we could just mimic the player and do this:

mob/proc/Guess()
    var/mynum = rand(1,3)

But how can we create a PDF that maximises our winnings? Let�s start by defining it:

We�re trying to work out values for a, b and c so that we maximise our winnings.

Let�s say the player had picked 1:

If we picked 1, we�d make �0.
If we picked 2, we�d make -�1
If we picked 3, we�d make �2

The probability of the computer picking 1 is a, picking 2 is b and picking 3 is c. So we can say that, if the player picks 1, the expectation is

E(winnings _when_player_picks_1) = 0a � 1b + 2c = 2c � b
Likewise, we find that
Let�s say the player had picked 2:

If we picked 1, we�d make �1.
If we picked 2, we�d make �0.
If we picked 3, we�d make -�1.

Then E(winnings _when_player_picks_2) = 1a + 0b � 2c = a � c

Let�s say the player had picked 3:

If we picked 1, we�d make �-2.
If we picked 2, we�d make �1.
If we picked 3, we�d make �0

Then E(winnings _when_player_picks_2) = -2a + 1b + 0c = b � 2a

We�re almost there now. We have to also take into account that there�s only a chance that the player will pick, say, 2. The probability of the player picking 2 is 1/3, so we multiply E(winnings _when_player_picks_2) by 1/3 to give E(winnings _when_player_picks_2)/3. Now we can work out our expected winnings:

E(winnings) = E(winnings_when_player_picks_1)/3 + E(winnings _when_player_picks_2)/3 + E(winnings _when_player_picks_3)/3

E(winnings) = (E(winnings_when_player_picks_1) + E(winnings _when_player_picks_2) + E(winnings _when_player_picks_3))/3

E(winnings) = (2c � b + a � c + b � 2a)/3
E(winnings) = (c � a)/3

And so we find that our expected winnings actually have nothing to do with the probability that we pick 2. To maximise the above expression, we can just have c = 1 and a = 0 (which in turn means b = 0 because a + b + c = 1 for a PDF). This results in the following PDF

After a large number of games, if we chose our probabilities like that, we�d expect to have won �0.33. It is left as a task to the reader to construct a program to test this out.

Contest: BYOBG!

Fri, 11 Apr 2008 21:44:29 GMT

Build Your Own Board Game!

The contest is to create a board game for at least two players.

It may be similar to existing board games, but its title, graphics, sound, and all other resources should be original content created for this game.

Tokens or cards (or stones, or similar components appropriate to board games) may be played upon the map or moved around it during the game. A player's inventory, tokens, cards, scores, and other information may be displayed in additional panes as appropriate.

The game should use some BYOND 4.0 layout controls rather than relying on the default BYOND layout behavior.

The gameplay should not depend on quick reflexes, though timed turns are permissible within reason.

You may choose any subject matter you like, but the content should be capable of earning a "Teen" or less severe rating from the ESRB (see http://www.esrb.org/ratings/ratings_guide.jsp).

A Help file is not necessary, but at any given point in play, the player should have no trouble understanding what is expected of him. For example, at the start of a player's turn, you might display a message like this: "You may now move any or all of your armies to an adjoining territory by clicking the army and then clicking the target territory. An army will turn gray when you have moved it. To undo any army's move, double-click it. When your are done, click the END TURN button."

For people who have played it before and are familiar with it, a typical session of the game should be playable in 20 minutes or less, though of course some sessions may go longer.

Prizes are $30, $20, and $10. To receive a prize you, or your designated representative, must be capable of receiving PayPal transactions. Fewer prizes, or none, may be awarded if the judges determine there are insufficient entries worthy of prizes.

Deadline is end-of-day Wednesday, May 14, 2008.

Source code need not be provided, but the winners must permit Dream Makers to make the game (at least in the version submitted) available for download to the public (or the private).

Further information, including where to submit entries, will be provided as the contest progresses. Submit any questions in the comments to this post.

[UPDATE 2008-0421: You can send entries to my email account, gtellgtell care of hotmail.com. Put "contest" somewhere in the subject line so I don't miss it! Also see the comments below for additional info.]

Taking Care of Business in a Flash

Wed, 09 Apr 2008 20:10:41 GMT

Tonight's bite-sized post is brought to you by an interesting Wikipedia article about flash fiction:

http://en.wikipedia.org/wiki/Flash_fiction

It has nothing to do with Adobe Flash... the "flash" is the amount of time it takes to read the fiction (though the psychological scars could last a lifetime).

It occurs to me that a person could make an interesting BYOND game by stringing together little flash-fiction vignettes. Each one might last 20 seconds or a minute (or more if you throw in some monsters to fight or puzzles to solve), and then the player moves to the next one.

The Wario Ware series for the Nintendo DS (http://www.metacritic.com/games/platforms/ds/ wariowaretouched) is said to be pretty addictive. Each Wario Ware game is, if I understand the reviews right, simply a long string of very short, but very varied, minigames. This kind of design could be great for the programmer suffering from writer's block; instead of trying to build a mountain, make a whole bunch of molehills!