A Note on Noat

Ever since I started college, I’ve been working almost on a daily basis on two different computers: my desktop at home, and my laptop at school. I also occasionally do things on my phone. Having this many devices to keep track of radically changed the way I work. For example, I do most of my homework directly out of Dropbox to keep it synced across both computers.

But one thing I’ve always struggled with are notes. What to do with that little 3-sentence blurb I caught on my laptop but now need on my desktop at home? How can I let my laptop know the URL of the important site I just found on my phone?

My old solution was the tried-and-true email system. Yeah that’s right…I’d send myself emails. Lots of them. And the more I delved into the murky waters of computer science and game development, the more emails I found myself sending. I needed something else.

Wunderlist? Evernote? No. Pastebin? Tried it. GitHub Gists then, surely. No, I needed a tiny bit of privacy. What then? Dropbox? I didn’t feel like managing a text file of notes to myself on top of everything else.

Oh wait, I’m a programmer.

So I made this thing called Noat. It’s yet another note-taking app that looks like this:

A look at Noat

A look at Noat

The image above showcases some of the features of Noat. It’s basically just a long stream of small boxes, each with a title and importance level (gray – default, blue – info, green – success, yellow – warning, red – danger) and some content. The content can contain some pretty rich formatting and even embedded images and URLs. But what sets Noat apart (at least in my opinion) is its simplicity. All you get is this stream of notes. You can edit or delete existing notes, or add a new one. That’s it.

It’s powered by App Engine and is built to be responsive, so you can use it on your mobile devices as well (and you can add a home screen shortcut on iPhones!). If you’re at all interested, the code is living over on GitHub.

I’ve been “testing” Noat for several months now and am exceedingly pleased with it. Hopefully someone else will find it useful as well.

Advertisements

Parse Is Awesome

There’s a maxim in software development that goes something like this:

If you have a great idea, someone is already working on it.

For me, the “great idea” was a simple, easy-to-use online game service (preferably free). For me, the “someone” is Parse. Given the amount of research I do into all things gaming, its a wonder I didn’t know about these guys before. They’re awesome.

You could wander over to their site to see why, but let me highlight a few of the more important things here. First off, they’ve created a system far better than I could have ever managed with either Gemini or Sagittarius. Parse is powered by Amazon EC2, comparable to Google App Engine in performance. And they have a pretty crazy database setup that focuses on MongoDB — what I would use for Sagittarius if I had a choice — but also includes MySQL, Cassandra, and Redis.

One thing I’m wary of about third-party services is that they usually kill on pricing or membership. For example, Steamworks is notoriously hard to get into for the average weekend game developer, and most other existing backend services offer pay-as-you-use, meaning nothing is free. But Parse offers one million request ops per month free. To put that in perspective, that’s about what Gemini clocks in at (it gets around 30000 hits a day at peak), and I’m servicing over 200 regularly active users. For someone just demoing a game or even sharing it with friends, Parse is perfect.

Just make sure you don’t go over 1 million though…$199 a month is steep. On the other hand, I always say that if your game does become that popular you probably wouldn’t worry too much about $199.

I got set up with a Parse backend and SDK in a little over 1 minute. I have been playing with it for a few days now and it does everything I’d want a game service to do. I’m planning to rewrite Dave Likes Pizza to use Parse as a better test of the backend, but from what I’ve seen it’s great.

At this point you might be wondering, “well what about Sagittarius?” In truth I have no idea. I was running into the proverbial brick wall in many ways with Sagittarius, and have spent a good part of the last month searching near and far for solutions. That’s how I found Parse. But now that I have this solution, I don’t know what’s going to become of my own service. Maybe I can turn Sagittarius into an UnrealScript/UE4 SDK for Parse?

Unreal Engine 4 at a Glance

I recently got the amazing opportunity to try out Unreal Engine 4. I hope to post more detailed info and a review of the engine at some point in the future, but for now I can only confirm a few things you should already know:

  • UnrealScript is dead, long live C++
  • Hot Reload (also known as Runtime-Compiled C++) is awesome
  • Dynamic global illumination (SVOGI) isn’t a reality as I mentioned in my lighting tutorial; Lightmass is sticking around for the foreseeable future
  • Epic Games is really good at living up to their name

Oh, and then there’s this:

A simulation of our Sun in UE4

A simulation of our Sun in UE4

One million lit, collision-enabled particles running at a silky-smooth 30 FPS on my middle-of-the-line rig. With UE4 around, the future of gaming looks equally bright.

Cloud Platform as a Game Service

