Screenshot Saturday

Some screenshots of my current game. It is called “Breaking and Entering”. It’s a stealth/crime/action game where your goal is to maximize your money through robbing places. Avoid the cops and the residents, otherwise you end up in jail and need to pay bail. You can also buy lots of items to help you out like x-ray goggles, a get away car, cloaking devices and more. Problem is buying too many things cuts into your overall profits, so in the end it’s really a strategy game. Much more to come, still in its early phases.

Here we are, breaking into the football stadium using a lockpick.

You grabbed some wine inside the stadium, but someone spotted you. Uh oh, they’ll call the cops.

Sure enough, the cops came and are now chasing you. Notice the bag of loot you are carrying.

Here we are in a quant neighborhood. A resident spotted me carrying loot from a recent break in.

Looking for an artist

So far this project is just me. I’m not the best artist in the world. So if you are interested in doing the artwork for the game, please drop me a line

A lil bit of pixel art

The chrome logo was easy, the Firefox one I think could still use some work.

Screenshot Saturday … two days late

I haven’t posted many screenshots lately as none of what I’ve been doing lately has caused any visual changes. I’ve wrapped up the WebGL renderer. I’m happy to say after a couple sessions of profiling using the Chrome dev tools and Firebug, I’m able to get pretty good framerates in Firefox now. Woot! Chrome is still by far the winner here, but I now feel more comfortable saying I support Firefox.

I’ve got the game’s intro just about done, and I am going to release it on its own as a little teaser to see what people think, and see what kind of performance people out in the wild get. Especially curious how Linux machines do. I made the intro “movie-like” and added social networking share buttons, which I thought came out pretty well :)

Forget it! I’m only supporting Chrome!

“This site best viewed with Netscape Navigator 3.0 at 1024x768”

In some ways I feel like this mindset is back, as much as I may not want it. After fighting disappointing performance in some browsers and missing features in others, I have decided my game will only officially be supported in Chrome. Here are my reasons…

Disappointing canvas performance

When I first set out to work on this game, I chose 2D canvas as the means to render it to the screen. Canvas isn’t known for its blazing performance, but I thought it would be adequate and I like its simple API. Here are the framerates I get in my game with Chrome and Firefox:

• The machines I am testing with
  • MacBook — 5 year old MacBook, 2Ghz Intel Core 2 duo, 2GB RAM, integrated Intel video, OSX Snow Leopard
  • iMac — 3 year old iMac, 2.93 Ghz Intel Core 2 duo, 4GB Ram, NVIDIA GeForce GT 120, 256MB VRAM, OSX Snow Leopard

(It should also be noted that for both browsers, CPU usage basically goes to 100%)

Hmmmm, that’s quite a difference. Chrome is rendering over 30 times faster than Firefox!. Wow. So what is the culprit? I had a hunch the bottleneck is in the rendering itself, and decided to pursue a spike of implementing a WebGL renderer. WebGL seemed like my only hope for Firefox support. And besides, the Chrome numbers aren’t exactly blazing, WebGL would probably benefit Chrome too.

The WebGL numbers

I am by no means an OpenGL or graphics expert. But I do think the WebGL renderer I came up with is fairly decent. In my game the tiles themselves don’t really move at all, but they change their color very often. I ended up with a solution that involved one vertex buffer object to represent a board’s tiles, and one buffer to represent the colors of the tiles. Each frame I update the color buffer with the colors for the tiles that are currently visible on the screen, and send them off to the graphics card to be rendered using bufferSubData.

First, I tested it out with a simple demo I made that basically just renders a ton of tiles (a 70x70 board, 4900 tiles) and one space invader. Other than that it basically does nothing at all:

It should be noted that 60fps is the max for Chrome (it locks itself to the screen’s vertical sync) and I can make it push many more tiles and still maintain 60fps. It’s also worth noting that the WebGL renderer causes the CPU usage to drop to 25% for both browsers.

Firefox saw significant improvement! Awesome! Perhaps all is not lost with Firefox. Now, let’s try this again, but this time with the actual game:

Firefox, what happened? There is a major difference between my game and the rendering demo. My game has quite a bit of stuff happening on the JavaScript side: particle systems updating, entities animating, boards parallaxing, sound effects playing, and other special effects happening. I suspect that Chrome just plain executes JavaScript faster, making the JS side of things happen fast enough to keep up with the frame rate. Whereas Firefox’s JS execution ends up bogging things down.

