90-Ball Bingo Card Sorting

Categories: Flash Bingo Games

I haven’t really done any work this week, since Christmas is getting nearer (so I’m busy with other things). I did manage to get some work done today before going to bed: the 90-ball bingo card sorting is now functional.

Unlike 75-ball bingo, sorting the cards in 90-ball bingo is a little bit different. You can just sort the cards based on the To-Go count (i.e. cards with just 1 number needed to bingo are shown first in the display list). However, 90-ball bingo is played in sets, 6 cards in each set. So the better way to do this is to rank each set, then sort the cards within the set.

There are different ways to rank the set. For HB, I am doing it differently, since one set with 4 cards 3To-Go may be ranked higher than another set having 1 card 1To-Go. For this new project, I made it simpler, so the set that has the card closest to winning will always be shown first.

To illustrate, let’s say:

  • SET 1: One Card is 1To-Go, all the other five cards are more than 4To-Go
  • SET 2: All six cards are either 2To-Go or 3To-Go

Set 1 in the example above will be ranked higher, because there is a card needing just 1 number to bingo. This is even if Set 2 technically has more cards that need fewer numbers to bingo. Why I did it this way is because players would likely want to view the set closest to winning. In the event that any of the card in Set 2 suddenly improves to 1To-Go (and assuming the other cards in Set 1 haven’t improved), then Set 2 will immediately be the higher ranked set, putting it in front of the display list.

Tags: ,


90-Ball Bingo Game, Other Updates

Categories: Flash Bingo Games

Made some good progress… except for some card sorting details, the 90-ball bingo game is now fully functional. I just need to finalize the screen layout but the game is 100% playable already. Consolidating common codes and asset libraries paid off, since additional related games are easier to finish, like this 90-ball game which shared a lot of functionalities with the 75-ball bingo game.

I’ve also fixed support for “crazy” bingo game patterns. Progressive games can now include crazy game patterns as well. For the 90-ball bingo game, this means there is only 1 progressive game in play: Any Line, Any 2 Lines, then Full Card. It’s really how this game is played, but for HB I had to change the rules a bit since I only support static patterns in progressive games then.

This will also make it easier to make one of the new bingo games in the planning stage, which I’ll call Color Bingo. To make it more different than the traditional 75-ball bingo game, other than the color feature, this will play an all-progressive pattern, always ending with a full card. I’m hoping this game will also just take 3 days or so to complete.

Spin Bingo may or may not make it at site launch. It’s gonna take more time to finish, probably a week at best. I still have to work on the site itself, so I need to decide whether to work on that or Spin Bingo first. At some point, I have to launch already, then just do additional updates afterwards.

Tags: ,


Flash RSL (Run-time Shared Library)

Categories: Flash Bingo Games

Run-time shared library allows you to share common library assets across several Flash files. You place all these shared assets in one file, then reference it from the other files that need the same assets. This decreases the overall load time of your Flash movies, since the common assets will only (ideally) load once. Also, when you make changes to any of the common assets, it can automatically be updated in the other files that use it.

Sounds great, right? In theory, it does. In actual practice, it can be a lot more complicated to get things working right.

I have avoided using this feature in my previous games, because I know it can be problematic. There has been some known workarounds in previous versions of Flash, but I didn’t try implementing it, since I felt it’s not worth it, plus I have always been pressed with time before (so it was more important to produce some immediate results, rather than spend more time in the overall design and structure of things).

Anyway, I’ve decided to try this feature for this project, hoping that the previous problems have already been resolved in the newest version of Flash. Unfortunately, it seems like the problems are still there, and worse, some previous workarounds no longer work. Great.

Here are some of the issues I noted:

  1. There doesn’t seem to be a reliable way to pre-load the common assets. It’s very important that the user sees a progress indicator while all the files are being loaded, so without a reliable way to get progress while the common assets are loading, it is bound to create some perceptible delay for first time users.

    Solution: I hope there’s one(!)… still working on it. This is really a major issue, so hopefully I’ll find a way around it.

  2. Shared fonts: there is no way to specify just a specific range of characters you need, like in regular embedding. I know it’s possible in Flex, but I am still doing everything in the Flash IDE. So you end up embedding the entire character set, resulting to a bloated file size.

    Partial solution: edit the font file in a font editor program, then delete all the characters you don’t need. I say it’s only a partial solution, since there is still some additional overhead involved, compared to the regular embed size results.

  3. Shared fonts: you would have thought that since the font is already embedded, you don’t need to specify “embed” in the textfields anymore. Not true. In fact, you can’t even use the shared font in static texts. Technically, you can, but Flash isn’t really using your font. I only realized this when I started noticing that some text aren’t as crisp as it should be.

    Solution: for dynamic/input texts, make sure the shared font is still embedded. For static texts, convert it to a dynamic one. It’s not an ideal solution, but it works.

  4. Classes in shared assets are not “shared”, pretty ironic huh? This is a long topic, so let me just give one example. If you reference the class name in the other files for declaration purposes, the entire class will still get compiled thereby bloating the file size again.

    Solution: use generic Object classes instead. The down-side is, you won’t get compile-time checkings.

  5. You can’t share graphic assets. Well, actually you can, but not in a run-time context. The graphic will still be compiled in the other files, increasing file sizes, defeating the purpose of sharing it in the first place.

    Solution: convert it to a movieclip. Also, make sure it stays as a movieclip whenever you use it (i.e. don’t use it as a graphic asset). Some overhead again, but it’s the only way.

Anyway, the experience has been very educational for me, and I’m still hoping there’s a way around problem #1 stated above. Has it been worth it? I think so. The 75-ball bingo game, with chat included, is only currently less than 100KB in total. I’m guessing that for the 90-ball bingo and Spin bingo games, the player will only need to load an additional 20-30KB each because the other components have already been cached.

Let’s compare: on HB the game file total size (minus sounds) is about 334KB. That’s for 3 games, plus chat component included. The expected size of this new project for the same things: around 150KB maybe, more than 50% less than HB. Granted, I can’t really do exact comparisons unless both sites are using the same graphic sets (and they aren’t), however I think it’s a good gauge of how things are shaping up.

Some may argue if a savings of 150KB+ is even important, but bandwidth costs money. If you a have a couple thousand players, this will immediately run in the GBs. Also, the faster the game loads, the better.

In part, I think this is why all my online projects have also been successful. No matter how great your games or designs are, if players have to wait a long time before they see it, you would end up losing majority of them before they even get a chance to preview anything.

Tags: ,

« Previous12Next »

Search Blog