Google has recently really been pushing their cloud services as a solution for game developers. Let’s take a look at a few of their blog posts in the last week, shall we?

  • November 3: Yes you can use Google Cloud Platform for a mobile game backend, and here’s the sources for two projects showing how
  • November 4: Hey look, a Japanese company uses us for their social games!
  • November 5: The super-popular word game Ruzzle runs on the Cloud Platform
  • November 6: Yup…
  • November 7: Real-time games are possible too, with Compute Engine, Node.js and WebSockets

In other words, what I’ve firmly believed ever since I created Gemini oh so long ago. Only now developers are buzzing in the “mainstream” media (“oh wow this is amazing and innovative and cutting-edge look what’s possible in games with App Engine whoaaaaa”) because Google is saying it. DANGIT GOOGLE.

On the other hand, I’ve been slowly growing disillusioned with App Engine as a game backend. The most glaring reason is this, quoted directly from the docs:

Because all queries are served by pre-built indexes, the types of queries that can be executed are more restrictive than those allowed on a relational database with SQL. In particular, the following are not supported:

 – Join operations

 – Inequality filtering on multiple properties

 – Filtering of data based on results of a subquery

Such things are almost essential in implementing game systems like leaderboards and server filtering. And Cloud SQL, the other Google-backed alternative, is still SQL (in other words, too static for the ever-changing data a game can produce).

It’s tough. Because just now when I’m facing a ton of dilemmas with my own Google-powered game service, Google comes out and says they have the answer to all my problems.

Still yet, I’m excited to see what people can come up with now that the idea of the Cloud Platform as a gaming solution is more widely known.

A Quick Clarification

Yeah that’s right…I’m still alive! I’d love to blog more, but I’m currently working on some things I can’t really talk about.

But today, I’m coming out of the shadows long enough to answer a few Frequently Asked Questions about Sagittarius. They are along the following lines:

  • What exactly do we get with the download? What is this App Engine thing?
  • What is a Starter Kit? Do we need it?
  • Modules? What are those? Where do we put them?
  • Okay, so I have the app running and my Starter Kit and some modules, how do they go together? What do I do now?

Since I’m a visual learner, I figured a diagram would help:

How Sagittarius and its various components work together.

How Sagittarius and its various components work together.

Remember, Sagittarius is a game service. You can think of a game service as living on a server somewhere (let’s say, in Antarctica or something). This is called server-side. On the other hand, your game is living on the computers of whoever’s playing it. This is called client-side. You may recognize “server-client” in the context of multiplayer games. It’s the same principle.

The thing that you download from the Downloads Page is the Sagittarius Application. This is a Google App Engine application, built on top of the App Engine datastore, that lives server-side. You can talk to it via an HTTP request just like you would any other Internet application living on a server.

Starter Kits are client-side code. With a Starter Kit, you have enough to begin talking to the Sagittarius Application from your own game without having to worry about things like HTTP requests and AJAX calls. What about modules? These add to the functionality of your Starter Kit, enabling it to do more cool things like handle servers or Messages of the Day.

So why all these levels of code and all these arrows? Let’s have a closer look at the example in the diagram. Here we see that a Sagittarius user (let’s call him Bob) has deployed a Sagittarius Application and is using two Starter Kits, one UnrealScript and one JavaScript. The UnrealScript Starter Kit (and associated modules) is powering his UDK game. The JavaScript Starter Kit (and associated modules) is powering his game’s website. Notice that they’re both talking to the same server-side application. That means he can display the same leaderboard in-game and on his website.

Bob could totally download the Java Starter Kit and make an Android app to display his leaderboard on mobile phones if he wanted to, too.

That’s the power of Sagittarius. I hope this clears things up 🙂

Sagittarius v0.3 Released!

You can get the latest version on the downloads page. Warning: the documentation on the wiki is currently a bit behind, but should be up-to-date within a week or so.

This version has been over a month in the making, but it comes packed with a lot of new features. One such feature is a leaderboards system built right in from the start. Underneath the hood, leaderboards use the same exact DBObject model as everything else in Sagittarius, but I decided to include them as a “special case” server-side to boost performance.

New also is the Modules page, where you can find plug-and-play code to enhance Sagittarius client-side. I have only a few classes there already, but I hope to have lots more in the future (and perhaps one day open it up to the community…if there ever is one :-P).

There is also now a JavaScript Starter Kit. To demonstrate its capabilities and the new leaderboards system, I made an HTML5 game called Dave Likes Pizza.

It’s funny how sometimes the smallest things can snowball into gigantic problems. While designing the leaderboards system, I faced a unique problem: how to properly grab and store the client’s IP value on demand. It didn’t seem so tough at first, but I quickly found out that there’s no way for the client to reliably get its own IP. For example, my working computer is masked behind my router, so it only ever “sees” the local IP (which of course is useless to other computers). The solution to this problem eventually caused me to rewrite Sagittarius from the ground up.

