Wednesday, November 27, 2013

Playing with the Oculus Rift

A couple days ago, we finally got our hands on an Oculus Rift dev kit. I'll admit I was cautiously optimistic. Virtual reality has been around my entire life and it has pretty much sucked my entire life. The Oculus Rift is supposed to change all of that. The word is that it actually works! However, before I could get too excited, a lot of reports began surfacing that the dev version of the Oculus caused severe motion sickness. The low resolution screen on the dev kit probably doesn't help (1280x800). We decided to become a developer and order one anyway. Better to try it out and see for ourselves. We had to wait a month for the kit to finally be delivered, since they weren't in stock when we applied.

Thankfully, once we received the kit, it only took a few mins to download the SDK and get everything setup within our build. I decided to test it with the hotel level first. I have to say, the hotel level has never looked so amazing! I was floored at how well the Oculus Rift immerses you into a 3D environment. You can pretty much look around at anything. I have to compare it to the feeling I get when I go scuba diving. You feel as if you are looking through a viewport into another world - a world that is very real.  For horror games, I think it adds a lot of exciting new options :).

As for the motion sickness, that is also true. After 15 mins of playing, I felt a bit nauseous. Not so much that I wanted to puke, but queasy nonetheless. I got more used to it the more I played and now I no longer feel nauseous so quickly.

Overall, I am completely sold on the Oculus Rift. I'm really looking forward to the 4k screen with less sensor lag. If they price and market it right, it will evolve gaming to a level that, until now, I've only been able to dream about.

Thursday, November 21, 2013

Joined Twitter

Just a quick note. Glowstick Games is on Twitter now. Follow us for the latest updates (game and non-game related) and an inside look at what's happening in our office.

Wednesday, November 20, 2013

Unity or Unreal Engine? Thoughts after getting started with both.

We got started working on Dark Deception as a couple guys working on their weekends, and one of the first things we had to decide was: What engine should we use?


After a bit of looking around, we had 4 main contenders: Valve's Source Engine, CryEngine, the Unreal Development Kit, and Unity.

We dabbled in Source Engine for a bit, but the lack of artist tooling made us drop it.
Then we spent a good while in the UDK (Unreal Development Kit), but ran into problems and decided it wasn't a good fit.
We considered CryEngine, but avoided it due to rumors about licensing delays and problems preventing nearly completed games from being finished. (When funding a game out of pocket, the idea of finishing it then not being able to release is really scary).
We decided to try out Unity for a couple of days, and we liked it enough we decided to drop the UDK and focus entirely on Unity.


Unity and the UDK are both very upfront about their pricing.
Basically, you can start out a commercial license for $99. The first $50K you make from your first game (after platform fees and taxes) goes straight to your company. After that, you pay a 25% royalty (again, this is calculated after platform fees). I'm pretty sure that money earned from kickstarter actually counts as game income for these purposes.  Epic recommends you get in touch with them for a full license after making about $200K to $250K, which means the full license probably costs around $50K.

You can start out for free.  To really get anywhere with the game in a team project, you're better off with the pro version and the team license.  That's $2000 up front per person, though there's actually a leasing program that lets you pay a lot less ($95 per month for a year).  By the time a year has passed, we'll either have a decent budget to buy the actual software, or we'll be closed, so we both went with subscriptions.
Unity has no royalties.

So as a comparison, lets look at what you take home depending on how much you make.  I'm looking at the money after platform taxes & fees (I don't know exact numbers, but I wouldn't be at all surprised if 30% of the money from every purchase on Steam goes to Valve).  This is assuming 2 people and that Epic doesn't charge you another $50k when you want to get the full license.  This is also ignoring any costs for buying Visual Studio and NFringe to edit Unrealscript.

Game MakesUDK cost  (estimate)Unity Cost (per developer)
Unity also has some extra costs in the form of the asset store - basically, you can buy libraries and assets from other people.  A lot of stuff that Unreal does automatically needs to be either made from scratch or bought from the asset store, which drives up the price somewhat.   A little annoying, since sometimes people will post a script to the asset store and link it in help requests, instead of just posting the code to show people how to solve their problem.  OTOH, lots of really cool libraries available for relatively small amounts of money.


UDK uses Unrealscript, which is a customized language that has a lot of odd constructs.  I've been working in C++ family languages for a long time, so a lot of coding systems Unrealscript requires feels very odd to me.
With the help of NFringe, you can program Unrealscript in Visual Studio, which is awesome (though very much not free).  However, every time you modify your scripts you have to restart the editor... very annoying, but I've heard rumors online that they're fixing that in Unreal Engine 4.

Unity uses C# with a bunch of custom classes and functions.  They've gone through a lot of effort to make things dead simple to use, but that does have some drawbacks.  They package MonoDevelop with Unity and with a bit of effort you can do inline debugging (you have to launch the unity editor from the IDE, then load your map and start the game). 

