Why Mobile Games Are Ruining Gaming

First off, I’ve got nothing against the mobile platform or mobile games in general. I even made a mobile game once, and it was a pretty fun experience (sans Apple being an absolute donkey about the whole submission process).

I also have nothing against Flappy Bird. I think Dong Nguyen is awesome, assuming his story is true. He symbolizes an entire industry of one-man indie gamers, and his meteoric rise and fall should serve as a lesson to the rest of us. This post is not about Flappy Bird.

Rather, this post is about two other games I saw on the top charts this past week, and by association a plethora of other mobile games that are slowly destroying the values we indie developers hold dear. This post is about Flying Cyrus and Flappy Miley.

Okay, I get it. Flappy Bird becomes one of the most popular games of all time, not just on mobile devices but on any device period. There are bound to be people making parodies and tributes, even more so to fill the void following the game’s pull from app stores. I understand this need and even welcome it. I learned a lot about basic HTML5 game development from several of the open-source tribute/parody games on GitHub. Terry Cavanagh, creator of Super Hexagon, gave us his own creative spin with Maverick Bird: a game that has quickly become one of my favorites.

So somebody decides to take out the bird and put in a disembodied Miley Cyrus head? Sure, why not. It’s a kooky idea that’s almost guaranteed to stop app store browsers in their tracks. But then — and here’s the kicker — someone decides to rip off that game.

Neither game is particularly good, mind you. Like the original, they were probably created in the span of days. Their assets are horrendous. Their music tracks are thoughtless. Unlike the original, they seem to have been created solely to rake in money. They are shameless. Are they even games? Yes, I’m sad to say. But just barely.

Sadder still, they are not alone. I was mildly disgusted to see a commercial for Farm Heroes Saga the other day on TV — not because I hate Candy Crush Saga, but because this new game is such a blatant clone of it. So you have fruit instead of candy. Maybe it’s a healthier game? Is that what they’re going for? Or are they too busy being wholeheartedly greedy to invest time into making a better sequel?

Right now, we are at the dawn of a new age in gaming. The three giants of consoles have just released their new products and there has never been a better time for indie developers to get their feet wet. All around me, I see amazing and beautiful games being made. Some are AAA like Titanfall and Destiny. I can only hope these live up to the hype. But others are smaller, birthed by studios as small as Dong Nguyen’s, nevertheless having just as much potential to blow my mind.

At the same time, we are increasingly becoming shrouded in darkness, a darkness born out of the basest of human needs to make money, even if it means doing horrible things like churning out knockoffs or forcing consumers to pay to turn off ads. This isn’t what gaming is about. This isn’t why I dreamed of becoming a video game developer years ago.

So I see these things, and I can’t help but feel disillusioned by the whole matter. I spent the better part of 7 months making a mobile game, pouring my heart and soul into every asset and corner of every level. It was a flop. Then these heartless, soulless husks of games dominate the top charts. If you can’t beat them, join them, am I right?

Maybe I’ll make a game called Cyrus Crush Saga. See how King.com likes that.

Advertisements

The Plan for 2014

A Happy New Year to you all!

As this is the beginning of the year, it seems like a great time to lay down some resolutions that I will (hopefully) stick to.

First up, the last few months I have been really slipping off the old YouTube/blog wagon — especially when it comes to tutorials. Granted, I ran out of ideas for things to do (by “things to do” I suppose I really mean “things I’d be willing to invest time in doing”) quite a while back, but tutorials are what my channel is known for. The last semester has been particularly rough because I’ve had a heavy course load in school, two jobs, and a few side projects I’m not even allowed to talk about, much less make a tutorial for. But 2014 should be better. No…it will be better.

Next up: games. I’m supposed to be a game developer, but what did I actually accomplish in that regard in 2013? I made one game. This game took one week to make. The other 51 weeks were not wasted effort, but they were far from productive. I had many ideas that never came to fruition — ideas that I still have tucked away in the dusty corners of my mind. Maybe in 2014 I’ll wash a few of them off and see where they take me.

And finally, it should be no surprise to anyone that UDK is no longer the center of my creative universe. And yet the subtitle of my entire online identity remains “Your Premiere UDK Resource”. As UE4 looms over the horizon and I start to focus more on things like HTML5, Python, Java…well, what should become of my identity? I’d love to start blogging and YouTube-ing about more than just UDK. So in many respects, 2014 will be an interesting transition year.

