Jump to content
  • Advertisement
Sign in to follow this  
  • entry
    1
  • comments
    2
  • views
    6119

About this blog

Research prototypes about gameplay and AI.

Entries in this blog

 

Visualizing Gameplay and AI for Fun and Profit!

[font="Verdana, Arial"][size="2"]It's always cool to watch in-game visualizations, and as a developer building them can be very rewarding too! However, in the heat of the moment it's easy to forget or tell yourself you won't need to visualize *this* particular feature.[/font]
[font="Verdana, Arial"]
[/font][font="Verdana, Arial"] [/font][font="Verdana, Arial"] [/font][font="Verdana, Arial"] [size="2"]Last week we released a video tutorial, recorded in AiGameDev.com's secret research lab, on the topic of visualizing gameplay and AI. This journal seems like a good excuse to go into more details with some higher resolution screenshots! Hopefully it will inspire you and convince you that visualizations are often a reliable investment.

NOTE[color="#696969"]: [/color][color="#696969"]We also ran an [/color][color="#0000ff"]in-depth masterclass[/color][color="#696969"] about the AI in the game, in particular explaining how to build chase and evade behaviors; you can get access to the replay by just typing in your email address if you're interested![/color]

[size="3"]The Case for (Better) Visualization
[size="2"]In practice, there are three major reasons why visualizations will pay off in your project:

Code Correctness -- As you're implementing a feature, even if you have unit tests, it's great to have visualizations to make sure your assumptions are correct. Complex game worlds may have special cases that your tests didn't cover, and new levels may reveal those problems only later. Identifying Bugs -- Beyond just checking that your code actually works, the visualization helps you rule out certain problems while you're trying to isolate a bug. If you have a collection of visualizations you can easily spot the problem or have an idea of where to look. Tweaking & Tuning -- As you get towards the end of the project, visualizations are also particularly useful for helping make changes to the levels, the behaviors, the gameplay in ways that wouldn't be as obvious using the regular geometry.[size="2"]In the rest of this post, you'll see five visualizations we used while building a game prototype that we call RUSHING BASES (based on British Bulldog, a tag-based game played in schools). Notice how most of these tools helped us both at the start of the project when building the infrastructure, and then while balancing the gameplay.


[size="3"]Example #1 -- Grid Map[/font]
[font="Verdana, Arial"][size="2"]
[size="2"] . [size="2"]
What Does it Show?
[size="2"]This particular demo is built based on 2D grids, so the map shows areas of the world that are accessible and those that are not. By default, cells that are blocked are shown in magenta, and the open cells are simply not drawn.


How Does it Work?
[size="2"]It's simply one large texture, of the resolution of the grid, which is applied onto a debug polygon stretched over the world. There's a Z-offset applied to make sure no Z-fighting occurs, and optionally you can setup the depth test to ignore the world geometry so the texture is visible everywhere on the screen.


Why did we need it?
Helps understand the impact of decisions about the grid's resolution. Identifies blockages and narrow spaces to improve the level design.
[size="3"]Example #2 -- Area Network[/font]
[font="Verdana, Arial"][size="2"]
[size="2"] [size="2"]. [size="2"]
What Does it Show?
[size="2"]The fundamental representation of the game is based on groups of cells that we call areas. These form the basis of the pathfinder and the influence map, as you'll see below. The area network visualization shows areas both individually, and how they relate to each other.


How Does it Work?
[size="2"]There's an instance of a circle shape that's reused and drawn in multiple places, based on the center of each area. The circle is scaled based on the area size, and given a unique color based on the area ID. Connections are drawn as unique splines, though in the past I've used common arrows from each area to indicate connections -- which is a bit more efficient to render but harder to visualize. The area labels are custom textures rendered by the underlying graphics engine, and overlaid onto the world with a Z-offset.


Why did we need it?
Helps understand the trade-off between area map's precision and simplicity. Shows the actual graph that underlies the pathfinding and influence mapping. It looks really cool and it's great to show people that visit the office :-)
[size="3"]Example #3 -- Hierarchical Graph[/font]
[font="Verdana, Arial"][size="2"]
[size="2"] [size="2"]. [size="2"]
What Does it Show?
[size="2"]This is the high-level search graph that's actually used by the hierarchical pathfinder. It's calculated based on the areas, but has a very unique structure that's show specifically by this custom view. Only the edges of the high-level graph are drawn, though the nodes are implicitly obvious.


How Does it Work?
[size="2"]The graph is drawn as a set of edges, each represented as a narrow polygon. (Modern graphics drivers don't always support rendering lines, and this is typically done as a set of triangles.) The nodes in the graph each have labels, which are drawn as camera-facing billboards.


Why did we need it?
Helps isolate pathfinding problems if there are problems. Shows all options of paths that could be used by the AI. Reveals missing paths and possible level design problems.
[size="3"]Example #4 -- Influence Map[/font]
[font="Verdana, Arial"][size="2"]
[size="2"] [size="2"]. [size="2"]
What Does it Show?
[size="2"]This visualization shows the influence map, which shows the cost of areas updated dynamically. Some areas are at risk (red, yellow) based on proximity to members of the opposing team, and other areas are marked as beneficial (blue, cyan) due to previously succesfull runs. This view shows both of those factors either combined or separately.


How Does it Work?
[size="2"]This implementation is done in the same way as the grid map, as a texture ovelaid onto the world. In this case though, the underlying texture needs to be updated on a regular basis as the influence map changes.


Why did we need it?
Helps understand the tactical decisions made by the AI while running. Provides feedback for balancing and tuning those decisions as a designer. Displays long term statistics about levels so they can be used for balancing.
[size="3"]Example #5 -- Navigation Paths[/font]
[font="Verdana, Arial"][size="2"]
[size="2"] [size="2"]. [size="2"]
What Does it Show?
[size="2"]This view shows the final navigation path, after pathfinding and string-pulling, for all the actors in the world. It's drawn as a set of arrows joined together, each representing a segment in the final path. It's also possible to enable showing the history of previous paths used.


How Does it Work?
[size="2"]The lines and arrows are all rendered as narrow polygons, like previous views. The only difference in this case is that the paths must be updated on a regular basis when the navigation changes. There are conditions and optimizations in place to reduce the amount of work done due to dynamic changes.


Why did we need it?
Shows path correctness at the low-level, helps identify various pathfinding bugs. Displays the decisions and path choices made by the AI on both teams. Reveals insights into the high-level behavior for design improvements and optimizations. Provides a way to view the selection of tactiac paths over time by drawing path history.
[size="3"]Conclusion
[size="2"]In our case for this game, the "Navigation Paths" provided by far the most useful representation since the game is very much about tactical pathfinding through an obstructed world. This visualization gave us benefits all the way from low-level code to design insights, as well as optimizations and behavior fixes.

[size="2"]In general, it's extremely useful to have visualizations of many different kind for a variety of purposes. As a rule of thumb, the more you work on a system in the codebase, the more time you should dedicate to implementing in-game representations for it. You'll thank yourself later!
[/font]
[font="Verdana, Arial"]REMINDER[color="#696969"]: If you'd prefer to see the visualizations in action, you should watch the [/color][color="#0000ff"]video tutorial[/color][color="#696969"] related to this journal entry! If you're curious about the chasing & evading behaviors in our demo, also do check out the [/color][color="#0000ff"]in-depth masterclass[/color][color="#696969"] on the topic; you can get access to the replay by just typing in your email address if you're interested![/color][/font]

alexjc

alexjc

Sign in to follow this  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!