My Filipino Dishes (with Science!) pt 2: Giniling

In this series of posts, I’ll be discussing the different Filipino dishes that I’ve been cooking and experimenting on for quite some time now.

« You can find out more in the introductory post.

Just two quick notes for all recipes:

  • Most of them, when paired with rice, will serve 3-5 people.
  • I will only show pictures of the ingredients. I’m leaving the “take a picture of the dish” to the foodies. Go to Google Image Search if you want pictures of the dishes.

For this first recipe, I present the very first dish I learned to cook on my own:

Giniling

(Ground Meat Soup… ok, that translation sounds weird. It’s like saying Chili is “Ground Meat Chili Soup”)

Giniling

in the picture: small carrots and potatoes in place of medium

1/4 kg ground beef
1 medium carrot, diced
1 medium potato, diced
1 small onion, minced
2 cloves garlic, minced
1 beef bouillon cube
1 small bay leaf
2 tbsp soy sauce

Step 1: Put the beef in a pot (I prefer stainless steel) over medium-high heat. Stir the meat around once in a while to evenly brown it. As the beef starts to brown, dump in the onion and garlic and saute them along with the beef.

Step 2: When the beef has finished browning, add the rest of the ingredients. Add water until the vegetables are fully immersed. Cover the pot and let it simmer (stirring occasionally) until the vegetables are cooked. Season to taste and serve.

Giniling (literally: ground- e.g. “giniling na baka” is “ground beef”) is a dish made with ground meat as the base. It has many variations, the most common of which resembles Picadillo – ground beef with minced/diced vegetables and tomato sauce. The dish can easily be tweaked to make the other versions and we will go through them later.

As mentioned above, this soupy, soy sauce-only variation is also the first Filipino dish that I learned to cook without any guidance as a grade school student, a testament to how easy this dish can be made. It’s also almost the same recipe, with slight modifications based on the lessons that I learned since the first time I made it.

Now on to the “Science”, starting with the meat.

Anyone who has made burgers will know the importance of the lean/fat ratio – lean cuts like ground sirloin (90/10) will reduce the fat at the price of flavor. Using cheap ground beef (70/30), however, tends to make the dish drown in fat. I would suggest using ground sirloin first then experimenting with mixing it with the cheap stuff.

Don’t wash the ground beef on a strainer! You might find this weird but some people actually do this. Some say it’s to clean the meat (no need, bacteria will die at browning), others say it’s to reduce the fat (just get a leaner cut or scoop out some of it after browning). The only good reason for washing beef is to find bits of bone in the meat, and this can easily be remedied by buying your beef at any decent meat store.

In terms of cooking, it’s ok to just cook the beef to gray done-ness especially if you’re pressed for time, but browning (i.e. Mallard reaction) imparts additional flavors to the meat.

(For the newbies: by “brown”, we don’t actually want you to overcook it to “totally brown”. It’s more like “gray with brown bits” like your favorite fast food burger. Browned meat bits covering a good portion of the bottom of the pot is a good sign to stop.)

With the meat done, step 2 is all about turning the dish from “Stir Fried Ground Beef” to “Giniling“. Let’s run through the rest of the ingredients and the possible variations:

The “add-ons” provide a contrast for the flavor and mouthfeel and should be small or at least bite-sized. Traditionally this would mean diced carrots, potatoes, and chayote (I love chayote, but I usually reserve it for other recipes so it’s not in this one). Variations include raisins, peas, corn (all 3 require no prep, and peas, corn, and carrots are the basic frozen mixed vegetables), and boiled quail and chicken eggs.

String beans as the lone addition is another option. This will turn the recipe into a cross between Giniling and Adobong Sitaw so no tomato sauce should be added. You can saute the green beans for a while before adding the water, or you can just let it boil/steam.

