BEN - Random Deathmatch Map Generator for Quake2

[console]

I'm not familiar with more modern versions of Q2.  I run 3.20 stock, so I don't know about newer download options.  I do know that the stock Q2 download is hideously slow (for reasons of preserving gameplay).

It's not so much preserving gameplay, as it uses a simplistic download protocol over UDP, which waits for the previous packet to be acknowledged before transmitting the next one... which is very slow by nature, and gets even slower the farther away from the server you are...

However, I'd recommend upgrading to r1q2 ( http://antiche.at/ ) which has significantly improved netcode over 3.20.

r1q2 will download maps much faster even over UDP, and on servers where HTTP downloads are enabled, you'll see maybe 20x speed downloads.

If we set up a random map generator server (I like the idea), I'd definitely hook it up to work with r1q2 HTTP downloads... So anyone using r1q2 would get the maps very quickly.


Regards,

[Yendor]

Sah-wheet!  Certainly the idea of having this little program running on the real internets is a great inspiration to make it "ready for prime-time"!  Ben has a ways to go just yet:)  Also, it is a windows32 MFC application, but I could at least give it command-line support.
Cheers!

[console]

Also, it is a windows32 MFC application, but I could at least give it command-line support.

Ah.  Yes, it would have to be pure command line and have no ties to Windows at all.  Our servers run Linux.

[peewee_RotA]

Ben Enhancments:

"This map is unique in a couple of ways.  It's made up mostly of a bunch of pipes which were assembled by a random map generator.  That's right!  I just built a bunch of pipe sections and had a random map generator randomly assemble them.  The other thing that's kinda funny about it is that it was made for an easter egg hunt.  That's what the baskets are for, in case you were wondering -- ya grab a bunch of eggs and bring 'em to the baskets for points. The title of the map is just to poke fun at the sewer theme, which actually looks pretty cool, but one might think "WFTF?" while running through it   You can play DM on this map as well as Easter Egg Hunt (whose gamex86.dll was never made public), or you can just look around... It's kinda cool considering it was random "
http://jitspoe.planetquake.gamespy.com/levels.html

It sounds like whatever random map generator was used for this would take prefabricated hallways and create the random map based on those prefabs. Any chance of this kind of enhancement?

[Yendor]

I remember that random map generator, I think it was from a company in Japan called Tsunami.  I remember it being quite rudimentary at that time, mainly working in 2D.  It did use prefabs, which was pretty cool, and the maps it made were nice looking, but rather simplistic.  I didn't really get too far into it though, since I was hell bent at the time to come up with something totally different.   The pre-fab-based generator used pre-fabs for hallways, junctions, and doors, then assembled them.   This is nifty, and is quite analogous to Ben1 (the first iteration of Ben, the source for which I have long since lost), which did the same thing but with simple hallways and no prefabs.

My primary goal with Ben2 was to facilitate the random creation of fully-undefined maps.  That is, not being restricted to pre-fabs of any kind.  That is not to say that Ben will never use pre-fabs - I love the idea, but Ben prefabs would be more rudimentary, like a wall prefab and a floor prefab, rather than a hallway prefab.  Further, implementation of prefabs would only be the first step towards being able to enable - you guessed it - a random pre-fab generator    My ultimate dream for the Ben project would be the complete random generation of maps from dead scratch - from the generation of wall-types (interior, exterior rock, etc.), floors, doors, lifts, and all the other goodies that give the best maps out there, their character.

But alas, I'm still in the rudiments stage with Ben, which is to create a playable map that is entertaining and challenging to navigate, which always rides a fine line against being impossible to navigate.  This can be considered a map-construct, or "blank" onto which prefabs would be applied.  The very first example of such a thing are the railings that appear around the elevated walkways in current Ben maps.  These are generated by the program, but could just as easily be laid out using a prefab railing section.   In short, given that we can create a playable space, in order to make it a playable map, one needs to assure that all areas of that space are accessible, to which purpose Ben currently uses lifts and stairs.  Then items must be placed in a semi-intelligent manner.  This is where we really turn a corner from a random generator to an AI-based "decorator" that makes sure said items are placed so that important things (quads, mega-healths, etc.) are not just sitting out in the open.  Obvious to anyone who has tried the current version of Ben is the fact that the item placement is far from intelligent enough!  This type of "intelligence" is similarly applied to the higher-order operations of texture and pre-fab placement and utilization.   For instance, things like water and lava should generally appear in the lower areas of a map, and sky should be visible at the highest levels. 

So the journey continues... for now, I am very close to having Ben capable of generating really good playable maps that, while fun to play, look very bland.  This is fine by me for now - the order of the day being the creation of a good space and a solid generator engine that is capable is generating a wide variety of map styles using a single base algorithm.  This has always been the goal of the Ben project, and I'm generally happy with what it's become.

So, prefab functionality will likely be a reality in the future, but it will be temporary, as the goal is complete random generation, even of the pre-fabs.

