js:void(0);

When you’re making a game, performance is important. This goes without saying. However, to what extent is it important?

It’s no secret that I use Auth0 for nearly all of my projects. Generally, I’ll just use the base offering, take the token it gives me, and move on. However, this time, I wanted to actually try to more fully utilize some of the features Auth0 provides. I didn’t want to keep having to do a back-and-forth “sign up” flow, where I give my server a token, the server validates it, then checks if I’ve signed up before. If not, it would send a message back saying “hey, you need a username” and that dance would continue until the user is fully registered.

Lately, I’ve been playing with deepstream.io@3.1.1 making a realtime game engine (read: wrapper) on top of it. This has provided me with an innumerable amount of challenges. One of them, today, was trying to set up an authentication service for my self hosted Deepstream instance. Reason being, I’m transitioning away from DSHub, because my needs will not scale with their plans. So, I took the plunge and worked on setting up the basics to get my small project working again.

Or, really, any PaaS, but my examples will use JS.

There are a lot of NodeJS PaaS’ that I’ve worked with previously - I really wanted to take the headache out of managing my own infrastructure. They provide headaches of their own, though. What if:

• For some reason, you start getting 502s on all of your websocket connections for no reason?
• Your deploys get stuck?
• Anything that’s out of your control happens?

Today marks 2 years of my doing “one thing a day” on Github.

I’ve got work to do today, but I wanted to blog first, so today appears empty

I posted about last year, and now I’m posting about this year! I’m not going to do monthly graphs or anything this time around, but I’ll talk about a bunch of projects that I worked on. I’ll split it between my own projects, and other projects. Here are my projects (or projects I’m affiliated with):

Hey folks!

So I have a proof of concept build for Reactive Retro ready. What is Reactive Retro, you say? Well, it’s a location-based game that aims to be like an older JRPG, with a focus on cooperative play. Right now, there isn’t a whole lot though.

So, today marks my 365th day of GitHub contributions. I started last year on June 25th, and today is June 24th. I’d like to talk about what I did, and why I did it. Maybe some tidbits about discipline, too.

Welcome! Today I’d like to talk about another subject which can’t be emphasized enough: Code Quality. This entails a lot of tools and patterns that ultimately come together to make your game more solid and programmer friendly. Even if you’re working alone on a project, these tools can save you some precious debugging time by pointing out simple errors, if not more complex ones. I’ll be using my current project, c as an example where possible.

Welcome! You might be reading this out of curiosity, or because you want to improve your programming capabilities to stop people from exploiting your JS games. Given that the first thing I do when I open a new incremental is open the terminal and start messing around with your games, I figured it’s about time to write something about what I see and how I break your games. Consequently, I’ll describe ways you can protect your games from the basic code manipulations I perform. Some might say “you’re just ruining the game for yourself!” while I’m going to turn around and say “I don’t care” – that’s not the point of this!

NB: This will only apply to vanilla JS applications, which I see more commonly. Frameworks like AngularJS and such are out of scope for this post. Advanced techniques such as using a debugger, while slightly more on topic, will also be disregarded for now.