I’m excited to see where the next 12 months takes us. Here’s to a year of happy gaming!

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?

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.

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!

Python vs. Java

Recently I was wrestling with Google App Engine (the Java version) for what seemed like the millionth time and getting extremely frustrated by it. So I decided to download the Python version and — because I had never touched Python in my life — do a crash-course in yet another programming language.

Verdict? I love it. A few people I know say that Python is the easiest language to learn. There’s even been talk at my school about switching first-year computer science over to Python because of this; it’s apparently a no-frills language that anyone can grasp before midterms. Of course, this talk has as of yet remained just that: talk. Right now freshmen at my school continue to learn Java as I did, and other than the occasional smash-my-head-against-the-keyboard frustration I don’t blame my professors.

I’ve only been “learning” Python for about a week, which is a little over 0.5% of the time that I’ve known Java. So as you read this post, keep in mind that I am in no way qualified to say which language is better (and in truth, no one is). But here are a few of my quick observations:

Brevity

I hate things that look like this:

/**
 * Squares the provided integer. NOTE: this function does not
 * handle integer overflow. If the provided integer is too
 * large, you may get an errant result.
 *
 * @param toSquare the integer to square
 * @return the square of the provided integer
 */
public static int Square(int toSquare) {
return toSquare * toSquare;
}

Of course that was a contrived example, so here’s an actual one from UDK’s OnlineSubsystem.uc:

/**
 * Called from native code to assign the system interface
 *
 * @param NewInterface the object to assign as providing the
 * system interface
 *
 * @return TRUE if the interface is valid, FALSE otherwise
 */
event bool SetSystemInterface(Object NewInterface)
{
SystemInterface = OnlineSystemInterface(NewInterface);
// This will return false, if the interface wasn't supported
return SystemInterface != None;
}

The pet peeve I have with these things is that the code basically explains the comments, which read like a boring novel and have about as much to say as an American politician. These things are scarily common in C-syntax programming languages, and for what reason I have no idea. On the other hand, Python code style rules (to my knowledge) suggest something more like this:

# Squares x and returns the result
def square(x):
return x*x

This is because one of Python’s goals is code readability. If the code can’t tell you what it’s doing, it’s probably bad code.

Project Structure

Somehow someone decided this was a good thing:

A common Java project structure

A common Java project structure

This sort of package control is the norm in the Java industry, and what it does (besides keeping code all neat and organized) is make navigating source trees and online repositories an absolute pain.

On the other hand, so far all my python code — all 5 classes of it — has been in one file in a single manageable directory. If I wanted to I could split the classes up, maybe nest them a folder or two deep…but there’s no point. Python’s import system makes sure of that.

Ease of Use

I can run my code at the same time I’m modifying it and refresh to see the changes. It’s glorious. This is sort of like the much-touted “code as you play” feature of Unreal Engine 4, where you could start the game, hop over to Visual Studio and code, then jump back to the game and see your changes immediately. This is quite unlike Unreal Engine 3, which wants me to shut down the Editor and recompile every time I need to change half a line of code. So far I’m enjoying the freedom.

Conclusion

I like Java too much to take its sometimes numerous faults to heart, and I haven’t delved deep enough to find Python’s faults yet (and knowing programming, I can only assume there will be some). So far Python is great. Should you believe me when I say that? No. But if you’re ever in the Python neighborhood, don’t be afraid to walk around and knock on a few doors. You won’t be disappointed.

Brainstorming the Next GOTY

I’m in that little creative space between the end of one project and the start of another, where all I’ve got to go on are ideas. School has occupied a lot of my time for the last few months, but summer is coming up and I want to find something to fill the void. Making the next GOTY sounds like a good way to do it.

Come on. Who are we kidding.

Okay, so I don’t plan to sweep the awards and cart them home in a wheelbarrow next year, nor do I plan to tell you how to do it, either. When was the last time you walked into a bookstore and saw a Success for Dummies book? (Actually, there is one…but I’d advise you not to buy it). What I can tell you about is what other people have done, and why what they do works.

Think Outside the Donut

