Going Gold

We’ve come to the part of the development cycle that no artist ever enjoys: the gold-stamping process. What is this mysterious “gold-stamping?” Why do artists despise it so? You thought it was just fixing bugs and making small tweaks, didn’t you? Well, read on to find out…

 

You’re reading the development blog for Where Shadows Slumber, a puzzle game coming to iOS and Android later this year. Check out our free Demo here.


 

 

LevelProgress.JPG

Gold Stamping: The Point of No Return

Every project must come to an end eventually. In order to make sure your game is ready for the whole world to see, every piece of it must be tested individually. Then, the entire game has to be tested as one unit. Before we can move on to that final testing phase, every Level, Cutscene, and Menu in the game needs to be approved by three teams: Art, Sound, and Development.

The Art team is just me – and the Development team is just Jack. Alba and Noah work on Sound together. That means we need three approvals for each Level, Cutscene and Menu. Approval means “I’m done working on this Level forever – there is absolutely nothing left to do. Put it in the game.” (See the screenshot above for a look at our spreadsheet that has each Level listed as well as the “Gold” stamps)

There’s a specific order we have to do this in, as well. I need to put my “Gold Stamp of Approval” on Levels before Sound does, because I’m in charge of the game’s visuals. If I add a blazing torch to a Level after Sound has “gold-stamped” that Level, they’ll need to come back and give that torch some kind of looping audio. Art and Sound need to gold-stamp the Level before Jack takes over, because he’s duplicating each Level in the game into a separate file and running an optimization process on that Level.

This optimization process takes time, and destroys the editability of the scene. (By way of analogy, consider what happens to a Photoshop file when you Flatten it into a JPG file. The JPG takes up less space on your computer, but you lose the editable Layers from Photoshop) Jack is able to lower the time it takes your phone to render a frame of the game by “crunching” these Levels. If your phone can render a frame faster, the game will feel smoother. Players hate lag more than they hate bad graphics or design, because it interrupts the flow of play. Everything we’re doing now is to make the game run smoothly even on older devices.

But you can see the problem: if Art or Sound has to tell Jack that they made changes to a Level, one of two things happen:

(a) We need to make that change in both the original Scene and the crunched Scene

(b) OR… Jack needs to start the optimization process for that Scene over again

Option A introduces the possibility of human error. Have you ever made a mistake copying something down by hand over to another sheet of paper? Imagine that with a bunch of tiny numbers and sliders in Unity! Unfortunately, Option B wastes time we don’t have. And since “crunching” makes these Levels unable to easily edit, there is no Option C.

In the late stages of the project, we’re in a mad dash to finish each Level and hand them off to Jack. We’re a bit on top of each other at the moment, and tensions are high. Some of our beloved changes won’t make it into the first release of the game and may have to be stealthily added as a patch later on. (Shhhh don’t tell anyone I said that, blog reader)

Those are all the downsides of gold-stamping. Enough complaining: let’s talk about why this process makes the game so much better!

 

HowEmbarrassing.png

iPhone X Stretching

We began working on this game long before the iPhone X was announced. Since we designed the game in portrait mode, we planned for it to work in 9:16 resolutions as well as 3:4 resolutions. The plan was simple: we would assume you had the tiniest screen there was (9:16) and make sure you could solve the puzzle using everything you saw. And then, if you had a large screen, your screen would show more of the artwork surrounding the puzzle… but not any more key information. (Our demo works this way. Download it for free on a few devices to see what I mean.)

The iPhone X dashed our hopes when it launched, since it has a very thin and tall screen. When we booted it up on an iPhone X earlier this year for the first time, we noticed that key puzzle information was being cut off! Furthermore, there were sections above and below the Scene that I never planned for human eyes to see. We had to fill those sections in with art, or iPhone X users would know the game wasn’t made for them.

Here’s another analogy: imagine if you were designing the set for a Broadway musical. You do all your work, and then a week before opening night your director comes to you and says: “Listen, we’re lowering the stage by 2 feet and extending the ceiling by 2 feet above the stage. Do you think your set will still look good?”

The correct answer is: “yes, but I need to extend the artwork so it doesn’t cut off!” It’s ok if your art bleeds over into a section that human eyes will never see. But you can’t have your screen bleed over into artwork that isn’t finished or cuts off arbitrarily!

Fortunately, Jack solved our width problem by writing a Camera Resizing script that adjusts the Orthographic camera size to the proper width depending on your hardware. (Thank God for Jack, lol. Just that script alone would take me the full 3 years we spent working on this game to complete) I am solving our height problem by extending the shadowy silhouettes on each Level where appropriate, and adding more art where it’s necessary.

 

