Category Archives: Programming

Stuck In The Middle With Light – My Global Game Jam 2016 entry

Last weekend I participated in my first Global Game Jam! I had a small team of just me and my sister. Despite the fact our team had less people than others, and neither of us were experienced artists, I think we still completed a neat little game called “Stuck In The Middle With Light“.  The Global Game Jam theme this year was “Rituals”. When I heard the theme, I was pretty excited because I believe I excel in creating an eerie, dark atmosphere. So I thought Rituals would be a very fitting theme for my personal aesthetics. The weekend was a lot of fun, but at times it was one of my most challenging development experiences.

The Game


In “Stuck in the Middle With Light”, you find yourself surrounded by demons lurking in the darkness. The only source of light is in the middle of the chamber, and there are unlit torches by this light. You must place the torches in the proper positions to complete the ritual and expel the demons from the area.

Game Design in 48 hours

Before Global Game Jam 2016, the only game jam I’d ever done was Ludum Dare 34. My entry was a “jam entry”, therefore I had 72 hours to submit my game.  Sure, it was challenging for my first game jam, but I really felt the pressure with only 48 hours in GGJ. The first night was very rough. My sister and I didn’t know Unity very well, so we spent a lot of time slamming documentation into our brains. As we got accustomed to Unity, we started outlining what the game would be about. Once the clock hit 2 AM I was exhausted and overwhelmed with the amount of work we needed to do. In hindsight, we should have just went home and rested the first night. If we had done that, we would have had a lot more energy the next day (Saturday).

At 4 AM, I managed to get over an hour of sleep. Apparently, that was enough rest for me to get back into the development strong. On Saturday morning, we looked at the concepts we had written the night before and scoped the game down to something we could actually finish. With the concept ready, I switched back and forth between making music and programming the game’s initial puzzle. I think it was important that we made a compromise on the game design, that could still fit our initial game idea but was still something we could program in a reasonable amount of time.

Perhaps the most productive time period was early Sunday morning, a little after Midnight. It was the final 12 hours. We defined a list of critical aspects of the game that needed to be implemented or fixed and this gave me the determination to make heavy progress so the game was at a comfortable spot at Noon. I consumed a couple cans of energy drinks and candy to carry me through the night. I finalized the core gameplay mechanics and put my best efforts into the game’s sound effects and music. By 3 AM, things were looking good and the game started to look more complete. I could finally rest and let my sister take over for a couple hours. The rest of the time I spent creating the game’s logo and start menu. As I did this, my sister fixed my terrible enemy A.I. – a case where I was very grateful to have an extra programmer helping me out for once.

First experience with using Unity Engine

This was the first project I had ever used Unity. A few weeks before the jam I decided I wanted to use Unity, because it seems clear that it’s becoming common practice for indie games to use Unity. For a 3D game, it does make a lot of sense to pick up an engine like Unity or Unreal Engine 4 if the engine can cater to your game’s needs. Both engines are battle-tested in major game titles and since 2015 they’re both very affordable for the indie developer. Developers should take advantage of these powerful tools when they can.

I learned a lot about Unity during the jam and it’s a really powerful engine. I can see why an overwhelming amount of indie developers have decided to use the engine for commercial games or just prototypes. Although Unity is well tested, it’s not perfect. Sometimes the editor would crash after I pulled a scene from Git. That was pretty inconvenient. Not to mention, handling Git merge conflicts with Unity scene files is pretty annoying as well. I should have researched a bit more about how to solve them before the jam.


I learned and experienced so much during my first Global Game Jam. What I enjoy about GGJ is that it encourages participants to work at the jam location, therefore it’s really refreshing to be around so many motivated game developers at once. You will definitely feed off the energy. Unity, for the most part, is a great engine to work with. I’m definitely considering it for future 3D projects.


EXPURGET – My first Ludum Dare (34) entry


 EXPURGET – Ludum Dare 34 Entry

Hey everyone, this past weekend I decided to participate in my very first game jam! The jam was Ludum Dare, one of the largest game jams around. I completed my entry EXPURGET in under 72 hours. It was an interesting experience to say the least. I’d like to write a more detailed post mortem this week.

Tools I used for the game

  • Godot v2.0 as my game engine
  • LMMS as my audio sequencer, along with ZynAddSubFX as my primary soft synth
  • Photoshop CS6 for art/graphics


The jam was a great way to test my problem solving and game design skills. I learned the two are very equivalent to each other. It was a lot of work but the time constraint seem to have helped the way I approached the game design immensely. Traditionally, I’ll go on for days trying to plan out a fun game, but for this game jam I had to come up with the game mechanics within hours. It seemed pretty daunting at first but, I think if you can come up with at least your core game mechanics in a few hours and it’s fun from the start then you have a great foundation to build on. I am quite satisfied with how the game turned out because it’s definitely one of the funniest things I’ve created. Stay tuned for more details on the art process, programming, and my experience with Godot Engine.

