ScramWords -- a word game

Examples
1

It’s about 90% cooked, and I’m hoping to post to the app store soon, so I wanted to show it off here. The video might be painfully slow paced, but that’s not the game’s fault. That’s just how long it takes me to spot a word.

http://www.youtube.com/watch?v=C219k2ytjLo

The idea is to combine combine the speed limits of games like Boggle, with the board & tiles structures of games like Scrabble or Words with Friends. On each board, there is a starting position, marked by a dot circled by the word START. Also on the board are one or more spots circled by “NEXT LEVEL.” To progress in the game, build a bridge of words from start to a level up spot. if you are quick enough, you can rack up points by playing words anywhere on the board. You’re also free to dump your entire tray of candy-shaped letters any time you’re stuck.

Each board has a different layout. Time gets shorter. The challenge gets tougher.

Still working on some of the effects and nailing down board design and other details, but it’s basically all there.

The word test comes from a roughly 60k word dictionary compiled from public sources, filtered for duplicates and formatted for easy use. To fit the dictionary into Codea, I created one massive string per letter, put each one in it’s own file, and added a very, VERY simple interface. For example:

function checkStringX(w)
    return string.find(
    
",xenon,xenophobe,xenophobia,xenophobic,xerography,xhosa,xhosas,xmas,xray,xrayed,xraying,xrays,xylophone,xylophonist,"
    , ","..w..",")
end

I’m happy to share the dictionary files if anyone else is building a word game.

2

I like the game concept. Great job.

3

Very cool, @Mark! Do the words submit as soon as they match, or do you trigger that manually? I was wondering if you tried to spell a long word which had a short word as its beginning…

4

You tap the Word! text to submit a word. I did have it going off automatically, but ran into exactly the issue you describe.

5

Liking the fresher look and highlighting the target circle is good though I would still prefer that the target was the circle under my finger rather than up and left.

Also the option of tap to select from the tray and tap to drop into the destination circle would be appreciated :wink:

6

The problem I had when moving the circle directly under the finger was simply not being able to see – especially on the iPhone version. But I think I can move the selection point offset about 1/2 back to center on the iPad and get a more satisfying feel.

Let me work on the tap-tap implementation. It should be do able.

Hey, I’m just glad to see that at least one person is still playing!

It will be interesting to see the update stats tomorrow. Last time, it seemed like about 80% of the original purchasers updated. I’m assuming the other 20% deleted the app.

7

Fair enough for the iPhone but I guess it’s just personal preference. I equate dropping the letter the same as pressing a key on the onscreen keyboard - sure I need to locate it but once my finger is over the right button I no longer need that visual confirmation. I already know the destination where I want the letter to go before picking it up and dragging it - I don’t select a letter then hover about wondering where it should go. :-). Maybe have a settings switch which allows the user to choose?

ScramWords plus Crabitron have seriously dented my productivity on Codea!

8

Thanks, @West. That’s good company to be in.

9

Pulled up this long forgotten project yesterday, cleaned up the code, worked out a couple of issues, drew icons, created a help screen, and went through the hundred an one steps to push it through XCode to the App Store.

Just waiting now for Apple’s review process.

10

@Mark recently I had a go at squeezing over 100,000 words into Codea, and managed to compress them from about 860kb down to 270kb, which is pretty close to zip performance, through two simple compression techniques. On running the program, Codea extracted them back into a hash table of all the words.

I’m happy to share if you’re interested (I also posted all my words via this forum, a week or two ago).

11

I’d love to look at it. The 1.0 version went to the store with about 70k words. I did the simplest thing possible (as seen above) — crammed everything into a massive string and just did a string.find. Works essentially instantly, and it’s easy to tack on more words.

But I can already see a couple of things I’d like to add, and a bigger dictionary would be a nice upgrade.

12

my word list is here

http:/www.filedropper.com/words

I’ll send you my compression approach by PM

13

I pulled a word list off the Internet and encoded it in a 1025x1025 .png image file containing
300,249 words that I have in my Documents folder. Below is the number of words, by characters per word. Not sure if an image file would be better or worse than a string. I decode the .png file and create a table of words. See this post for info. http://twolivesleft.com/Codea/Talk/discussion/comment/16821#Comment_16821

EDIT: Here is another post.
http://twolivesleft.com/Codea/Talk/discussion/1972/send-file-to-a-pc#Item_6


char  # words
1     26
2     213
3     1511
4     5840
5     16153
6     21981
7     31221
8     38895
9     41596
10    39425
11    32745
12    25346
13    18134
14    11808
15    7133
16    4019
17    2185
18    1032
19    534
20    264
21    106
22    51
23    21
24    7
25    1
26    0
27    1
14

If you’re encoding in a lossless image and the pixels are essentially random, then the result isn’t going to be compressed much more than a plain string - unless of course you applied compression first.

15

It’s not really compressed. A 1025x1025 png file at 3 characters per pixel can hold 3,151,875 bytes. That’s a little more than the size of the word list I was using. A 1025x1025 png image was easier to use than a 3mb file on my iPad.

16

What I’m offering is the ability to compress that by about 2/3, if you are interested.

17

@Ignatz What is the benefit of compression here? Does it speed up the initial read of the dictionary (which would mean that decompression worked faster than the overhead of reading the larger file)? Once it is in memory, is there any difference between a compressed source and an uncompressed one? Or are you storing it still compressed in memory (which sounds like it would then need to be decompressed for every lookup so I consider that unlikely)?

Way back when (possibly when Mark started this project) we had a discussion as to the best way to store the dictionary in memory for fast lookup. I don’t remember the precise details. I think - Mark can correct me - that table lookup was faster but not by enough to persuade Mark to switch! (For table lookup, the words are the keys of a big table - actually, I think I had 26 dictionaries - and the spellcheck tests to see if the key exists in the key index of that table.)

Just checked. I didn’t have 26 dictionaries. I split my dictionary into 23 according to word length (so that I could decide only to load words up to some length) and to keep the file length not too big. I had 76,876 words in my English dictionary and 622,115 in my Norwegian one. I think I pulled the English one from the dictionary bundled with aspell and the Norwegian one is from some official/reputable (I don’t remember which) source which releases its word list as a GPL file (finally someone gets it right!).

18

I compressed my word file so I could bundle it in the Codea code rather than having it separate.

And because I find compression a fun game :slight_smile:

19

@Andrew Yep, a 70k dictionary returned values almost 40x faster from table lookup as opposed to my generic string match. But it spent over thirty seconds (on my ipad2) populating the tables. And since the return time on a string match was less than a tenth of a second, and I only need to do one lookup at a time, the easiest thing to do from a perspective of making it fast for the users was just leave it in strings.

The total size of the current dictionary comes out less than 450k bytes. Codea allows me to shove the whole thing into a string without complaining. So honestly compression isn’t a major concern at this point.

But I’m interested in packing a bigger dictionary, so long as it doesn’t add a long prep time.

I’m intrigued by the image idea. I’ve used the same kind of scheme (ChipBots originally had an option to save your whole bot design to a little postage stamp sized image) but I don’t quite see how you’d quickly unpack the dictionary or scan the image for a random scheme.

20

It takes 17 seconds to read the 1025x1025 image and create a table of words. So a 70k file should create an image of 153x153 and shouldn’t take more than a few seconds.