You need to log in to create posts and topics.

Random Map Generator

Hi folks,
I wrote a computer program that can generate random portal 2 maps (cooperative).
This is its first attempt to create a highly complicated map:
http://steamcommunity.com/sharedfiles/f ... =140236196
The program also generates a solution, which I uploaded to
http://www.superiki.de/portal2/solution19Apr2013.html
I verified the solution step by step.
The design is very plain, because the program is still in its alpha stage.
Any suggestions and comments are highly appreciated.

Sweet! I'll have to give this a try - I've been always hoping somebody would come up with something like this considering puzzle design is a pain sometimes.

Image

did you use that PTI library that was uploaded here a few months ago?
this sounds pretty cool, I'm interested in how you went about doing this

ImageImageImage

Also, I made a map just for you! Sunset
Click Here to view my Workshop and play my puzzlemaker maps
BenVlodgi wrote:
did you use that PTI library that was uploaded here a few months ago?
this sounds pretty cool, I'm interested in how you went about doing this

The generator is written completely in Java without any additional libraries (I used the p2c file format descriptions that are available, in particular the one here at ThinkingWithPortals). All maps that it generates have the same voxel topology and they differ only in entity placement. This might change in later versions. By placing glass, laser walls, fizzlers, and buttons, and by deciding where portals can be placed, the genenator can construct complicated puzzles. At the moment, these are the only items that it uses, because their logic is fairly simple and was easy to implement.
The generator has a method to determine the "complexity" of a map and it tries to build maps with a high complexity. The generation time of this particular map was several hours.
My friend and I were unable to solve it within a reasonable time frame, so the generator seems to be able to construct pretty complicated maps.

Wow, this sounds really cool! I'll have to try it. Do you plan to post the source code to this ever?

Now, I wonder if anyone can make a program that takes a P2C and figures out the solution? :P

Falsi sumus crusto!
FelixGriffin wrote:
Wow, this sounds really cool! I'll have to try it. Do you plan to post the source code to this ever?

Now, I wonder if anyone can make a program that takes a P2C and figures out the solution? :P

Blindruns will no longer be "blind"

My YouTube Channel: https://www.youtube.com/user/Camben24
Aperture Science: We do our science asbestos we can!
Ultiman9711 wrote:
Sweet! I'll have to give this a try - I've been always hoping somebody would come up with something like this considering puzzle design is a pain sometimes.

I have not thought about that, but one could use the generated levels as a basis and then modify them to turn them into nice maps.

FelixGriffin wrote:
Wow, this sounds really cool! I'll have to try it. Do you plan to post the source code to this ever?

I think that I want to play around with it some more before cleaning the source code up and releasing it. I might add support for more different testing elements and a more complex map topology.

FelixGriffin wrote:
Now, I wonder if anyone can make a program that takes a P2C and figures out the solution? :P

I think that solving arbitrary p2c maps would be significantly more difficult than solving these very simple ones. But I would really like to see this done.

Thank you for visiting Thinking With Portals!

I suppose a program could come up with some sort of dependency map--the laser emitter requires the button, the button requires the cube, the cube requires the switch--but it probably couldn't do anything with portal placement. For example, I'm not sure how a program could figure out that you need the reversed tractor beam over the goo to save the cube.

Falsi sumus crusto!
FelixGriffin wrote:
I suppose a program could come up with some sort of dependency map--the laser emitter requires the button, the button requires the cube, the cube requires the switch--but it probably couldn't do anything with portal placement. For example, I'm not sure how a program could figure out that you need the reversed tractor beam over the goo to save the cube.

Using Dijkstra's algorithm in the state space, the program is already really good at figuring out where and when to place a portal, as you can see from the example map in this thread and its solution. It would be harder for the program to answer the following questions: How fast can a player run / bunny hop? How high can a player jump? How high can a player jump if a cube is available? What surfaces can a player see when using a faith plate? How far can players jump using orange/blue gel? Et cetera.
A program that solves p2c files would have to be able to answer such questions.

pfff this was what I feared most for when the PTI came out.

There is a huge difference between a map and a properly designed; thought out map.
The PTI made it a lot easier to make a simple map without much design philosophy or experience, and this is the next step: we make maps for you. I would hate to see the workshop being flooded with these kind of maps.

All in all it's a nice programming concept but the potential outcome scares me.