Modularity In Game Environments

Haytch

Hello Poly counters! I've not been here in such a long time.

I've left the game industry due to family circumstances and I'm now teaching at a University in London.
I've written a blog on the simple basis for modularity and wanted to get everyone's two-cents. Eventually I will also write a blog on advanced modularity (more specifically interior-exterior joint modularity) but i'm keeping it relatively simple for students for now..

https://escapestudiosgamesart.com/2020/02/18/modularity-in-game-environments/

Please don't hesitate to give any feedback etc and engage on the blog post! Kind Regards.

Eric Chadwick

Nice article, thanks for sharing.

I was curious about your opening statement.

Modularity within game environments is often a taboo topic. Mainly because it hurts my head so much trying to figure out the metric system for it; often you find a grid to work on whether it is metric or centimeters. It’s not that scary when you try to tackle an interior modular scene OR an exterior modular scene because you only have to stick to a few principles:

1. It has to work within the grid.
2. The textures have to match up.
3. Does it look accurate.

Seems unclear to me why you used the word taboo. Perhaps "difficult" is more descriptive here. Taboo generally means it's off-topic for cultural or moral reasons, neither of which seem to apply here.

If you're presenting this to students, I'd recommend starting off with a positive statement about the subject. Modularity is very powerful (as your examples show!) and is actually relatively easy to understand and implement.

Sure there are complications, but you can address those in time. Start simple, and give them an easy target to hit with their first try, so they can achieve a sense of accomplishment.

Also, we have a lot of resources here on our wiki, which might help you or your class.

• http://wiki.polycount.com/wiki/Modular_environments
• http://wiki.polycount.com/wiki/Texture_atlas
  
• http://wiki.polycount.com/wiki/ChannelPacking
  
• http://wiki.polycount.com/wiki/MultiTexture
  

Mark Dygert

The GDC talk that some of the guys over at Bethesda put on a few years back is a treasure trove of info.

https://www.youtube.com/watch?v=QBAM27YbKZg

They also go over some of the history of their modular kits and the theories and decisions that lead them to work like they did.

The thought process behind, why they made the kits why they did, is critically important for people learning to work with modularity because not every game or modular system is the same and seeing how they arrived at the decisions they did and hearing the lessons they learned is really valuable.

A module can be an entire building or it can be a single brick. It can be several tiles (floor, walls, ceiling) or they can all be combined. It's less of a rigid structure and more of a set of rough guidelines, like you alluded to. Getting them to see that is often hard, they usually like a lot of  "do exactly these steps, follow these rules blindly and success will always happen". Which in my book is the exact recipe to make a mindless little automaton that can only follow tutorials and can't figure out anything for themselves.

Not only will they need to work within existing modular systems but they need to be of the mindset that can also stand up a whole new system. With the right mindset they will also push whatever system they're working in to be the best that it can be. They need to not just accept the current system but to question it and make sure it is healthy and forward facing. If they have that mindset they will also do the work early on to make sure that the system is as robust as they need it before taking it into production.

I also agree with Eric and would avoid using the word taboo, there is a lot of discussion on the subject so it's not really "taboo". Almost everyone that works with modular systems doesn't mind talking about them, unless they're being tied down by a NDA. I think it can be confusing for people new to the workflow. They might get conflicting solutions, ideas, theories and methods but that is because not every game is the same so not every system will be put together the same way because they aren't solving the same problems or facing the same challenges.

If I was teaching a class...
Real-ish projects: After some high level overview talks, I would break the students into groups and give each group a slightly different scenario and not tell them how to solve it, let them figure it out and loosely guide them along the path as they research and vet their own ideas. That way they would see there are several different situations with different working their way out  based on subtle detail shifts in the project. They would learn from the other students while also being forced to think for themselves.

Time management and adaptability: They need to know that "No battle plan survives contact with the enemy, but planning is still everything."  It's a difficult dance to illustrate to people who are looking for concrete rules to build their career around but they need to know that planning and preparation is important but so is flexibility. To do that I would throw them each a curve ball mid project as if some functionality in the game had changed and they need to adapt their systems to work around it.
Things like:

• There are new characters added to the game that are taller, making doorways and hallways too short.
  