Admittedly, there are some things in my game that are not well optimized. I have some animation effects that make use of Array.filter quite a bit, and so both anonymous function objects and arrays are being created often. This area could use some optimization, sure. So to test what it would be like with those areas perfectly optimized, I simply removed them temporarily. I saw about a 10% performance boost in Firefox, yielding 18fps in the best case scenario.

Firefox is holding me back

I could try and squeeze as much as I possibly can and try and eek Firefox’s framerate to around 30fps. It almost certainly can be done. But … I can also go forward guns ablazing with Chrome and …

• have a larger viewport with more tiles on the screen at once
• more animation happening
• more game logic happening
• just plain have a better game, period

Chrome really isn’t holding me back at all. Once I coupled WebGL with V8, I’ve got an engine with a lot of wiggle room. I like that wiggle room and want to take advantage of it.

So screw it, I’m dropping Firefox. I hate to say that, and I hate that it’s come to that, but I just find it hard to argue with how much more performant Chrome is.

What about the other browsers?

Safari and Opera both lack requestAnimationFrame, and simulating it with setTimeout and Date.now() is noticeably slower and not as accurate. I do have hopes that once Safari gets requestAnimationFrame, it will have decent performance. Opera I’m less certain about at this point but I plan to investigate it more.

Internet Explorer 9 and 10 are total unknowns so far. It’s simply a matter of not taking my game over to Windows and giving them a try yet. IE does not support WebGL, but there are some workarounds I want to investigate. I am also curious how well the 2D Canvas renderer performs, but very much doubt it will compete with the WebGL one.

As for other OSes, my research seems to indicate that with Chrome I should expect a performance boost on Windows, and a performance hit on Linux.

And for the record

This is a hobby project of mine. So I feel I’m OK making this drastic of a decision. Obviously supporting as many browsers as possible is important for most projects, but this isn’t one of them. If the game ultimately is well received, I may just port it to a non browser environment anyway. For now, it’s a fun excuse to play around with new browser goodies.

Screenshot Saturday, #3

Screenshot (and demo) Saturday #2

Not too much to report this time. I’m travelling much of this week and so haven’t done as much work as I would have liked.



But to honor SSS, here is my latest. It’s four layers of parallax with a simple plasma demo going on in the last one. This is the start of the opening scene for the game. Each layer will eventually look like rubble from a spacecraft, as if the ship crashed. Currently it does look more like a cave :)

Demo Sunday

Here is a little demo of my engine’s particle systems. This almost certainly doesn’t work in your RSS reader, head over to the actual blog if you are interested.

I ported the particle system over from CocosNet, which is an engine I did in C# and MonoTouch a while back. CocosNet was in turn a port of cocos2d. So if you are a cocos2d user, this demo will look familiar :)

This is early, unfinished work. It will only work in Chrome or a recent Firefox (works best in Chrome, gets about double the framerate)

Screenshot Saturday, #1!

It is a tradition on /r/gamedev to have screenshot saturday, so I thought I’d carry that same tradition here.

I got particle system implemented in my engine. Here is one example simulating a fire.

And another looking kind of star like.

And here is a super simple, early screenshot of actual gameplay. So exciting! :) It looks like that on purpose. The idea behind my game is it starts out as the classic “snake” games from old school cell phones, and then the snake escapes and goes on a wicked adventure.

Not so hot just yet, I know. But stay tuned, things are going to really start ramping up here quickly. I’ve got all the pieces in place now, and have started embarking on the real meat of the game. Maybe not next Saturday, but the one after that or thereabouts the screenshots will take a dramatic turn towards the interesting.

ps: And one more

A simple test of my animation system. All three layers are completely independent and are moving, tweening, easing, shimmering, and doing all kinds of things. I figured I’d throw this one in so I don’t give off the impression the entire game takes place on one plane.

pps: sweet, tumblr allows you to embed script tags and html. Since my game is written in JavaScript, it won’t be too long before I’m embedding real working samples of it. The web rocks.

Playing Games in Depth

I currently have two games on my plate: Metal Slug and Rayman Origins. A friend of mine and I are in a high score competition with each other over Metal Slug, and my girlfriend and I are plowing through 100% completing Rayman. In both situations, we are playing the games to their limit, discovering everything the developers had in mind, their subtle nuances, etc. When playing a game this deeply, it’s interesting how your view of the game can change.

Metal Slug

On it surface, Metal Slug is a very simple run and gun. You would be excused in thinking the only thing about it that really stands out are its gorgeous graphics. But when you start playing for high score, interesting details you otherwise would have missed begin to emerge…

• Shooting a soldier is worth 100 points, knifing them is 300, and running them over with your tank a mere 10.
• Rescuing 10 hostages on a stage nets a 100,000 point bonus, which is very significant.
• There are never 10 hostages out in the open on a stage, the remaining handful are always hidden
• There is no time bonus for finishing a stage, just don’t let the timer run out (else you lose a life)

