Ah, I finally experience the so-called “callback hell” in NodeJS. This can probably be fixed with proper design, but my experience is still lacking.
After days of struggling to write SQL in Knex/Bookshelf for NodeJS, I decided to give up and just write raw SQL queries.
Both Bookshelf and Knex’s documentation are outdated, it seems. A lot of the methods I tried to use usually spew “method doesn’t exist” errors, and I spent most of my time just figuring out how to get the method to work rather than test for query results. That was just plain frustrating.
I was asked by a friend to help him out with his project recently. He needed a trustable server guy to do all the back-end work because it involves payment and all that. I decided to take the chance to learn NodeJS, as well as handle all that server admin stuff that I have always thought of doing but was too intimidated to, because of how complex Amazon Services were.
Then, a senior (who happens to be a very awesome server guy) told me about Digital Ocean.
I’ve only ever heard of VPS thanks to my ex-company using it, and at that time they already hit the ground running with Amazon AWS and EC2 and all that difficult stuff. I needed a place to get my feet wet, and this is it. What is DO (Digital Ocean)? It’s a cheap VPS hosting. Uhm… I’m not familiar with this stuff, but it’s like a blank slate for you to do whatever you want on.
Typical webhosting services provide a CPanel or some very restrictive SSH access, which limits the things you can do for your server, like installing necessary software or tinkering with system settings. Most of the time, they have pre-installed services for you (e.g. an older, stabler Ruby on Rails, or WordPress) and you can’t change them because you don’t have the permission to.
Previously, I used OpenShift and Heroku, but found them to be opinionated and limiting, especially since I didn’t know what I could (or couldn’t) do. Although those are free services, I think paying a mere 5USD per month for DO is a better investment for learning and future projects.
Anyway, this is just a post to say I like DO very much. The control panel is minimal and easy to use. The “droplets” & “snapshot” feature is all I need. They have tutorials for almost anything to get you started. I installed NodeJS, MySQL, Git, setup user accounts other than root, and other Linux-y stuff, which I haven’t done in 3 years, all rather easily, thanks to the easy-to-follow tutorials.
With the way things are going, my hopes to write a NodeJS game server one day doesn’t feel that impossible after all.
Even though I am officially unemployed, I have been fortunate enough to have a friend offer me a (sort of) freelance gig. He needs someone trustable to build a backend system for him. I told him I’m more experienced in front-end and gamedev, but he was okay with it. So there we have it, a proper reason for me to learn backend programming.
But anyway the point of this post is some nuggets of knowledge I picked up so far. NodeJS has NPM (node package manager), which is similar to how RoR has Gems. One of them is Bookshelf.js, a library (built on top of Knex.js) to handle database queries.
Most of the tutorials on Google have sample code that looks something like this:
The last part, catch() , was supposed to catch query errors, but I hit the wall for a couple of hours because Node was telling me that catch() is not a function. Turns out, it has been changed to otherwise(...) .
Thanks to Que, in his more recent blog posts for using the function, that gave me the revelation. Phew!
In early May, I got back into Unity3D after a few months of hiatus (because of using Haxe to make webgames), in order to teach basic game development at a local tech community. Naturally, teaching being my first time, I fumbled through each class, learning as I go. Next week will be the last of the 8-week course.
I went into teaching with minimal materials. I predicted I would be able to quickly hack up a working Crossy Road game, then integrate it with Admob, Unity Ads, Google Play Services, and In-App Purchases. I wasn’t wrong — Cumulatively, I spent about 12 hours (6 weeks x 2 hours) implementing all that, excluding the preparation time.
The only problem was, students couldn’t keep up and were left behind early in week 3. It’s too late for them to catch up now, but I’ve provided all the necessary documentation and sample projects for their review. Hopefully this experience won’t deter them from game development.
What did I learn from all this? Preparation takes time. Students are always slow, no matter how simple the teaching material is — They need time to absorb and understand each new line of code before moving on.
The solution? Show them the steps, and let them try it out. Make sure everyone has tried out the step personally, before moving on. Personally guide them, even if I have to go to each student one-by-one. The drawback of this, though, is that classes are drawn out longer, and there’s a lot of lulls in between each step. At first, I thought this was awkward. But after personally attending a few classes to study other teacher’s methods, I realise that this is natural.
Preparing materials has also made me learn a few tricks about teaching too. For example, students can understand better if each new topic is presented in the following format:
- Step-by-step instructions, with screenshots
- Review (i.e. show the preview again)
This allows students to know what they’re expected to do, so they won’t blindly follow instructions without knowing what’s the outcome. The step-by-step instructions with screenshots help as effective visual cue. It also helps if the screenshots come with comments or highlights.
So here is the game that is out on the Google Play Store now — It’s not exactly balanced, but I demonstrated the core game with Ad and Play Services integration. The next update (coming up next week) will implement IAP. After that, I’ll upload the code on Github for everyone to study and learn from it.
I thoroughly enjoyed teaching, although I always felt anxious and nervous, afraid that whatever I teach is incorrect. Perhaps I’ll gain more confidence as I teach more often. Unfortunately, while I hope to continue teaching after this, I’m afraid I have been an indie gamedev for far too long.
It is time for me to seek employment. My savings have officially run dry. My 3-year period is up. My bootstrapped indie journey comes to an end. If anyone is looking to hire, I’m totally available — All my portfolio and links can be found on my Itch.io page.