Cross-discipline communication

No matter how hard we try, important details are often lost in translation from one dev team member to another. This is why it is often important to go back and confirm that what we think we told the other person is exactly what they not only heard, but understood. This is often necessary because producers, designers, artists, and programmers all tend to speak in slightly different languages; what a designer means by a certain term is not always what an artist or a programmer means.

Case in point: One of the projects we are currently developing is turning TSR's 1979 fantasy wargame, Divine Right, into a computer game. I told the lead artist, whose first task is recreating the 1979 Divine Right map, that we were going to be using the standard 4k resolution of 3840x2160 for the game. This will, to a certain extent, future-proof the game, and allow for a very nice wargaming experience for those with big, high-resolution UHD screens. What I meant is that 3840x2160 would be the base resolution for the game art; anytime a game is being developed, everyone has to know what the base graphic standard is, whether it is MCGA (320x200, 256 colors) to 4k (3840x2160, 16.7 million colors).

However, what the artist heard is that the map should be 3840x2160. In order to fit those parameters, he had to horizontally squash the hexagons, which produced the compressed effect that can be seen below.

That's not his fault, as this is one of his first game development jobs, and therefore I should have remembered that he does not yet speak the same dev language that a more experienced game artist does. We were talking about a map, a map is defined by a specific resolution, and a specific resolution was specified. It was perfectly sensible for him to create the map at the resolution specified, and he did a very nice job of it. The fault, and the responsibility for the error, was all mine. 

However, one core game development principle is that one should never be afraid of making mistakes, identifying mistakes, or admitting makes, but rather, one should address them as quickly as possible. Even more important is to prepare for the eventuality that a mistake will need to be corrected, so always work in a way that allows for maximum future flexibility. Fortunately, the artist did that by choosing to create the original map in vector graphics, which meant that it could be easily resized; it was literally a matter of minutes before he sent over the revised map below, with the hexagons no longer compressed.

The number of hexes is still the same, the hex height is still equal to the vertical resolution,, but the width no longer fills the horizontal resolution, which leaves screen space for the monarch personality cards and other UI elements. The text needs to be redone, but that is a relatively minor task; the important thing is that nothing needed to be redrawn. This is a good example of a problem caused by a communication error that is promptly fixed by smart development processes combined with continuous communications.

Frequent and open communication is the key to quickly identifying and correcting problems. Don't ever allow yourself to avoid communicating with your team or go dark for fear that you're doing, or have done, something wrong; that is the best way to ensure that whatever issues you've got are going to get worse and become serious problems. If you're not sure something is right, or if you're starting to suspect something might be wrong, don't hesitate to look into it and talk about it.