Hell Week

Jack and I first met in a sketch comedy group in college back in 2010. In that group, and in theater troupes around the globe, the week before opening night is usually referred to as “Hell Week.” For big productions, some things can only really be done at the last minute. (Lights, sound, final props, rehearsing on a real stage instead of a temporary space, catering) That means the final week before “showtime” is often spent running around like crazy doing a bunch of little tiny things that have been put off until now.

Is it procrastination? Is it just how this always goes? Who knows! Jack and I have only ever done this once before, years ago, when we released SkyRunner on Google Play and the App Store. (It has since been removed from the App Store because we let the Jack and Frank’s Magical Cruiseline Developer License lapse. Whoops!) Back then, things were much more relaxed. No one was really anticipating our fledgling student project. And we were fairly certain it was never going to go anywhere – we were just proud to make a game. We built it on a Saturday, hit submit, and never looked back.

This time around, things are different. There are a lot of moving parts to game development. Everything starts off cool and slow when you’re first testing out an idea. Then, international partners become involved, and a real schedule is expected of you. For the past few months, we’ve been emailing Apple saying “don’t worry, it’s coming, we just need more time!” This past week, we made good on the most recent roadmap we sent them.

Early this morning, we submitted Where Shadows Slumber to the App Store for review!

To celebrate, let’s explore what Hell Week looks like for a small team of distributed indies collaborating online to finish a game…

 

HellWeek-OptimizedLevel

A Week Full of “Do It Later” Tasks

I must admit that I’m a severe procrastinator. My skill is to take something (like, say, a cutscene) and do a really great 80% job on it. Then, because there’s no one watching me to tell me to finish it, I’ll go: “Cool! Looking good. I’ll finish that later.”

As it turns out, the week before you build your game for the last time is what experts commonly refer to as later. This week, the tasks I put off for so long finally fell on me like a ton of bricks. I spent the majority of this week finishing the game’s remaining cutscenes as Jack optimized the game’s final Levels and cutscenes. Because my work wasn’t done, it held up his progress on optimization. For reference, optimized Levels look like the image above – they’re solid black since the lights work totally different in those Levels. That means it’s impossible for me to work in those Levels, so Jack needs to wait for me to finish my work and then duplicate the scene in Unity and optimize that. By Friday, I was finally able to get those done in time to review the text translation sent to us by Logrus IT. Jack put in the new text file and tested the game to make sure the final build worked as a cohesive whole.

Alba and Noah spent Hell Week adding the game’s final missing sounds and improving the cutscene audio. We neglected to put sounds into the game’s UI for a long time, just because there’s an unspoken rule that you do UI last because everyone forgets about it. Whoops! This is also the time to work on the “mix” – which they described to me as the audio volume of every different sound as they work in tandem together. Without this crucial polish step, sounds can crash on top of each other during gameplay. Alba and Noah worked to make them weave together smoothly.

 

HellWeek-Jack.jpg

Hell Weekend

Everything came down to the two build days – two days, Saturday and Sunday, focused entirely on testing and small changes. We were in Jack’s apartment huddled around his desktop as Alba and Noah worked fiendishly from Miami and Queens, respectively. I counted a total of over 18 hours over the course of both days spent just optimizing the game and doing a bunch of final changes! (Shout out to Jack’s fiancée and her sister for bringing us food on Saturday :D)

Like I said, some things have to wait until the end of the project before you can really do them. The weekend was spent putting in Jack’s final optimizations so the game runs smoothly on all phones. Then, those changes had to be tested on all of our iOS devices to make sure they didn’t cause other problems. I didn’t work nearly as hard as Jack did in these final hours, but it was important that I was there to give the artwork a final check. During optimization, a lot of the art rules changed: lights that used to stack on top of each other now blend smoothly together, for example. That looks awesome, but some tiny tweaks to their intensities and colors had to be made before we could ship it. That’s just one example of many little things we did over the weekend.

(Shameless plug: if you want us to come give a talk at your school, organization, or church, email me at contact@GameRevenant.com! We would love to go into more detail about how hard it is to make games!)

I don’t know if Jack knows this, but the main reason I wanted to work on games with him is because of his determination. Going into this Saturday build session, it didn’t look like we’d be able to send the game to Apple. The optimization process caused an unexpected crash on one of the game’s middle Levels, and I was pretty certain we’d need to delay internally again. But Jack never gives up, so we handled that bug, found some more, crushed them, and got everything done in time!

 

AppStoreImages.jpg

App Store Monday

Monday was another “put it all together” day, and it was technically the day Apple was expecting to receive the game. I spent all day putting our Store Listing together in iTunes Connect as Jack finished some tests and Noah and Alba worked on “mixing” the sound. Since I submitted the game early this morning at around 3:30 am EST, I guess it came in a bit late since that’s 12:30 am in California. Some things never change!