• The camera position changed from over the shoulder to 3rd person.
• The draw call count is affecting frame rates and they need a way to lower it.
• They need make hallways at 45 degree angles or round rooms.
• Texture budgets where lowered to provide more memory for other things.
• Characters jump farther, run faster or can do something new like wall run or swing on a rope. 

This would involve a tight deadline and some rework, they would be forced to choose between a "perfect solution" that they don't have time for, or a quick solution that achieves their goal on time but might not be optimal.

I would then impress upon them importance of forward thinking and anticipating things like this during the research phase. "Had you asked a few more questions, you MIGHT have arrived at the optimal solution, on time". Of course you're job is slightly more than cheerleader and cat wrangling but getting them in the mindset of production hardened veteran will really help them.

Interdepartmental compromise: They would also have the option of working out a solution with the design team to reign in some of the functionality. "Design can have swinging ropes but only of X length and only in certain areas". That interdepartmental negotiation can be critical to a projects success, so don't leave them with their pants around their ankles on day one. Each group would have a designer personality assigned to them, all the way from bat shit crazy who will never give up on their idea, to a reasonable personality who works with each idea. If a group gets hard blocked by a crazy designer you can always go through a change in personnel "Daren the bat shit designer quit and has been replaced, lucky for you they have been replaced with a somewhat reasonable person". They need to know how to deal with both types. Don't teach them to just bend over and take it, but to wrestle for the best solution possible. If that means choking out design until they tap out, let them know they can do it. Just make sure they wisely choose the hill that they want to die on.

To me those things are way more important than just breaking down an existing modular system. But, that is probably unconventional... they would learn from it and they would probably like it.

Haytch

Eric Chadwick said:

Nice article, thanks for sharing.

I was curious about your opening statement.

Modularity within game environments is often a taboo topic. Mainly because it hurts my head so much trying to figure out the metric system for it; often you find a grid to work on whether it is metric or centimeters. It’s not that scary when you try to tackle an interior modular scene OR an exterior modular scene because you only have to stick to a few principles:

1. It has to work within the grid.
2. The textures have to match up.
3. Does it look accurate.

Seems unclear to me why you used the word taboo. Perhaps "difficult" is more descriptive here. Taboo generally means it's off-topic for cultural or moral reasons, neither of which seem to apply here.

If you're presenting this to students, I'd recommend starting off with a positive statement about the subject. Modularity is very powerful (as your examples show!) and is actually relatively easy to understand and implement.

Sure there are complications, but you can address those in time. Start simple, and give them an easy target to hit with their first try, so they can achieve a sense of accomplishment.

Also, we have a lot of resources here on our wiki, which might help you or your class.

• http://wiki.polycount.com/wiki/Modular_environments
• http://wiki.polycount.com/wiki/Texture_atlas
  
• http://wiki.polycount.com/wiki/ChannelPacking
  
• http://wiki.polycount.com/wiki/MultiTexture
  

Excellent question dude. And thank you for your kind words, so... the reason I say it can be quite a taboo topic is because the deeper down the rabbit hole you go. The scarier and more complex it can become... originally when I wrote this article I was going to write about interior exterior popularity kits that work off of a 0.5m grid where the interior and exterior both line up flawlessly. However, both times I've ever spoken to level designers regarding this approach I've often found them getting annoyed and confused with their own trial and error and explanations. And as you can see from my second demonstration an originally made level used specific elements for the architecture instead of tackling it via modular pieces, thus creating an arguement in studio... 'why didnt you do this modular' and some artists may also say they understand modularity but often dont.

So it's not taboo in terms of no one talks about it but conversations often feel rushed or not fully understood.

Haytch

Mark Dygert said:

The GDC talk that some of the guys over at Bethesda put on a few years back is a treasure trove of info.

https://www.youtube.com/watch?v=QBAM27YbKZg

They also go over some of the history of their modular kits and the theories and decisions that lead them to work like they did.

The thought process behind, why they made the kits why they did, is critically important for people learning to work with modularity because not every game or modular system is the same and seeing how they arrived at the decisions they did and hearing the lessons they learned is really valuable.

