MAGFest 2017 Rocked!

Jack and I have just returned from a wild weekend at MAGFest 2017, and I have nothing but positive things to say about the experience. Back in late September, we applied for MIVS – the MAGFest Indie Videogame Showcase. After multiple rounds of judging, we ended up making it all the way! We were one of many indie game studios that were invited to demo our game at MAGFest.

By invited, I do mean invited. One of the best parts of this convention was that there was no booth price for indie developers. Ticket sales from the convention were used to pay our way, and it meant a lot. MAGFest ended up being one of the less expensive shows Game Revenant has done so far… by comparison, my dalliance to Chicago for Mr. Game! cost me a number that rhymes with gour-gousand.

The most valuable part of these events is getting feedback from players. It isn’t always easy to hear constructive criticism from your fans, but it is necessary. (Jack is going to be writing about this subject next week!) We specifically asked people at our booth to give us “tough love” as we near completion of the demo and move on to production. Without hearing some negative feedback, you’ll never escape the indie thought bubble.

“My game is the best game that’s ever been created. My game. Me. Haha… everyone else must be stupid for not making it first. Not me though. Hahaha…”

– The Indie Thought Bubble

So just to show you we’re listening, here’s three big lessons we learned about our game’s demo (which you can download) that we’ll keep in mind as we start final production this month.



A blue-haired tester at MAGFest plays Level 3, “Canyon” on our iPhone.

1. Make The Game More Difficult

Right now, the demo is a bit too easy. This was something 90% of our testers told us. People would marvel at our cool idea, beautiful artwork, immersive sound (for those that could actually hear it in the crowded convention hall) but stop short before discussing the puzzles.

The most common feedback was that it felt like we had 5 or 6 tutorial levels instead of the 3 we were aiming for. Players don’t like feeling “led” by puzzle games, whether that leading is overt (tap HERE to move! HERE! Right over HERE!) or subtle. We’ve got a subtle thing going on right now, where there are too many easy levels in a row. Players find that to be boring.

We vow to make the game physically relaxing, but mentally challenging! Just because the game is supposed to give you a “moment of zen” on your daily commute doesn’t mean it can’t really make you think. Harder levels, and more compact tutorials, are on the way!



The booth got so packed we had to use our phones to demo the game as well!

2. More Narrative Elements

This feedback usually came in the form of a question. “Will there be a story?” It was always a hopeful question, like “I really hope you guys have a story planned.” We would tell people that although the demo won’t have too much (we’re working on a final cutscene for it now) the final game definitely will have a cool story.

Our goal is to tell a story without using words. My passion is animation, and I think body language is an incredibly useful tool for communicating ideas. I don’t think we need dialogue bubbles or text to tell the story of a man’s solitary journey through a dark and strange world. The other reason is because avoiding the use of text will make it easier for our game to launch in other regions where English is not the official language.

So, don’t worry! A story is on the way. Once it arrives, maybe the 18+ rating on the game will seem a bit more obvious…



Jack stares off into the distance, permanently scarred by a two syllable word: Grongus.

3. Rename The Game To…

Not all feedback is good. Sometimes, you need to let criticism go. People gave us lots of good ideas, but of course the constant refrain was to rename the game to Where Shadows Grongus. This won’t happen, so I hesitate to even mention it. However it was requested by about 105% of our testers and it seems dishonest not to say something.

The name of the game is final. It performs well on search engines like Google, Yahoo, Bing and DuckDuckGo, just to name a few. We have a real ownership of the string Where Shadows Slumber and a new logo has even been created for that title.

Please stop asking us to change the name. Don’t tweet at Game Revenant about it, and leave our Facebook Page alone. This debate is over.



The two of us eagerly awaiting the announcement of awards at the end of MIVS.

Thanks, MIVS!

The MIVS Staff deserves a thank-you for giving us this awesome opportunity. You won’t find this kind of sweet deal at other shows, but MAGFest is a strange animal. Here’s the staff members that worked on this year’s show. Thanks, everybody!

Lexi – layout, hotel & badge handling
Joel – judge coordinating, hotel & badge handling
Nate – map artist, video editor, web content
Kat – MIVSY maker, volunteer scheduler
Marc – Awards spearheader
Kotey – Tournaments
Paige – External entity coordination
Peter – LEDs, new Obelisk lead
Nichole – Press, coordination with internal social media

Tronster – coordinating everything!


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

Do you have feedback for us? Did you play the demo of Where Shadows Slumber? Please try it on your Apple or Android device and then leave a comment for us below! We’d also love to hear from you on the official Game Revenant Facebook Page, or on our Twitter account.