[Yendor]

now this is cool

it will never beat a real person making a map, but its still interesting

I don't know..

How much of the source code do you have, and would you be interested in a project called Quiablo?

 

\

BTW, what's a Quiablo - a FPS version of Diablo?  Interesting... more than I'd be able to bite off though!

[peewee_RotA]

BTW, what's a Quiablo - a FPS version of Diablo?  Interesting... more than I'd be able to bite off though!

I've done similar mods several times before that have never reached completion. So based on that I can pump out the gameplay code for this in probably a matter of days. The monster design and models would take a little longer but that's not a problem at all either.

What really needs to exist is a backend that would function like so.
Single player Upon loading the game the first time, 15 map files generate at random each representing the area's in diablo1. The town is a static map that the player can explore until map file 1 is generated and then compiled. This would then trigger the game to allow access to level 1. Each level would be a new floor to that map accessed through stairs only accessible once the next map is compiled. Using the stairs would load the next level, or possibly a loading screen that can wait until the next map is finished. Levels will be very simple and use only basic prefabs to reduce compile time. Single player Levels would be saved in the format of playername_level1.bsp. When a player character is deleted, it would delete his map files as well as to avoid recreation. Due to the ammount of monsters in each level, area portals would probably be a neccessity in the map maker.

Multiplayer would work in one of two ways. Local host COOP in which all players follow a leader player and exiting spawns all players to the next map which follows the single player way of creating the maps. The second mode is MMORPG mode in which a master dedicated server has 5 consecutive ports set up. Levels would be generated slightly different. Each map file contains all 4 of the needed levels and would randombly generate on each server upon server start, or at a scheduled time that the server brings itself down for maintenance. 1 port for town, 1 port for church, 1 port for catecombs, and so-on and so forth. Everytime a player enters a new level set, they are connected to the new server where they can download the map. These maps would be named by date and time followed by level, I.E. 20080709_0300_1.bsp. Upon existing a server, a player will also need a more intuitive tool to delete map files. Possibly an optional modified client that has that as a menu option inside the multiplayer menu. In either case, the player save files would be stored on that specific server.

There's a lot of backend stuff, and also the possible need for client changes. In fact ben doesn't need a whole lot of changes. Only the ability to spawn a new set of monsters, texture themes, prefabs, and possibly area portals. Most changes would need to be made on a server side client or a client side client basis.

[Yendor]

Ahh, that's along the lines of what I thought.   Currently, however, my focus remains on getting the core engine really working nicely.   I've got many irons in the fire at the moment, from motorized camera tripods, to toy widgets, motor controllers, home-made long-bows, and a few others, so my focus in the Ben project is to get it making good emough maps to warrant it's deployment at the core of a Random Maps Server here on TastySpleen, admins permitting. 

But at the end of it all, it would certainly be cool to release an open-ended version of Ben that could be scripted to make maps for other games/engines, but such a thing is realistically about a year off.  The server-ready Quake2 version I would like to have done by the Fall of this year, after which I may just hand out the Source Code and let people have at it in an open-source frenzy!

[peewee_RotA]

More Ideas for normal random deathmatch maps:

Have the program designate a "center room" This room is always cylindrical, contains one of the most powerful weapons, and is seveal stories with witch most roads lead to upper walkways in these higher stories.

You could add another user variable to designate how many "centers" a room has which would reduce the size of all the rooms equally. It would result in maps similar to tokays towers and lost hallways.

I'm also wondering if it's possible to add "water level" and "water content" that way any floors below a certain hieght have water in them. Lets say 1/2 of a floor is the water level, so the entire lowest floor has 1/2 of the rooms filled with water.

If water content is changed to slime or lava, then the randomization for any room that leads to lava is changed to create traps instead of pathways with noitems on the lowest floors where the lava or slime reaches.

I think they sound like ideas that can be logic oriented enough to include in a random generator.

[Yendor]