TooManyVerts.JPG

Low Poly Means Low Poly

When you set out to make a low-poly game, you aren’t just deciding on an art style. You’re also setting boundaries for how much the game will need to handle. This is why you’ll see a lot of cartoony artwork on mobile games and MMOs. Both of those are situations where you want the game to run on low end devices like old phones (mobile games) or old computers (MMOs). Cartoony graphics let you show what you want without having high-resolution textures or incredibly detailed model topology. It isn’t just an artistic decision – it’s also a marketing, business, and programming decision.

However, just because I said that I would do low-poly art doesn’t mean I kept my promise. There are a lot of Levels that go wildly above our Triangle / Vertex budget. (See the screenshot above, with emphasis on the Tris and Verts) Unity counts the number of Tris and Verts that are displaying on the screen at one time. Jack wants us to be well under 100k of each. That may sound like a high number, but you’d be surprised by how even simple scenes can skyrocket to 150k. When he finds Levels that are egregiously “over-budget,” he sends them over to me so I can make reductions.

Fortunately, Tri / Vert budgets are not like monetary budgets. If Jack told me not to spend $100,000 dollars, and then I bought a yacht, we’d be $100K in the hole. (But, we’d have a boat. Jack, I urge you to reconsider this proposal.) With polygons, as long as I cut down on fatty models before the game launches, no one will ever know. Except for the readers of this blog, of course. But you’re sworn to secrecy! Don’t share this post.

There is one more thing about this I discovered: Unity’s lighting system counts polygons in a very strange way. You can’t always trust their readout. I discovered that multiple lights require Unity to count the same object multiple times. If a cube has 8 Verts and one light is lighting it up, Unity will show 8 Verts. If there are six lights on it, Unity will show 48 Verts. So there’s some Levels that Jack will reduce once he does his big crunch, since he rewrote how our Lights will work to make them all act as one super-Light. (More wizardry, I’m sure.)

We’re doing all we can to make the game run fast on your phone. If it’s still lagging, get a new phone!

 

TextureAtlas.png

File Formats and Compression

This is the kind of boring stuff that puts artists to sleep, but it’s important. Unity imports textures, models, and audio files according to a standard. You can set the standard somewhere, but we never did. Instead, I am going through every file in the game and asking the had question: does this really need to be as large as it is?

The answer is usually “no!” which is good. I’m crunching a lot of textures down from 1024 x 1024 to 32 x 32 pixels, Unity’s smallest maximum size for images. Noah and Alba also did a bunch of audio crunching that I can’t really explain properly. You’ll have to wait for their revealing tell-all novella (Where Shadows Is Grongus: Nightmare Stories From Development Hell) for all the juicy secrets!

One more thing about textures: it might not be super necessary for me to make these textures smaller after all. Jack is actually doing this crazy optimization thing where we have every texture on one big image called a Texture Atlas. This image is as small as I can make it and has every texture in it laid out like a grid. We have one of these for every Scene in the game (Levels and Cutscenes) and when the game wants to render an object that uses a texture, it’s going to go to this image and pick from the proper coordinates.

This is insane and Jack explained it to me once and it’s insane and I’m sure it will make the game run super fast. If I’m remembering correctly, Jack told me that the rendering system needs to pause and switch gears every time it has to render a new Material. (So if the grass is GreenMaterial and the tree is TreeMaterial, the renderer needs to pause and switch) If it never has to switch like that, the rendering process should go way faster. The way to do that is to make one Material with the Level specific Texture Atlas called “Scene-0-2-Atlas” or something and put that on each object with the right coordinates. We’ll have fewer batches to render, and you’ll never even know what’s going on under the hood!

I’m going to stop giving the layman’s explanation here before I embarrass myself by showing my limited knowledge. But look forward to Jack’s upcoming tell-all blogella (Life With Frank: The Man Who Knew Nothing) for all the juicy secrets!

 

rubber stamp APPROVED

See You In Hell

This is going to be a rough week. This lengthy process is taking longer than I would have liked, and I’ve been pulled away from animating the final cutscenes. I desperately want to get back on track so Alba and Noah have enough time to work on the audio score for the final cutscenes.

Thanks for reading this blog post – I have to get back to gold-stamping!

 

 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

We hope you enjoyed this update about the game’s development. Have a question about aesthetics that wasn’t mentioned here? You can find out more about our game at WhereShadowsSlumber.com, ask us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, and feel free to email us directly at contact@GameRevenant.com.

Frank DiCola is the founder of Game Revenant and the artist for Where Shadows Slumber.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s