The remaining ingredients build the flavor profile. Soy sauce and/or tomato sauce/paste provide the base flavor (oddly enough, these two ingredients work well together). We don’t use tomato sauce in our household for practical reasons: while soy sauce is used everywhere, tomato sauce isn’t and will just sit idle in the ref. Not to mention that there’s no much difference in the flavor whether you use it or not (IMO).

The bay leaf is there for the aroma; don’t use too much of it or it will overpower the basic flavor. You can remove the bay leaf before serving if you want.

Beef bouillon cube isn’t a traditional ingredient, but I find bouillon cubes to be a better alternative than guessing the right amount of salt to bring out the body and flavor of many Filipino dishes. (Beef stock would be nice, but since when did you see beef stock in your average Filipino household?) Sometimes I also add oyster sauce for extra body and a hint of sweetness.

And finally, the last ingredient: water. Adding enough water to cover the vegetables will produce soupy Giniling. In some cases, you may not want a soupy dish e.g. you’re serving it along with stew. You can reduce the amount of water by half in those situations.

You shouldn’t remove water and rely solely on the soy sauce for liquid, however, as you need water to cook the vegetables and help >deglaze the bottom of the pot where much of the flavor is still stuck.

And that’s it, a basic Filipino dish that a child can cook. You can’t really go wrong with it apart from adding too much soy sauce and making it too salty, and even then you can try to salvage it by adding sugar.

Next dish: Bistek »

My Filipino Dishes (with Science!) pt 1: Introduction

If I were to be asked about my specialty as a hobbyist cook, I’d say it’s Italian. Most of the food pics I’ve taken in the past years are either experiments in spaghetti or homemade pizza.

Through some unforeseen events, however, I had to brush up on Filipino cuisine earlier this year as I took on the role of designated dinner cook for our household 4-5 times a week. My productivity took a nosedive (I had to budget 1-2 hours a day out of my work) but it gave me a chance to experiment and level up my Filipino cuisine cooking skills.

In these series of blog posts, I’ll be discussing the various dishes that I have been making on a regular basis. To make this different from other cooking blogs, I won’t just be posting a recipe handed down to me by my mother/grandmother. Instead, I’ll try to look a bit deeper into the recipes and attempt to explain why some cooking techniques work and why some don’t. In short, I’ll be doing a mini Good Eats / Serious Eats Food Lab for every dish.

But before that, let’s get one thing out of the way first…

The obligatory “Why hasn’t Filipino cuisine caught on abroad yet?” discussion

I’ve had some small discussions with friends about cooking recently and this topic came up a couple of times. Since I’m writing blog posts on Filipino cuisine, I might as well give my 2 cents on the subject now.

In my opinion, there are a few big reasons:

1. Filipino cuisine is rustic and practical.

For reference, look at Japanese cuisine. The “boom” in Japanese cuisine was through sushi – an exotic dish whose preparation takes years of experience to master. But do Japanese people eat sushi everyday? Not really. Their regular dishes are not that different from their East Asian and Southeast Asian neighbors.

I feel that many are trying to do the same thing with Filipino cuisine, find a class of Filipino dishes that will get a restaurant a Michelin star. But that won’t happen – while there are certainly a lot of exotic Filipino dishes, AFAIK none of them have the same level of sophistication as, say, French cuisine. You can certainly dress them up as such, but people will see through the farce.

On a similar note, the “practical” above also means that Filipino cuisine are often full of fat – something that you’d want to have to prepare for famine (especially in a country frequently devastated by Typhoons). Until the whole “fat is evil” propaganda is corrected to “excess food is evil” in the biggest accessible potential market for Filipino cuisine (USA), it will definitely be a hard sell.

2. Filipino cuisine is (and isn’t) fusion cuisine.

Being a colony and trade port for so long, Filipino food has been influenced a lot by other cultures, whether it’s the pre-colonial regional influences (Chinese, Malay/Indonesian) or the more recent influences (Spanish, American). Because of this, it’s hard to claim a dish is purely “Filipino” or not.

