I just got back from GDC, full of inspiration! This is a small report of the first day and I intend to write about the other days in coming posts.
Marvel's Spider-Man AI Postmortem
We're starting new AI courses in DAE so i thought it was a good idea to attend this session by Adam Noonchester of Insomniac Games. Main takeaways:
- The insomniac engine used to have behavior trees but for the Spider-Man they implemented "Data Driven Hierarchical Finite State Machines". The complex behavior trees had become very difficult to debug and were not composable. The DDHFSM system uses structs containing data that drive the creation of the eventual FSM.
- There was also the cool concept of "sync joints" in the animation system. In each combat related animation their has been added an extra sync joint. When one character plays an attack anim and the other a response animation, the sync joints of both animations are matched, causing the animations to play simultaneously and at a correct distance from each other. Difficulties here are the fact that you need to add a response animation for each attack animation that gets added to the system for each character. That can quickly mount up to a lot of work.
- For combat there was a "Melee Manager" that made sure no two NPC's attacked spiderman at the same time. There was a strategy that decided who attacks spider-man first. To avoid that you can just run away of the current assigned attacker there is the concept of "job stealing" where another NPC can become the attacker in certain conditions (fi the player is closer to another NPC)
- A bit similar was the "Ranged Manager" that controlled the ranged attacks. In deciding who's the next to attack Spider-Man the off-screen NPC's get a lower prio than the ones on the screen. There are many details in this system, fi jumping in the air could cause all the enemies to stop attack, so quite some special cases were implemented.
- Positioning the NPC's around Spider-Man was first done with a circle divided in different wedges, but that quickly turned out not to work. Instead a Gradient Descent algorithm was used.
- The web blankets that Spider-Man shoots are a collection of joints that raycast onto the surface. For non flat surfaces that rays rotate inwards until they're also connected.
- Flying animations: 3D animation is hard!
- The navmesh was a lot of work
- Moving surfaces are not nice for navmeshes
It was clear that the FPS engine needed a different approach for Spider-Man.
Teaching puzzle design
The next talk I attended was more in line with my role as a lecturer at DAE instead of a developer. This was a session with three speakers, First came Jesse Schell, known for his book "A book of lenses".
He talked about how he approached puzzle design in class, starting with what we call a "class-discussion" with questions and answers to determine the definition of a puzzle. The function of a puzzle in a game is to "stop and think".
- Are puzzles games? His statement is "Puzzles are like penguins": Penguins are birds that do not fly. Likewise, puzzles are games that cannot be replayed.
- A puzzle is a game with a dominant strategy, and once you found that dominant strategy you solved the puzzle.
- A riddle is not a puzzle, since it has no progress, you either know the solution or you don't. There is no knowing a part of the solution.
- Having multiple solutions to a puzzle will make the player feel smart(er) for finding a different approach than someone else, while it's still one of the solutions you provided.
At the end Jesse mentioned this article on gamasutra and this video on youtube as further reading/viewing.
Next was Naomi Clark of NYU Game Center to talk about how they teach puzzle design. She spoke of the "Bolf" game they play; golf with beanbags. Students must design bolf holes and then play like you would play golf, trying to finish below par.
Later in their course students create a game with puzzlescript, which generates 2d dungeon like puzzle games:
After that they create puzzles with Portal 2's Puzzle Maker in pairs, where the focus is on playtesting. In the results it quickly shows which games have been thoroughly tested and which were not.
Third speaker was Ira Fay. He talked about playtesting puzzles.
- Hardest part there is that you cannot reuse your testers; once they've figured out the dominant strategy their value is gone.
- Small changes in the game design can cause big swings in the difficulty level of the puzzle, making it hard to design.
- There is also a wider variance in player skill
He then continued to talk about their escape room design course! Really cool, I wondered how they evaluate this though.
Analyzing for workflow reduction: from many to one to zero.
This was not such a good talk, it stayed very high level, talking about generalities without any concrete examples. The speaker basically recommends one or even zero click build tools, in other words: continuous integration...
New ideas for any-angle path-finding
Best talk of the day! Daniel Harabor presented his any-angle pathfinding solution. Any-angle is pathfinding on a grid, but where you can enter any grid cell at any angle, instead of only multitudes of 45 degrees.
He started with pointing out that string pulling is not always optimal and that Theta* (which is A* with string pulling during the search) yields good results but is slow.
The new algorithm, called Anya, is both fast and optimal. It made me think of a line sweep algorithm. A variant called Polyanya does the same thing but with polygons. I cannot start to summarize the algorithm here, but the good thing is: he posted his slides online!
He also mentioned the website movingai.com, which contains a lot of interesting resources, but most cool are the benchmark worlds of real games where these algorithms can be tested!
Stop fighting! Systems for non-combat AI
Last talk of the day by Rez Graham was about AI algorithms for AI that is not involved in combat. Most of the time AI handles NPC's that take action with the player, but NPC's who are "idle" often do that on the most weird places or in unnatural ways.
Check out this online curve tool! He used this to create the graphs that illustrated the utility curve concept. He talked about utility theory as if everyone should know what it that is, unfortunately I didn't.
At some point he made a very good point that I can only applaud: "Throw it the fuck away". He was talking about prototypes. I should've taken a picture for my students :)
Unity's GDC Keynote
I then attended Unity's keynote, which you can watch in full here.
Hopefully all these links are helpful, more is coming later!
No comments:
Post a Comment