Rubber band and pegs game

I have to make a flash game like this: There is a board with holes in it (more than 1000). Initially, there are 3 pegs placed on the board and a rubber band around them. We have 3 possible operations: 1. Add peg - adds a peg on the board 2. Remove peg - removes a peg ( if there are more than 3 pegs) - the rubber band must take the shape of the remaining pegs. 3. Move peg - rubber band must be updated with current positions of the pegs.

How would you solve the problem of finding the rubber band's shape optimally?

I have 2 ideeas, but I have to work on them a little bit. The main ideea is that we have to change the rubber band's shape only at "Move" operation, and we use the same number of pegs, only one is changing position:

开发者_StackOverflow中文版

1. A derivation from convex hull algorithm. We have to know wich pegs are inside the rubber band and wich are outside. It might get a little complicated.

2. We work with only 3 pegs: 2 anchors and 1 middle. The 2 anchors form a boundary line for the interaction of the 1 middle peg. On the active side of the line the rubber band functions as 2 segments between the 2 anchor pegs and the middle peg. On the inactive side the 1 middle peg is free to move while the rubber band functions as a straight line between the 2 anchor pegs. The caveat to the above is that there are cases in which movement of the 1 middle peg in the active side of the boundary line can can cause one of the 2 segments to contact a 4th peg. The program must detect this occurrence and update the new anchor pegs accordingly. These are just suggestions from some limited experience with this concept. The developer should determine the best approach based on his experience and judgement.

Do you have any other ideeas, or suggestions?

"The developer should determine the best approach based on his experience and judgement." — did you copy and paste this from the spec you were given? :)

You ask for an "optimal" solution but if I were you I'd aim for a "correct, and fast enough" solution. You've got a contract to fulfil, you can leave the asymptotics to the academics.

Anyway, your plan to update the band only when the player moves a peg looks like a good one. We are going to need to remember all the pegs that are touching the rubber band, and for each peg we have to remember which side of the rubber band it's on (in order to draw the band correctly).

Now, suppose the player moves peg A from a to a'.

As a general principle, it's worth bearing in mind that even if your time segments are short, and the distance from a to a' is small, nonetheless there might be multiple things that happen. So you're going to have to consider all the events that might happen in that time segment, pick the earliest such event, update your data structures accordingly, and then continue with the remainder of the time segment.

So what kind of events are there?

• Peg A "picks up" the band. (It does so if peg A was not already on the band, and the line a–a' crosses one of the lines between pegs on the band.)
• Peg A "puts down" the band. (It does so if peg A was on the band, with neighbours B and C, and the line a–a' crosses the line B–C.)
• Peg A gains a neighbour on the band. (This happens when peg A is on the band, B is a neighbour of A and the triangle a–a'–B contains another peg C.)
• Peg A loses a neighbour on the band. (This happens when peg A is on the band, the neighbouring pegs on the band go A–B–C, and peg B is in the triangle a–a'–C.)

So you should determine all such events; work out the time that each event would happen; sort the events into order by time; handle the earliest event (only); repeat for the remainder of the time segment.

(What to do if two events happen simultaneously? I'll leave that up to your experience and judgement.)

Edited to add: a complication is that a peg may appear on more than one segment of the rubber band (for example, the band may go A-B–A-C-A). But I think the above sketch of an algorithm still works.

A further wrinkle is that even with a small number of pegs, you can make arbitrarily twisty configurations of the band. For example, suppose the band is stretched between pegs B and C. Now take peg A and move it in a figure-of-8 around pegs B and C (clockwise around B, anti-clockwise around C, let's say). Each time round the loop, peg A picks up another couple of pieces of the band. You can't afford to let the complexity of the configuration grow without bound, so need some way of stopping things getting out of hand. I suggest imposing a maximum limit on the length of the band, so that any attempt to stretch it too far causes it to snap (of course you'd have warning signs before this happens, e.g. band getting thinner, changing colour, ominous creaky sounds).