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.
Case in point: 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. This will, to a certain extent, future-proof the game, and allow for a very nice wargaming experience for those with big, high-resolution 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 to the right.
That's not his fault, as I knew that he is a DevGame attendee and therefore should have remembered that he does not yet speak the same dev language that a more experienced game developer does. We were talking about a map, a map is defined by a specific resolution, and a specific resolution was selected. 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, the responsibility for the error, was all mine.
Fortunately, one of the things we also teach in DevGame is the concept that one should never be afraid of making mistakes or correcting them, but rather 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. The artist did that by choosing to create the basic 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, the hexagons no longer compressed.
The number of hexes is still the same, the height is still equal to the vertical resolution,, but the width no longer fills the horizontal resolution, which will leave space for 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 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, if you're starting to suspect something might be wrong, don't hesitate to look into it and talk about it.
Elveteka takes less than 10 minutes to play through and has to date produced 551 emails in my inbox.
ReplyDeleteAnd I joined the project halfway through.
At that volume answering an email within 24 hours is SLOW.