What some don’t realize is that it’s okay for a “Filipino” dish to not be “purely” Filipino. There are many dishes that we attribute to a certain culture that are actually heavily influenced by foreign cultures e.g. tonkatsu. All that matters is that we’ve adapted that dish into our lives, modifying it such that it is more practical given the availability of ingredients and such that it’s flavor fits in with what the mainstream considers “tasty”.

This also means that we probably shouldn’t market Filipino cuisine as “fusion cuisine” because we already adopted them as “Filipino” (with a few exceptions like, say, banana ketchup spaghetti). Just as forcing ourselves to find a “truly Filipino” dish is blindly nationalistic, going the opposite route may be perceived as belittling one’s own nation’s culture.

3. Pansit, Lumpia, and Adobo.

Screw Pansit, screw Lumpia, and screw Adobo. I’m ok with them, but they’re definitely not on my list of favorite Pinoy foods. I’m not even going to write about them in this series except for one of them, and that’s only because they’re so close to another dish.

But when you ask a 2nd or 3rd generation Filipino-American about their favorite food, it’s always these three freaking dishes that their Lola used to make. No mention of the various stews, grilled foods, deserts, etc. No mention of the regional dishes and how they contrast with the ones found in Metro Manila.

In other words, so many of these people are out of touch with what’s really being eaten in the “motherland” and we cannot expect them to promote Filipino cuisine well.

With that out of the way, let’s move on to the first dish »

Sunday Reading: When Community Events Go Horribly Wrong

“If you can’t be a good example, then you’ll just have to be a horrible warning.”
– Catherine Aird

As a follow up to my previous post on organizing events, here are some articles about a couple of recent community-run conventions that crashed and burned in spectacular fashion. They’re rather lengthy so find a good chair and maybe a tall glass of juice and some popcorn (or do as I did and read the articles on a tablet while lazing around on the bed).

The first is DashCon, a recently concluded community-organized Tumblr convention. The Daily Dot has a good write-up about the event from an outsider’s perspective.

Here are some other perspectives to give you better idea what happened and how the whole thing turned into a trainwreck:

Our other example is last year’s Las Pegasus Unicon, a My Little Pony: Friendship is Magic convention.

Here’s a write-up about this event. It’s basically the same as DashCon; the main difference here was that there were higher profile guests (e.g. Tara Strong) making the trainwreck even worse.

Thanks to this MetaFilter post, I found a list that summarizes how these things happen to community events:

  1. Some people have an ambitious idea for a fan convention
  2. They expect a huge success and book beyond their budget
  3. The con starts and Friday ticket sales won’t cover booking costs
  4. Organizers scramble to keep the show running
  5. People speculate that the whole thing is a scam
  6. Everybody is assured ticket sales will be up for Saturday
  7. Guests are not paid, pay their own way, or don’t show up
  8. Attendance is way down on Sunday because everyone’s heard about the trainwreck
  9. The organizers either skip town or get cornered to pay what they can

The other link in that MetaFilter post also gives a veteran anime convention organizer’s perspective in holding such events.

The take-away here is that if you want to hold your own community event, you have to be realistic with your expectations: start small, be professional at all times, and know that holding events is hard work and not a way to boost your ego/excuse to fly in and rub shoulders with celebrities/earn a lot of money.

Making an HTML5 knockoff of Chinese arcade game knockoffs with Phaser

If you’ve visited an arcade in Asia, you might have seen a couple of arcade games which blatantly rip-off popular titles. Here’s a video of a Plants vs Zombies game in Singapore taken by YouTube user JasperLee93:

Here’s another one with Angry Birds (filmed at a local arcade by user Stug50):

At first glance, the game boils down to:

  • Enemies randomly spawn and move around the screen.
  • Insert coin to get energy which you can spend to shoot at enemies.
  • Killing enemies give you additional energy based on their toughness.

