Bookworm Deluxe For Mac Free Download

[Laurene Arrison]

Bookworm is a puzzle game where you have to create words with the letter tiles in the field. Click on adjacent letters to form words and score points. The longer the words you create, the higher your score will be! There are also special tiles and bonus words. Beware of the red burning tiles, because if they reach the bottom of the screen the game ends.

Click on the letters you want to use to create a word. You can only select adjacent letters. Once you have formed the word you had in mind, click on submit and Lex the bookworm will eat the letter tiles you selected. New letters will be provided so there are always new options to explore.

In the original version, bonus words were displayed beneath Lex the bookworm starting from round 2. Forming these bonus words boosted your score. This feature is unfortunately removed from the version we currently have on our website.

Hi, I'm Tomas from SolitaireParadise.com and I would love to hear your opinion about this game, or if something is not working. Just let me know and I will do my best to look into it! Your feedback will NOT be visible for anyone except me.

I started from the template in my ancient win32 tutorial (after fixing a few things that don't work anymore, mostly casting variables and resolving between A vs W versions of functions). This gave me a win32 app with a windows bitmap I could poke directly.

To get the pixels from the game's window, I asked window to give me the window handle, got the device context for the window and after that I could simply bitblt the bits over to my bitmap. Easy peasy.

Sending clicks to the game was done via mouse_event (which is deprecated, but works, and is likely to be simpler than the currently-official method). To position the clicks properly, I needed to query the window's position.

There's a danger in doing controls this way, namely, while your bot is in control, there's fairly little you can do to stop it. I experimented with detecting keyboard presses to kill the bot, but with the focus on the game this is rather tricky. Eventually I ended up setting up another administrator account on my PC so I can control-alt-del and switch users and then kill the bot from the other account.

Now that the bot can see the game and click on it, I needed to know which state the game was in. This I did simply by looking at the values of a couple of pixels on the screen; this pixel has this value only when in the main menu; that pixel has this value when asking to start a new game or continue previous one; that pixel has this value when in-game.

My first stab at the OCR was to take a few pixel values from each letter, and ran the game until it didn't detect several letters (by painstakingly comparing the two glyphs and adding another detected pixel). This didn't work horribly well, but let me get started with the other parts of the bot.

The final iteration first runs the screen capture through a preprocess where the pixel values are first multiplied by themselves four times to crank up contrast, and then pixels are considered "dark" if their value is less than 1/6 of the brightest pixel of the tile. This let me get mostly legible glyphs out of even the brightest and most particle system-filled tiles.

When matching the glyphs, first the tile is scanned for "dark" pixels, and if the dark pixel matches the glyph's dark pixels, the glyph gets a point; if it doesn't, the glyph loses a point. Finally, the glyph score is divided by the number of dark pixels the glyph is expected to have. The glyph with the highest score is selected.

If you were to load up the glyphs in photoshop, you'd be surprised how few pixels differ between some of the glyphs, such as O, C, G. Another times, one glyph pretty much completely covers another, such as with M and V, or B and E. Hats off to any "real" OCR software - mine was working in more or less optimal starting point (ignoring the particles and such, of course).

Now that the game board is known (or close enough, anyway), I needed to find the words. In the first few versions I used a big word list I've used in the past, but that contains so many words bookworm doesn't recognize that the bot wasted a lot of time just trying various words.

So I figured it would be best to use the same dictionary as the game. I googled to find whether someone has extracted it already, but all I found was someones explanation on how to add words to the word list. I shrugged and took a glance at the word list file.

Then I just went through the game field recursively, traversing the tree whenever a valid branch was found, and whenever a full word was found I recorded it. (so for "books", "boo", "book" and "books" words would be noted).

So if we were tracing that graph and we have already found two 'a' letters, the next possible letters would be 'h', 'l' or 'r'. If none of those tiles are available, we're done. If we do find a 'h', we record "aah" as one word, and then start looking for 'e', 'i' or 's', and so forth.

Each found word is given a score based on the difficulty of the characters (so that 'e' gets one point while 'Qu' gets four), multiplied by any special tiles the word crosses. Normal tiles have multiplier of 1, special tiles have multiplier of 2, while fire tiles have a multiplier of 100. I really, really wanted the bot to concentrate on killing the fire tiles.

With the potential word selected, the bot clicks on the tiles of the potential word, and then reads the screen to see whether Bookworm gives a word score (meaning bookworm considers it a valid word). If so, the bot clicks on submit. Sometimes the particles that fly from the total score hit the area where the word score appears, causing the bot to think it has a valid word =)

Whether the word was valid or not, the bot will then take another screen shot and tries to figure out the tiles. With all the noise going on, it's best to just retry the OCR a lot. To avoid trying to enter the same failed word over and over, whenever a word fails, the bot will skip a word from the best-scored list. This counter is reset on a valid word.

It's still possible for the bot to lose. If a fire tile appears at the bottom (or gets there by accident), and is surrounded by incompatible letters (such as 'V' surrounded by 'Qu' tiles), it will never get included in a potential word and this won't be scored!

Detection of game state (including the "level up" dialogs) could be more robust. I didn't set the game to click on the "level up" dialogs by design so that I'd get control back every now and then. As a stand-alone demo that would be easy to add.

A smart human player can pick a low-scoring word just to get the tiles into a configuration where a high-scoring word is available. The bot doesn't even consider this. Another human strategy is to save the bonus-multiplier tiles until a long word grabs many of them and scores even higher. This would be easier to implement.

In the end, I only ever ran the debug build of the bot - the processing power of modern computers is downright crazy, considering all of the brute-force pixel-crunching and recursive word searching that it has to perform. The dictionary, in it's rich and expensive tree form, takes about 25 megabytes of memory.

It was a fun little project to do, but I'm not even going to release the source code (for obvious cheating reasons). I never cheat in multiplayer games; someone might use this "engine" to do just that.

c80f0f1006