Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411430 Posts in 69363 Topics- by 58416 Members - Latest Member: JamesAGreen

April 20, 2024, 01:57:04 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityTownhallForum IssuesArchived subforums (read only)TutorialsBraving Procedural Generation
Pages: 1 ... 4 5 [6] 7 8 ... 23
Print
Author Topic: Braving Procedural Generation  (Read 213361 times)
dariusk
Level 0
***



View Profile WWW
« Reply #100 on: October 07, 2009, 03:54:41 PM »

Huh? Yo man, we're not focusing on anything yet, nor should we be. [...]
That's a good blog post, though Smiley I enjoyed reading it.

Gentleman Thanks for the response ChevyRay, you are totally my procedural generation hero and this thread and your articles are a big inspiration to my own projects!

I was kinda erring on the side of being provocative with that post. Having an intro to procedural generation thread is brilliant. This is my favorite thread on TIGSource... tied with Derek's GameMaker tutorials. But it would be nice to see someone post some stuff here about how to generate obstacles for relatively simple gameplay -- perhaps generation of ships and stuff in a basic shmup or a really simple platformer. The generated Super Mario World levels in the Mario AI challenge are awesome:

http://julian.togelius.com/mariocompetition2009


(great video)
http://www.mojang.com/notch/mario/ (original Infinite Mario Bros, java applet)

Logged

ChevyRay
Guest
« Reply #101 on: October 07, 2009, 04:50:26 PM »

I remember a couple weeks ago when somebody linked me up to those videos! They were quite excellent.

I totally agree with your statement, by the way. Actually, in all honesty I should experiment with smaller, more focused procedurally generated elements of games as well and try writing up a tutorial on PG as applied to games in more specific ways.

There are also unlimited more advanced ways to apply PG as well. For example, many PG games, like Spelunky, have generated levels within the game, but the game's pacing itself is ultimately based on a solid structure. The game gets harder and harder until you reach a final boss, and that structure is always the same. Longer games, though, require a more carefully balanced pace. The game has to peak at different parts, ease out once in awhile to give the player a break, and then pick up again. This could be procedurally structured as well, for example, having the difficulty constantly change based on how good the player is doing. Or, as an easier to apply example, you could generate some Perlin-noise, map a "path" through that noise, using some sort of formula that directed it over and around rises in "difficulty" to ultimately end up at the highest peak on the map, and have your game follow that path according to its values mapped on a linear timescale. Due to the nature of the noise, the difficulty would always "flow" nicely (as long as your game elements reflected the difficulty value as accurately as possible, which is a whole different venture), and never drop or rise too dramatically for the player.

That example probably wouldn't work exactly as I described it, but you can sort of see what I'm getting at, right? Taking randomness (or context, which is not used as often due to its nature of being more difficult to apply, in general) and applying it to games in ways more critical to the design, other than just level layout, such as pacing, or even visuals.

On the topic of visuals, procedural generation also can play a huge part in that. I won't go into detail, but a very simple example would be cracking glass: instead of the same crack appearing every time, having the crack be different based on the force/velocity of what hit it, possibly with some random factor, and then procedurally "web" out after that.

The truth is, there are so many trees to bark up :D deciding which ones to bark up based on the game you are designing, and what your intentions are with the game and its design are really what we should be doing, in my opinion.

I should write a new tutorial, now that people seem to have gotten the grasp of this one for sure, and introduce a more context-sensitive application of procedural generation. And possibly, like your blog post did, try to hint at other ways which it can be applied, or even other more ambiguous ways which PG can be applied.
Logged
astrospoon
Level 4
****


Andy Hull


View Profile WWW
« Reply #102 on: October 07, 2009, 06:03:05 PM »

While I think that things like procedurally generating tree branches and cracking glass can be cool, I think that in most games, it is a waste of time. Unless the differences generated in the cracking of glass play a role in game play, you are just creating extra work for yourself when a simple animation would do just fine.