Upon realizing how simple the game is, I decided to finally fulfill my childhood dream of programming my own arcade game. I’ve got spare time, decades of experience in programming, basic game development knowledge… it shouldn’t be that hard to pick up an HTML5 library as a web dev and build a game this simple, right?

Gunner

Turns out the answer to that question is “It’s both easy and hard.

Before we explain why that is so, let’s first take a deeper look at the games we’re cloning.

Fishing games?

If you’ve walked around the arcades that carry these games, you’ll see that there are other games in the same class but don’t infringe copyrights. For example, this “Demon Hunter” game shows up a lot in local arcades:

After doing a bit of lazy research, I’m pretty sure that this is where the whole thing started:

Yes, fishing games.

The gameplay is pretty much the same. Insert credits to get points. Use points to shoot targets which in turn gives you more points. Game ends when you run out or decide to redeem your points. There’s also some additional factors in play:

  • The game is not damage based, but luck based. Enemies who drop higher rewards have a lower chance of being destroyed, and higher powered weapons which have higher chance of destroying these enemies cost more points/energy to use.
  • Since it’s luck based, the game developer can tweak the probabilities such that playing an optimal strategy would only result in minimal gains. We see this in the first video where the player is just spamming the strongest area of effect weapon and yet the score never swings too much to either way.

Based on these observations, these games aren’t your usual redemption games like skee ball, but are more like pachinko where playing for an indefinite amount of time is possible and in fact is the only way to gain high rewards.

Tweaking the gameplay

It’s pretty obvious that the “redemption” mechanic won’t work in an HTML5 game. The “shoot stuff to get bullets to shoot at more stuff” core mechanic is still suitable for mobile and browser play, though, so it’s only a matter of replacing the main reward scheme.

After thinking about it for a bit, I’ve found a couple of possible routes:

  • Time Attack – set a limit to the energy or kills and let the players try to beat their old times.
  • Survival – similar to the arcade classic Gauntlet, the game drains continuously drains energy and players try to kill as many enemies as they before they die.
  • Incremental – similar to Cookie Clicker, you can spend energy to buy upgrades that will shoot enemies for you and you can just leave the game alone to let it rack up a lot of points.

Time Attack was my first choice since it’s the easiest to implement. Survival is also in because it’s practically just the opposite of Time Attack. Incremental will take a lot of trial and error to find the correct mix of upgrades so this mode is shelved (I don’t think any HTML5 engine can even handle thousands of explosions per second).

Game Theme

At that point, I’ve already figured out what I want to do but I still have to make an important decision about this game:

So what do we blow up this time?

While it would be funny if I just took assets from some other popular franchise and make my own knockoff, I wouldn’t be able to release it into the public and I won’t be able to write a post like this one. So instead of doing that, I looked around for free and legal sprite compilations for ideas on the theme of this game and eventually stumbled upon CPL-licensed compilation SpriteLib.

It was then that I decided that the game would be based on the WW2/1942 themed sprite sheet 1945.

1945

We’re going to blow up endless waves of Japanese fighter planes.

Choosing an HTML5 library

If I wanted to make a commercial game, I would’ve gone with Unity3D or some other game programming platform. But I’m not making a commercial game, and from the start I was already set on making this an HTML5 learning exercise. I’ve already made a couple of throwaway JavaScript games so I expected a relatively easy transition to Canvas/WebGL.

HTML5 game libraries tend to fall into two types. On one end you’ve got frameworks like Construct 2 and GameMaker where you write your games in a drag-and-drop visual programming environment, while on the other end you’ve got bare-bones libraries like CreateJS where you code everything in pure JavaScript.

Phaser

In the end, I went with the middle ground: Phaser.

Like CreateJS, Phaser is just another library; you still program your game using plain JavaScript. Unlike CreateJS, however, Phaser is a higher level framework with common game elements like Game Loop and Physics implementations already built-in. As a web developer who has worked with frameworks like Spring and Rails for a decade, I was much more comfortable with the latter.

