- Joined
- Jan 28, 2011
- Messages
- 99,623
Tags: Bard's Tale IV; Greg Underwood; InXile Entertainment
We interrupt our regular schedule of successive Obsidian and Larian news items with an unexpected new Bard's Tale IV Kickstarter update. This update introduces Greg Underwood, the game's senior programmer and an oldschool Bard's Tale fan. After introducing himself, he goes on to describe how the team have been implementing an oldschool feature - grid-based movement.
We interrupt our regular schedule of successive Obsidian and Larian news items with an unexpected new Bard's Tale IV Kickstarter update. This update introduces Greg Underwood, the game's senior programmer and an oldschool Bard's Tale fan. After introducing himself, he goes on to describe how the team have been implementing an oldschool feature - grid-based movement.
What are the duties of a Senior Programmer on Bard's Tale IV? Well, it varies a lot from day to day. A lot of the code I’m working on is plumbing-level stuff – handling loading and in-memory storage of game data, building the components we’ll use to make the puzzles and traps in game (kind of like Lego-bricks for code), save and load of game data, etc. I also range up to do some UI implementation or bolt in the occasional player ability. Another aspect of my job is to act as a voice for the fans on the team – my experience as a player and fan of the original games is part of why they hired me. And so far, they’ve been great about listening to my suggestions and working to incorporate them. A few of those are in the works and today I'd like to introduce you to the first returning mechanic: grid movement.
RPGs back in the day were built on a grid, both because it was familiar (via table-top games like D&D) and because computers and software wouldn’t be able to handle proper 1st person free movement for another 10 years or so. Early RPGs like The Bard’s Tale not only used a grid, but the fact that it was a grid was often part of the puzzle of the game. You knew there were hidden areas on the map because it was a grid and your careful mapping (on graph paper, no less! No automappers yet) shows there’s a spot you can’t see how to get to. That’s an aspect we wanted to bring forward into this new Bard’s Tale game, so supporting a grid-based movement mode has always been a high priority.
However, time has moved on and we want to take advantage of the many benefits of free movement, too. For instance, it allows for more natural, organic, outdoor areas. It also helps areas you wouldn’t think of as being overly organic or natural, like castle or dungeon interiors. A nicely laid out building interior has a lot more soft corners and curves to it than you’d at first think based solely on the floorplan. More importantly, while parts of the building align on a grid seldom do level designers align the entire floorplan to a grid. Finding a system that works with both a free-flowing world and grid based movement presents some interesting challenges. Take for example this screenshot of the interior of one of the castles.
As you can see, the floor plan might be a straight hallway with 90 degree turns, but the art team has done their job in decorating the area and making it feel lived in. This landing with columns, candle stands, benches, and the stag statue create various obstacles to the movement grid system (visualized here as black squares with the yellow arrows connecting them). This layout is a first pass, partially automatically generated using a system I built to take some of the workload off our designers. This allows us to spend more time later on fine-tuning the level to our satisfaction.
You can see how the grid of nodes coming up the stairs wouldn't work well continued down the area between the columns. We will most likely adjust the grid to have a single path go down the center of the columns, and it may or may not line up cleanly to let you walk between the columns in grid movement mode (I've drawn the likely path in red below).
Another concern is how combat relates to movement nodes. A natural assumption is that combat can only happen on a movement node, but movement nodes and combat placement have somewhat conflicting requirements. Movement needs to feel regular and natural, following halls and turns. Combat needs to be placed such that all enemies can line up on their combat gird positions and not be placed inside of a wall. So we decided we needed to split out a separate combat placement grid from the movement grid. I then built tools to help identify if a given combat placement would have concerns with overlapping props or be too close to a wall. This lets the art and design teams go through a level and adjust the placement or collision settings on various objects and make sure there are viable combat start positions available.
Here is an example of the movement grid (changed to green lines here) and combat grid (red, with obstructions noted by the yellow lines). This particular area obviously still needs some attention from level design and art to clean up so combat can be sure to have enough space to start.
As you can see, even with a tool that generates nodes for you, there's still a fair bit of work to make it all fit and feel just right, something worthy of those players who remember the graph paper days. This is just some of what I've been working on for The Bard's Tale IV and I'm looking forward to talking about more in the weeks and months to come.
Well, okay, better than nothing I guess. The update also has some more photos from E3, but there's still nothing about Techland, only a mention of "behind-the-scenes meetings" with unnamed "business partners". Hmmm.RPGs back in the day were built on a grid, both because it was familiar (via table-top games like D&D) and because computers and software wouldn’t be able to handle proper 1st person free movement for another 10 years or so. Early RPGs like The Bard’s Tale not only used a grid, but the fact that it was a grid was often part of the puzzle of the game. You knew there were hidden areas on the map because it was a grid and your careful mapping (on graph paper, no less! No automappers yet) shows there’s a spot you can’t see how to get to. That’s an aspect we wanted to bring forward into this new Bard’s Tale game, so supporting a grid-based movement mode has always been a high priority.
However, time has moved on and we want to take advantage of the many benefits of free movement, too. For instance, it allows for more natural, organic, outdoor areas. It also helps areas you wouldn’t think of as being overly organic or natural, like castle or dungeon interiors. A nicely laid out building interior has a lot more soft corners and curves to it than you’d at first think based solely on the floorplan. More importantly, while parts of the building align on a grid seldom do level designers align the entire floorplan to a grid. Finding a system that works with both a free-flowing world and grid based movement presents some interesting challenges. Take for example this screenshot of the interior of one of the castles.
As you can see, the floor plan might be a straight hallway with 90 degree turns, but the art team has done their job in decorating the area and making it feel lived in. This landing with columns, candle stands, benches, and the stag statue create various obstacles to the movement grid system (visualized here as black squares with the yellow arrows connecting them). This layout is a first pass, partially automatically generated using a system I built to take some of the workload off our designers. This allows us to spend more time later on fine-tuning the level to our satisfaction.
You can see how the grid of nodes coming up the stairs wouldn't work well continued down the area between the columns. We will most likely adjust the grid to have a single path go down the center of the columns, and it may or may not line up cleanly to let you walk between the columns in grid movement mode (I've drawn the likely path in red below).
Another concern is how combat relates to movement nodes. A natural assumption is that combat can only happen on a movement node, but movement nodes and combat placement have somewhat conflicting requirements. Movement needs to feel regular and natural, following halls and turns. Combat needs to be placed such that all enemies can line up on their combat gird positions and not be placed inside of a wall. So we decided we needed to split out a separate combat placement grid from the movement grid. I then built tools to help identify if a given combat placement would have concerns with overlapping props or be too close to a wall. This lets the art and design teams go through a level and adjust the placement or collision settings on various objects and make sure there are viable combat start positions available.
Here is an example of the movement grid (changed to green lines here) and combat grid (red, with obstructions noted by the yellow lines). This particular area obviously still needs some attention from level design and art to clean up so combat can be sure to have enough space to start.
As you can see, even with a tool that generates nodes for you, there's still a fair bit of work to make it all fit and feel just right, something worthy of those players who remember the graph paper days. This is just some of what I've been working on for The Bard's Tale IV and I'm looking forward to talking about more in the weeks and months to come.