The reason that most of the time you see PG used for level creation, is because it is the most noticeable application. Using it to generate items and enemies would be the next most noticeable application, etc.. Sure, generating everything in a game would be cool, but it is pretty impractical for the most part, and also probably undesirable. The human created content usually brings WAY more life to a game then whatever the algorithms can cook up. And writing good generation algorithms takes a long time.

the memorable part of Spelunky is really all the cool interactions and animations that Derek put into the game. The random levels are a huge part of why the game is so fun and enjoyable (and especially replayable), but the charm comes from all of the small touches Derek added in the code and animations. Lifeless random levels are still lifeless.

Logged

ChevyRay
Guest
« Reply #103 on: October 07, 2009, 06:29:34 PM »

Yeah, those were mostly just simple examples. But I don't think it's a waste of time, always. It can be fun to do, and rewarding, regardless of how important it is. Folks like me enjoy coding that kind of shit just for the sake of coding it Evil

It's true that what your cracked glass looks like doesn't have nearly the same effect on your game as how your levels are designed, but the process of learning how to do it can definitely serve as a learning experience, or even inspiration, for bigger and more important things such as your game's levels and layout. For example, I used a fractal algorithm to create the single-plane "world maps" in my first tutorial, mostly to explain what fractals were and how they can be applied to something as particular as game level design. Cracking glass is also a strong example of a fractal, though, and one could effectively create a dungeon-generating algorithm or something like that with code not all that far off from what was used to generate cracked glass.

I mentioned game pacing as something that PG could be applied to, because that felt like something more important, like level design/layout as you've said, that PG hasn't been applied to quite as much at this point.
Logged
astrospoon
Level 4
****


Andy Hull


View Profile WWW
« Reply #104 on: October 08, 2009, 05:03:57 AM »

Yeah, I am the king of coding overly complicated things that don't really need to be in a game, so I understand. (Just yesterday I was talking about adding the ability to tranquilize birds, attach cameras to them, and then wake them back up and let them fly away so that you can get a better view of the landscape around you in my newest game.)

I agree though, for learning's sake, anything you do is good. I was more commenting about why we don't see more of it done in games. And to that I think the answer is: too much work for too little payoff.

I think that the tough part with generating story is that the details still have to be set up by hand- just like the level sections in Spelunky. Then you are essentially pasting together these pre-set "events" into a narrative. (And possibly randomly switching characters involved in said events, or a few different outcomes for each one) But in the end, people will still be able to "see" the story bits repeat.

More exciting I think is just letting story happen, by generating an interesting and deep enough world. If your characters can have motivations of their own, you would naturally develop some interesting conflicts with them which would in turn generate cool story like moments in the game.

I think a big part of making Procedural Generation work well is having good enough AI to take advantage of the different scenarios that are created. Otherwise, you end up with Diablo. Sure, the walls are in random locations, but the game never really feels different because of it. You are still just clicking on skeletons and stuff.
Logged

Hayden Scott-Baron
Level 10
*****


also known as 'Dock'


View Profile WWW
« Reply #105 on: October 09, 2009, 07:30:55 AM »

Are there any tutorials or articles that you recommend with regards to making corridor based mazes? Also, what is the best way to solve a maze? Should I use something like Astar (which I know nothing about, and fear might be too complex for me) or should I just brute force the solution trying every possibility?
Logged

twitter: @docky
shrimp
Level 5
*****


View Profile WWW
« Reply #106 on: October 09, 2009, 07:38:50 AM »

Are there any tutorials or articles that you recommend with regards to making corridor based mazes? Also, what is the best way to solve a maze? Should I use something like Astar (which I know nothing about, and fear might be too complex for me) or should I just brute force the solution trying every possibility?

I found this page very useful - as a reference to possible algorithms and properties of mazes rather than a tutorial. Scroll down to "Maze Creation Algorithms". Also has details on solvers.

A* is not too scary but is easy to get wrong. What language are you using? If it's C# I'm happy to post my very general-purpose A* solving code. (In another thread?)

If you just want an A* reference (amongst others) I would use the excellent Amit's A* page



Logged