Version 0.3 therefore comes with a much more robust system, outlined in the design spec. In particular, there is now support for mustache templates. Admittedly there’s only one mustache right now, {{IP}} (which as you can guess is substituted for the client’s IP in the preprocessor), but I hope to have more soon.

As always, if you have a cool feature you’d like to see or run into any problems, don’t hesitate to submit an issue over at the GitHub Issues Page.

Making an HTML5 Game in 7 Days

TL;DR

I made an HTML5 game in JavaScript called Dave Likes Pizza over the course of a single week. You can play it here or view the sources here. This article is about the development process, which is rather interesting because I previously knew almost nothing about JavaScript or web development.

Day 1: Ideas and Research

The first most pressing question might be, “Why HTML5?” I have experience in a few game engines (Unreal, Sparrow, LibGDX, SDL, to name a few), none of which have anything to do with the Internet. But I think that the Internet as a whole is approaching a sort of technological singularity, in that it is quickly becoming possible to do anything on the web. If you don’t believe me you can check out this page of WebGL demos. Probably no one knows this better than Google; they even have a thing called a Chromebook that is essentially a lump of hardware with a browser. And weird thing: it can do stuff.

So I decided to try out HTML5. Because I knew nothing about JavaScript development, I did a bit of research (this involved going to Google and typing in “JavaScript game engine”). Turns out most of the solutions available are still in development — this is a cutting-edge field, after all — and the ones that look viable cost lots of money. If you’re looking for a good resource, try this comparison of Javascript engines. Ultimately I chose CraftyJS, mostly because it seemed easy to pick up.

Day 1 ended with me working through the basic CraftyJS tutorial.

Day 2: Brainstorming

It’s important to have clear goals before you start banging out a bunch of code. My goal was to create a simple game to showcase new features in my Sagittarius game service. In other words, I didn’t want to make the next Halo, but something like Snake or Frogger was within the realm of possibility.

Of course, being me, I also didn’t want to just make Snake version 1329092. I wanted something at least a tiny bit original.

At some point I remembered my days in high school, programming games on a TI-84 scientific calculator (fun fact: TI-BASIC was the first programming language I learned). One of the first such games I made was Avalanche: guy on bottom, spikes on top, guy dodges spikes for as long as possible. Simple. So simple, in fact, that my TI-84 version with a little O guy dodging V spikes was only 92 bytes of code.

But how to make it original? The crucial step towards Dave Likes Pizza was wondering why the guy had to dodge the spikes. What if he wanted to collect them? Of course, no one really wants to collect spikes. But spikes are triangles, and I quickly realized that another triangular thing is pizza. From there the rest of the idea was trivial.

In case you’re wondering, I was talking to a guy named Dave when I had this epiphany (well, more like listening halfheartedly, since my mind was on Avalanche). I’m not sure whether real-life Dave likes pizza, but I can tell you he is much less square.

I also played around with some Crafty code but didn’t really accomplish much on Day 2, other than getting the pizza idea down.

Day 3: Prototyping

Here’s a screen from about the middle of Day 3:

An early development screenshot of Dave Likes Pizza

An early development screenshot of Dave Likes Pizza

You’ll notice Dave there, looking all nice and green. You’ll also notice that the pizzas are squares and brown, not the most appetizing combo in the world.

This sort of thing is called prototyping, and anyone who’s done any serious software development (related to video games or otherwise) should know about it. For those of you who don’t, the basic idea is to keep everything as bare-bones as possible for as long as possible. To understand why, suppose I went and spent 2 or 3 days making nice artwork and assets for the game, then busied myself with coding and found out I couldn’t complete the game. I would have just wasted a whole bunch of time.

On larger projects you’ll usually see teams of people, maybe one working on the code and one working on assets. Eventually they’ll have to collaborate, but there’s a reason why they’re split into separate teams. Working on a prototype makes it much easier to iterate builds and you don’t have to worry about linking in a bunch of .png’s and .mp3’s and junk.

For Day 3 and much of Day 4 I worked on this prototype, getting the details of the game down. Eventually I added a timer and a pause button.

Day 4: Asset Creation Begins

I still coded a lot on Day 4, but I also spent a bunch of time in Photoshop. It was time for me to decide the artistic direction of Dave Likes Pizza.

Not a difficult decision at all, it turns out. Pretty much any game with food as a central component has to be whimsical in nature. It’s like an unspoken rule or something.

My greatest inspiration was Tiny Wings, which you might be able to see evoked in the concrete textures used throughout. It’s actually a really great way to create nice-looking game art really fast:

  1. Make a vector outline of your scene in pastel colors
  2. Overlay a concrete texture in photoshop
  3. Crank up the saturation to bring out brighter colors

