In a golf park they have got a golf ball collection machine to collect the golf balls every day when the day is over. But the managers of the park prefer to use the least possible fuel (or energy) for the machine to this work
For some unknown reasons they also have got access to current aerial photos of their golf fields, - photos which can be digitized.
This meets the conditions for optimization.
How can we make the days golf ball collection the fastest way?
In this abstract context we are bound by some rules.
-We must move in a straight lines between the golf balls on the canvas
-All golf balls must be picked up.
-We should end at the golf ball we started up with.(especially this rule is crucial for the measurement paradigm and the way we calculate the score outcome).
Various real-world golf course environment characteristics are omitted: lakes, gravel holes, hills, forests, etc. (but depending on the level of ambition and not necessarily easy, so might some of such elements be gradually built into the game and come to play some role)..
And does this optimization problem, incidentally, just not seem familiar? - indeed yes, it is all about the 'travelling salesman problem' that so many mathematicians has been dealing with for decades.
Here we keep it simple.
Just a 2D canvas to do the golf field. And kinetics rects and circles and a png img to represent the the golf balls.
Our code is JavaScript code with use of kineticjs plugin.
It guarantees that all the classic mouse events (mousedown. mousemove and mouseup) are all met if we just once for all make our code aware of these events by adding them to our container in the code. (Best guess is that also touch-enabled devices equipped with modern browsers should have their respective simple touch mousedown/-up events automatically handled equally as well with no need for code change.(..).Normally we would pro grammatically detect whether or not a particular browser supports touch interactions, and successively in the preceding load procedure do the right code allocation ). )
The spread of the golf balls are random. We ensure that none of the circles overlap to such an extent that it bothers the distance calculation and the player to navigate the mouse.
With the the new game option button, we can also determine the number of golf balls.
All circles ( identical to the golf balls) are registered in an array as kinetic class objects. The same applies to the rectangles that carries the image of the golf ball png.
In a for-to-loop these elements are placed on the canvas (added to layer).
Each pair of circle+rect(in topmost position) is precisely stacked to x-y (nth) coords.
On each mousedown click event we do register the mouse x-y coords and in an collision detection routine we do ensure that we points to something inside the circle AND if yes: we do register the center x-y coords of that same circle. The same we do with the choosen neighbor circle (golf ball) we want to jump to. On mouse up event we draw the straight line (Kinetic.Line) in between. And so on the golf ball collection will proceed.
We also calculate the length of each line segment so to keep track of distance gone. Distance is accumulated and monitored in the current measurement text box.
As we we always keep a mirror of the circle- and rect arrays we can redraw the exact same image of drawn golf balls. Hereby the player has got the opportunity always to do a better score.
But there is an easier way for the players to get the golf balls collected:
In each gameset of thrown golf balls we 'hide' a rectangle whose 4 corners are specifically formed by 4 of the golf balls. And if the player can spot this rectangle he can point to the intersection of the diagonals of the rectangle and short-circuit the tiresome collection and trigger a bonus of 500 ()..
The more golf balls that are in play the more difficult it is to spot the rectangle.
The rectangle are random located. Its width and height are also random given.
It would be obvious to operate with other geometric shapes so as to make this feature a little more unpredictable.
Also time might be incorporated to expose the player for choices that bring into consideration the time cost dimension with some fair kind of resulting plus/minus effect on score status.
© Arrangement, January 2015, netscale.dk