But even with all the stress, I can’t help but be astonished by what we’ve created. Look at the pictures up there, from our iTunes Connect submission. Seeing these beautiful images lined up like candies gave me a feeling of pride and accomplishment that I haven’t felt in a while! I’d totally buy this game if I saw it on the store… wouldn’t you?

At this point, our app is In Review, which means that the App Store employees are checking it for egregious errors or incompleteness. They’re strict about what they allow onto the store, but I have no worries that our app will be approved. Whether it will get promoted by Apple, or even the vaunted Editor’s Choice tag, is another story. We’re not releasing the game on iOS anytime soon, so they have plenty of time to look it over and decide amongst themselves. But the hard part is over – our game is fantastic, it’s uploaded to the App Store, and I’ve never worked so frantically before in my entire life!

This is also a long-winded way of saying you shouldn’t expect the game on Android anytime soon. Testing and perfecting for iOS took longer than we thought it would. (What else is new? LOL!) How long do you think it would take to test the game on Android while simultaneously not breaking anything we already did for iOS?

Please be patient with us! One of the coolest things about Where Shadows Slumber is that it is a labor of love created by hardworking indie developers collaborating remotely across the greater NYC area. That also means everything’s going to take a bit longer than you expect. You can send us nasty comments on Facebook about how Android owners are being treated like second class citizens, but that won’t help us make the game faster! (Besides, Jack and I both have Android phones, and we’d like the game on our devices one day too. Lighten up!)

 

20171110_204906

What’s Next?

Now, we enter an exciting new project phase. Jack and I are going down different paths now: I can only help him so much with the Android release. While he’s testing the game on tons of Android devices, I’ll help however I can with all-night testing sessions and really detailed QA reports.

But my job now is to coordinate our team’s marketing efforts and make the most of that iOS launch “bump.” We’re going to meet as a team to brainstorm ways to make the most of our upcoming release. We’re also working on a launch trailer that will make die-hard fans proud, and newcomers interested. It’s going to be epic! And yes, when the trailer launches, you will finally know our release date! Thank you for waiting so patiently.

This is the progress update I’ve been dying to write, and it’s finally here. The whole team is eager to show off the final game when it comes to iOS, and we’ll be working hard to make the Android version really awesome.

Next week, we’ll dive into our marketing efforts and the plans for our trailer. Or is it… trailers? Find out next week!

 

 

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

Thanks for reading this project update! If you’re new to this blog, 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.

State of the Art – August 2018

Welcome to the State Of The Art, August 2018 edition! This monthly progress report is written by Frank DiCola and is focused entirely on how the game’s visuals have improved in the past month.

Missed last month’s State of the Art? The July edition is right here.

 


For Our Eyes Only

A quick note, before we dive in… since this is the final State of the Art, it’s going to be a little bit underwhelming. Sorry about that! The game is so close to being finished that Jack and I don’t really want to release any more images or footage until Where Shadows Slumber is uploaded onto the App Store. In the past, journalists have accidentally used our old images of previous builds (including our 2016 Demo!) in their articles instead of new stuff. For that reason, we’re trying to put some distance between our progress related uploads and the launch of the game.

If you were lucky enough to visit us this past weekend at Play NYC, you got a chance to play the final pre-release build of the game! As you would have seen, all of the art is totally done with the exception of a few cutscenes that need some polish. We brought a build that had every Level and Cutscene in the game, so we got a chance to see people play every part of the finished build. Two brave souls even dedicated a few hours (across both days) to finishing the entire game! So even though there are no new images in this article, rest assured that this is a good sign of progress, and not a bad sign that I’ve been sitting on my hands the past 6 weeks!

Thank you so much for following this blog, and I apologize for the lack of juicy spoiler images. You’ll have to wait until the game launches on iOS and Android later this year to feast your eyes on the beauty that is Where Shadows Slumber. Until then, enjoy these sweet black rectangles!

 

 

Black

Art, Then and Now

The last State of the Art was written on July 3rd. At the time, the only pieces of art left to do were the game’s last four cutscenes – World 5, World 6, World 7, and an animated Credits sequence. Small artistic touch-ups were needed across the game’s many Levels, as well as a few art related bugs.

Those last four cutscenes are all nearly complete. I say nearly because, since time is of the essence, I animated them just far enough so that our wonderful audio team could take over and begin creating sound effects. Today, in an effort to finally finish the game, I’ll put the last little details into these scenes. These details include things like snowy footprints or rustling trees – background information that isn’t necessary, but helps to paint a better picture of the scene. I know Jack is eager to crunch every Level and Cutscene so we can have a fully 100% optimized game, so right now it’s more important to call these scenes done than to obsess over the details. I shall spend not one more day on them!

