LTU Forge Global Games Jam

Participated in my first games jam a couple weeks ago, the LTU Forge Global Games Jam. Super fun, a little stressful at times, but it was so exciting to be able to do it in such a welcoming environment. Coming out of it, I feel inspired and more experienced for having done it. I really want to do another; a feeling similarly expressed by my friends.

Carl Escape is a narritive/dialog based game, so naturally that was the first system we worked on.

Multiple dialog bubbles with focus on the currently talking character was the implementation we went with after a few iterations. Blukat worked on the data structure that backed this one.
While the final game had only two characters, it allowed for dynamic names, backgrounds, and choices in the dialog tree.

As the art and storyline came in from JD, JabberJaws, and BearAxe, Blukat and I plugged in the assets into the API, everyone coming together when things needed final tweaks. Half way through, the dialog front end was mostly complete so I switched over to working on the minigames.

Powered by Hexo Logo Fursona by TFOTR

Vue.js render() and $slots; Corrupt DOM

Just ran into an issue today when making a component with a custom render() function and messing around with vnodes passed in via $slots. A seemingly simple template produced really odd results where some DOM elements would disappear, some would be duplicated, some would be out of order, and others would have their inner content ripped out to their outside after a few rerenders. Small template tweaks would also produce vastly different output, sometimes seemingly correct output.

You can see an example in this codepen:

See the Pen Vue.js $slots with and without v-bind:key by Peter “Cobertos” F. (@cobertos) on CodePen.

Is WebAssembly faster than vanilla Javascript?

I keep seeing GitHub issues of people just like me trying to figure out what WebAssembly (Wasm) and previously asm.js mean for performance-related javascript (in my case, games). WebAssembly should introduce less abstraction between you and the hardware and so your code should in general run faster, right? In reality this question is harder to answer because WebAssembly runs in a Javascript VM-like environment and was not made directly motivated for performance. I’ll be putting aside the misinformation and anecdotes to hopefully find out if and how applying Wasm might make your projects more performant.

A bit of background on Wasm

Wasm was originally created for so much more than just performance. Wasm is about providing a proper compile target for native code to get into the browser. In the earlier stages of the development cycle, Wasm was actually asm.js, a unofficial JavaScript standard that only supports strict subset of JavaScript to allow native code to compile and run in a JavaScript VM. Wasm is also about providing an environment where multiple sources of code can run safely at a low level where things like memory management and control flow structures (jumping and loops) matter. Already Wasm is doing a ton of things that previously were infeasible or a real pain to do in the browser. (Sourcing a lot of this from this blog post by Adrian Colyer. It’s good to keep this in mind while we ask performance only questions.

Wasm loads much quicker than Javascript code in pretty much all cases I’ve seen that is not really a topic that’s up for debate so I’ll skip over load performance and focus on runtime performance.

Chemistory Level and Net Code

Chemistory over the past couple weeks got a few new features, the biggest being an actual level and client/server networking code (or at least the start of it).

There’s a separate build for client (Browser) and server (NodeJS), both of which run THREE.js and Oimo.js, though the server doesn’t actually render anything. It took a switch to Gulp from Grunt, a pull request to WWOBJLoader2, and heavy use of ifdef-loader but it all actually talks to each other. Next steps are to add boilerplate for RPCs and member syncing and test out a little bit of multiplayer.

I really hope this goes quickly! I want to get back to game play and UI so I can start play-sharing it with my friends.

HelloWorld Games Jam Outcome

My current company, HelloWorld, hosted a small games jam after hours. Over the course of 5 days, James (another dev at HW) and I put together two small concepts utilizing a networking engine one of my other coworkers wrote

The original concept for my game was platformer where the player must escape a pool of rising lava and race her friends to some sort of goal. The first step was intergrating the networking engine with THREE.js and physics to get 3D aesthetics and correct movement. The actual gameplay is quite shaky due to integration problems and time limitations. Once the boilerplate was as complete as it could be, I spent a bit of time throwing together a test level and playtested it with James. For some added spice, I tried my hand at adding an animated model for the player. THREE.js and Sketchfab made this easier than I expected though I had to use the converted GLTF format SketchFab provides (THREE.js’s THREE.FBXLloader doesn’t support animations and has other corner case issues). Given the time constraints this is as far as I got but I say for an 8 hour game jam that’s not too bad.

Super exciting and I’m looking forward to the next time I get to participate in a games jam. I’ve been keeping my eye on the The Forge to see if Lawrence Tech will host in 2019 where maybe a few people from HelloWorld can participate.

Automated Memory Leak Testing in the Browser

Large single page web applications have a disadvantage over multi-page applications in that no page reload occurs. This means memory leaks are able to cause more performance problems in single page web applications as the lack of page reloads will not clear the javascript heap. While catching these leaks can be done by manually memory profiling, I will show you an automated test that will give a glimpse at whether memory leaks may be occuring.

The actual test is pretty simple though it requires Chrome to run. This is because Chrome comes with some nifty flags that let in browser tests do things other browsers can’t.

  1. Chrome is the only browser that has the ability to read precise memory usage via javascript. This is enabled by the --enable-precise-memory-info flag.
  2. Chrome also is the only browser that allows you to trigger the garbage collector from javascript. This is enabled by the custom javascript flag --js-flags="--expose-gc"

Where I currently work, we use the Karma test runner for testing so setting up different browsers is as easy as installing an npm module and adding the browser to the build with the given flags.

After adding Chrome to your test runner, you will want to add the actual memory test. The memory test consists of a few parts.

Theme's Done

Took longer than expected and there’s still some little tiny niggles but everything’s back to about where it was, except better. Sharing buttons (not just Tumblr’s), social links, no more glitchy WebGL background (sadly I miss it but it was too much to maintain), a better build system, post excerpts, CDN, sub 1.0s page load times. Buttery smooth.

Expect hopefully a couple tutorials, some game development, and maybe some sewing/cosplay in the near future!