One downside to Phaser is that it’s relatively new and that there are a lot less developers compared to other libraries. Even with this lower profile, solutions to problems in Phaser aren’t that hard to find: it has decent documentation, a huge list of sample code, and an active forum.

Another good thing about Phaser is that the examples in the Game Mechanics Explorer site are all implemented using the said framework. As we shall see later, many of the initial implementations of the games code are directly lifted from either that site or the official examples.

From 0 to basic game in 4 days

Now that I’ve decided on the theme and the framework, it’s now time to code the basic features of the game:

  • Add a basic enemy spawner
  • Add basic shooting
  • Add collision handling with damage and explosion animations
  • Add energy (which is adjusted per shot and kill)
  • Add relevant graphics e.g. rotating gun, energy and kill display
  • Add other enemies and shot types

The first 3 points are easy; it’s just a matter of copying and modifying code from Phaser’s Tanks example which has shooting and explosions. Spawning enemies is also just an exercise on whether you have understood how object groups work or not.

Phaser Tanks

Another good example for learning object groups is Game Mechanic Explorer’s Bullets demo:

Bullets

With these sources, I had initial working game in just a few hours:

From scratch

click screenshots to play the corresponding game builds

And the (very short) code:

The following days had me coding the other 3 points. I went with 7 kinds of enemies to shoot at:

Enemies

  • Downward moving green planes
  • Tougher horizontally moving white planes
  • Horizontally moving submarines
  • Even tougher and faster horizontally moving blue planes
  • Large downward moving bombers
  • Horizontally moving destroyers. Destroyers and subs should not overlap as they are on sea
  • Fast and almost invulnerable golden planes

And 3 shot types:

  • Regular shots for the early game
  • Large shots for taking down tougher enemies
  • Burst shots replace area-of-effect shots (which I was too lazy to implement); these larger shots burst into five small shots upon impact.

Here’s the hit probability and reward table:

Small Large Burst Energy Reward
Rookie (Green) 66% 100% 100% 2
Regular (White) 30% 90% 100% 5
Submarine 5% 20% 35% 25
Veteran (Blue) 5% 12% 15% 50
Bomber 0.9% 3% 5% 100
Destroyer 0.55% 1.9% 2.5% 200
Elite (Gold) 0.2% 0.8% 1% 500

I also added a leveling up system to give a sense of progression, something that was not present in the original arcade games due to their sit-down-and-play nature. This gave the game an end state of sorts in the form of a level cap since Time Attack wasn’t in the initial list of features. In addition, I’ve set the experience point system to a flat “1 kill = 1 xp” system which gives the green planes value up to the endgame and not just be early game cannon fodder or late game bullet shields.

Here’s the result of only 4 days of on and off coding:

First major build

This is what I meant when I said “making HTML5 games is easy for a web dev” especially when using a framework like Phaser.

Then came the hard part.

“The first 90 percent of the code accounts for the first 90 percent of the development time.
The remaining 10 percent of the code accounts for the other 90 percent of the development time.”

—Tom Cargill

Things happened and I had to put off developing this game for a month or so. I came back expecting to have an easy time implementing other features that were missing from the prototype:

  • Game modes: Time Attack and Survival
  • Firing modes to complement the shot types: Triple adds 2 extra side guns while Bomb lets you drop a bomb anywhere in the screen that explodes into 10 shots.
  • LocalStorage saving of high scores and previous settings
  • Game menu UI for choosing game mode, viewing past scores, reading the tutorial, and so on.

As I was implementing these features, the problems started to emerge. Looking back, fixing these problems cost me more time than coding the new features; what was supposed to be a few days of effort suddenly became a few weeks.

The Problems

Designed for Desktop

Some UI problems became apparent when I tested the game on my phone and iPad for hours. Again, here’s the first major iteration of the game UI, scaled down and inserted into a phone mockup from Mockuphone:

First major build

