Something Classic Games

Hello again from Canadia! Another exciting week has passed and lots of work was completed by the Something Classic team! Our current goal is to reach an alpha state, meaning the game is playable from beginning to end, complete with a credit roll, before doing a final polish pass on the game and adding any extra effects or art to make the areas really radiate. With Luke hammering out some marvelous maps at a super-human pace and Tyler converting our game script into interactive game scenes right-after, our alpha-goal feels like a stepping stone away!

In my last blog post ( Weekly Devlog #3: Battle System and Action Queues) I focused on the battle system and revealed how it was designed from a technical point of view. This week I’m going to mix it up a bit and talk about the tools I personally use to program features and to debug my inevitable failures when the game world explodes in miraculous fashion. As always, Click the thumbnails to view full-sized screenshots :).

If you don’t already know, “Shadows of Adam” is being built using HTML5 APIs, and the game engine we are using is ImpactJS. One of the biggest obstacles we’ve had to deal with because of this web-based tech stack is debugging. Debugging an interpreted language like JavaScript is significantly more tedious than a compiled language. For a long time, we were using console.log() throughout the code in order to determine if everything was working how it should. This is not an efficient way to work, and if you have a small team like us, you want to streamline your development process as much as possible. Work smart, work fast. Thus, in order to help deal with this debugging mess; I ported over the entire game and engine to NodeJS, and then used a wonderful little code oscillator called traceGL to analyze our JavaScript code in real-time as it runs. TraceGL allows me to filter through the entire source code for certain keywords, in the image to the left I search for “font” and receive a list that is updated in real-time with all of the calls to the font class. From there, I can find the “Darkness knows no bounds” text and trace to the exact place where it is being called. In this case, it is in our “dramatic-message” event command code. We can then trace further and load-up the dramatic-message code and analyze the particular function and receive visual color-coded feedback on the state of each variable in that particular function (True/false). These features are an absolute lifesaver because it allows me to see the code running in real-time and helps narrow down potential issues. The GIF image below is one such bug that would have been a pain to fix if not for traceGL. I honestly had no clue what was happening when I saw it for the first time!

The cause was because of a bug where the game started processing the next queued action while the previous action was still clearing itself up; but it only occurred when certain actions were performed in a unique sequence. Typically, when an action is complete it fires a signal telling the action queue that it is done, but because of the way the actions were queued up, a timer-based action can end up overlapping a trigger-based action which caused the queues to fail the timer-based check and never terminate while it starts processing the next action. So when the “HealAll” spell was cast, it was trying to tell the queue manager that it’s code was complete. Except the queue manager received a signal from the prior action saying “I’m not done yet” so it continued processing BOTH actions simultaneously until the end of time. Blargh.

Of course, TraceGL isn’t the only tool at my arsenal. The most important one by far is my integrated development environment (IDE), and for that I turn to Webstorm 10. Webstorm is the Visual Studio for the web, and I honestly couldn’t imagine working on SoA without the powerful feature set it offers. It also has some wonderful debugging options (Complete with line breaks!), but typically I rely more on TraceGL for a more in-depth and visually appealing way to see what my code is doing at any point in time. Like Josh mentioned earlier, we use Git as our version control solution and it has saved our asses many times. If you’re working on a project of any size, make sure you use a version control solution. You’ll thank us later! Webstorm has GIT built-in so I typically use either the built-in GUI or the terminal console straight in the IDE. By using Webstorm and TraceGL in tandem, it provides a very powerful platform for code debugging and helps make me a more efficient programmer.

Full list of tools I use: (Every team member may have minor variations of this)

• IDE: Webstorm 10
• Development Server: WAMP
• Version Control: GIT via GitHub
• Game Engine: ImpactJS
• Programming Language: JavaScript, PHP
• Level Editor: Weltmeister
• Code Debugging: TraceGL / Webstorm
• Bug Tracking: Git Issues
• Feature Progress: Axosoft SCRUM
• Binary Distribution: Electron
• File Sharing: Dropbox / FTP
• Game Script / Design Document: Google Docs
• Game Object Tracking: Trello / Google Sheets
• Team Communication: Skype / Email