Closed macluo closed 9 years ago
Is this issue to make such an engine, or just to look at them? Because I think there's another milestone in which we actually have them working.
Honestly I have no idea. It is up to you guys or whoever likes to work on it.
Changed to milestone v0.5. At least we now should discuss how to get this started.
I think one thing we talked about briefly was having multiple algorithms for this, letting the user choose which one, and factoring it into our analytics. Is this something we want to do?
I don't see why not, is there any reason we shouldn't have it do that? As long as all the generators obey an interface (probably put in seed, get out maze JSON), we can add as many as we like.
Forgot to mention, we can just make one for now and have it obey that interface, and then add more later if we feel like it (and mention that you can add more in the presentation).
I agree with Will. We should just make one for now and then add another if time permits.
On Sun, Mar 22, 2015 at 5:40 PM, Will Morrow notifications@github.com wrote:
Forgot to mention, we can just make one for now and have it obey that interface, and then add more later if we feel like it (and mention that you can add more in the presentation).
— Reply to this email directly or view it on GitHub https://github.com/CSC510-2015-Axitron/maze/issues/51#issuecomment-84709365 .
Since this requires some mazedb work, I'll claim this and do one or two maze generator algorithms and define an interface.
Going to put down the interface here (pending changes) as two new paths, GET /maze/gen/algorithms which returns
{
['list','of','algorithm','names']
}
POST /maze/gen/:algorithm with data sent
{
width:[10-40],
height:[10-40],
seed:(optional number)
}
and returns
{
maze:(normal maze data),
algorithm:(same as requested),
seed:(the used seed, either player specified or randomly generated if not specified)
}
As far as tracking user stats, I think I'll tackle that later, but we'll need to either change the current play relationship to add in algorithm and seed or put in a new relationship that links players to algorithms and seeds.
Going to amend that to be both GETs, in the form /maze/gen/:algorithm/:width/:height or /maze/gen/:algorithm/:width/:height/:seed
For anyone who might want to develop their own, here's a website with English descriptions of a whole mess of algorithms: http://www.astrolog.org/labyrnth/algrithm.htm
Finished in f156ab47780b5fda79bf576a109cebee20d0a16d and deployed to heroku (check out http://axemaze-db.herokuapp.com/maze/gen/recursivebacktracking/10/10 ). Tested the mazes through local loading, they work fine and look like mazes. It sometimes does some funky things like make an L joint with the exit being the corner of the L, but that doesn't matter too much. I wrote up the interface for the maze generators in the server.js file, so any of you can add some if you want.
I see. This is a very interesting way to generate PG mazes on the fly. Both height and width have to be between 10 and 40, so on the game menu are you thinking dropdown list or text fields?
We could use a slider for it, if we're going to enter deeper into jQuery UI's territory (which seems reasonable to do): http://jqueryui.com/slider/
I would think instead that the size of the maze should also be chosen procedurally -- perhaps biased to lower values by lower "seeds" (level numbers).
For example, you could use the function 1 - (1 / (1 + x)) as a base for this effect, so that the size never exceeds a certain amount.
Take that function, multiply it by 40, add or multiply a bit of randomness, then threshold it at min 3 and max 40.
Then do it twice, one for width and one for height.
EDIT: and let x=SEED/constant, where constant is some constant bigger enough than 1.
I can certainly do that. My javascript friend is actually mad that I used GET for the two mazegen calls instead of POST so I might change that too. So the modified call will be POST /maze/gen with data {"algorithm":(alg),"seed":(123)}, the seed parameter optional.
Done in 7b732c1ccea1fab71d1441200d5c1dc34d52b8b5 and pushed to heroku, the closer the seed is to a multiple of 5,000,000, the larger it will be, from a minimum of 10 to a maximum of 40.
Going to count this as done, if there are any problems make a new issue for it.
Possible recursive and dynamic programming with heavy math stuff. May utilize methods from designer.js