Category Archives: game programming

Why is my canvas image looking all scaled? (HTML5)

If you are doing some drawing with the canvas and you find your images getting scaled even if you swear you didn’t set the .scale property (JawsJS, EaselJS) then allow me to show you, my imaginary reader, the crazy magic that could be causing it.

Canvas and CSS

Canvas is just a place for you to put bitmap data. Its 2 attributes, height and width controls how many pixels the canvas contains. So this:

<canvas width="240" height="240"></canvas>

just initializes a 240×240 bitmap data. The canvas keeps that data and does whatever it wants with it. The rest of the DOM can’t do anything with that data.

CSS is where you tell the browser how the DOM should be rendered. Its primary purpose is laying out your DOM to make it look cool. So what happens if you set the css height and width of a canvas?

<canvas width="240" height="240"></canvas>

<canvas width="240" height="240" style="width: 480px; height: 480px"><canvas>

Here’s how CSS and Canvas negotiates their renderings: the CSS asks the canvas for the bitmap data so he can render it. The canvas shows her bitmap data. CSS turns the bitmap data into pixels based on the CSS rules he was given. “Hmm.. canvas says she has 240×240 bits of data, but my orders are to draw them in 480×480 pixels. This means 1 bit data is equal to 2×2 pixels. Cool, I’ll tell the browser about this.”

CSS tells the browser that he’s got all the layouts done and browser can now go and draw it on the screen. And that is why your canvas is all scaled and shit.

More boring explanation here

A Poor Person’s Guide to Making a Facebook Game: A Intro

Dudes, here’s the thing. When I was first starting out on this Facebook game making business I had no idea how complicated things would get. It’s like no one told me about this side of flash programming. You can’t just google and forum lurk your way into wisdom. You have to go deep, like 5+ sub links deep. Is it because most social games are run by companies who don’t want to share their secret sauces? Yes, maybe. Companies are evil like that.

Not me. I’m a friend. And I want to share what I learned. Partly because I’m a good person and don’t want other people to suffer like I did, but mostly because I want to get other (read: smarter than me) people’s feedback. Disclaimer: I haven’t made a successful facebook game (yet) and some of the things I’ll write about are things I didn’t do but totally should have.

Making a social game is different from making ordinary for-flash-portal games. Way different. For a typical flash game to be profitable, it has to be distributed to as many portals as possible. So it is common wisdom that you should put everything on a single .swf file, otherwise the portal people are going to hate your guts for making their lives miserable. Try to do that for your social game, cram 250+ animations of houses and racially diverse avatar skins and “save this cute lost puppy” dialog popups and you have yourself a slightly less heavy MMO client. And look, databases! And server queries! And user metrics! And Facebook credits!

It’s more like making web apps really. You provide them a service: you free them from boredom. The customers/players pay you to keep tabs of the data they generated from your app/game. This is similarities are uncanny for spreadsheet style games.

This is my linkedIn if my contacts have really cool job titles. My real linkedIn sucks.

So I think I will be writing about how to make games as apps. And here is a list of random topics I might write about:

  • Optimizing loading time
  • Dynamic asset loading
  • Efficient asset pipelines
  • Vector caching
  • Continuous integration
  • Transacting with real money
  • Connecting to social graphs and APIs
  • Virtual spaces
  • Logging user metrics

Btw, I use flash (as3) and php because I don’t know other languages.

Biomodd Game Post Mortem
Original design sketch.

I was trying to stay away from writing a post mortem for this game because I don’t want to accept that it’s over. Multiplatform support, multiplayer networking, a 3 (occasionally 2, but usually 1) man development team and a very short project deadline; this was clearly one of the most challenging projects I ever did. It was also the most fun. From the all nighter brain storming session with Jeryll, Angelo‘s wonderful design inputs, game design arguments with Lomel (ex. Should Maria Makiling have a “Wrath” meter that allows her to nuke the whole place?); the whole creative process justified the reason why I chose to make games: it’s way more fun than just playing them.

However, coming from a software engineer’s perspective the project piled up with mistake after mistake that the game would have come out mediocre at best. And it did, actually. The game wasn’t there during the first opening night and it was barely enjoyable when it came out in the second.

What Went Wrong?

Choosing the wrong guns

During the initial planning, I was the only game programmer present, and a very inexperienced one at that. Multiplatform? That leaves GameMaker out. Multiplayer? Hmm, Java has nice networking features. Graphics requirements.. ok there’s no way we can render something that intensive in Flash. I chose Flash and Java anyway for the main reason that Flash is actually more multiplatform than Java, and Java will handle Flash’s networking. I was in the middle of creating my game engine in Flash when I posted this..

