Style-guide and pre-production
|
As many groups chose to develop the Behemoth concept, we felt pushed to do something different, add personality to it. We wanted to have a good answer for the question “What does your Behemoth game has that others don’t?”. Plot and art style depend on each other in our concept, because they were born together.
After deciding the plot and art-style, the latter being low-poly/origami with a sunset-like colour palette, the artists could focus on conveying as much as the story and concept as we could, boosting the mood and environment to the same extent. This also gave more space for mechanics to be added and for our programmer to mess with stuff and have fun with it!
Making the style-guide involved a lot of research and hours of looking for inspiration. Before presenting the theme/style to our group, I wanted to make sure that it was doable and conceivable, and that it made sense visually with a top down perspective, so I made several sketches and rough tests in photoshop. Maybe some time gets invested in an idea that might not be approved, but in my opinion this is better than diving into a project without having any testing or not even vague ideas about core elements. For example, I trusted we would have lectures on animation in relation to unity (otherwise I would’ve chosen a different style) and that’s giving us a lot of trouble that could’ve been avoided. And regarding the theme of our game, I didn’t want to hype them with the concept to realise afterwards that it was something we couldn’t carry out as artists in the time frame given. Finding the Dmesh software made up my mind. I’ll talk more in depth about the software and asset creation on my next post.
The ProcessWhen the group has a definitive idea, the next step for an artist consists of sketching everything you have on your mind, put in on paper.
Testing, testing and more testingAsking for opinions is vital. It is also vital for me to test constantly, see what fits best to what you’re trying to do. In my case, I need some kind of preview of how it would look like as a whole. I might love one of my designs, but if it looks awful on-screen, it doesn’t work. Testing avoids so many problems…! Although usually testing is focused on programming and game design, it’s crucial to visual design too.
We needed a colossal majestic creature, threatening because of its enormous size, but with a non-violent nature. We choose the one with less aggressive but still powerful shapes, and the one in which could also put the cannon on top of it making some sense.
 The behemoth mockup test had to be representative enough of the final art to check that it worked well with the rest of the scene. A common mistake (which I’ve made) is making separate assets without considering the whole vision of the design. Everything needs to fit together in order to avoid dissonant elements.
The first Behemoth design had the perfect shape (according to surveys!), but it was too long (mostly the head, which had no practical function whatsoever) and it occupied 1/3 of the screen because of where the axis for the cannon was positioned in the design, so it needed a change. Fortunately, it was just a low-quality mockup! Something similar happened to the early enemy ships design; they were too similar in shapes to the behemoth, it was hard identifying them as different and foreign (to the behemoth) because they also had sea-creature inspired shapes.
In the next post I’ll talk about Dmesh and how it’s used to make the assets base.  |
