Did much work need to be rejected?
We wanted to make sure we weren’t rejecting too much polished work needlessly. So we had artists send us progress images of their work. In most cases, we could make our selections and rejections early. We rejected less than 20% of the cards.
There were a few finished cards, though, that just weren’t working.
They might have looked alright at a distance, perhaps in peripheral vision, covered by a gauze of coffee steam. But on close inspection they weren’t up to scratch. All of our artists produced good work, but on occasion, as everyone experiences, the inspiration and execution are not in alignment.
What we wanted was something that could hold a candle to the Magic: The Gathering artworks, so we kept our standards as high as we could afford with the time and budget.
It was a very very intensive work period, but we’re really happy with how things turned out.
The final board.
The board has been through different iterations, how did you get to the final product?
Jordan and Marcin decided it needed to be something more advanced than what we had, although everyone wanted a change and to also have an actual physical board made.
Our first board was good to help us visualise the game – but we wanted something with more grit, more originality and more maturity. This isn’t long after we brought Rick in for our coding & development and he had valuable inputs.
Marcin, Jordan and Rick were instrumental in guiding me through the iterations conveying to me the technical needs of the game. How it might run in the Unreal engine, the amount of screen space needed for other elements, and how fast it could run on a typical PC were all things to consider in the design.
The original design solidified our desire to have the board appear to be a real object. Something that *could* exist and be touched if only it were real. I flared out the corners of the board to add a bit of drama to the geometry.
I had also begun to realise Marcin’s suggestion to represent each zone of the world as corners of the board. There, the potential exists to have each environment reactive to the current state of the game. Maybe the volcano mounts with tension as more fire energy is collected. That’s an idea for the future, but not a priority to implement at the moment.
To be honest, the biggest challenge with this board has been to make something aesthetically pleasing, thematically relevant, but which also has room for all the necessary elements on the board. It all has to be visible and readable. The four corners of the board were so obtrusive and strangely shaped, I had to trim them down several times.
You need the 10 gems, the avatar, everything has to be big enough but not be too close to something else.
One small example is the energies. Representing the value with a number was just taking up too much space, and looked awkward. Both the numbers and the symbols were too small. We ended up developing a light system which solved both problems.
Another example is the geyser on the archipelago. I had experimented with water simulations, but it all just looked like it didn’t belong on a physical board. My solution was to make all four corners of the board look as though it were made from wood. I used a low-poly modifier and a carved wood shader. This made the elements visually consistent, and allowed me to represent fluid without introducing things to the board that looked out of place.
The lower overall poly count of the board was a bonus for me. (less laggy)
Another issue I was having was with the Perspective camera. This just means that the camera portrays perspective naturally, with things getting smaller the further away they are. This was great for the environments, cause it let us have an angled view to see them clearly. The issue was that it wasn’t utilizing screen real estate properly- elements that were designed to be a certain size would be too small on the opponent’s side. So, I ended up using an ‘orthographic’ camera, which flattens out perspective completely (so things stay the same size, regardless of distance). This way, I could tilt the board to get a view of the environments, without squishing the opponent’s side.
The board + visual is built in Blender, a 3D development software. As far as how this translates to the Unreal Engine, it’s actually going to utilise flat image renders of the board. This will minimise system requirements, improve loading time and give us more flexibility with our designs.
The animated sections of the board are exported from Blender as PNG sequences, cropped down, and placed over the original board image. Rick has coded the cards themselves to be 3d object inside of Unreal that will sit on top of the board image, calling upon pre-made 3d animations when needed, in order to react to events in the game.
A lot of back end code stuff takes a very long time to make the game look like the game, until that time there’s a lot of ‘placeholder assets’. For example before you have a game where you have cards flying, you’re more likely to have a game where cards just teleport, until the build of the game is stable enough to start linking in the animations themselves.
You need all kinds of weird codes that count all the cards, excluding some cards and only actioning others. Rick’s spent a lot of time developing back end code, getting the game to look like what it’s meant to look like.
