Lessons learned in game art production - Part I
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
From April 2017 through March 2018 I had the opportunity to work on the art team of two VR titles by Black River Studios (BRS). This article is an attempt to sum up my experience. I tried to keep it not too technical or over detailed so everyone may learn a thing or two.
This is part I and it deals with the production experience I had in Conflict0: Shattered. As soon as part II is published, I’ll update this article with a link.
*EDIT.: You can find part II here: http://www.gamasutra.com/blogs/RicardoBess/20181029/329489/Lessons_learned_in_game_art_production__Part_II.php
We had a rough start, I was new in the company and we had tried to figure out the looks of the game, but since we didn't have a straight understanding of the game - game designers were having a hard time figuring out what the game was about - it was hard to evaluate what we were achieving (not to say the stylized approach to art I was proposing was not pleasing many of the team members).
By then, we had developed a simple scene to have a look on what the game would look like and a not much successful proof of concept.
Image 1 - Some of the visual development created by the whole art team
Right after this delivery we had a major time cut in our schedule. We had around 3 months to deliver the final product.
How we handled
Knowing that we had to be extra efficient I asked the game designers for a “script” of what would happen in the game. After some days they presented a diagram similar to the one bellow.
Image 2 - diagram showing the game flow
It wasn't very detailed, but it was enough to start visualizing the game.
In the next day I drew the following “beat board” illustrating the main moments of the game. After checking with the game designers if that would suffice their vision I asked the art team to scrutinize it with the diagram.
This way everyone (3d modelers, animators, UI/UX designers, tech artists and FX artists) could figure out what they had to do and how they could improve that vision. I kept the simple low poly style I was going for before, but I added a few visual elements which would make the art style a little more digestible for the team.
Image 3 - the beat board
This pack of images was good and it helped making the game start to be a little more “real” for the art team. This way tech artists could start thinking about the tools we’d need, UI designers could start thinking about the communication with the player and so on.
I asked for the 3D modeler to block as fast as he could the assets we would need. In a couple of days he delivered the blocked 3D assets and I set down with one of the game designers to make the level design. As he laid the assets on the scene I made sure to ask what he was trying to achieve with his asset compositions. After we designed half the level together, I went to my computer and made a second pass on all the level design we made, looking for more pleasing and entertaining compositions (always respecting the intentions established by him).
Since at the time I didn't have a VR headset to test the level design, I managed to use a work around process. The game locomotion was based on waypoints (to avoid motion sickness). So I managed to use this waypoints positions as cameras to check the level design. Though it was still a flat screen, it was the most precise way I had to be exactly in the player viewpoint.
In this way we avoided a problem faced during the proof of concept when game designers layouted the levels alone and, though this freed the artists to work on other things, it made the levels lack in appeal and staging.
We went in this process till we had all the outdoor part of the level blocked. At this time the project tech artist, made a “lighting first pass” looking to achieve the overall mood indicated at the beat board.
Image 4 - Some examples of the lighting first pass
Since the beat board was made of rough-quality, bidimensional images and the game was a VR title (360° first person) we had space for improvement. So I took some 360° panorama screenshots from the lighting first-pass and painted over concept art images for some of the key places.
Image 5 - some of the painted 360° panorama screenshots
From that on it was more a matter of daily production - figuring out what could be added to improve the game (searchlights, rain, droplets of water, etc) and QA (looking for lightmap issues, missing polygons, etc) - and constant iteration.
- It’s OK to change the core of the game, but never lose sight of what the stakeholders are expecting from the final product. Always plan to make a game whose production fits the time you have. Maybe you just don’t have the resources you need to make the masterpiece you want to.
- I didn't expect the art team would react so negatively to the art I was proposing. I tried to show top industry artists as reference, I was looking for fast producing assets and pipelines and yet almost everyone was turning their noses up. It’s essential to spend some time knowing the team before getting into production.
- Make sure everybody can visualize the end product (especially those directly involved with the end look of the game). This gives a goal and when the team knows what has to be done, they can spend their time doing it.
- Try to discover what is preventing people from doing their work and fix it (even if it is not your job to do so). Sometimes designers don’t feel comfortable working in the game engine, so be their hands. Sometimes 3D artists need an asset list of what has to be modeled, so take 15 minutes and make a list for them.
- Production time cuts and team members being reallocated to other projects are problems. Most of the time you can’t do anything but cut content to make deadlines attainable.
This sums up my experience in this project and though we had a lot to deal during production, the lessons learned were valuable.
Stay tuned for soon I’ll post part II.