Other than that, there are some release prep things I still need to do. I try to focus on tasks that involve other people first, which means I put off some solo projects like the game’s app icon, app preview video, press kit, and our release date announcement trailer. We’re not announcing our release date yet, but [spoiler] when we do it will be in the form of a cool trailer! We’ve heard that’s the best way to generate buzz for the game. Hopefully our efforts these past 2 years to “pre-market” the game mean that when the trailer hits YouTube there is a large group of fans eager to share it around social media.

 

Black

Thoughts on The Ending

Soon, I will stop being the artist on Where Shadows Slumber and become Mr. Bug Finder. Then, in the weeks before the game hits the App Store, I’ll be Mr. Marketer. After that, I’ll be Mr. Salesman as I go on the Extremely Real and Actually Real Where Shadows Slumber World Tour! (Buy our game so we can do this)

It’s so strange to think that in just a few days, I won’t be modeling environments or animating these characters ever again. Saying goodbye is a bit of a relief, but it’s also disturbing. It feels a bit like leaving a job at a company without having another one lined up. And I’m not talking about the financial success of the game (we have no idea what to expect… $500? $500,000?) but rather my own personal sense of purpose. I never thought I would feel totally lost right at the moment our three year passion project is about to hit prime-time. Is this normal? How am I supposed to feel?

Anyway, this is the State of the Art blog, not the State of Frank’s Mind blog. Let me save my goopy tell-all for a podcast appearance with Jack sometime. (Speaking of which, even if you have the tiniest, most insignificant YouTube channel or podcast, invite one of us on! We love to talk! Contact info in the signature below) All you need to know right now is that the art is 98% finished and we’re heading into our final Quality Assurance (QA) stretch.

Stay tuned to this blog for mega updates about the game, tales from QA hell, and maybe even a comedic play-by-play of our upcoming Xcode struggle. Thanks to Jack for giving me a good name for this blog, and thanks to everyone who has been keeping tabs on us. I may resurrect this monthly recap if we have new art updates, such as when we port the game to Amazon’s Alexa, but right now I’m looking forward to wearing a different hat for a while.

See you next week!

 

 

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

Thanks for reading this entirely text-based art update! If you’re new to this blog, 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.

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.

The Triangle of Truth

Hello again, everyone! It’s Frank again. I know you are all eagerly reading our weekly updates to find out when the game will be finished, but this week you may be disappointed. Rather than announcing a launch date, I’m going to explain to everyone the project management principles behind why Where Shadows Slumber has had such a long development cycle. We’re going to discuss the Triangle of Truth!

 

 


 

 

triangle

The Triangle, Explained

The “Triangle” refers to a project management principle that has gone by many names, visualized in the image above. This diagram has been used to describe everything from project strategies and economic models to government healthcare systems and construction projects. It’s one of those mantras that just always seems to hold true, no matter the circumstances. When you are creating something, such as a mobile video game, you’d ideally like for it to be as good as possible for the cheapest cost and have a fast development cycle. Sadly, the edicts of being demand that you must sacrifice one side of the triangle to achieve the other two. As the desired two metrics increase, the sacrificed metric must decrease. Let’s define these bolded terms first, and then talk about Where Shadows Slumber.

Good: The product stands out among the crowd as something special. We want quality to be as high as possible.

Cheap: The cost incurred creating the product. (Not to be confused with the price a consumer pays for the final product) We want our cost to be as low as possible.

Fast: Time is money, so the sooner the project is done, the better. Life is short! We want our development cycle to be as short as possible.

When you see how Where Shadows Slumber lands on this diagram, everything will start to make sense.

 

We Chose “Good” and “Cheap”

Jack and I are two recent college graduates who teamed up together to make video games. The development of Where Shadows Slumber is not too dissimilar from the development of SkyRunner, our previous mobile game. We decided not to spend a truckload of money on the game, so that it could be as good as we can muster at the lowest personal cost. Essentially, we decided to spend time on the game rather than cash. This is because we have no money, so it was an easy decision.

That’s not to say that I’ve spent $0 on this game! It’s fair to say tens of thousands of dollars have gone toward the development of Where Shadows Slumber, easily. But our budget is a pittance compared to large indie studios and AAA development houses. The sides of the triangle have been chosen: we want a good game, and we can’t spend a lot of money, so we’ll just have to spend as long as it takes to get the job done.

What would Where Shadows Slumber look like if we sacrificed a different portion of the triangle? Let’s analyze where we are now, and then look at the others. Right now, we’re sacrificing time.

 

SACRIFICE: TIME  / /  GET: QUALITY, LOW COST

Time: We’ve been working on the game since the spring of 2015, and we’ll continue to work on it over the next few months. That’s a 3 year development cycle!

Cost: Game Revenant has spent ~$25,000 to pay our audio engineers, travel to conventions, and equipment. We work from our apartments and meet in coffee houses, so we don’t spend money on rent or utilities. Jack has a full-time job and I mooch off my generous, loving and forgiving family.