The most glaring UI problem was the large wasted space on the deck combined with the small size of the shot type toggle buttons. This could easily be fixed by increasing the latter’s size.

First major build

Another, more subtle, UI problem for mobile devices shows up when you try to play it with your your thumbs or index finger: doing so will make your palm cover the energy and kill counter. Players cannot see their health and progress at a glance under this scheme, even when the text was converted to colored bars.

I eventually went with the most obvious solution to the problem: just put the damn things on top.

Score/Energy moved to top

Apart from these prominent issues, the only other flaws I encountered with the mobile UI are the spacing of the menu “buttons” which have been corrected somewhat in the later builds.

Pause screen options are too close

Separate buttons

More Mobile Problems

Game Performance

I’m not fooling myself: HTML5’s performance in modern browsers and devices is decent, but it’s still not “there” yet. At the later levels, it’s almost as if my game is a benchmark for HTML5 performance seeing how laggy things can be when everything is moving and exploding.

I added Stats.js early on to see the actual performance of my game:

Histogram top left

The histogram view was useful but slightly distracting. I replaced it later on with Phaser’s built in frame rate calculator:

FPS counter

With these in place, I went around and tested the game on various devices. Performance was good on high-end devices like current generation iPhone, Nexus, and Galaxy S. The game had significant amount of lag on older weaker and older devices, though, so I tried out various tweaks to see if they had any effect.

Performance Tweaks

The most obvious approach to tweaking the game would be to treat HTML5 as an old-school gaming platform reduce the amount of sprites onscreen. Unfortunately, this goes against the core of the game which can be summed up to “have a lot of sprites on the screen and blow them up”.

Past that solution, there’s really not much we can do to improve the performance of the game.

We can convert everything to object groups, but we’ve already been doing that from the start (see code above).

Special Elite in bitmap

I also converted the web fonts to bitmap fonts due to fact that any text rendering, webfont or not, can be computationally expensive depending on the browser. Using bitmap fonts are theoretically better, the engine treats them as normal sprites so they should be rendered faster and more consistently at the price of scaling anti-alias quality.

Upon testing, these and other tweaks didn’t seem to affect the performance that much… as expected. Most of the performance was still device and browser based. For example, the game’s unplayable on Firefox on my 2 year old mid-range Android phone, but is playable even at low frame rate on Chrome on the same phone. Similarly, the game is noticeably smoother on Safari on my 3rd gen iPad than it is on Chrome.

While we’re at the topic of performance, let’s talk about packaging HTML5 apps into hybrid mobile apps.

Turning the game into a full mobile app

You can turn any HTML5 game into a full app by wrapping in a WebView of the platform of your choice. Phaser is no different.

On the other hand, WebView performance isn’t better than the performance of the native browser. There is another option for packaging HTML5 games that promises higher performance compared to plain WebViews: CocoonJS’s Canvas+ mode.

Depending on the complexity of your game, it may take too much effort to turn your game into a Canvas+ compatible app. This article lists down the main things you need to do. They range from simple (using an older compiler) to crazy (converting bitmap font to JSON and adding a polyfill to replace the non-existent XML parser with a JSON just to make custom fonts work).

I tried converting the app but quit halfway. At least I got to the point where the CocoonJS launcher can display the menu, albeit incorrectly.

Canvas+ in CocoonJS

Loading Speed

Aside from in-game lag, I also noticed that the game loads much slower when played online compared to local play.

Slow loading

I’m already using Sprockets via sinatra-asset-pipeline the to concatenate and minify the JS and CSS files, but the way Phaser preloads assets (via XHR/AJAX) combined with the amount of different sprites I have in the game means that this simple game can take quite some time to load.

The solution here is to combine the sprites into an atlas with tools like TexturePacker and change your game to use that instead of individual images and spritesheets.

Initial image atlas