Stellar Blitz Progress – Accelerators, particle effects, action packed racing!


The new logo

I have made significant progress this month in the development of Stellar Blitz. If you’re new to the devblog, Stellar Blitz is a mobile multiplayer racing game written in HTML5/JavaScript for the client and Node.js for the server.  As I mentioned in a previous post, the game design was originally a twin stick arena shooter but recently I’ve decided to change the game into an epic space racing game.


Game lobby

The transition has been going solid so far. Up to four players race for a star in real time online  multiplayer. Racers can go on accelerators to enhance their speed and get ahead of the competition. They can use their hubble powers to shoot down racers ahead and eliminate them from the race!

Programming racing mechanics has been interesting so far. Prior to development I had no clue how to implement a racing game and my first attempts were quite embarrassing. Now I’m starting to get a hang of the technical and design aspects of the racing genre. I’m also applying what I’ve learned in other projects about good use of particle effects. Particle effects really help a lot in giving a game a good feel. In Stellar Blitz I use particle effects for things like projectiles, backgrounds, and explosions. If programmed well they can save a lot of video memory which is critical on mobile devices because you don’t need a bunch of frames added to a sprite sheet.


Early gameplay

Since I’m using PIXI.js as my rendering engine I did a little search on Google to see if there’s any visual particle editors already out there. And what do you know, there is! PixiParticles is a pretty simple particle engine but it has fit my needs well. I actually like how light it is. I wasn’t looking for anything over-engineered and the editor works fine and loads/saves JSON files. Integrating it with my in house engine was trivial and it saved me a lot of time. I really wanted to work on the game and not spend a few days on a custom particle editor to do the exact same thing this project does.

Stellar Blitz is having solid progress and I’m starting to think it can go into an open beta before the year ends. Stay tuned to get the latest updates and release dates!

Experience with Godot Engine so far

About nine months ago I found an interesting post on /r/gamedev about the Godot Game Engine. It was dubbed as an open source 2D/3D game engine. I thought to myself “What makes it difference from the thousands of open source game engines that are left abandoned?”. As I read through Godot’s website my question was answered. Godot is not a one-trick pony.  Becoming productive in the engine did not take long, in fact, maybe it was two hours for me to learn the workflow and go through the documentation. As I worked with Godot I noticed the engine is really well thought out, because the engine was used to create many games by the original developers. This is great because Godot isn’t just a student project hacked up in a couple months, it has been used and tested for years in-house by Okam Studio.

So why am I using Godot for my next game?

Development Environment


The nearly all-in-one development environment that Godot provides is really impressive. The editor has a powerful animation tool for sprite sheet animation and cut out animations. I’m always surprised how many tools are built into the editor. The best thing about the editor is that it actually uses the engine to make the GUI and it’s really extendable. Making your own modifications to the editor  is stupidly easy because the API is the same as the one you use for your own game in Godot.

Visual Editor

Godot has an interesting idea of a scene graph. There are Nodes, which is the base object for games in Godot (think GameObject in Unity). Scenes are a collection of nodes, and what’s cool about Godot is that scenes can be instanced. When you get used to this workflow it feels really efficient and organized.



There’s no doubt that Godot has a smaller community than some of the more popular game engines. I didn’t jump on Godot as soon as I discovered it. I let the project simmer for a few months to see if the developers can stay active and improve it. I was pleasantly surprised at how much they improved the engine in less than four months. That’s when I knew the developers cared a lot about the project and the community was big on reporting bugs/issues.

Godot’s community may be small, but it’s active and extremely helpful. The lead developer is always open to merge pull requests and consider community feedback. I’ve made a couple of pull requests myself like fixing a couple bugs with the editor and adding functions. They usually get merged in no time. Godot really feels like a community effort, which ironically is rare in open source projects.


Godot’s 2D engine is truly impressive. It has shaders, 2D lighting, shadows, feature-packed Particle system, and Parallax layers. Everything feels extensible, and if I need more power I can always drop down to pure C++  which is great. Picking the right game engine for your game is hard, but for my next game I have found Godot to fit really well for my needs.


Stellar Alien Hotfix v1.80

This week I published a new Stellar Alien update to all platforms (Google Play, App Store, Amazon). In this update a new tab to the pause screen was added to allow you to configure the game’s controller. I talk about this in detail in my last post. Otherwise It is mostly a hotfix for some bugs and polishing existing features.