Quality: The game is superb, beautiful, and time-tested. We even created a free Demo that went through extensive user testing and has stood the test of time. This informed our approach to the final game, but it took a while to get to this point.

 

SACRIFICE: QUALITY  / /  GET: TIME, LOW COST

Quality: We always knew we wanted Where Shadows Slumber to be an awesome, premium mobile game. But if for some reason we decided to release a poorer quality version, we’d be done by now. What would happen if we sacrificed quality by having fewer puzzles, no meaningful story, and low-quality audio produced by Frank making noises with his mouth?

Time: We already created a rudimentary throwaway version back in 2015 when we first begun work on the game. We could have cut it off right there! Also, our Demo has been available for download since November 2016, so that gives you an idea of how much time we could have saved.

Cost: Obviously you don’t need to spend a lot of money if you don’t care about the final result. Jack and I could have just created a shorter, worse game and it only would have cost us a few app store developer fees (Apple, Google Play) and the cost of buying development devices for building and testing.

 

SACRIFICE: MONEY  / /  GET: QUALITY, FAST DEVELOPMENT

Cost: It is possible to get investors for indie games, either by getting a loan from the bank or by appealing to groups like Indie-Fund. Jack and I briefly considered this a year ago, but by that point we had put in so much of our own time, we felt like reaping the full benefits. (Remember – investors don’t give out money for free, they want a cut of the sales!) We could conceivably have gotten $500,000 – $1,000,000 to work on this game if we put our own money in and also got some investments. If we did…

Quality: Along with our personal efforts, we could have hired a small team of veteran developers to aid me and Jack. Veteran programmers would help Jack organize his code, and veteran artists would produce work superior to mine. With Jack and I to guide their efforts, we could take a management / visionary role and let the experts do the hard work. I think the quality would be the same it is now, but it would have gotten there faster. Speaking of which…

Time: My work would be cut in half if we paid an Animator / Character Gui* to handle all of the cutscenes and humanoid animation in the game. That would free me up to work purely on environments with Jack. On the development side, we could hire a full-time Quality Assurance Gui to test the game on various devices. A full-time Marketing Gui would handle our social media efforts, press relationships, and business travel. We could have also brought Alba and Noah into the fold a lot earlier, meaning most of their work would be done by now. Every gui we hire is another hat Jack and I don’t have to wear!

*Gui is a gender-neutral version of “guy” that we used to use in Off Center

 

2305701220_0fc3d01183_b

There Is Always A Drawback

It should be stated that when you sacrifice a portion of the triangle, you don’t get it back. There is always a cost. If you spend money, it’s gone. If you sacrifice quality, your game suffers. And if you spend three years working on a game, you suffer.

I’ve lived in isolation for a period of three years ( ! ), all the while neglecting personal relationships with friends and families, turned down jobs, rejected business opportunities, let my body grow fat, and forgone other personal life goals in order to work on Where Shadows Slumber for as many hours a day as possible. (Imagine my surprise when I discovered that women are not eager to date a man who spends 10 hours every day in front of a computer and rarely leaves the house. Shocker!)

Jack has been working his fingers to the bone every day at not one, but TWO tasks: his full-time work at a startup in NYC and his passion project Where Shadows Slumber. He’s written about this before on our blog, and I encourage you to read his past writing. I was particularly mortified at the mention of how he has to find small scraps of time throughout the day (30 minutes in the morning, 25 on the train, 45 between arriving home from work at night and making dinner) just to work on the game. I have no right to complain – in light of his sacrifice, my life is a breeze. What kind of person would lead their friend into this kind of a life?

I don’t mean to be dramatic, but the point of this blog post is that the toll is real. Choose your sides of the triangle carefully, because the side you scorn will stop at nothing to seek revenge.

 

MiyamotoQuote.png

Where Shadows Slumber: Eventually Good

Miyamoto’s famous quote that “a delayed game is eventually good, but a rushed game is forever bad” may not be true anymore in a world where games can be patched and DLC can be sold. In a world where software is now a service, rushed games might eventually become good, given time.

However, this is also an industry where you live and die by your first impressions. Users don’t ever return to write a second review, and journalists move from game to game quickly. Jack and I are making a sacrifice of time to ensure that Where Shadows Slumber makes a splash when it hits the market. We can’t spend money we don’t have, but we can always put in just a bit more work.

Are you a game developer, artist, musician, writer, or creator working on a passion project? Feel free to share this blog post with your friends and family, especially if they have ever asked you “gee, when are you going to be done with this darn thing?” Let me know what they say in the comments below!

 

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

This has been a project management blog from the creators of Where Shadows Slumber. 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.

State of the Art – May 2018

