This week Dave provides insights into some of the underpinning elements of game development and critically evaluates the role of standardisation within the games industry and how this might translate to our evolving heritage practices. If you missed his introduction post last week you can find it HERE. If you have any questions please don’t hesitate to get in touch via the blog, twitter or email. I will hand over to Dave to continue the post here, happy reading! – T


 

Standardisation is incredibly important in the games industry. Not only in the making of games but the terminology that has built up in describing systems and job roles (something I think we don’t always get right and need to work on). I want to break this down into 2 main parts… well  3, the third being genre, but I’d like to cover that in another post in more depth.

Making Games

From an art point of view, the type of standardisation in terms of making games. This could do with naming convention of textures e.g.

  • BrickSmallRed_d
  • BrickSmallRed_n
  • BrickSmallRed_g

 

Here, is an example of a naming convention that I’ve used on one of my games.  As you can imagine, when a game gets released to the public, it more than likely will have hundreds of textures, so the idea is for artists to quickly find and identify textures just by looking at the name. This can also help when it comes to bug fixing. Maybe the game is “framing out” or in layman’s terms running really slowly. A decision could be made that all the brick textures need to be reduced in size. This is when the naming convention would come in handy for a programmer or technical artist to quickly group the textures and make the necessary changes.

Of course, every game I’ve worked on there are always discrepancies….for example if a texture has brick and stone elements, how do you name it? The logical thing to do would be to call it: BrickStoneSmallRed_d but if you times that by the hundreds, then the simplistic naming convention can get out of hand very easily.

The postfix i.e. the _d, _n, _g represents the TYPE of texture, in this case the diffuse, normal and gloss.

So a diffuse would be the color map, the normal represents the “bumpiness” of the surface and the gloss is how “shiny” a surface is. The game engine is programmed as to recognise what type of texture it’s dealing with and react accordingly

Now this changes from project to project (not all follow the above convention)  but it does seem the standard these days to have some kind of postfix.

Sometimes the game engine has its own rules.  In Cryengine, if you don’t put a model in a specific folder with the correct naming convention, it simply won’t show up in the editor.

The game engines I’ve been involved with whilst in the industry have been written in-house by the programmers. Sometimes, you’ll get a really random rule (if I remember rightly, one programmer came up with an ai mesh navigation system whereby all the polygons HAD to be planar. If they weren’t, it simply wouldn’t even export. )

 

Terminology

I think this is where we do fall down sometimes.  Having worked for three different companies, it still surprises me how the terminology does change from company to company.

As an example there’s a type of texture where an artist effectively “unfolds” the model and makes a texture from those “unfolded” elements. The best way of describing it is like cutting a shirt up and laying it flat thus making a 3d shape into a 2d shape

In game engine terms, it’s an efficient way of working. This is what an example of one looks like (Screenshot from Substance Painter)

substance

 

Now my first company called it a crop sheet….makes sense. When I went onto another company, I just got blank looks when I started talking about crop sheets. No one had ever heard of it. They called it a UV map. The owness is for me to adapt to THEIR terminology. Problem is I’ve also heard it be called an atlas texture and a texture sheet too.  All valid of course but if the industry could settle on one term would just be more efficient, save confusion and also help with non-game makers (that’s you)

The same applies for job roles. Sometime, no two titles across game companies are the same.

Example:

Tara Games

  • Lead Environment artist:
  • Management experience, planning, hands off role, work with art director

 

McD Games

  • Lead Environment Artist:
  • Tech based, R&D driven. Hands on

 

It is surprising to me when incredibly talented ex-work colleagues can’t get the same job title at another company. Again, this is something that frustrates me and ideally needs to be rectified somehow within our industry.

The Moral of the Story

So why talk about all this, we’re heritage people right?… well, yes, but if you’re going to take gaming seriously in terms of engaging with the games industry, then you need to understand a certain level of terminology. Now before you panic, of course no one is expecting you to know everything, but a basic grasp will always be better than no grasp. Likewise the games industry will need to know certain terminology from heritage (I’ve already asked Tara re: meaning of some terms already) basically we need to learn from each other if we’re to collaborate…again, I stress, only needs to be incredibly basic but will help.

 

Lastly, heritage will also need to create its OWN terminology especially if it does go down the path of videogames. It’s only natural that when 2 entities meet a “new” entity is born, one that will share its DNA from its parents but also develop its own understanding and language. It’s important to recognise this and to learn lessons about getting terminology and standards/ correct and to ensure that they’re the same EVERYWHERE.