Hotfix v1.7.3c:
-New control settings. Choose between the static or dynamic controller.
-Fix memory leaks
-Squash some bugs
-Nerf the difficulty of Level 3
-Fix crash


There have been some comments before about the difficulty of Level 3. I am trying to be cautious whenever I decide to make a level easier. I believe the early levels are very easy to complete but I have years of gaming experience. It’s important, especially for mobile game developers, to be able to step outside of their gaming experience and empathize with casual players. Casual players have not played hundreds of video games so some things in your level design that make sense to you will not make sense to casual players. There’s a weird balance you have to try to make, but it’s difficult when you’re trying to please everybody.

Recently a lot of Stellar Alien updates have been focused on squashing bugs. I’m doing this because I’d like the game to be at a very stable place before I start adding more levels and mechanics. Stay tuned!

Stellar Alien v1.7.1 – Progress

Hey there Earthlings. A new Stellar Alien update is in progress! Version 1.7.1 will consist of critical bug fixes and crashes on low-end mobile devices ( I just wish people would buy better devices :^) ). The update won’t just be bug fixes though. It will include some improvements to game experience such as new customization for the controls and dialogue system.


By default the movement controller is fixed in one place on the screen. With v1.7.1 you can use the “controls” settings to allow the controller to be placed automatically wherever you touch the screen. Just check the box for “dynamic controller placement” and it will save the setting. You can change the setting anytime you want by pausing the game and hitting the “controls” tab in the pause menu. Additional customization to the controller, such as the controller size, will be implemented in this update as well.

Overall I’m excited to improve the usablity in Stellar Alien and allow players to customize the game’s experience to fit their needs. Stay tuned for more updates on the progress of Stellar Alien version 1.7.1!

A friendly reminder to start thinking about ECMAScript 6

I must admit I have quite a love-hate relationship with JavaScript. Some days I’m enjoying its ridiculous flexibility while other days I am annoyed by its tolerance for any silly mistake I may make. Although JavaScript has some serious design warts, the ECMAScript 6 standard is here to improve upon the language. I welcome the new features and I am glad to hear that the standard will be finalized sometime this summer of 2015.

As you may know, it will be sometime before everyone will able to write straight up ES6 but luckily we have transpilers like Babel and Traceur to compile ES6 code into ES5.1 (the current standard JavaScript derives from). This is really exciting as you can write code using almost all of the new ES6 features today and it will still work on all browsers. These transpilers are pretty great and I think we’ll be using them for a while until ES6 gets spread around. Therefore, I encourage anyone hoping to improve their JS code base to consider giving ES6 a try. I use Babel personally, along with Gulp as my build system. It’s seriously sweet and it allows me to write more expressive code than I could in ES5.1.

Okay, so if I haven’t convinced you to check out ES6 yet then I’ll overview some of my favorite new features. I won’t go over every single one, just my personal favorites. A better overview of the many new features in ES6 can be found here.

Classes (Syntax Sugar)

This probably many people’s favorite addition to the standard and it is mine as well. ES6 introduces a new syntax for creating classes, basically a blueprint for object instances. Now don’t worry, this is just syntax sugar. You still have the flexibility and efficiency of prototypes, this new syntax just comes in handy when you just want to make a dang class!

Here’s an example:

ECMAScript 5.1

ECMAScript 6


I think the standard did a great job with the class syntax sugar. It’s very simple and the syntax is thankfully not too verbose. This should make many code bases more expressive.

Fat arrow functions

Another great feature is the new arrow function. JavaScript these days is always dealing with callbacks and anonymous functions everywhere. The fat arrow is here to save some key strokes and keep the code looking pretty. Now this isn’t just syntax sugar though, an arrow function has a lexical this. In other words, it captures the this of the context of which the arrow function was created in. This should hopefully save a few headaches of dealing with this and we should see less var self = this; in code bases.



let and const (Block scoping and Constants)

This is also a great addition to the language. Traditionally you would create a new variable in JavaScript with the var keyword. The variable will then be scoped to the function. let, however, creates a variable in block scope. This is neat because now we can bust out variables in if statements or loops without worrying about them being modified by something outside of the code block. I also find let allows for much more readable code than var. It’s worth noting that let is NOT hoisted to the top of the function, unlike variables created by the var keyword.

Additionally, we have the const keyword. This will make a constant value that cannot be changed. That’s pretty sweet and should give us programmers less headaches.



ECMAScript 6 turned out to be a great revision for JavaScript and we can all start developing in it today using transpilers. Many large websites have already started using it, so it sounds to me it’s ready for prime time. At the very least, get some time in the weekend and try it out for yourself!