Hayden Scott-Baron
Level 10
*****


also known as 'Dock'


View Profile WWW
« Reply #107 on: October 09, 2009, 08:10:13 AM »

I'm using a type of Javascript, but I think I'm probably better off writing something myself so that I understand exactly what is going on. Smiley

Thanks for the links. I'll give some the maze generation methods a try!
Logged

twitter: @docky
Fifth
Level 10
*****



View Profile
« Reply #108 on: October 09, 2009, 10:10:16 PM »

I wanted to try that "generate noise and then run an algorithm over it so that it makes caves" thingy of several pages/months back.  Just for fun, y'know.



It's a simple one: any square whose 3 out of 4 adjacent squares are of a type will become that type on the next pass.
As you can see, there are bits that never clear up.
But it was fun.
Logged
ChevyRay
Guest
« Reply #109 on: October 09, 2009, 11:12:56 PM »

A final clean-up pass would be easy to do, though. I like that one, kind of. I should try combining that with some other kinds of tunnel-digging algorithms and see what kind of goodies one can produce.

@Dock: I could always write a tutorial on A*, possibly. There are lots in existence, but I get pretty good feedback about the way I write my tutorials, so one more can't hurt.

I could write it up with some other pathfinding methods as well, such as plain-jane BFS, footprints, some non-grid-specific methods, and some group-pathfinding systems I've worked out myself over the past couple years. It will be non-language-specific too.

Who's up for that? If I get 5 ayes, then I'll set a couple days aside to write one up. Smiley
Logged
shrimp
Level 5
*****


View Profile WWW
« Reply #110 on: October 09, 2009, 11:56:33 PM »

It's a simple one: any square whose 3 out of 4 adjacent squares are of a type will become that type on the next pass.

/TEARS GAZE AWAY FROM HYPNOTIC IMAGE

Ah wow, I was thinking of implementing something like this soon as a second stage of placing "biomes" (types of forest etc) on a map. I was thinking each square could be assigned a biome based on slope, altitude, etc, using a process to pick a mostly closely matching biome. Then it would run this kind of process where each square "competes" with its neighbours, and thereby clumps/smooths everything a bit.

I was thinking of doing 8-way neighbourhoods (may not be any advantage), and effectively 5-out-of-8 neighbours, although it will need a bit of work to make it work for N colours.

If you felt like posting some GIFs where you do 2-out-of-4 instead of 3, and some 8-way versions, that would be very interesting! (and hypnotic  Addicted)


Logged

roboprez
Level 1
*


Got to love them pixels


View Profile WWW
« Reply #111 on: October 10, 2009, 02:12:57 AM »

@ChevyRay
Aye, It would be good to have a simple A* tutorial.
Logged

Fifth
Level 10
*****



View Profile
« Reply #112 on: October 10, 2009, 04:27:40 PM »

Still having fun with this cellular automation stuff.

