I am a graphic design student in a game design program. During the first 10 weeks of our second semester in the program; Spring 2017, game design students are assigned to develop a game in an academic process as a group project where the game to be built is based on a concept created by another group during the previous semester. Each team consists of graphic and game designers, programmers, and project managers, all using Scrum as a management method, and dividing their product backlog into Sprints of 1 week each.
The game concept my team chose to develop was “The Revenge of Teddy”; a concept based on the theme “Fall”, and is about the school nightmare of a young boy where the player plays as the kid falling into his dreams and fighting his own fears.
My task for the first Sprint was to create a background that contributes to the aesthetics of the game in conveying the feel of falling and the darkness of the nightmare. I was inspired by the background concept art presented in the concept document for the game, but all I had was one picture where all the elements were merged and it was hard to break them down especially color-wise. I tried to create a similar background using similar colors with similar values but it seemed to be time consuming and the results were not satisfying. So, I contacted the art director of the team who worked on the concept for “The Revenge of Teddy” and asked to have the Photoshop file of the background in order to properly break down the components of that brilliant work. Everything seemed to be just right and I was starting to get a picture of how the background works and what modification I can make in order to fit the game criteria and goals, we, in our team, set to achieve.
However, before the design and modification stage, testing what I already have in the game engine seemed to be convenient since the rendering and behavior differs from one program to another. The graphical work is mainly done on Photoshop or any other digital drawing tool, while the game making is done in game engines and, in our case, we are using Unity.
I saved the layers of the original background PSD file to separate PNG files, and added them to the assets folder of the game project in Unity. I then created a prefab for each asset and gave them the same layer order they had in the PSD file. I was expecting it to be that simple, that in the next few minutes I’ll be working on the new background of my own style, and that there was no actual need for the testing. Well, the result was far from being satisfying. Instead of having a dark environment in a dream world, I was looking at intensively bright picture under water as presented in Fig1-3. The transparency was almost gone, the dark values were absent, the colors were bright and different, and the objects were barely observable.
I went back to Photoshop, and started experimenting with the colors and transparency, adding and removing layers, and rendering every step in Unity. I even made 3 color versions of the background; green, blue, and purple, as shown in Fig4-6, to test the transition from one color to another by implementing a scrolling layer of the theme color on top of all the other frames for several stages of the gameplay… It was a bad idea since the colors were either overlapping or presenting a noticeable gap between the layers when scrolling. Then the programmer I was working with to test and modify scripts for the parallax effect that was planned for the next sprint, discovered a way in Unity that makes automatic color transition by gradually rendering all the values on the color wheel positioned between 2 selected colors; for example, if the chosen colors are red and green, the color travels from red through all the degrees of orange and yellow, reaching the selected green color, and maintaining the same opacity. The process was as follows; I copied the RGB and alpha values of the 3 theme colors in Photoshop, and used the numbers to obtain the same colors in Unity. The results were more satisfying than the previous ones but still in a lower degree of quality than expected. So, as a final stage of the background color design, we had to manually adjust the colors in Unity with the trial and error technique until we reached the current results, shown in Fig7, that fit the game aesthetic goals previously mentioned.
The main problem we encountered during the background concept was the transfer of the artwork from a digital drawing program to a game engine. The reason behind the problem was that colors and many other properties are differently rendered and displayed in different programs, which means not all that applies in one program, necessarily applies in the other even if the transfer is based on numerical values as reference.
Many other ways could have been used to handle such problem, but they require to give away some of the visual values, while the game visual aspects and the game atmosphere related to the aesthetics and game feel, are beyond important; they represent a huge part of the MDA framework, are essential in the game production, and they’re the major interest for the graphic designer responsible of the game visuals that contribute to the Aesthetic goals set for the project.