Jump to content
Posted 26 April 2012 - 07:39 AM
Posted 26 April 2012 - 09:29 AM
Posted 26 April 2012 - 12:35 PM
Posted 26 April 2012 - 01:43 PM
Posted 26 April 2012 - 09:37 PM
Posted 27 April 2012 - 03:10 AM
First post. Hello everyone.
Random generation of course comes with some problems, as has already been pointed out [players getting stuck, 'blandness']. Assembling levels out of coarse grain chunks is an attractive middle-ground, but in order to not end up with introducing a number of problems [two blocks with pits on opposite sides being selected to construct a pit that is too wide to jump across, for example], you really need an extra something. A likely easy solution to solving this would be to have a compute controlled player test-navigate each area, and make selections based on areas the bot is capable of navigating. At each 'decision point', which would be a point where the bot is not falling or dead or whatever, you generate a bunch of scout bots that jump off or run off in random directions. You place features in places where you can assure at least some subset of the bots survive to some next 'decision point'.
If you have this bot in place, and thus solve the getting-stuck problem [since your bot wouldn't select options that result in the bot getting stuck, as it would be unable to reach the next 'decision point'], then you could probably even relax the coarse grain room thing, and let your bot navigation test fill in some gaps, thus affording you additional flexability, and the ability to use finer grain [thus reducing the level of redundancy]. A player would likely recognize whole rooms, but if your generator can make placement decisions on the level of ledges and blocks, rather than whole rooms, redundancy won't be perceptable. You could even guide it by demanding that the general flow of the level proceed in a certain direction. Or, as another middle ground, add whole rooms and let a random generator add more stuff to the room [you have a template, but programatically add enemies or a few extra bricks or things] to break up the monotony.
Posted 27 April 2012 - 04:37 AM
The only guarantee you really need is to assert your pathfinder can stay ahead of the player. You don't even need to generate the entire level is one go. If you know your player takes X seconds to make it to the current end of the world, that means you have X seconds to build more world for it to be as if the world was complete from the beginning, from the players point of view. Realistically, you could even just not build the parts of the map that are off the path the player chose, and leave parts of your game world forever uninstantiated.
"Loading Time" might be a problem. since i would need to run pathfinder multiple times for huge paths. However with multithreading and caching it may even take just a second.
I cant really be sure about it till i implement it.