Frank DiCola is the founder and CEO of Game Revenant, a game studio in Hoboken, NJ.

Mechanic Spotlight: Shadows, Part 2

Where were we before we were so rudely interrupted by my extreme laziness? In my last post, we went over the basics of how shadows operate in Where Shadows Slumber. This week, we’ll pick up where we left off, and I’ll describe the way I actually implemented shadows, and the reasons for doing so.

Last time, I described two different ways to think about objects changing in shadow. Unfortunately, I did so in a sentence that, in retrospect, looks simply confusing:

[Things] can always change when put into shadow, or they can only change when you move around the object casting the shadow, so you’re on the other side of the casting object, relative to the changing object.

Yeah, that’s no good. So let’s figure out what this means, in a way that’s a little longer, but easier to grasp. We’ll use the classic pillar / bridge problem, where the pillar is casting shadow, and the bridge is changing with that shadow.

If I walk past the pillar, the shadow will overcome the bridge. If I continue walking, the shadow will move, the bridge will be revealed, and at this point, it should have changed. This is exactly what we want.


Not only is the pillar / bridge problem less violent than the trolley problem, it’s more relevant!

Now consider the scenario where I start to walk past the pillar again. The shadow overcomes the bridge again, but this time, I stop walking, leaving the bridge in shadow. Instead of continuing forward, I turn around and go back. The shadow moves, so we can see the bridge again, but we’re on the same side of the pillar as we started. Now the question arises – should the bridge have changed?

This is a very important question when considering this mechanic. Thinking about it from a ‘pure’ standpoint, of course the bridge should have changed – it was in shadow. After all, that’s the rule, right?

This was exactly my thought process, and is why I implemented the mechanic in the way I shared in my last post. The early prototype we made behaves in exactly this way. However, as I got further into level design, I realized that this is not what we want. In order for many of our level designs to work, the above scenario would need to result in the bridge not changing.

When designing levels for a game like this, there are a number of considerations to make, but one of the most important is to remember that the player will not always do what you want. I may want the player to walk around the pillar, but the player may instead decide to walk behind the pillar, and then turn around. If I need the player to end up on the far side of the pillar (for a story event, part of the puzzle, etc.), that becomes hard to accomplish with the current version of the shadow mechanic.

So, it seems that we need to update the implementation of our mechanic. The way we want it to work has more to do with what side of a shadow-casting object we’re on – the bridge can only change when we move around the pillar.

Fortunately, this is actually an easier problem than the previous one. When we think about it this way, we don’t even need to use shadows – what we’re really checking is when we pass the object. When the light (player), the blocking object (pillar), and the shadow object (bridge) are all in a row (collinear), we can simply know that the object is in shadow rather than checking. This is true when we make a few assumptions:

  • Both the pillar and the bridge are about the same size. This means that we may have to break the bridge up into a number of 1×1 ‘shadow objects’.
  • Each light involved originates from a single point (so point/spot lights, not directional lights).
  • The bridge is further away from the player than the pillar.

When all of these conditions are met, we can ignore the shadow itself, and just change the bridge when the player passes the pillar. It’s a little hard to conceptualize, but a picture is worth a thousand words!


Alright, maybe like 500…

At the moment the player passes this ‘collinear point’, we trigger the shadow object to change (note that at that moment, the shadow object will be entirely in shadow). But the shadow is just there for cosmetic purposes, like a magician’s illusion – it’s so you don’t see the trick!

As I said before, this problem is much easier to solve – every frame, we simply compare the angle from the player to the blocking object with the angle from the player to the shadow object. When those angles switch, it means that the shadow object is in shadow and should change.

In this way, we can easily keep track of when a shadow object should change. There are a few ways in which this situation can become more complicated – if there are multiple lights or blockers that should affect a single shadow object, if there are multiple shadow objects that should use a different set of lights or blockers, etc. These are all very important things, but they’re all things that can be implemented by carefully extending the system we laid out above. As such, implementing them is left as an exercise to the reader : )

There are still ways we can use the previous implementation to help out with the shadow system. There are a few cases where we might need to actually know if an object is in shadow, rather than just making the assumption that it is. Thus, our shadow system includes a sort of ‘back-up’ shadow-detection – in certain cases, we fall back on the more accurate, more expensive shadow detection we worked on in my last post.

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

That finishes up our high-level overview of our implementation of the shadow mechanic – I hope you enjoyed it. Let us know if you have any questions or feedback! As always, you can find out more about the game at, find us on Twitter (@GameRevenant), Facebook,, or Twitch, and feel free to email us directly with any questions or feedback at

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