Dev Blog #7: From 2D to 3D – An Artist’s Perspective

Following up from Rohan’s previous post on moving from the 2D prototype through to the 3D game we have now, Matt talks about the challenges of completely retooling the games graphics.

Bridge_old
The original mockup for the bridge of the Ceres class freighter.

While Rohan was facing the imposing task of hand coding every interface in each of the ships, I’d begun to realise that the task of building the graphics for each of the ships was going to be equally monumental.

Each room of each ship required several hand drawn versions, clean, dirty, damaged and a plethora of switches, each with their own set of states. With Photoshop, the task of producing each state wasn’t particularly difficult in and of itself, but it did require a fair amount of patience and organisation to maintain. It was when requests to modify small sections of the rooms came in that the whole thing started to get complicated. It meant reworking all states of the rooms to accommodate any of the little pixel by pixel changes that I’d made.

Bridge_prototype
The bridge after Objects in Space first began production in 2D

A large amount of game development is about iteration, being able to quickly and decisively make changes to features, visual or mechanical. The hard coded, completely hand drawn aesthetic that we’d gone for looked beautiful, but were impossible to iterate on in a timely manner.

And thus we decided to once more take on Cocos2D-X’s 3D technology – like we’d partly done with Metrocide.

Bridge_new
The helm of the Ceres as it exists today.

The jump from 2D to 3D was a welcome challenge. It would give us a great deal of freedom in terms of reused assets, but would also add a lot of complexity to the pipeline.

We really liked the look of the 2D prototype. The, pixelated, low resolution images really brought something interesting and thematically relevant to the table. With that in mind, we chose to do an initial pass of modelling using low resolution, highly pixelated textures combined with lowpoly geometry.

There’s some really easy tricks to make this kind of style work, having super low resolution texture (32×32 up to 256×256) set to filter by nearest neighbour in engine will immediately give that chunky pixelated look. Generally keeping edge normals set to hard, ensuring to emphasise edges in textures and really just cutting the polycount wherever possible all lead to this low-fi look.

The hard part, (at least for me) is keeping texture density the same across a scene. Each “pixel” on a meshes texture needs to be not just square, but also the same size as every other pixel viewable to the player. So long as meshes are relatively cubic, this isn’t such a problem, but in any asset that’s curved, we start having to produce bespoke texture maps ( as opposed to texture atlases). Doing this often requires just that little bit more time as texture resolutions need to be matched, a time consuming and frustrating process.

Crew_Old

Crew_new
The change to 3D really added a great deal of depth to the environments. Get it?

 The end result, whilst not identical to the original prototypes, definitely gives a sense of the atmosphere that the original prototype had.

Of course no challenge would be without its difficulties, Anyone reading this should probably have a good idea of most of the popular 3D game development engines out there, Unity, Unreal, Crytek, so on and so forth. Cocos is most certainly not one of them. From a developer’s perspective, it’s lightweight and fast, from an artist’s perspective it’s… difficult.

It’s mostly little things, like the lack of screen space shaders, a clunky animation system and a restrictive forward renderer. For the most part, we find ways around these technical hitches, and it’s not a huge issue, but every now and then we’ll hit significant walls that force us to rethink a visual feature or two.

One of the toughest parts though is that there’s no editor GUI to speak of, everything has to be implemented from scratch, including the model import process. Rohan’s done a great job with what’s available, but not having the ability to edit simple properties such as textures and tint colours or a click and drag interface for positioning assets can be a downright pain some days. Unfortunately, these sort of niceties take a long time to develop, longer than we really have time for.

Beyond those difficulties, it’s actually nice to be working to a limited capacity, to have some serious restrictions placed on the art pipeline. The restrictions placed by the engine usually lead to some fascinatingly creative solutions to the issues that crop up.

Fortunately Cocos2D-X has recently started to back their 3D tech in a really serious way, adding elements such as materials, 3D physics and navmesh into the library of tools available for developers, even multiple light sources! While most of these new features are in beta, it’s great to see them adding to the repertoire of tools available for artists.

There’s a ton of benefits to working in this manner, ranging from being able to rapidly iterate on designs (far faster than we could with the 2D images) through to the ability to reuse assets in interesting and unique ways.

Reactor_prototypeFor example, you can see the original 2D pixel art version of the reactor room (right), there are some really nice nuanced elements at play, like the lights and their fall of bouncing around the room.

Rector_firstPassAnd here (right again), we can see the first iteration of the rector room, one of the rare instances where the 2D prototype’s visual layout didn’t translate quite so well into 3D.

After a couple attempts at getting this aesthetic to work, I decided to scale things up a little, built some modular reactor pieces, and some wires, and ended up with this:

Reactor_new

The whole process from re-design to ready took less than five hours.

Another great example is the power room. While the original certainly had something going for it, the 3D version feels far more claustrophobic, kind of like you’re locked away in a server room somewhere and less like something you might find on the Death Star.

Power_prototype

Power_new

As always, an artist’s work is never done, there’s always some element here or there that I’d like to fix, modify or outright replace.