Everything in the game, including the pizzas and the power-ups (which I designed on Day 4) follows this strategy. To test things out I put the final background image into the game and left it there until the end, but I kept the pizza sprites out because I still hadn’t figured out Crafty’s animation system.

Day 5: More Assets

In most Avalanche games the spikes magically disappear when they hit the ground; the apparent implication is that they fall “behind” the ground and out of sight. The real reason is that keeping spikes around will eventually crash the game, since Avalanche theoretically never ends. If someone survives for an hour, imagine how many spikes they’ve dodged! There’s no way to represent them hitting the ground realistically.

However, Dave Likes Pizza is a game about collecting as many spikes (a.k.a. pizzas) as possible, which makes no sense in the context of a never-ending game — so I imposed a time limit of 2 minutes. At a rate of 2 pizzas spawned every second, this means roughly only 240 pizzas per game. That’s a lot, but certainly nothing a browser can’t handle. My major innovation of Day 5 was to keep the pizzas around even when they hit the ground.

My final sprite sheet shows how this mechanic works for pizzas and power-ups. It’s fairly simple: when the pizza/power-up object hits the ground, kill it and replace it with a 2-image static animation corresponding to the object.

On Day 5 I also finished coding the power-up logic and added a whole bunch of sounds into the project. One AMAZING resource for this was Kevin MacLeod’s site. I can’t recommend this site enough for great free game music!

Day 6: Menus

First, a progress screenshot:

What Dave Likes Pizza looked like on Day 6

What Dave Likes Pizza looked like on Day 6

By the start of Day 6 the actual game was pretty much complete, including a last-minute swap to the Acme font from Google Fonts. But…the pause button didn’t really do anything. In fact, there were no menus at all.

To rectify that I decided to build a simple menu and have it working by nightfall. It turns out that working in JavaScript is absolutely beautiful for this sort of thing because menus can be coded in HTML. Each menu “button” is essentially just a text field with a link reference to another menu/scene. My leaderboard is just an HTML table. That little line to submit your score at the end of the game? That’s right, it’s just an HTML input form. And because I had set up my CSS correctly, everything was immediately styled exactly the way I wanted it.

In all, the logic for the menus takes up less than 50 lines of code, and only took about two hours to write (and much of that time was spent drawing the game logo and figuring out how to animate its bounce).

On Day 6 I minified all my JavaScript code and uploaded it to GitHub Pages. Then I shared a link to the game on Facebook to let a few people play it and see how it would fare. How did it turn out? Well…

Day 7: Last-Minute Fixes

Another unspoken rule about video games (besides the “games with food have to be whimsical” thing) is that if things go wrong, they’ll usually go wrong right away. This is why beta testing exists and should be mandatory.

But since my company — insert mocking laughter here — consists of one person who’s both the CEO and on janitor duty, beta testing is a luxury I can’t afford. The initial reception was that my game was cool but full of bugs, one of which was the fact that the leaderboard had stopped recording scores after 9 or so entries.

I rushed to fix the problem and traced it to a quirk in App Engine, the service that’s hosting Sagittarius that’s powering the leaderboard. Sagittarius stores leaderboards in compressed JSON format in a single entity property element. If that’s gibberish to you, just imagine each leaderboard as a long unreadable string. By default App Engine doesn’t allow strings longer than 512 characters, which is why new scores weren’t being recorded. So I had to rewrite the whole leaderboard system — insert nervous laughter here — and upload the new code.

There were also a few cosmetic issues, none worth going into detail about. All were corrected by the end of Day 7.

Closing Thoughts: JavaScript

JavaScript is wonderful and weird. Wonderful because:

  • Like Python, which I learned a few months ago, it’s insanely easy to learn
  • Like Python, it has dynamic typing (no need to declare what type a variable is!)
  • It has anonymous functions, which solve all the problems I have with Java
  • It’s interpreted! No need to compile, just reload the page!

Weird because:

  • Everything is a function, so OOP is really hard (but not impossible)
  • If you screw something up, good luck finding it 😛
  • Variable/function scope — probably only CS majors will understand what I mean by this, but dear God it’s horrendous in JavaScript

In short, I would highly recommend learning it. Especially if you plan on doing any sort of web development, like making a personal site or something.

Closing Thoughts: Dave Likes Pizza

If I charged $1.99 for people to “buy” Dave Likes Pizza, I would have already made more money than on my previous game Never End, which was $1.99 on the App Store.

I’m going to assume that this is a good thing and that I’m headed in the right direction as far as video game development is concerned. I really enjoyed the condensed development process; it seems like forcing myself to get the game out the door in a week caused me to make smarter choices and better design decisions.

Thank you to everyone who has already tried Dave Likes Pizza, and if you haven’t already please feel free to give it a go. And as always, happy gaming!