Welcome to State Of The Art, May 2018 edition! This monthly progress report is written by Frank DiCola and is focused entirely on how the game’s visuals have improved in the past month.

It’s hard to believe the past month was just 30 days – everything feels so long ago, from our hilarious April Fool’s Day post to my trip to PAX East. As we wrap up production on the game, I find we have more work to do, not less. Not what I expected, but Jack and I are up to the task!

Missed last month’s State of the Art? The April edition is right here.

 

 

 


SPOILER WARNING: This post contains screenshots, GIFs and videos of later sections of the game. If you want to experience them in all their majesty for the first time on your mobile device when the game launches, don’t read on!


 

 

 

 

LevelSelect-5-6.gif

More Gorgeous Menus

The GIF above is a little teaser of what I have for you in this update: two more Worlds have been polished and are now App-Store-ready. As I hinted at last time, I completed World 5 (the Hills) and World 6 (the Summit). Check out their Level Select menus! I know it seems weird to show these off, but I always love how they come out. It’s so cool for me to get an opportunity to visualize the game world from a different perspective. This 2D view allows you to appreciate the scale of Obe’s journey as he climbs to the top of a massive mountain towards the game’s end.

 

SOTA-April-Hills

The Rainswept Hills

These two Worlds posed a unique challenge to me because they take place in the wilderness. Up until this point, I tried to stick with my modular tool-set for as much of the game’s artwork as possible. However, sometimes you just can’t do that. When it comes to mountains, valleys, and rocks, they demand a jagged unevenness that just can’t be achieved by cookie-cutter pieces. Every Level in this World has a custom ridge that is 100% unique!

Jack will kill me if I show off every Level in this World, so I’ll have to settle for my two favorites. Level 5-2 has always looked great, but now that it’s raining like hell the Level has really come to life:

Then, towards the end of the Hills, we transition to a snowier climate. Obe is getting to the top of the mountain. He sees a cottage at the edge of the cemetery where he can rest for the night. Here is the last Level in this World:

I love doing weather effects because they really challenge me to think of how every tiny thing in the scene ought to change. Leave a comment and let me know what you think of “the Hills!”

 

SOTA-April-Header

The Forgotten Castle at the Summit

Obe is making his way through a blizzard to a lonely, abandoned castle at the top of the mountain. Once again, I got the opportunity to polish the weather effects here and I think they look incredible. I can’t show off everything, so here’s a quick look at two different Levels.

The first is Level 6-1, “Pass.” Obe is making his way through the snow as he attempts to cross this old bridge. Thanks to Jack’s terrain setup, Obe will actually use different animations depending on what terrain he is standing on. Notice how he interacts differently with Buttons and bridges.

In the shadows, another kingdom is revealed. Are we looking into an alternate dimension? Perhaps the shadows are a window to the past? The future?

Level 6-4 takes place inside the castle. Now, a snowstorm rages outside as a lonely sentry patrols the entrance.

This World does some amazing things with shadows, so I don’t want to give too much of it away. It looks a million times better than where I left off a few months ago, so I appreciate the chance to come back and punch it up.

 

SOTA-April-Cutscene.JPG

Next Up: Cutscenes, Cutscenes, Cutscenes

Rather than move on to the final World of the game, I’m going to take the next few weeks to animate the game’s remaining story cutscenes. World 7 needs a bit of love right now, so Jack is going to spruce it up a bit before I make my glorious return to polish. Cutscenes are tough because every minute of animation is roughly 40 hours of work ( ! ) so I’m going to be nerding out in my room for a few more months, it seems. Two of the cutscenes have been animated and shown off at festivals, but they need sound. The other eight have not been started, although their scripts were written long ago.

At some point I may enlist Alba and Noah to help me input the sounds into the animation, because I think we can cover more ground that way. But as far as character animation goes, it’s just me and the keyframes. Some people at PAX East asked me if I ever use motion-capture for these short films. The answer is: No way! We don’t have a crazy setup like that at Game Revenant (read: at my apartment or Jack’s apartment). It’s all animated by hand, baby.

Wish me luck as I make my descent into animation hell. See you next month!

 

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

We hope you enjoyed this update about the game’s artwork. 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.

Unity’s Performance Debugging Tools

Last week I discussed some of the basics of how rendering works in Unity. As I mentioned, all of that was setup for this week’s blog post. Since I’m working on rendering optimization now, I figured it would be a great time to go over the debugging tools Unity provides in order to aid rendering performance. Online resources can be a little scarcer for rendering than they are for other aspects of coding, so hopefully anyone who’s working on their own game might glean some useful information from this post. And even if you’re not working on anything right now, I hope you follow along and maybe learn a bit!

