BhimZ's Four Corners Of A Geek

"Tech Talk, Games, Stuff & Gadgets, or Simply Babbling."

Monday, February 21, 2011

Error: Blackberry Yahoo Messenger Invalid Yahoo ID/Password

Beberapa hari yang lalu, saya sempat dipusingkan oleh pesan error di layar BB saya setiap kali saya mencoba login ke Yahoo Messenger. Pesannya berbunyi: "Invalid Yahoo ID/Password". Hal ini sempat membuat saya bingung, karena setahu saya ID dan password yang saya input sudah benar. Saya melakukan double-check dengan login via PC, ternyata berhasil dan tidak ada masalah sama sekali; sehingga kecurigaan saya akan password saya di-hack terhapus sudah. Saya cek ulang YM di BB saya, mencoba mencari update terbaru, namun ternyata versi di BB saya sudah yang terbaru.
Sementara saya masih belum tahu apa penyebab sebenarnya (hasil googling tidak menemukan topik tentang error di server BB atau Yahoo), namun hasil googling tadi menunjukkan bahwa banyak orang mengalami kasus yang sama. Berikut saya share solusi yang saya dapatkan, in case masih ada rekan-rekan yang mengalami kasus yang sama:

Solusi #1:
  • Buka Yahoo Mail anda (http://mail.yahoo.com)
  • Di pojok kiri atas -- di bawah nama anda -- kliksekali, kemudian klik "Account Info" (bila diminta password, isi dengan password Yahoo anda)


  • Pada halaman Account Info, pilih "Manage Apps and Website Connection" di bawah menu "Security Settings"



  • Pada halaman berikutnya, klik "Remove" untuk semua item yang mengandung kata Blackberry (Jangan khawatir, setelah anda terkoneksi item-item ini akan digenerate ulang secara otomatis)

  • Login YM dari BB anda. Sekarang YM seharusnya sudah bisa diakses kembali.
Solusi #2
Ini cara kedua yang saya coba sebelumnya dan berhasil:
  • Login ke Yahoo Mail
  • Masuk ke Account Info (ikuti cara di atas)
  • Pada Account Info, ganti password Yahoo anda
  • Login via Yahoo Messenger di PC anda
  • Selagi YM di PC terbuka, login via YM di BB anda. YM di BB anda kini sudah bisa diakses.
Semoga tips ini cukup membantu rekan-rekan ;)

Monday, November 1, 2010

A Guide To Building Mobile Game Image Assets II: Resource File & Animation

We've talked about how to break down image assets for mobile games on the previous part. In this part, we'll continue on how to create resource files and preparing animation assets.

Creating A Resource File

Loading image files takes process time, plus each image files actually have headers which can actually mean additional file sizes. If you have a lot of small images, it's best to combine the images into one single image file instead. In our previous example we have 3 files; the background, paper and pencil; just combine those files using image manipulation applications like Photoshop or GIMP into a single file called resources.png (file name is not a standard, you can think of any other name).

Try to have as few empty space as you can to reduce the file size to minimum, but don't break apart the resource image – say, the paper image – into smaller parts and then mix 'em up with other resources like the background image for the sake minimizing empty spaces; this will only confuse the programmers. Keep a sense of 'boxed' or image grouping. Lastly write down the position of each image groups (starting x and y, width, height) to help the programmers split the images into different images again later in the codes.


Animation Sprite


Animation is done in 2 ways: programmatically, or by image sequence (actually, 3 if you count a combination of both). For example, if you want to animate a dragonfly flying across the screen, then the animation of it moving across the screen is done programmatically inside the code. But the animation of the dragonfly fluttering its wing while moving is done by scrolling several frames of images in a sequence.

The image are stored as a single image, ordered in series frames from left to right or top to bottom; from the beginning of the animation to the end.

One thing to note is; and the one thing the artist often forget or doesn't know; is that the image arrangement MUST maintain the width and height of animation frame. Notice the difference between these two images:

Incorrent Goalkeeper.png:

The spaces between each frames varies from each other



Corrected Goalkeeper.png

Spaces between each frame is the same

Also when creating moving animation such as jumping, consider communicating with the programmer on making the movement path of the sprite to minimize empty spaces.