For starters, if you’re planning to make a GOTY you’re going to need to think “original”. This is pretty much a given, considering that rehashes and copycats are a dime a dozen and worth less than that. I don’t have to be a big-name video game critic to tell you that the latest Call of Duty fresh off the production line isn’t likely to win awards (Treyarch, if you’re listening, feel free to prove me wrong). Now “original” doesn’t necessarily mean completely radical; BioShock: Infinite is already a strong contender for 2013 GOTY and it is an incremental installment at best.

The problem, of course, is how to come up with such an “original” idea. As a freelancer I’ve seen many indie developers strive to reach this very end, only to fall back into the trenches of “okay, it’s gonna be an FPS, the marines are landing on an alien planet and before you know it…” It’s disheartening after a while, more so when I’m powerless to help. I was never good at coming up with ideas, anyway.

Simple is Better

Thankfully, there’s Google. And what Google and a bunch of research has taught me is that ideas must start simple. You can use the cliche analogy of an idea as a tiny seed growing into a giant oak if you want. And by simple, I mean something you can tweet about. Less than 140 characters. No 20-page design documents, no whiteboard filled with doodles. Simple is something you can tell a guy in the elevator before he gets off on the second floor.

Jenova Chen, perhaps better known as that guy who made 2012 GOTY Journey, once wrote a brilliant Master’s thesis on his creative process. He has centered game development around the idea of Flow, a concept first pioneered by psychologist Mihaly Csikszentmihalyi (me-high, chick-sent-me-high), which basically states that a game should match its difficulty level to a player’s abilities to maintain maximum interest. Chen has certainly been successful at this, seeing as how I couldn’t stop playing Journey once I started. I hope to talk more about Flow later, but for now you should read the thesis. It isn’t boring like a lot of other academic work, trust me.

But thatgamecompany is known for even simpler ideas. What they do is base entire games around emotions. Think: “I wanna make a game that makes people feel peaceful”. That’s certainly something you can convey over the water cooler during 30-second breaks. Where to go from there? Well…what makes people feel peaceful? Water maybe? What are peaceful colors? Blue? How about nice peaceful ambient bell sounds? Mmm…no timer, no rush, no feeling of failure. After a bit more work you’d have Flow, Jenova Chen’s first well-known game.

I wanna make a game that makes people feel companionship. Wait, is companionship even an emotion…? Ahh, let’s roll with it. How do you make two people become companions? Get them together, make them work together…well first they have to be alone. And they have to want companionship. How about…a desert? A big open desert? And…suddenly they meet someone and —

You get the idea.

Sounds easy here because I reverse-engineered it knowing what the end result was. But it’s not easy. I’m not saying any of it is. Hopefully, though, forcing yourself to think simple and think small will help you focus your ideas into something that will blossom. All it takes is time.

Another Example: Education

Miegakure is a 4-dimensional game. Yeah, that’s right. A game in four dimensions. I don’t remember when I first heard of it; it’s been out there a while now and I believe it’s still in development. But what you see in the video above are two seasoned game developers with a very important message.

They, too, like to start with simple ideas. But they take an entirely new direction: education. Basically, you take one “little nugget of truth” you want to “teach” to the player. In the case of Portal, that might be how gravity works. Then you “package” the nugget up. When the player plays the game, they uncover the nugget of truth and “learn” it, usually without even realizing it. And in so doing, their connection to your game becomes that much stronger.

I use Portal in this case because I experienced this very thing with it. I didn’t take my first physics class until a year after playing the game, and while I was learning about kinematics I had a eureka moment where I like, “hey wait a minute, I learned all of this in Portal already!” Perhaps some of you can relate.

This way of brainstorming ideas is especially strong because it also be applied to very small portions of your game (for example, individual levels or even components within those levels…you can see a few later on in the video, but I won’t get into them here). It is also much easier to build off of. Unlike an emotion, which is abstract and often difficult to translate to concrete things like characters and assets, a “lesson” has a concrete fixture in our world — whether it be gravity or math or how to play an ocarina.

What Now?

If you read this expecting a recipe for making good games, or maybe even a list of good game ideas I’ve come up with, I apologize. Unfortunately, brainstorming is sometimes the hardest part of the process and everyone does it differently.

As for me, I’ve used exactly what I’ve written about here to come up with a little nugget I think is worth wrapping up, watering, tending, and growing. Only time will tell whether it’ll grow into a big GOTY oak…well, that and actually making my ideas reality 😛

As always, happy gaming.