Unity is a nice little game engine, and, as such, it does a lot of the work for you. For the most part, when making a game, you don’t have to worry about the nitty-gritty stuff like rendering. When building for mobile, however (especially when you have specific graphics/lighting customization), you might have to descend into shader-land. Fortunately, Unity provides a few tools that can help you to deal with optimizing your rendering pipeline.

 

4-24-Profiler.JPG

Profiler

The first step in fixing rendering performance issues is to know about them. The best way to do that is with the Profiler window (Window -> Profiler). While you’re running your game, the Profiler keeps track of a lot of incredibly useful information, like how long each frame takes to render, split up by category. For instance, the Profiler will tell me that a frame took 60 milliseconds to run, 40 of which were due rendering and 15 from script execution, etc. This is the first place you should check when trying to improve performance – there’s no point in optimizing your rendering if it’s actually your scripts that are running slowly!

profiler

So much information!

For the purposes of rendering, there’s an entire Profiler section! The Rendering Profiler keeps track of the number of batches, setPass calls, triangles, and vertices in each frame. Looking here for inconsistencies, spikes, and just high numbers in general is a good way to get an idea of why your game is taking so long to render. The Profiler also has a lot of other info that’s useful for diagnosing and debugging performance problems. I really recommend profiling your game and thoroughly looking through the results to get as much information about how your game is running as possible.

 

android_debug_bridge

Android Debug Bridge

While profiling in the editor is pretty useful, it doesn’t tell us much – of course our game will be fast on a great big computer, but how does it run on a crappy phone?

The is where ADB, or the Android Debug Bridge, comes in. ADB allows your computer to communicate with your Android phone about all sorts of stuff. Specifically (for our use cases), it allows you to profile your game while it’s running on a device. If you plug your phone into your computer, build the game directly to your phone, and open the profiler, you should see some results. This is the information we want, because it tells a much truer story about how your game runs on a phone.

Where Shadows Slumber, for instance, runs at ~200 fps in the Unity editor. When I plug my phone (the Google Pixel 2) into the profile, I get a framerate of ~60 fps. This is pretty good, so I know our game can run on newer devices. However, when I plug in my old phone (a broken HTC One M8), I get closer to ~12 fps. Looking at the profile during this run will give me much more useful information about what I should fix, since this is the device where performance is actually suffering. If you’re making any big decisions or changes based on profiler results, make sure those results come from your actual targeted device, and not just from the editor.

ADB usually comes with the Android SDK – if you have the Android SDK set up with Unity (which allows you to build to Android devices), then you should be able to use ADB with the profiler pretty painlessly.

I should also mention that there might be an equivalent tool for iOS debugging, but, as I do all of my development on a Windows machine, and all of my testing on an Android phone, I wouldn’t know what it is. Sorry!

 

4-24-Header

Frame Debugger

The next most important tool for rendering performance is the Frame Debugger (Window -> Frame Debugger). While the Profiler tells us a lot about what’s happening during rendering as a whole, it still treats the rendering process as a black box, not letting us see what’s actually happening. The is where the Frame Debugger comes in – it allows us to see, step by step, exactly what the GPU is doing to render our scene.

As I mentioned last week, the GPU renders the scene through a bunch of draw calls. The Frame Debugger allows us to see what each of those draw calls is drawing. This allows us to determine which materials/shaders are causing the most draw calls, which is one of the biggest contributors to rendering lag. It also provides a bunch of information about each draw call, such as the properties passed to the shader or geometry details. The important thing that it tells you is why this draw call wasn’t batched with the previous draw call.

frame debugger

All of this happens in a single frame

Batching is Unity’s first defense against rendering lag, so it makes sense to batch as much stuff into a single draw call as possible. Because rendering is such a complex process, there are a lot of reasons why draw calls can’t be batched together – certain rendering components simply can’t be batched, meshes with too many vertices or negative scaling can’t be batched, etc. The frame debugger will tell you why each draw call isn’t batched with the previous one, so you can determine if there are any changes you can make that might reduce the number of draw calls, thereby improving rendering performance.

For example, in Where Shadows Slumber, we re-use meshes in certain places. Sometimes, if we require a “mirrored” look we’ll reuse a mesh, and then set the scale to -1. This was before we really looked into rendering performance, and, unfortunately, it causes problems – a mesh with negative scaling can’t be batched with a mesh with positive scaling, so this ends up creating multiple draw calls. Rather than setting the scale of the object to -1, we simply import a new, mirrored mesh and update the object, allowing these draw calls to be batched and improving performance.

 

4-24-Stats.JPG

 

Stats

That’s it for the heavy-hitters; between the Profiler, Frame Debugger, and ADB, you should be able to get a pretty good idea of what’s going on in render-land. Unfortunately, digging through them can take a while – sometimes you just want a quick indicator of what’s going on in your scene. Enter the Stats window.

The Stats window (click “Stats” in the Game View) is a small overlay in the game view which gives you a quick rundown of various rendering indicators in real time. It’s not as in-depth, but it gives a much quicker picture of performance.