That's an interesting notion about having a central room.  Although it's not always cylindrical (Ben works in a 3d Cartesian grid), the program does sort of implement this type of thing, by use of the "Branches" setting.  The number of "Total Moves" is divided into "Branches" number of branches.  At the end of each branch, the cursor is simply reset to the position at which the map generation started.   If there are lots of branches for the given number of moves (say Branches/Moves  > .25), you will definitely get a map that has a prominent central arena.   However, there is no control over the shape of said arena, as the definition of any shape requirements would eat away at the true random nature of map generation.   It would be cool to make the first move after a branch reset always vertical (up/down) however, which would add a cool aspect to things.  I also plan to give the program more vertical space to work in (it's at 10 cells maximum now, and should be at least 20).

I'm not sure exactly what your concept of "room centers" is, but I'm interested in your idea, as it sounds like it's different than what I'm doing now... Room "centers" are actually determined in the current version, and essentially end up being the cell where the best item is placed.  This part of the engine is indeed next up on my list to improve, and it does need improvement!   I will be separating the area "obscurity" determination from the actual map generation (the two are co-mingled in a way that seemed cool at the time but has proven to be lame), changing it so that the score for how hard it is to get to any given area is determined after the entire map layout is generated.  This is also co-mingled with where lifts and stairs are located, which also needs much improvement (we have far too many lifts currently).  This entire subsystem will soon be re-written, giving the maps a much higher degree of mystery ("I can see it, but how do I get there?") while eliminating unreachable areas (which only occasionally come up now), and vastly improving weapons and item placements.

As far as water goes, I remember back 9 years ago when I coded this beast, not being able to figure out now water/lava works.   But I took another look at some MAP files (generated from Qoole), and it sure seems simple.  Was I really that lame back then?  I dunno, but I'm going to take another look.  I can easily detect any areas that would "hold water" (floor surrounded on all sides by walls), and fill them accordingly.  And surely, there are a couple items that would be OK to place under lava (invul, megahealth, BFG), as long as the lava damage is balanced accordingly.

[peewee_RotA]

makes me think that there also has to be an intelligent way to place enviro suits at the beginning of a dead end pathway that's 80% or more covered with slime. That path could then be allowed to have an item at the end.

Same with stairs. Maybe a path that decides to go upwards, tests first to see if there are 2 or 3 moves available in the north, south, west, or east direction first to add stiars. If any of these paths segments are already rooms then make an ele instead.

As for "centers" think of The Edge. The Outside, the center arena, and the mega room are all "Centers". The real definition would be this. Centers are rooms that paths lead to. In any map you can describe every single room as one of the following 3  things. A center where most combat takes place, a pathway that leads to a center, or a pathway containing an item that a player will walkthrough normally but generally will not fight in.

[Lardarse]

If you need help with a Linux port, then I may be able to help you. I would probably start by distilling the interface down to a command line (which is better for being called by another program).

Also, are you interested in going down the open-source route, so that others have the chance to improve your code?

[Yendor]

If you need help with a Linux port, then I may be able to help you. I would probably start by distilling the interface down to a command line (which is better for being called by another program).

Also, are you interested in going down the open-source route, so that others have the chance to improve your code?

Definitely that is in the plan, in the next couple months, to first clean up the code a bit and re-vamp the item placement system, maybe add water/lava capability, then release the code...

[Yendor]

makes me think that there also has to be an intelligent way to place enviro suits at the beginning of a dead end pathway that's 80% or more covered with slime. That path could then be allowed to have an item at the end.

Same with stairs. Maybe a path that decides to go upwards, tests first to see if there are 2 or 3 moves available in the north, south, west, or east direction first to add stiars. If any of these paths segments are already rooms then make an ele instead.

As for "centers" think of The Edge. The Outside, the center arena, and the mega room are all "Centers". The real definition would be this. Centers are rooms that paths lead to. In any map you can describe every single room as one of the following 3  things. A center where most combat takes place, a pathway that leads to a center, or a pathway containing an item that a player will walkthrough normally but generally will not fight in.

The interesting thing here is that, while I set out to make a completely random map generator, it quickly became obvious that there are many aspects that are best NOT left to complete random chance.   Given the nature of the map terrain generator, there is an immediate need to place lifts and stairs in appropriate locations to make the entire map accessible.  Item placements are another, as will be water/lava placement.  These things are all non-random, semi-intelligent algorithms, yet must have some component of randomness in them in order to keep things from being predictable (oh yeah, if I go up as high in the map as possible, I'll certainly find the BFG!)...

Your concept of "centers" is a very cool one.  As it stands, the program establishes one main "center" by virtue of the Branches setting - resetting the cursor location every n number of moves... and this is all well and good.  The distillation of your idea of "room centers" becomes and emphasis on plural "centers".   I think you've hit on the primary weakness in the map generation algorithm!  Having more than one "center", or what I'd call an "arena",  is a fantastic idea.  Thinking a bit, it seems that the way to implement "arena seed" areas in the working space prior to the  actual process of "carving" the map.  These Arena Seed regions would have one cell in particular that would be the center, and a region around it, most likely vertically aligned (ie. tall and skinny).  Within this region, you could set certain parameters  and conditions for moves that take place there. 

For instance, set a "rule" that after the first move that lands in the region, the next move will always be vertical.   This would result in a map similar to Tokay's Towers.   A rule where move length is limited to 1 or two cells, would result in lots of twisty raised walkways and perhaps balconies.   Or forbid moves more than one cell horizontally into a region, and you'll assure that the resulting arena will be free and clear, a large open space. 

Damn - a good idea indeed - and the reason I'm here  -  thanks!!

[peewee_RotA]

Having more than one "center", or what I'd call an "arena"

Actually I got the idea from Poltergeist:
Tangina Barrons: "This house has many hearts"