Additional Tips:

  • Use png files with transparent background.

  • Don't use too much colors, if possible use web colors instead. Chances are some of those colors won't show in the phone anyway (although some phones nowadays support more colors, but still it's a good optimization practice).

  • Don't use smooth gradients; I can't emphasize this enough.

  • If you're animating large sprites, it's a good idea to break down the spite into several smaller parts and animate just the important part rather than animating the whole thing. That way you don't end up with plenty of big image files and bloat the jar file. You can also try breaking it down into several small animations.

  • You can use third party png file compressor such as OptiPNG to make the image file size a lot smaller, just don't over compress the files as they may cause the image to not show on the phone itself. Personally, if find using OptiPNG with just the default setting works fine.

A Guide To Building Mobile Game Image Assets I : Image Breakdown

In creating mobile games, I seldom have problem communicating with the graphic artist on how the art assets should be. I found out that most of the time we are going back and forth on not how the game should be displayed, but on how the artist should prepare the image asset itself. Make sense, since most of the artist I work with never really had experiences with mobile games (while the ones that does are really hard to find).

Learning from that experience, I decided to compile a small guide on how to prepare image assets for a mobile game. This guide is dedicated for graphic artists, though I'm not exactly one (I only do some digital art once a while) I hope that it's quite useful. We'll start on how to break down a screen into image assets for the coder to use.

Note:
The image assets used in this article is created by me, taken from one of my games. Feel free to use them if you like, but don't forget to give me some credits.

Breaking Down A Screen

To enable the screen to be animated (and for optimizing purposes), a screen needs to be broken into several bits of images. Take this screen below as an example:


The first step is to split the dynamic elements with the static ones. We wanted to apply animation to the paper and pencil; let's say, adding a sliding into the screen effect at the beginning of the screen.

Therefor, the paper and pencil are dynamic elements and should be separated. The turn indicator and the writings on the paper are also dynamic elements, but we'll disregard them for now. Thus now we have three images: The background, the paper and the pencil.



The next step is to identify which element we need to optimize. In mobile games, it's generally not a very good idea to have large or full screen images; as we always need to remember that mobile phone has a limited memory heap size and/or processor. That's why the background image should be optimized. The trick is to find a repeatable pattern of the image, so rather than using a full image, we could instead use bits of the image and tile them using codes inside the game. Looking at our background image, we can see that it's actually just a single pattern repeating itself over and over, so let's just remove the rest. Now we have a smaller image for the background, shown below:

Taking the step further, we can also break down the paper image. By looking at the pattern, we could break the image into the following part, while the straight line on the paper can probably done by code so we can just remove that.

Tips:

Not every image can be broken down like this, for example, the pencil images. That's why you should always try to keep the images simple, and as much as possible avoid using gradient fill so it can later be broken down if necessary. Gradient fill especially smooth ones also use a lot colors, which means bigger file size, and it probably won't show much on the phone since the screen size is usually small.


Removing the duplicates, this is what's left from the paper image:

Last step is write down the size of each image parts, so the programmer can know how to replicate the image from the code (this is something the artist sometimes forget to do, and takes a lot of time for the programmer to figure out):


background = 176 pixel * 220 pixel

tile_background = 40 pixel * 40 pixel


paper=147 pixel * 176 pixel

tile_paper_left_border = 33 pixel * 11 pixel

tile_paper_hole_border = 33 pixel * 33 pixel

tile_paper_top_border = 11 pixel * 33 pixel

tile_paper_right_border = 11 pixel * 33 pixel

tile_paper_body = 33 pixel * 33 pixel


Note: the sample above is not a coding standard, just something I came up. If you're an artist and working together with a programmer to make the game, try talking with him to see what standards you should use.


Of course, it's much easier if you can break down the images into equal sized parts and then just tell the programmer the size of each tile parts.

Now that we're done with this part, on the next part we will continue on building resource file and preparing animation sprites.

Tuesday, July 10, 2007

Nasi Rames, Bu! Demo Version -- The Street Cuisine Game

Title: Nasi Rames, Bu! Demo Version
Type: Java Mobile Game / Casual
Supported Platform: Nokia S60 Series, Nokia NGage / NGage QD, Sony Erricson W-Series
Download: Here!

"Nasi Rames - A Traditional Cuisine from Indonesia, consist of rice with various toppings of fish, meat, vegetables and spices of choice. Usually sold by female street peddlers or traditional diners in Java."


Nasi Rames, Bu! is a unique casual game, where you play a part as a traditional food peddler. Your job is to complete your customers orders, by matching items in the order with items on the menu. Careful though, the longer it takes for you to complete an order, the customer might get impatient and decided to leave without paying. In each level, there's a certain number of score that you have to fulfill, or else you'll lose the game.

The demo version currently only allows you to play until level 1-3, but a full version game will come soon enough. Here's what to expect from the full version game:

  • More menu item, more order, more mayhem
  • Color Coded Order - finish orders with the same colors to add some combo bonus!
  • Out of this world orders - serve rice with the most unthinkable toppings ever: pizzas, cactuses, cell phones -- even rockets!
  • 21 wacky levels
  • Better graphics