stats

That’s a lot of batches!

While it sounds like the stats window doesn’t add much – after all, the Profiler can give you the same information – I’ve found it to be very useful. The Profiler is probably better when you’re actively debugging rendering performance, but the stats window allows you to notice places where rendering performance might take a hit, even when you’re doing other things.

When I’m testing some other part of the game on my computer, I’m not going to notice any rendering lag, because my computer is so much more powerful than a phone. I’m also not going to be looking at the Profiler or Frame Debugger, because I’m not worrying about rendering at the moment. However, if I have the stats window open and I notice that the number of draw calls is in the hundreds, then I know something is going on. At that point I can get out the Profiler and see what’s happening – but I wouldn’t even have known there was anything amiss if it weren’t for the stats window.

 

4-24-SceneView.JPG

Scene View Draw Mode

As we get further and further down the list, we’re moving from “debugging all-star” to “it’s useful, but you probably won’t use it much”. Scene View Draw Modes fall into this category, but they’re still good to know about. You can access different Scene View Draw Modes by clicking the drop down menu at the top right of the scene view window.

The Scene View in Unity is one of the main windows that you use to make your game – it shows everything in the scene, allowing you to move around through the scene and select, move, rotate, scale, etc., any game objects. Usually the Scene View just displays the objects exactly as they would be displayed in the game. However, it has a bunch of other modes, and some of them are actually pretty useful. The two that I find the most useful when considering rendering concerns are listed below, although they’re all worth checking out:

Shaded Wireframe: This is my default draw mode, as it looks pretty similar to the normal shaded mode. The difference is that it also shows all of the triangles and vertices that you’re drawing. This is useful because certain shader operations are performed once for every vertex. Decreasing the number of vertices in your scene can give you a bit of a performance boost, and the shaded wireframe draw mode helps you see when you might have too many vertices.

3-4toomanytris

The shaded wireframe shows that there are too many polys.

Overdraw: This mode draws each object as a single transparent color. This makes it very easy to see when multiple objects are being drawn in the same spot on the screen. Since the GPU has to draw every pixel of each object (even if that pixel will be overwritten later), it ends up wasting some calculations. Areas that are very bright will waste even more calculations. Switching to this draw mode every so often lets you know if there are any places where you might want to remove some meshes.

 

161004-worst-hacks-history-feaure

The Internet!

It should pretty much go without saying, but one of your best resources for debugging performance is the internet. Unfortunately, when it comes to rendering in Unity, the information out there is pretty scarce. Unlike with normal imperative coding, where you can simply Google “how to pathfinding” and get 30 implementations, you have to work a bit harder with rendering stuff. I find it’s best to do what you can and only resort to the internet with very specific questions. That said, there is still a lot of helpful information out there. You just have to know going in that only one of every three stack overflow questions makes any sense, and only one of every four Unity forum threads are using the most recent APIs. It’s like “Googling: Nightmare Mode”!

For anyone reading this post who is actually working on rendering stuff – I’m very, very sorry. I hope that this post and the tools I discussed help to shed at least a little bit of light in the dark underworld that is shader-land, and I hope you can achieve your rendering goals and make it back to the mortal realm before your soul is forever lost.

For everyone else who hasn’t done any rendering stuff, I hope you learned a bit, and that maybe I inspired you to get involved with some rendering code! It’s really not that bad, I promise!

 

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

If you didn’t already have a working knowledge of rendering, I hope this post helped! If you do know about rendering stuff, I hope you don’t hate me too much for my imprecision! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, join the Game Revenant Discord, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.

Rendering in Unity

As you probably know, Where Shadows Slumber is starting to ramp up toward a release this summer. It’s an exciting, terrifying time. We can’t wait to share the entirety of what we’ve been working on with the world, but there’s also a daunting amount of stuff to do, and not much time to do it.

If you’ve played any of the recent beta builds, hopefully you like what you’re seeing in terms of design, functionality, polish, art, and sound. Unfortunately, if you’ve played the beta on anything other than a high-end device, you’ve probably noticed something that you don’t like: lag.

Lag is annoying. Lag is something that can take a great game and ruin it. It doesn’t matter that your level design is perfect, your models are beautiful, and your music is entrancing if it only runs at 10 frames per second. If that’s the case, nobody is going to enjoy playing it. And, regrettably, that happens to be the case for Where Shadows Slumber.

LikeButta

Like butta’!

So, one of my biggest tasks before we release is to optimize the game, making it run faster and allowing us to have higher frame rates. The area with the most opportunity for improvement is during rendering. A game consists of a lot of logic – Obe’s location, things changing in shadow, etc. – but rendering is the process of actually drawing the scene onto the pixels of your screen.