That’s right, I can’t make the animations smooth enough for an enjoyable game experience. So I went back to Java. I chose an old Java game framework called JGame and Sun’s Project Darkstar Server. Both frameworks looked easy enough. I put aside JGame since it was the least challenging and began working on the Server Side.

Bad choice number 1. It was too late when I realize that JGame wasn’t a good choice programming wise because it hardly implements any OOP, and there were already two programmers sharing and modifying the same java code file. Plus it became a headache just trying to locate java functions inside a 1000 plus line single file source code.

Bad choice number 2. Choosing to work on the network servers before even creating a working game. I thought that if I finish the hardest part, then everything would be smooth sailing from there. What I didn’t saw, was the possibility that I just might not pull off that hardest part. Blinded by my inexperience and my pride to do something only few developers even attempt to do, I marched on; with the rest of the Biomodd guys not seeing the semblance of a game coming out from my computer screen.

This was a case when a rapid prototype would have benefited the project greatly. More people could have played the game even if it was still on beta. Playtesting and balancing would have been done based on their inputs. And more buzz would have been generated about the game.

Lacking the right tools

Remember Java’s “write once, run anywhere” credo, well, I never realized how much of a fantasy that was until I tried running the server and the client on Ubuntu. I never anticipated the screensize not automatically adjusting plus the sound not working on Linux. Add the extra work of uploading the necessary .jars and you have yourself a big problem that would’ve been easily solved if I used multiple Virtual Machines on my laptop.

I was also using Vista x64 which much to my disappointment, being the fanboy that I am, crashed every time my development processes took 100% of the memory.

Jeryl in the lab

What Went Right?

Changing Horses in Midstream

And having the courage to do so. I have been ignoring Slick2D up until 3 weeks before the Manila exhibit. I realized I can’t go on with JGame and if I continue trying to make it work the code is going to be worse and worse. Slick was actually pretty easy to jump into and I recoded the whole game in just 2 days. The transition was painless I even added some extra holes in it for the networking layer.

The code base itself became more stable and extensible that it just took me a little more than an hour to add the 2-player and Twitter features.

Compromise

A lot of the features originally stated in the game design didn’t make it to the final game (or at least the game that was played in the exhibit). My inadequacies in programming skills prevented me from creating a stable networking layer. Hardware issues made receiving data streams from environment sensors a difficult task. The way we intended to represent Maria Makiling seemed impractical considering our lack of artistic skills. We also have to let go of the much debated Wrath issue of Maria Makiling. It looked as if the features that made the game fun on paper weren’t going to be part of the actual software.

Then, 2 weeks before the end of the exhibit, I made some of the few good decisions I made in this project.

  1. Put the game source on code sharing.
  2. Dropped the networking layer altogether.
  3. Made a single machine 2 player game.
  4. Connected the game to twitter.

First, I shared the game in Google Code. This way the game can finally declare itself open-source. (Well, not really that open, outsiders only have read privileges). It didn’t actually contribute anything development-wise, but putting it up there made the project “immortal”. The installation may be dismantled, its parts distributed or recycled, but the software and the source will always remain in the clouds free for anyone to check out – and/or laugh at. (Which reminds me, I might need to clean up the code a bit for those who are allergic to duct-tape coding).

Second, I made the painful decision to let go of the highly unstable networking code. It was becoming a monster and working on it ate a lot of valuable dev time that should have been spent on improving the gameplay. Throughout the project, the multiplayer feature took the highest priority; the game cannot be the game if it wasn’t multiplayer, the game design hinges on that. Also, call it programmer’s ego, but the thought of giving up on the coolest thing you have ever coded simply didn’t enter my thoughts during that time.

It was after taking a few days off that it finally hit me. There simply isn’t enough time to pull off what I’ve been trying to do. And it wasn’t that I was giving up on my code, I simply saw a different way to write it. The networking layer needs to be taken down, but that doesn’t mean the game had to change. In fact, releasing it on single player for the exhibit was already shameful in my part.

The game should only be played with other people. So I settled with the easiest option: make it 2 player. With only a few days left on the exhibit, I thought it was too late.

Lastly, there’s “the game tweets” decision. Originally, Tina, the electronics ninja, setup some sensors to connect to the internet and visualize the state of the installation. The game was supposed to hook to that as well, creating a unique interaction that fuses everything in Biomodd together. Sadly, because I was too focused on unimportant stuff (curse you, networking and parallel programming!) I didn’t give much attention on this until it was too late. I was trying my hardest to get pachube feeds to the game when I thought, “It’s going to take a lot of time to set this up. And I still don’t have any idea how to interpret the data into the game aside from changing the background. Maybe if the sensors just tweet me stuff they want to happen to the game…”

