Of Light & Shadow is a 2.5D platformer game. There are two characters which the player controls, Mr. Light and Dr. Shadow. The first can only survive in the Light, the second only in the Shadow. The player can switch between those two characters and has to to pass some tricky passages and puzzles to complete levels. If you like competition there’s a online highscore so you can see how good you really are.

The development of the game started in Fall 2010. A group of multimediaart students started concepting for a game. In early 2011 the basic idea was set. Two characters based around light and shadow levels. At this point they recruited some programmers, including me, to make this game happen. So in the end we were 12 guys, 1 project management, 2 sound artists, 4 programmers and 5 artists.
We decided to develop the game with the Unity engine. Unity already provides a lot of functionality and makes it possible to focus on creating the game instead of the basic stuff needed for it. No need to code 10 tools. But we had no idea how to develop with Unity. So we learned, we experimented, we did tutorials. And we started doing a first prototype. It looked like crap, but it let you try the light/shadow core gameplay a bit. As you can see at that point we had the idea of the two character being played simultaneously. We changed that to a one or the other mechanic later. We were also still looking for a solution of how to visualize the light cones. In the end we used a transparent plane with a shader which renders only those pixels which are being lit. The cool solution would have been volumetric lighting. That’s one of those cases where you feel the downside of using a 3rd party engine. If a feature like volumetric lighting isn’t supported by the engine, you have no way of doing it yourself.

We continued prototyping, and the artists created some assets for level objects and the characters. The result at June 2011 was the second prototype. We had the light/shadow mechanics set up, the character switching mechanics, the character assets. And a demo level which let you try those mechanics. It still looked quite raw, but the gameplay was really testable for the first time. The winter semester after that the programs were away on their mandatory internships and the artists were busy creating a animation movie. The development of the game nearly slowed down to a standstill.

After the programmers returned in late December and the artists finished their movie. We picked up where we left and started concepting and creating the first real level. This was the level which is now level 4 in the released game. By the end of January 2012 we had the level finished and for the first time let random people from the university play it to gather feedback.
From then on we kept adding levels, tested, evaluated feedback, adapted mechanics until late April 2012. At that point we were finished with most level except level 6 which was still too buggy. After that date we focused on polishing and even more testing/bug fixing.

Finally in early June 2012 we released the game. We held a public presentation at the university, put the game on the website and started promoting it. And it didn’t take long for the first reviews to pop up. We where overwhelmed by how positive the feedback and reviews were. When you develop a game for so long you often don’t appreciate the game anymore. You only see the bugs and ugly stuff, you take everything else for granted. Those reviews are a reminder of how good the game actually is, and that there are people genuinely enjoying it. And that’s awesome!

Lessons learned:

* Set up your workflow so the artists and game designers actually implement their stuff themselves. This reduces the workload of programmers and let’s them focus on actual coding. This is very easy with Unity and you are wasting programmer resources if you don’t do this

* When you start creating a game with a prototype, make a clear cut after the prototype is finished. Don’t build upon the prototype, start developing the game from scratch with good software engineering. We didn’t do this and kept dragging bad code with us for too long. We should have made the cut after our second prototype.

* Milestonish deadlines are important. I guess this depends on the team mentality a lot, but for us it was important to have a deadline (with consequences) to work towards. The nearer the deadline came, the more productive we were. But only use this as a last resort methology. I think it’s actually pretty bad because you can plan well if everything is done at the last minute and it encourages sloppy work. Besides that it will burn out the team members. But nevertheless such deadlines are important because they say: “Ok this must be done at this date, or you are screwed”.

* Work together in one room. This might be more important for indie/student projects. It was certainly very important for us. Working together in one room made us way more productive then working from home. You support each other, you motivate each other, you talk to each other. It just solves a lot of problems.

* The university is actually not a very nice environment to be developing such a game. Of course they provided us with the hardware and software necessary and we are thankful for this. But when developing a game with the goal of releasing it, you want to focus on that game. And the university is very good of keeping you from focusing on it because you have lot’s of other stuff to do.

What we ended up with is a awesome platformer game, we can be really proud of.

Of Light and Shadow webpage (Download the game there)

Review of “Of Light & Shadow”