Earlier this week, I started a post about the different tools you can use to help optimize your rendering performance. It seemed like a good idea, since that’s exactly what I was doing. However, I realized that if you don’t know how rendering works in the first place, most of it is complete gibberish. So I’m gonna leave that post for next week, and this week I’ll give a quick introduction to how 3D rendering works in Unity.

Blog-Render.JPG

Rendering

Rendering is the process by which the objects in your game are drawn to the screen. Until it’s rendered, an object in your game is just a collection of information about that object. That information gets translated from information the game engine understands into information the GPU can understand. There are a few important concepts to understand here:

  • An object’s mesh describes the shape of the object. It consists of a collection of vertices and triangles.
  • An object’s material is a description of how that object should be drawn. It encapsulates things like colors and shininess.
  • Every material uses a shader. This is the program which calculates exactly what color each pixel should be, based on the information in the mesh and material.
  • World space is the 3D coordinate space in which all of your game objects live.
  • Screen space is a 2D coordinate space that represents the screen to which the game is drawn.

The basics of rendering are pretty easy to understand, at least from a high-level view. The meshes for the objects in your game are translated from world space to screen space, based on the camera that’s doing the rendering. For instance, in Where Shadows Slumber, objects that are further away in the x-axis will be higher up and more to the right when viewed on the screen. Fortunately, we don’t have to mess with this too much – Unity’s cameras do a good job of making this translation.

Once we know where each pixel should be drawn, we need to determine what color that pixel should be – this is where the material and shader come in. Unity provides a whole bunch of information to the shader (position, angle, information about lights in the scene, etc.). The shader uses that information, plus the information from the material, to determine exactly what color the given pixel should be. This happens for every pixel on the screen, resulting in a beautiful picture of exactly what you expect to see.

The GPU

Now that we understand the basics of rendering, let’s take a deeper look into how it actually happens: the GPU.

The GPU, or graphics processing unit, is the part of the computer in charge of calculating the results of our shaders to determine a pixel’s color. Since modern phones have over 2 million pixels, our shader code must be run over 2 million times per frame – all within a fraction of a second.

How does the GPU manage to do so many calculations so quickly? It’s due to the design of the GPU, and can be summed up in one very important sentence: the GPU is good at performing the same operation, a bunch of times, very quickly. The key thing to remember here is that it’s good at performing the same operation; trying to perform different operations is what slows it down.

Specifically, switching from one material to another causes a bit of a hiccup in terms of speed. The properties of the material are passed to the GPU as a set of parameters in what is known as a SetPass call. SetPass calls are one of the first and most important indicators when it comes to optimizing rendering performance, and are often indicative of how quickly or slowly your game will run.

Because SetPass calls take so long, Unity has a strategy for avoiding them called batching. If there are two objects that have the same material, that means they have the same parameters passed to the GPU. This means that those parameters don’t need to be reset in between drawing the two objects. These two objects can be batched, so the GPU will draw them at the same time. Batching is Unity’s first line of defense against rendering slowness.

The CPU

While the GPU is the star of the show when it comes to rendering, the CPU, or central processing unity, still does some important stuff that’s worth mentioning (even if it doesn’t have a huge bearing on the optimization steps we’ll be taking). Of course, the CPU is in charge of running your game, which includes all of the non-shader code you’ve written for it, as well as any under-the-hood things Unity is doing, like physics and stuff.

The CPU does a lot of the “set up” for rendering, before the GPU comes in and does the heavy number-crunching. This includes sending specific information to the GPU, including things like the positions of lights, the properties of shadows, and other details about the scene and your project’s rendering config.

One of the more important rendering-related things the CPU does is called culling. Since the CPU knows where your camera is, and where all of your objects are, it can figure out that some objects won’t ever be viewed. The GPU won’t know this, and will still perform calculations for those objects. In order to avoid doing these unnecessary calculations, the CPU will first remove any of the objects that won’t be drawn, so the GPU never even knows about them.

Image

All of these Hitlers would be culled by the CPU (image credit: smbc-comics.com)

Since we’re talking about performance, it should be noted that the GPU and the CPU are two different entities. This means that, if your game is experiencing lag, it’s likely due to either the GPU or the CPU, but not both. In this case, improving the performance of the other component won’t actually make your game run any faster, because you’ll still be bottlenecked by the slower process.

So, now that we know a little bit more about how rendering actually happens, maybe we can use that knowledge to improve performance! At least, that’s what I’m hoping. If Where Shadows Slumber never comes out, then you’ll know I’ve failed. Either way, I’ll see you next week for a look into the tools you can use to help you optimize rendering performance in Unity!

 

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

If you didn’t already have a working knowledge of rendering, I hope this post helped! If you do know about rendering stuff, I hope you don’t hate me too much for my imprecision! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebookitch.io, or Twitch, join the Game Revenant Discord, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.