Compared to Sprockets, it’s not a total solution for game assets yet. For one, while tile sprites work with atlas, but only in certain situations that haven’t been totally pinned down yet so it’s suggested to remove them from your atlas. Bitmap fonts are also separate files from the atlas, causing 2 extra AJAX calls per font to be loaded. And finally, there’s no atlas for audio yet so while Phaser only loads the audio type suited for the browser (e.g. ogg vs mp3), it’s still an AJAX call per audio file.

Now on to other problems…

Temporal Problems

Game Length

In the early builds of the game, I tended to get too engrossed in blowing enemies up that I didn’t notice how long it took to get to the final level. It was only when I added the timer for Time Attack that I found out that I was spending 50 minutes to an hour just to reach that point in the game.

Game Length

I added the Game Length setting to address this. The original game length is now called Extended while the Normal is now half of that (which makes a normal game run for 25 to 30 minutes). I’ve also added the Quick mode which are expected to run for 10 – 15 minutes, just good enough for pick-up-and-play sessions.

To implement Normal and Quick, I just assigned them a factor: Normal is 2 while Quick is 5. Time Attack is then shortened by dividing the required kills to level up by this factor. On the other hand, Survival is also shortened by setting this value as a multiplier to the energy drain factor. With Quick Survival starting at 25 energy drain, you need to be both accurate and lucky just to get past the first 5 minutes.

Huge drain

Pausing

Phaser’s pausing scheme also gave me a couple of problems. Pausing the game in the current version of Phaser has two side effects: first, everything is paused including the game loop. This prevents input handlers in your update() function from being called. Selective pausing will be added to later versions of Phaser, but in the meantime, there’s a workaround in the examples list which will let you do stuff while the game is paused.

The second thing to keep in mind about pausing is that it doesn’t affect the game clock time. This can cause problems when you check the game time for delayed events, say when you schedule an enemy to spawn in now + 10000, you can make that event appear to happen immediately in game terms by pausing and unpausing after a minute.

Spawning while paused

I got around this issue by doing what I should’ve been doing from the start and use custom timers in place of the game time. In the later builds of the game, everything related to time (e.g. enemy spawning, shot cooldown) are handled by timers.

Let’s close this list of problems with the one that I see every time I let someone else play the game.

WTH is this game?!?

People don’t immediately get what the game is all about when you show it to them. This is also a problem with the arcade games where I see kids lose less than a minute of starting a new game.

How to Play

A working How to Play section has been around since version 0.37 but players tend to skip it so I added a pre-game message summarizing what the game is all about in the next version:

Pre-game How to Play

Even with this screen, new players still had an awkward few minutes before understanding what the game is about. It was then that I realized that the first thing that comes into their heads when they see enemies moving towards them is to think that it’s a defense game.

Parallel enemies

Since then, the early enemies now move horizontally and the player’s “ship” now “moves” parallel to them. Almost all of the fishing game variations use this style; the only one I found that had enemies rushing towards you is one with a damage mechanic.

In closing…

August’s a busy month so I’ll have to shelve this project again. I still have a bunch of things that I want to add to the game but they can wait.

You can play the latest version of the game at http://datenshizero.github.io/gunner/. The latest code is also hosted at Github.

This whole experience supported what many already know: one of the best ways to learn a new technology is to think of a project you want to make and try to build it using that new technology.

Shameless plug: if you want to learn more about creating HTML5 games in Phaser, head to Leanpub and grab a copy of my free book!

Free HTML5 Game Programming Book (almost) Out

Two months ago we had an HTML5 game workshop. Weird stuff happened and I ended up being the substitute instructor for the Phaser workshop. Also decided to use Leanpub for handouts instead of my usual slides.

I got a positive response out of it and went on to spend a couple of weeks fleshing out the book.

Last week, I released a heavily updated book and started spreading the word. The book ended up getting to top 3 of the most downloaded books for the past 7 days:

Here’s the link to the book: HTML5 Shoot ’em Up in an Afternoon

Any feedback about the book and helping spread the word would be greatly appreciated. :D