I tried four different algorithms:
1. checking the neighboring cells (the one I showed before, with winding box-like passages)
2. checking the diagonal cells (which smooths things out, but doesn't work well enough by itself)
3. a sort of experimental thing which checks the bottom five cells for addition versus the top five cells for subtraction (which kinda makes the floor bubble into weird slopes)
4. and another that's just the opposite (which makes the ceiling bubble).

I also made a button which picks a few of the algorithms at random, doing three sets of a single algorithm three times, then a different one once.  Which I think ends up with some interesting-looking results.

Anyway, if anybody cares to check out the result, I've got the little program here:
http://www.l-ames.com/logan/rand-cell-noise.zip
Logged
kavs
Level 2
**


Brad Kavanagh


View Profile WWW
« Reply #113 on: October 13, 2009, 09:23:31 AM »

Who's up for that? If I get 5 ayes, then I'll set a couple days aside to write one up. Smiley

Aye!  Grin
Logged

Hayden Scott-Baron
Level 10
*****


also known as 'Dock'


View Profile WWW
« Reply #114 on: October 13, 2009, 09:50:07 AM »

Sure, I'd like to see your take on A-star!
Logged

twitter: @docky
shrimp
Level 5
*****


View Profile WWW
« Reply #115 on: October 13, 2009, 01:20:36 PM »

Awesome little app Fifth, thanks for sharing Smiley
These kind of little prototypes are great, wish I was disciplined enough to make more of them myself instead of piling stuff into the game!
Logged

Eclipse
Level 10
*****


0xDEADC0DE


View Profile WWW
« Reply #116 on: October 13, 2009, 02:24:03 PM »

Who's up for that? If I get 5 ayes, then I'll set a couple days aside to write one up. Smiley

Aye dude Wink
Logged

<Powergloved_Andy> I once fapped to Dora the Explorer
pgil
Guest
« Reply #117 on: October 13, 2009, 03:51:12 PM »

Who's up for that? If I get 5 ayes, then I'll set a couple days aside to write one up.

Do you even need to ask? AYE!  Beer!
I really hate reading tutorials written by code geeks. You're really good at explaining things so that non-programmers can understand it.
Logged
ChevyRay
Guest
« Reply #118 on: October 13, 2009, 05:28:25 PM »

Alright, that's enough incentive for me. I'll get to writing one up. I've got insanely busy few days ahead of me (like 2 more birthdays and a week-long trip), so it might be a couple weeks or so before I get around to it. I also have to get back into "pathfinding" mode, but that's never too hard. I'll start off the tutorial with a real meat & bones explanation of Breadth First Search, so you understand where A* is coming from, and then I'll sort of ease into the algorithm using pseudocode and some diagrams. I'll finish off with a few tips on expanding/improving your searches, but for the most part I'm not gonna concentrate on effeciency but rather just getting the damned thing to work. Smiley
Logged
Triplefox
Level 9
****



View Profile WWW
« Reply #119 on: October 14, 2009, 04:30:20 AM »

I went to a symposium on procedural content at UCSC the other day. Here are my revised notes, I didn't stay the whole way through all of them, but combined with the links you should get a pretty accurate picture:

Evolving levels for Super Mario Bros.
http://julian.togelius.com/Pedersen2009Modeling.pdf

This research attempted a player experience model based on Infinite Mario Bros. to take data from hundreds of players on the Internet and use their responses to questionnaires to evolve a neural network AI that correlates the level generation process to desired parameters(the ones used were fun, boredom, anxiety, unpredictability, challenge, and frustration).

They achieved a high prediction rate for some of the parameters(notably frustration) but not all. Additionally, some interesting correlations were found through this process; long jumps, for example, were correlated with unpredictability.

The process involved generating first a level that attempted to predict questionnaire responses, and then two levels that are very high and very low in a user-selected parameter, and then a second questionnaire to follow up on the generated levels and tune the process.

Evolving Game Rules
http://julian.togelius.com/Togelius2008An.pdf

In this research a matrix representation of rules for object collision, and movement absent collision, was used to drive a Pac-Man like maze game.

Movement logic is a choice of none, random short, random long, clockwise, counterclockwise, chase, flee.
Effects of collisions include nothing, death, teleport, and score effects(add/subtract)
Time limits and score goals vary

There are four colors, Red, Green, Blue, and player agent(Cyan) each having a unique relationship of interactions with each other.

The fitness function is based on learning progress from Raph Koster's fun=learning theory; fitness over time is associated to some curve. In the ideal curve, the player improves their score linearly with each iteration.

Outcome: It works, but mostly in fine tuning situations. Possible evolutions include the use of Amazon-like collaborative filtering, or adapting it to compositional content creation(evaluating the desirability of each item of content and composing new items from previous data)

The author's observation of this approach is that having a big dataset is the key factor: with enough player data you can avoid getting stuck at local optima. (My own note: an underlying problem with recycling player data into the generator is that it depends on core assumptions about the generation process; if the generation strategy is weak, the entire process is limited.)

Experience Management through Narrative Content Generation
http://www.cc.gatech.edu/~riedl/

Goal: Computational models of narrative reasoning and generation
Specifically: Automatic creation of meaningful sequences of events; large-scale, customized storytelling for all applications(entertainment, training, education)
Not about total replacement, but assistance: how far can we get with AI?

Four categories: Authoring, On-Demand Narrative Generation, Experience Management, Game Engine

Riedl determined that a feedback loop is necessary; the user changes their process over time too!

Two basic properties of story were attacked: Logical causal progression, character believability (more complex stuff eschewed for now)
Representation used: Partially ordered plans; AI planning algorithm finds a sound sequence of operations that manipulates the world state into a goal situation.
Planning turns out to be an imperfect model as-is: a naive planner will find the shortest series of steps, short-circuiting the natural storytelling process.

The new model: Intent-Driven Partial Order Causal Link planner
Logical causal intention + reasoning about character intentions

Future developments: Player modeling?

Real-time experience management: manipulating the world so that it conforms to some set of attributes
Model is visualized as a state space wherein the player and the system manipulates the trajectory of the state space.
There are three categories of behavior in real-time experience management: constituent(expected), consistent(roughly expected, with temporary detours from the trajectory) and exceptional(previous trajectory is unreachable).
Example: Player kills the big bad wolf at the outset of Little Red Riding Hood
Solution: Find all possible branch points and generate their results in advance so that the planner can work regardless of what the player does.

(At this point I ducked out because I was starving)

Kate Compton: Using Procedural Generation for Human-Computer Collaboration
(Kate worked on Spore.)
www.galaxykate.com

Kate opened by pointing out that infinite worlds are the most common application of procedural techniques today, and we have a toolbox of autonomous methods to use them in real-time:

Top-down generation: l-trees, grammars, function-based
Post-generation optimizations: hill-climbing, genetic algorithms
No human oversight
No interaction

The alternate approach is human-computer collaboration. Infinite content is perceived as valueless; human creations are perceived as valuable.

Fitness functions are hard to work with: Slow+complex to evaluate and dependent on how much you simulate, and difficult-to-define variables that vary across the playerbase.

An existing use of the player as fitness function evaluator is in dynamic difficult adjustment; however, calculations behind the scenes to find player frustration are difficult and complex. An alternative: give players deliberate hard/easy choices at various intervals during play, either within the world or via prompting.

The generation system doesn't know what the player wants, but they can filter as the player says "I want that!"

Problems with player as fitness function: Player acts as a highly myopic hill-climbing algorithm, can't jump around to new possibilities, gets stuck at local optima, doesn't have a lot of iterations before their patience runs out.

Solutions: cheat (know approximately what the player wants), encourage local exploration with a strong UI, present copious and continuous feedback, so that the algorithm runs as many iterations as possible.

Creature Creator's reactions are entirely randomized but the player responds to them emotionally, which makes them more engaged.

Terrain Generator had a much bigger problem than Creature Creator: playability. The classic procedurally generated terrain wasn't playable. The team started saving seeds of acceptable planets, but it still wasn't playable, there wasn't enough control, and there was a loss of variety.

Gradually, a script-based system was developed that turned into a "planet editor," with brushes, painting, etc.

The terrain generation process was never fun: feedback was strictly visual and didn't help the user with gameplay rules or possibilities, so all workflow was intuition-based.

Games That Make Games

LBP, Spore Galactic Adventures, Fantastic Contraption, Line Rider

Main thing is user engagement: playing game designer is not the goal for these types of games

Great variation of engagement level: a few dedicated users and a much larger "casual/disinterested" based. Most players only want to change one or two things and they want to feel confident while editing; low confidence in the workability of results, and observed failures of creation, will disengage players.

Brushes can describe visuals of terrain (hilly, snowy, desert, lakes) but they could also describe gameplay features (walkable, enclosed, populated...)

(There's some interplay of randomness, human customization, and AI where procedural techniques really shine, but it seems to vary from case to case and really hinges on the heuristics.)
Logged

Pages: 1 ... 4 5 [6] 7 8 ... 23
Print
Jump to:  

Theme orange-lt created by panic