So I connected the game to twitter and the possibilities of the tweeting interaction began pouring as I code it. The game tweets, players tweet the game. And since I know that the game was only going to be played within the PCs of Biomodd, I can get away with this easily. It won’t flood Twitter’s bandwidth, players feel Makiling in the context of the game and the installation and there’s certainly the “Whoah, this has never been done before” factor.

Conclusion

The project is definitely my most challenging yet. I don’t want to conclude.

Links:

Biomodd[LBA2] website: http://www.biomodd.net/
Google Code Project Repository: http://code.google.com/p/biomoddgame/
Maria Makiling’s Twitter account: http://twitter.com/maria_makiling

It is what is. 🙂

Remember that AI game you were working on?

Back when I was still in school, a professor advised us to createa code repository. Sure you might find your old programs stupid and badly written but within those old crappy code you might find something of value. Come to think of it, this is one of the reasons why I made this blog.

While working on the Biomodd game, I stumbled upon an old project of mine. It was a java based simulation platform for implementing bot behavior. I started coding it a few weeks after graduation fresh from my immune algorithms thesis. The algorithm bit of the thesis was interesting but I was more curious at how I can extend the system so that I can easily swap algorithms without changing much of the code. I didn’t know it then but I was actually trying to design a framework. Like most of my “ventures”, I eventually had to freeze the project after I dug into “flocking algorithms” and totally messed up the physics part. I was at my hometown with no internet and no physics or math book so I had to rely on stock knowledge for pretty much everything.

My OOP and design pattern skills were limited but the code came in handy when I was studying for an IT-certificate course (don’t ask J). We were required to present a game that utilizes OOP concepts. I revived the project, added a few sprites, simplified the movement algorithms (to a simple linear Point A to Point B movement), added a few if-else conditions then presented the “game” to our class the next day.

It was almost a year since I last touched the code and had to download JCreator in order to open the project file. Going back to JCreator after my experience with NetBeans and Eclipse made me wonder at how simple my programming needs were back in college. No code-complete, no SVNs, no build or debug tools, no refactoring.

Everything was so simple. I looked over my code and saw stupid OOP mistakes. Bad use of inheritance here, bloated classes there. I searched for the movement logic and, thanks to the code comments of my old self, easily found it and toyed with it once more.

I guess maybe I need to create a google code account or something, just to have something to put all the past codes/garbage in. Ok I’ll do that, as soon as I have broadband access.

Designing the Biomodd Multiplayer

We are still currently at the development phase of the project. The team is made up of 3 volunteers: 2 programmers and 1 game artist.

I am responsible for both the server side architecture and the client-server messaging protocols. Lemuel is in charge of the client side engine. And Jeryl is responsible for the art assets. It would be great if we have another programmer take care of the messaging protocols so I can focus on the server.

As you can see from the game design, the uniqueness of the game calls for 3 technically challenging features. First, it has to be multiplayer, which means it has to be built on a server-client framework. Second, it has to simulate a growing organic being. Third, the game must have no “beginning” and “end”.

Standalone games are usually executed on a game loop (movePlayer->moveEnemies->checkAgainstGameRules->renderGraphics-> repeat until game ends). But in the case of a multiplayer game, the game loop is partly in the server and partly in the client. The server stores the game state and broadcasts it to the clients for rendering, while the clients get user inputs and sends it to the server to update the game state. In a turn based multiplayer game this change in structure wouldn’t really matter much, since the players are contained in a simple little queue and at any given time only one client is accessing the game state. This changes drastically on an arcade style multiplayer, since the game runs on real time and at one point multiple clients might be trying to access a single resource. This would eventually lead to deadlocks, memory leaks, and all kinds of nasty behavior. To resolve this issue, we implemented Sun Microsystem’s Project Darkstar Server. (Though still on its beta phase, this framework worked like a charm).

Traditional multiplayer game designs limit the amount of data transfers between client and server. Send packets too much too soon and you’ll clog the network. This leads the team to its current roadblock. The entire game state (plants, enemies, players and all) must be stored in the server. Everything, including the movement calculations, plant growth, collision detection, spell cool-downs, etc. must be calculated in the server. Why not put some of them in the client? Because the game has neither a definite beginning nor end. The game exists even without a client. Once a client enters the world the server has to send him the entire game state.

Putting all the stress in the server would be impractical. We are currently trying to resolve this issue by using timestamps. By storing a timestamp value corresponding to the time a game object was last updated, hopefully, any fresh client can calculate the game state based on the time elapsed without having the need to physically store the game objects. That way we are transferring the computational burden to the clients.

We are using Project Darkstar for server side and jGame for the client (the latter is actually pretty old/dead, but it’s easier for non-game programmers to understand than “real” java game frameworks like jMonkeyEngine).

With the deadline creeping in, the team would be more than happy if we can at least make the game playable. I for one, still think it’s the kewlest game ever.