A module can be an entire building or it can be a single brick. It can be several tiles (floor, walls, ceiling) or they can all be combined. It's less of a rigid structure and more of a set of rough guidelines, like you alluded to. Getting them to see that is often hard, they usually like a lot of  "do exactly these steps, follow these rules blindly and success will always happen". Which in my book is the exact recipe to make a mindless little automaton that can only follow tutorials and can't figure out anything for themselves.

Not only will they need to work within existing modular systems but they need to be of the mindset that can also stand up a whole new system. With the right mindset they will also push whatever system they're working in to be the best that it can be. They need to not just accept the current system but to question it and make sure it is healthy and forward facing. If they have that mindset they will also do the work early on to make sure that the system is as robust as they need it before taking it into production.

I also agree with Eric and would avoid using the word taboo, there is a lot of discussion on the subject so it's not really "taboo". Almost everyone that works with modular systems doesn't mind talking about them, unless they're being tied down by a NDA. I think it can be confusing for people new to the workflow. They might get conflicting solutions, ideas, theories and methods but that is because not every game is the same so not every system will be put together the same way because they aren't solving the same problems or facing the same challenges.

If I was teaching a class...
Real-ish projects: After some high level overview talks, I would break the students into groups and give each group a slightly different scenario and not tell them how to solve it, let them figure it out and loosely guide them along the path as they research and vet their own ideas. That way they would see there are several different situations with different working their way out  based on subtle detail shifts in the project. They would learn from the other students while also being forced to think for themselves.

Time management and adaptability: They need to know that "No battle plan survives contact with the enemy, but planning is still everything."  It's a difficult dance to illustrate to people who are looking for concrete rules to build their career around but they need to know that planning and preparation is important but so is flexibility. To do that I would throw them each a curve ball mid project as if some functionality in the game had changed and they need to adapt their systems to work around it.
Things like:

• There are new characters added to the game that are taller, making doorways and hallways too short.
  
• The camera position changed from over the shoulder to 3rd person.
• The draw call count is affecting frame rates and they need a way to lower it.
• They need make hallways at 45 degree angles or round rooms.
• Texture budgets where lowered to provide more memory for other things.
• Characters jump farther, run faster or can do something new like wall run or swing on a rope. 

This would involve a tight deadline and some rework, they would be forced to choose between a "perfect solution" that they don't have time for, or a quick solution that achieves their goal on time but might not be optimal.

I would then impress upon them importance of forward thinking and anticipating things like this during the research phase. "Had you asked a few more questions, you MIGHT have arrived at the optimal solution, on time". Of course you're job is slightly more than cheerleader and cat wrangling but getting them in the mindset of production hardened veteran will really help them.

Interdepartmental compromise: They would also have the option of working out a solution with the design team to reign in some of the functionality. "Design can have swinging ropes but only of X length and only in certain areas". That interdepartmental negotiation can be critical to a projects success, so don't leave them with their pants around their ankles on day one. Each group would have a designer personality assigned to them, all the way from bat shit crazy who will never give up on their idea, to a reasonable personality who works with each idea. If a group gets hard blocked by a crazy designer you can always go through a change in personnel "Daren the bat shit designer quit and has been replaced, lucky for you they have been replaced with a somewhat reasonable person". They need to know how to deal with both types. Don't teach them to just bend over and take it, but to wrestle for the best solution possible. If that means choking out design until they tap out, let them know they can do it. Just make sure they wisely choose the hill that they want to die on.

To me those things are way more important than just breaking down an existing modular system. But, that is probably unconventional... they would learn from it and they would probably like it.

Wow, very interesting! I do remember that video a few years ago regarding Bethesda and their cave kits... I do now, seeing that you've pointed out, realise the word taboo may have been misused, the word I was trying to explain was, an unnecessary avoidance. As you say, everyone who works with modularity loves talking about modularity however,  if it's notfully understood that's when people often dont hold their hands up and say. What the ef is going on?! Help menundersrand it clearer.

My head changed the wording from taboo as he said It looked more like a negative instead of a positive which wasnt what I was trying to point out, I was simply trying to say hey, I know modularity is scary but it's not actually scary! Look! So my bad. Thank you!