These four points alone show something about Metal Slug you might not have expected: taking your time is ideal. Try to knife as many soldiers as possible, shoot them out of desperate if they are getting away. When in the tank, you want to carefully avoid running the over and instead prefer to shoot them. There are many areas in levels where soldiers will continue to spawn a lot. Taking your time means the overall number of enemies you encounter increases, increasing your score.

When fighting a boss, you can grenade them relentlessly for a much quicker kill. But this will net you fewer points than just using your gun. You get 10 points per attack on a boss, and using grenades means far fewer attacks.

The 8th, 9th and 10th prisoner in levels are often well hidden. I’ve decided to not cheat by watching run throughs on Youtube. So far I’ve only found all of them on levels 1 and 2.

The second half of level 4 involves many tanks dropping down from cliffs above you, then many turrets bombarding you. Your instinct is to blast through quickly, as it’s pretty hectic. But taking your time and killing each individual tank and turret is not only easier, it nets you many more points.

In the end, playing Metal Slug for score means playing it much slower than you’d expect. A surprising conclusion.

Metal Slug Weapon intricacies

The weapons in Metal Slug are more than just a cool change of pace. Each weapon has well designed pros and cons. Flameshot is excellent when dealing with hords of soldiers, but terrible against heavy artillery. The rocket launcher is the exact opposite. The shotgun is by far the best weapon in the whole game, and thus is only handed out sparingly. In all places the shotgun is given to you, it’s in your best interest to hold onto it as long as possible. This means knifing soldiers instead of shooting them to conserve ammo, and skipping future weapon drops.

Metal Slug Design Failures

I feel Metal Slug has a flaw or two when playing for high score. On level two there is an item that is sometimes worth 5,000 points, and other times 50,000. As far as I can tell, this is purely random. If you get it for 5,000 points, you were just screwed out of about 4% of your entire run’s score! There’s no point in continuing, just start over.

On level 3 the hidden prisoners don’t always appear. There is a chance of getting between 0 to 2 hidden prisoners in each of the hidden locations. If you can’t get 10 prisoners, you lose a 100,000 bonus, roughly 10% of your entire score. Why so cruel, Metal Slug?

Certain things in Metal Slug are worth 10 points (like running over a soldier, the turd bonus item, etc). The designers probably felt 10 fit well into their point scale, but it ruins a convention in high score games. Whenever you continue, your score goes up by one. This allows people competing with each other to easily see how many continues the other player used to get their score. In Metal Slug you can continue to your heart’s content and this method of determining continues will only suggest you at most continued 9 times.

Metal Slug Conclusion

In the end I feel the designers did a decent job of adding depth to Metal Slug through high score pursuits. They could have done better, for sure, but in the end the game becomes much more interesting, deep and different when played in this way. It’s almost like playing a whole new game.

Rayman Origins, in contrast…

I love Rayman Origins. I think it’s one of the best platformers I’ve played in many many years, just a phenomenal game. But I find it interesting that 100% completing the game is a bit flat, and even boring.

In order to 100% complete a level in Rayman Origins, you need to: * Collect 350+ lums * Find all the hidden prisoners * Play the level again in time trial mode and beat the gold medal time

On paper this sounds great. We typically collected about 280-300 lums on our first play through of any given level, so getting up to 350 does require you to more carefully comb the level. But I’ve almost never found getting those additional lums to be interesting, or open a new level of play in the game. Instead I’d even say quite the opposite. On many levels, getting that many lums is really just a chore.

I don’t enjoy the time trial mode at all. At least, so far (maybe some later levels will be better?) It feels tacked on in a quick attempt to squeeze out some more replay value. Rayman’s levels, for the most part, are not designed for speed runs.

As for finding all the hidden prisoners. Well, this was never difficult. We always found all of them on our first play through. It would have been nice if in some later levels there was some interesting tricks needed to reveal the secret locations.

In the end, as much as I love this game, I find 100%ing it just work, and not all that interesting.

In Conclusion

I was surprised what my conclusion was on these two games. A seemingly shallow arcade game from 1996 has surprising depth, and a phenomenal game from last year is surprisingly flat when taken to the extreme.

As for my own game, I’m very interested in taking a page from Metal Slug here and hopefully avoiding the Rayman pitfalls. Making a game that is suddenly interesting and challenging in all new ways when taken to the next level is not easy at all. I’ll definitely be exploring ideas on how to do this in this blog as I progress.