In general, I found Unrealscript to be more verbose than Unity's C# systems, which can be both a good and a bad thing.  I'll show an example of basic Bot that follows the player around.

In Unity, I drop in a 3rd person player, tear out the camera and control components, and add a Nav Mesh Agent component and a new script.  I also need to select my floor & obstacles and bake the Navigation in the editor.

My script is simple:

public class Follow : MonoBehaviour {
private NavMeshAgent nav;
public Transform playerLocation;
void Start () {
nav = GetComponent<NavMeshAgent>();
// Update is called once per frame
void Update () {
nav.destination = playerLocation.position;

In the editor, drag the player game object into the playerLocation variable, and there you go.  Took me a while to figure out how to do all of that, but very little overall code.  On the other hand, this bot will always play the same animation, will often look a bit clumsy, and you don't actually know anything about what the NavMeshAgent is doing under the hood.

In the UDK, making a basic bot is far more annoying.  You need to make 2 classes (a pawn and a controller), figure out all the required defaultProperties (set the mesh, set the controller, set the groundspeed, etc), figure out UnrealScript's state system and important controller functions.  The code below replaces one line of the code in the Unity script:

Player = GetALocalPlayerController().Pawn;
if (NavigationHandle.ActorReachable(Player)) {
} else if (FindNavMeshPath(Player)) {
if(NavigationHandle.GetNextMoveLocation(TempDest, Pawn.GetCollisionRadius())) {
MoveTo(TempDest, Player);

Lots more to type, and far more opportunities to screw it up.  But since I've already got that entirely typed out, I can pretty easily stick in alterations to change behavior at specific times.  For example, if I want to do a lunging jump as soon as there are no obstacles in the way, I just replace the first part of the if statement.

UDK also automatically handles animations really well, so when a bot is turning or sidestepping it plays appropriate animations.  The bot has built in footstep sounds too.  My understanding is that its not too hard to set that up on the artist side, but we never got to that point.

Overall, UDK depends pretty heavily on large amounts of scripts if you want to do anything custom.  In Unity you're just adding custom scripts to GameObjects, and those scripts are often really short and simple when you get them working.  I'd say the UDK is much harder to get started on and do simple things in, while in Unity it's harder to get a really polished final product.

I've been getting stuff done a lot faster in Unity than in the UDK, but I'm still worried that I'll have a harder time with the really deep and complex stuff.


Vince seems to like Unity a lot more than the UDK.  He was making good progress with the UDK, but light mapping issues were giving him fits.

From almost everything I've seen, most Unity games just don't look as good as most Unreal games.  An engine written the way Unity has been will have a very hard time matching Unreal in terms of performance, which means fewer polygons and rendering tricks.  UDK also comes with a lot of awesome rendering, lighting, and special effects systems, while in Unity you'll have to find those in the asset store (and most asset store systems don't post any information about how expensive they are to render).

At this point our Unity build looks better than our UDK build, but most of that is because we're not running into lighting problems.

Level Creation

Both editors are really good at letting you put together large and complex levels.  I like Unity more because of their component and prefab systems.  The component systems means you can easily add almost anything to an existing game object.  Want something to emit light? drop in a component.  Want it to move around? be an obstacle? emit particles? Just add the right components.  

Being able to quickly and easily create new components that can be configured in the editor means that when Vince wanted to make a flickering light, he could just copy and paste a script someone had posted online, then configure the speed of the flicker in the editor.

The prefab system means you can easily create dozens of copies of an object.  You can modify some of those objects to be customized, and you can easily change the prefab to modify all instance of the object across all your levels.

In the UDK, you can create custom types of objects via script (which then requires an editor restart), but you can't do much to modify the functionality of an object that already exists.  However, the UDK has kismet, which allows you to set up complex systems and behaviors without touching the code.  The biggest complaint I've heard about kismet is that it can't really be put into a version control system, but it's also missing some basic functionality (like vector math).


For a small indie studio that doesn't want to spend years on a single game, Unity makes a lot more sense from almost all perspectives.  It wont give you AAA quality visuals or top of the line rendering capacity, but it will let you focus on your gameplay and actually get your project out the door.

For a larger team that wants to make a game that looks amazing and/or has tons of enemies on screen, the UDK is probably a better choice.  The upper end of what can be done with the engine is higher, and most of the systems assume that you'll take the time to polish everything.

Friday, November 15, 2013

First Video Footage

Due to numerous requests, I've decided to post footage of one of our very early builds in Unreal. This is pretty much one of the first builds we had up & running in Unreal over a month ago, so, of course, it's not very good looking :P.

The password is darkness

Thursday, November 14, 2013

The Journey Begins

Hello everyone! My name is Vince Livings. I am an artist and one of the co-founders of Glowstick Games. The other co-founder is, Mark Henderson, an amazing coder that just did an AMA on Reddit yesterday. We formed Glowstick Games on Oct. 1, 2013. Basically, we had both spent a few years at large game companies, like EA and Zynga, and had become tired of working on games that prioritized monetization over fun game design. There is definitely a need for balance between the two, but lately things had been skewing too heavily towards forced mechanics aimed at monetization. Games have played a large role in both of our lives. Mark is a PC gamer at heart and I grew up with consoles. We both want to make games that people will genuinely enjoy and want to share with their friends. Thus, we are attempting to follow Frank Sinatra's advice and "do it our way".

One thing that we both agreed very early on was that we wanted to involve the gaming community in the development of our first game. To us, that means being completely transparent and showing you all as much of the development process as possible. I've always felt the one mistake that a lot of new developers make is that they are too insular and don't listen to their audience.We are making this game for you, not ourselves. Your feedback will be essential in helping us deliver the awesome game that you deserve! Now on to the game....

Dark Deception(TM)  is a new horror game being designed for multiple platforms. Initially, we are bringing it to Steam, Wii U, and tablets. We are also looking into making it compatible with Oculus Rift.

So why did we choose to go with a horror game? I will admit that I pushed for it. I am a huge horror fan and it seemed like a fun thing to do. Being scared is fun and I love games like Silent Hill, Resident Evil, Fatal Frame, Amnesia, Outlast, and  Dead Space.  However, we are just a 2 man team and we don't have the manpower to make a game of that scale. Mark and I sat down and asked ourselves, what can we realistically make? We don't have a ton of funding and we can't really spend 1-2 years working on one title. We also wanted to avoid having to make a mobile game that catered to popular trends right away. In this case, we looked for inspiration from the classics -the games we grew up with. We chatted about fun NES and Atari games that we might be able to revamp/modernize and could also be made quickly. One of the first games to be brought up was Pac-Man. I always loved Pac-Man growing up. It was probably the only video game that I could get my parents to acknowledge and play. Pac-Man has always seemed a bit like a horror game to begin with. You're a big head with a huge mouth running around a dark maze eating pellets and devouring helpless ghosts. After some back and forth, Mark found this image online and showed it to me. 

 I'm not sure who the artist is, but the image really sold me on the idea of a horror version of Pac-Man. We decided we would take a Pac-Man style game to the next level. We planned to accomplish this by developing a game with themed horror environments/mazes, first person perspective, interesting enemies, and a film quality horror story with an awesome antagonist, written by Mike Lee ( Our game is kind of like Pac-Man meets Portal & Haunting Ground mixed with Tales from the Crypt :).

Dark Deception(TM) began development in Unreal 3. After a couple weeks the build was looking decent, but neither one of us had enough experience with Unreal to solve some of the obstacles we were running into.  Learning their scripting language and figuring out the engine at the same time was taking its toll.

It was becoming apparent that continuing to work in Unreal would, more than likely, significantly delay our development process. Even light mapping was more difficult than expected. This made it necessary to switch to Unity in order to keep the dev cycle shorter. Unity vs Unreal is like night and day. Unity is probably the easiest game engine that I have ever worked with. It's not quite as powerful, but it can produce some nice results as well. There are great dev communities behind both Unity and Unreal, which makes it easy to find answers to most of your questions.

Here's the first peek at one of our stages in Unity - the hotel. Every level in our game will different. This level is still being developed and several assets have not yet been added. At this point, the UI is almost non-existent and what is there is very rough. Enemies and items are also not populated throughout the level yet. When designing the levels, I looked at classic Pac-Man maze designs and analyzed what made them fun and which areas could be improved. Pac-Man levels are typically symmetrical and smaller in size. For me, the thrill of Pac-Man is the balance between all of the sharp corners/tight turns and the long, straight lanes. I wanted our environments to reflect that as well, only on a much larger scale. In Pac-Man, you have four ghosts chasing you. As you progress through our game, we up the ante on that a little bit ;).

We are also very fortunate to have obtained the audio services of Chris Pinkston through a friend. Chris has been involved in a ton of AAA games that I am sure you are all familiar with. Just check out his awesome credit list on IMDB ( He has been cranking out some awesome tracks for the game so far.

Lastly, here is a glimpse at the enemy for the this stage - an evil little bellhop toy monkey. This is simply a viewport capture from Maya. He's quite friendly and, just like the ghosts from Pac-Man, he will pursue you - out of love ;). All joking aside, our AI is a bit better than the ghosts in Pac-Man. We are striving for intelligent reactions, movement, and unique attack patterns for enemies in each level. So far, so good...

 Mark and I will try to post at least once a week. Stay tuned for more! You can also check us out on FB and Twitter (!