From a user-experience perspective, there were relatively little changes in the hangman solver and hangman word builder pages. While we modified several elements of the solver behind the scenes, these pages deliver more-or-less the same experience with a slightly more user-friendly spin.

The largest redesign was in the boggle solvers – we shifted a number of elements of these solvers around to adapt them for mobile screens. For small screens, we kept the rapid entry box and reflowed the word-grid structure on the screen so that it was easier to page through the possible words and see where they fell on the screen. For users with a larger display, we gave them the option of looking at a page-able and click-able wordlist to facilitate more in-depth review of your options.

We took advantage of this opportunity to clean up our section on word scramble solvers and word jumble solvers – these have been consolidated down to a single page (here). For those of your looking for points-based solutions, take a look at our scrabble helper and words with friends helper.

On that note, we implanted the first significant change in the scrabble helper page since launch; we eliminated the complicated letter / tile value entry panel and settled on a much simpler “starts with / ends with” structure for helping build words. We’re looking at a couple of additional options entry options for this page. The intent is to make it easier to use on mobile.

We’re always open to feedback – drop us a line. And if you like our solvers or puzzles, please share them with your friends on Facebook or Twitter. Our advertising budget resembles the null set, so any word-of-mouth assistance is appreciated!

The post Sitewide Redesign: Responsive Design To Improve Mobile Experience appeared first on Hanging Hyena.

For the aspiring web developers in the audience, the original version of this site was designed to render best on a desktop browser. I would still recommend this approach to a new developer. It minimizes the complexity involved in delivering your first project. Let’s face it, optimizing a web page for four browsers (IE, Safari, Chrome, Firefox) with similar screen resolutions is a lot easier than solving for three levels of display and multiple device sizes. Furthermore, I’ve found most full-sized tablets tend to be fairly forgiving when rendering pages optimized for a desktop display; the issue comes with smaller devices (small tablets and mobile phones).

The urge to improve the quality of our mobile display comes from two sources. First, we’ve seen a consistently higher bounce rate from our mobile users; while many of them do return to the site regularly, we would like to give you a better experience! Second, one of the small joys of running a site like this is being able to “show it off” to friends and family, which is slightly less impressive when you have do cellphone gymnastics to deliver a half-way decent display…

The new design will be based on JQuery Mobile: we’ve already got our first couple of prototype solvers in production. The first of these is our general-purpose word solver; we’ve got this set up to render a horizontal three panel display on desktop (data entry, words, instructions) which turns into a neatly stacked vertical view on a mobile phone. Once we got this working, we quickly moved the template to our scrabble solver and words with friends solver. At this point, our boggle solver is probably next. We want to finish piloting this on the smaller solvers before we modify our heavy hitters…

On a related note, we’re redesigning several of the features in our scrabble solver; please let us know if there is anything you would like us to consider incorporating.

The post We’re going mobile…. appeared first on Hanging Hyena.

The technical side of this project turned out to be fairly straightforward. As discussed in the article we wrote about building a fast boggle solver, we approached the problem as a twist on our existing scrabble solver. We took key elements of the logic behind our scrabble solver (which checks the possible permutations of a rack of letters) and adapted it to check the possible paths through a 4 x 4 matrix. To create the new solvers, we simple expanded the scope of this search to support a larger matrix.

The past several years has seen the launch of a number of new boggle-style games. We’re aware of a 5 x 5 version (Big Boggle) which until recently has been primarily marketed in Europe. In 2012, a 6 x 6 version (Super Big Boggle) was launched. The mobile space has seen Zynga’s launch Scramble with Friends (our original boggle solver was tweaked to serve as a scramble with friends cheat). And there is a new mobile game, Ruzzle, which has been growing rapidly this past year (our current 4×4 solver serves as a ruzzle cheat).

If you are currently using the solvers for other games, please drop us a line and we can look into tweaking them to serve you better!

The post Hacking Boggle: Extending Our Collection of Boggle Solvers appeared first on Hanging Hyena.

Like many developers, I’d had dreams of building “a product” of my own. I even had a couple of piles of code sitting around from various attempts over the years. Most of these were built around pretty solid concepts – the sort of ideas you could walk into a room and pitch to rational adults. Projects like games, a stock analyzer, and data tools. I’m imagining the “startup weekend” pitch for Hyenas:

“Team, we intend to become a market leader in the scrabble helper, hangman solver, and boggle cheat space. This site will offer illicit services to a large audience of low-revenue visitors and entertain them for hours on end.”

Keep your cell phone handy: the reaction footage from the MBA’s will be comedy gold.

But yet… unlike all those “better” ideas, this project actually got built and was launched. By the end of the weekend, we had a nice collection of command line Python programs. On Monday night when I got back from vacation, I took the hangman solver function and used the bottle.py web framework to turn it into a simple web service. The front end of the site was an HTML page, dressed up with some JQuery. By the end of the night, I had version 0.1 of the hangman solver. Two weeks later we were live on a shared hosting platform. We continued to tweak the site’s visual design and “analysis engine” over the next month before we did our public launch in January, via a Facebook post.

That was the start, not the end of the story, as those of you who have built websites are well aware. Once we were live, we had to set up all the supporting elements: Google Analytics, server monitoring, a WordPress blog, and social media. We launched with almost no awareness of SEO and “Google-friendly” site design: we spent a lot of time during early 2012 trying to figure this out.  Our focus started slowly shifting from the easily measured problem of “is this website running” to the much murkier challenge of figuring out how to grow an audience and make our users happy.

Along the way I learned a lot about Python and became a better developer in general. I’d been using Python for statistical analysis and simulation modeling for several years; this project forced me to learn the basics about a much wider site of modules in the Standard Library. I was presented with a series of problems to solve using Python, each of which had a tangible incentive for solving them (eg. less manual work, cool features/insights). Running a site also gives you religion around best practices like version control, commenting, and proper design. You’re forced to live with the messes you create!

Thus far, the project has been a success. We built up an audience of regular visitors, who click on enough ads that the site is self supporting. One nice aspect of the project is that our incremental cost of building new stuff keeps dropping: we now have a paid-for server and some SEO firepower to give new material a push. All of this from a project that would be laughed out of the room at a startup weekend…

In retrospect, I’m not surprised it worked. The secret sauce is that the whole project has always been small and crazy. This let us avoid many factors that kill serious projects.

Drawing from one of Paul Graham’s essays (How Not To Die), most side projects don’t die because they were “beaten in the market”, they die because the founder got busy working on something else. Unless you are wealthy with no family responsibilities, your side project automatically comes second. I’m not advocating any other set of priorities, by the way. If you want to be successful, you need to structure your project to power through these distractions. Here’s how we accomplished this:

• Focus on Utility First, Then Presentation: My goal is to walk away from every coding session on a new project with a tiny useful tool which solves a real need that I can use immediately. Don’t worry about scope, making it look pretty, or commercial potential. Crude scripts work great: most of my stuff starts as a simple 5 – 20 line Python script that automates a manual task. You can knock this out in a hour or two. Now… go use that script!

There are three productivity ninja hacks hiding in this picture. First, you are limiting your work session to an hour or two, boosting the odds you will actually write code: everybody can find an hour if they look hard enough. Next, by limiting the scope of the work to a single usable function point, we increase the odds of completion. Finally, by building something you will use regularly, you are setting up a reminder to finish the app. The latter is pretty serious productivity kung-fu for things like admin interfaces: by making something both seriously useful and painful to use, you maximize your incentive to polish up the visual design and supporting features over time.

This isn’t necessarily the most productive approach to writing code. I’ve found that I do my best work when I have an uninterrupted block of 6 – 12 hours to spend coding. However, this approach seems to work fairly well when you can’t dedicated large blocks of time to spend working on your project due to other obligations!

• Don’t Waste Time “Strategic Planning”: I actually tried to define a “strategy” for our offering in the early days. Our target audience was going be scrabble players, acquired by going viral on social media, and most of them will use mobile phones. What a pack of fatuous BS.

Most of our traffic is for other games, is generated via SEO, and my best commercial audience actually uses desktop browsers. I never knew any of that until we actually launched and watched the public reaction…

•  Share Early: I’ve spent too much time working on high risk corporate system stuff, so this was a big learning curve for me. Unless you’re actually accepting money or touching personal data, the consequences of being hacked or a system crash are generally pretty minor for a weekend project. The motivational value of seeing real live people on your site? Priceless…

The acid test of this principle occured in mid-April, where we had a fifteen hour outage when I was out of the country. It began 15 minutes after the start of a day-long business meeting (without cell service) and continued until I got back from watching hockey that evening. Net cost? Zip. The server was rebooted over hotel wi-fi and the monitoring script was fixed that weekend. We were back to our usual traffic levels within a couple of days.

• SCRIPT ALL THE THINGS! Your goal as a developer should be to eliminate your involvement in as many areas of the project as possible and streamline the rest. Most of this site runs on automated scripts: everything from server monitoring to administrative decisions. I can and have walked away from the site for weeks at a time.

Another nice thing about scripts is you can usually recycle them on future projects, permanently increasing your productivity…

• Steal Reuse Code Shamelessly: This one is simple: you have finite resources to get a side project delivered. Don’t waste your energy reinventing the wheel. Remember, anything that prolongs your delivery of a working product increases the risk you won’t complete the work and launch.

There are many wonderful open source projects out there that solve 90% of the problems involved in website development (WordPress, Jquery, Django, bottle.py, others). Unless your goal is to replace WordPress or Django, don’t waste time redesigning them….

• Take Delight in the Absurd: Anyone can go build another content management system, photo sharing site, or social networking service. Unfortunately, that usually means that everyone will take a shot at it, pitting you against a flood of competitors. But for weird stuff like building a worm farm designer? Craft Beer analyzer? Consignment sale manager? Not only is it much more memorable but you’re much more likely to discover a little niche that you can own and enjoy…

I suppose a final tip might be to pick something that you love – either in the content or the process of developing the site – and center your time around that activity. That helps you keep going through the early stages of the work, where you’re plugging a ton of time into a site or feature that only gets a handful of people per day. Because time will suddenly become your friend once you get moving: old sites have more credibility with Google and it is often much easier to version / modify your existing code than build new stuff. Love helps you power through the tough spot.

For our regular readers, thanks for a great first year! We look forward to helping you beat the cheetahs and laugh like a hyena for many years to come!

If you liked this article, share it!

Tweet

The post Hanging With The Hyenas: Lessons Learned From Delivering My First Side Project Using Python appeared first on Hanging Hyena.

Here’s how I break up my posts:

• Show Horses – The good stuff! Content that you want shared on social media and that you eagerly hope will generate quality backlinks. A Show Horse post requires a good concept and high quality writing. The topic should be something with broad interest to the Linkerati (SEO, building websites, running a business) and requires a certain amount of “polish” to really make them fly…
• Work Horses – Covers a niche topic in reasonable depth, may be part of a larger string of related posts. These are generally SEO focused – oriented towards a specific set of keywords and/or containing well-crafted links to a second site. Expected to attract a modest amount of highly focused traffic (eg. tell me how to install library XYZ in python) who is a potential buying audience for affiliate items. Requires average writing and less polish than a show horse. Frequently ranks on their own pretty quickly but won’t attract much traffic – might attract some respect and/or links from insiders in your space if well written.
• Kibble – Lowest quality posts, written to let Googlebot know that you’re still alive. Often a good source of “house links” with targeted anchor text within your site and to related properties. Since this site is about word game solvers and word games, we have several options for cranking this stuff out. New word game features and upgrades are a good source of kibble (like when we released our hanging with friends cheat and scramble cheat). This stuff can be generated using a template (at least at the conceptual level) so you can create it efficiently. This is the blog equivalent of a DJ playing a long song while they take a break.

Each of these requires a different level of investment to succeed:

• Show Horse content frequently requires a couple of days to really optimize; this is where getting external perspective from a designer or SEO consultant can help. It should also be less than 10% – 20% of your total content – you generally don’t get more than 1 – 2 true Show Horse ideas per month.
• Work Horse content will require more subject matter expertise than Show Horse content, since you’re generally going deeper on a topic and establishing authority. Since these posts will be generating search engine referals you should take steps to control your bounce rate. Avoid thin content and make sure the article contains enough related links to deter visitors from quickly returning to the seach index. On a similar note, invest the time to make sure the technical quality of this work is solid. On the positive side, it will (or should be) evergreen content which you will derive value from for many years.  I’ve found I can generally crank out a quality Work Horse article in about 2 – 3 hours. Bonus Tip: Recycle your old presentations into Work Horse articles; you’ve already done about 80% of the required work.
• Finally, be ruthless in reducing the amount of time required to generate Kibble. The best Kibble is generated as a byproduct of your regular business activities.  My favorite source of kibble for this site is doing short (300 word) announcements after we release a new word game solver (for example, when we launched our words with friends helper) or tweak a feature. This usually can be cranked out in under 10 minutes. The other great source I’ve seen is data from software testing and usage reporting. I’ve taken output from a couple of the test programs behind the word game solver (here’s an example) and reformatted it into reference posts, doling it out 300 – 500 words at a time. Some of this stuff even ranks!

Know what you are trying to deliver – and invest accordingly..

The post The Three Types of Blog Posts – Show Horses, Draft Horses, and Kibble.. appeared first on Hanging Hyena.

This is a big issue in the open source community. Github and Google code are littered with the remains of half completed and unmaintained libraries. This is a loss to everyone involved: the volunteers that built the library, the brave souls who were early adopters, and the community at large. And when the open source ecosystem fails for a particular space, our end-users have no choice except to turn to a corporate provider.

To Advertise or Not, That Is The Question…

This site started as an experiment and family project. While it has always been of commercial value to us, the initial gains were indirect. It opened up some great doors. It also gave us a safe place to validate the underlying technology. LoadRunner can’t compete with a couple thousand crazed scrabble fans!

However, there is a certain amount of recurring work and expense involved in maintaining a site. On the low end, you need to keep the spammers in check and maintain a minimal level of content/link creation to keep Google interested. On the higher end, you need to respond to changes in the underlying games and new game launches. After a few months, this can become a burden. It competes with family time and new projects, chewing up the credit card a bit.

Which is the first revelation – the project already was “work”, I just wasn’t noticing it in the early stages of the site. Once competing priorities arose, it became harder to rationalize doing this work. This isn’t unique to this project, by the way. The same issue occurs with most of the lesser open source projects and weekend hacks. Unless you have a huge mission, engaged audience, and strong team – many projects flounder at this point. Start strong, fade away to nothing.

This site took an important step towards self-sufficiency last week. We started displaying ads. The purpose of this article isn’t to brag, by the way. Hangman solvers aren’t a “get rich quick” niche – cash hungry internet marketers should keep walking

What a Revenue Stream Really Provides: Freedom to Grow…

Most of our vacations involve trips to the beach, which involves a 6 – 8 hour drive (with small children, which only makes it longer). This usually tends to be pretty good “thinking time”. This site was conceived on our last Thanksgiving trip and we cranked out a couple of improvements over Christmas before we launched. This trip was no different – once we settled down into the long drive across the South Georgia countryside, I started thinking about the stuff I wanted to build next.

That’s when it hit me. I have a budget now, at least in the eyes of my wife and the IRS. Not a big one – I still need to show up at work on Monday – but enough to cover part of the expenses of “trying something new”. Want to redesign an interface and spend $50 bucks on a Javascript book? No Sweat. Need to start a secondary site (new domain,  another hosting account)? That $100 is covered. Feeling the desire to spend a couple of days building a new solver? “Hey Honey, we might be able to fund a date night or two from a new solver…” That goes over a lot better with your significant other than “I’m going to hide in the basement and cut some code, see you in a week” – just a tip for you married guys

The ads don’t generate much, just enough to cover our costs. That flips this site from being a burden to a net benefit. Worth protecting and improving. Sustainable. Funded by something other than pure ego.

Plus A Running Start For The Next Adventure…

For the entrepreneurial developer, there are three really good reasons why you should try to monetize that little side project. Even if there isn’t much commercial potential.

First, it will make you a better developer by encouraging you to maintain / expand a project over a long period of time. Even during a quiet month, I usually wind up tinkering with something that reinforces my understanding of Python or Javascript. It also gives you a token incentive to buckle down and learn the ”hard stuff” in your chosen toolset, using tangible projects and measurable outcomes.

Second, it gives you some exposure to the business side of the web: generating traffic and monetizing it. If you ever do launch a ”real product”, you will need to know this stuff. SEO and social media sounds silly until you realize just how much traffic can come from Google, Reddit, and Twitter. Ad design, targeting, and placement are boring until you need those $5 clicks you are buying from Google to start covering their cost. It is a lot easier to learn this on a small site than after you start a real business – with partners, investors, and customers asking why the server keep crashing and when the next payment is coming.

Finally, you get a running start on your next adventure. The server is paid for. We have a battle tested codebase that can give us a head start on development. Google crawls this site regularly – we can get new content indexed and ranked within a few days and know how to get the first dozen links to a new site (without resorting to spam). My out-of-pocket cost to test something new just got very small…

And that is the big win. When you take the cost of running experiments to near zero, you can explore a lot of ideas. It’s like being locked in a room full of free lottery tickets. It’s up to you to keep scratching…

The post Building Sustainable Websites appeared first on Hanging Hyena.

We opted for a minimalist approach – enter your letters and we give you a list of possible words. The player is free to play them how they wish – keeping them involved in the strategy of how to put down their tiles while we help out with crunching through the dictionary of potential words. This gives a nice balance of help without making the game too easy…

Naturally, we did a version of the scrabble solver which was customized into a words with friends helper. Same basic design, just optimized some features for that game. Interestingly enough – while I suspect most of our audience is actually playing words with friends, the bulk of our scrabble traffic is on the regular scrabble solver. We actually saw a similar effect on the hangman offering – people tend to use the relatively generic hangman solver rather than our customized hanging with friends cheat.

We did look at a couple of alternatives – the algorithm behind the scrabble helper is actually fairly flexible. One of our early designs actually envisioned a full board solver. From a technical perspective, this would have been fairly straighforward. We would have basically written some loops to generate the additional cells (full board vs. row) and then extended our solver to iterate across the different rows/columns. The biggest challenge, from a usage perspective, is the chore of entering / maintaining every more. We suspected that would turn off about 99% of the audience (based on analysis of a couple of similar sites)…. and thus our simpler approach (which gets a bit more love).

The key is balance – give people just enough assistance that they can win a little more often, while giving them just enough skin in the game that they want to keep playing..

Incidently, we’re open to feedback – if there’s a feature you like / hate / love / need, drop us a line and we’ll take a look at it…

Head Hyena.

The post Scrabble Helpers – Striking The Right Balance appeared first on Hanging Hyena.

Writing word game solvers has become something of a hobby for me. My first project was a Hangman Solver: this started off as a regex filter (Python) applied to a word file which we tweaked to make it more efficient. The next step was modify the program into a Hanging With Friends Solver: there are a few tweaks in Zynga’s rules which make it easier to guess a word (reduced number of possible answers). This website was built by taking these two Python functions and embedding them in a web framework.  The front end is HTML dressed up with some basic JQuery.

Our scrabble word builder served as the starting point for the boggle solver. Scrabble requires an efficient search through the possible combinations of a sequence of letters. Boggle is a twist on scrabble: instead of searching the permuations of a sequence, you’re searching the possible paths through a n x n grid. The required change was a handful of lines in Python to implement.

Drawing the web page was also simple: since a grid is basically just an array with line breaks (thank you, CS 101), we cannibalized the array widget from our other solvers. So far, so good….

Most of our prior solvers relied on the stately “chess-like” pace of play in Hangman and Scrabble. The solver automates the process of finding “options”: we presented a list of possible words, from which the player must select the best option (score + plausibility). From a user perspective, they have the time to flip between screens and page through lists of ideas, since they only need to select and play a single word.

And this is where things came undone….

Instead of passing a sequence of seven letters back and forth, Scramble with Friends (Boggle) requires you to pass a set of sixteen letters into the solver and enter multiple words into the application as your answer. Remember, humans can only hold a small amount of data in memory, forcing the user to make multiple trips. Our solver walked into a “pipe capacity” problem: we needed to move too much information through the player for the available time…

Thank you Mario, but our princess is in another Castle..

For all you aspiring game designers out there, know this: speed is a great antidote to cheating. Speed matters in Boggle / Scramble with Friend. Judging from the boards I saw during testing, a typical Scramble with Friends grid has 300 – 400 possible words. A fast player (like my wife) can knock out 30 – 35 words per hand. Relatively intelligent slowpokes like myself are limited to about 20. That’s a 50% increase in “raw points”, most of which are likely to go unopposed (since those are 10 incremental words). If a game of scrabble will go to the smartest player, a game of boggle goes to the fastest.

This emphasis on speed is facilitated by the fact a good natural player can knock out 500 – 600 points per round using techniques like word stemming (plurals, suffixes, and  prefixes). These are best done outside a solver (eg. looking at the screen) to reduce the amount of screen flipping. Zynga also added an inspiration option to the game, which provides the user with some suggested words to play. These are all alternatives to using a solver (or things you may use in combination with a solver).

So What Actually Helps Here?

First, reframe the problem into something we can actually solve. There just isn’t time for screen flipping: between the time required for a cell phone to switch screens and the limits of human memory, you won’t get enough speed to make the exercise worthwhile. Now if they are using a regular computer or another phone… we’ve got a chance…

You should also consider the fact that the typical user wants an edge but doesn’t want to lose “respectability”. While there are technical options for quickly getting the data into the solver (screen snap -> OCR), most of these actually have a short user lifecycle (for non-psychopaths) since they’re too high powered. After a weekend of absolute carnage, the thrill wanes.

Next – define how the solver is going to help, relative to natural play. Two things matter in boggle: word quality (points value) and word entry speed. Word entry speed breaks into two parts: time spent finding words, time spent “drawing” the word. Identify what you can improve (points value, pattern recognition) and what you can’t (drawing speed).

The most obvious thing we can do to improve points value is to rank our possible words in descending order. That came down to an embarassing trivial Javascript array sort. We already had a JQuery word list widget from our earlier work. Done. While I may only crank out 20 words, I can now find “senator”, “fiendish”, or other high scoring ideas.

Now lets attack the problem of helping the user find words on the letter grid. We solved this by using Javascript to add two features to the front end design. First, we used Jquery to highlight cells containing the letters for the word (green for the first letter, red for the last letter, yellow for everything in between). Next, we used the jsPlumb library to draw lines between the letters in a word. Instead of looking at a wall of letters, the user now sees this:

I was blind but now I see! This was a critical process improvement: our test users spent a lot of time staring at the word grid, trying to find the suggestions. Highlighting the word and drawing the path made it easy to see what you needed to plug into the mobile app. The jsPlumb library was easy to use; however it doesn’t always work for mobile viewers.

To squeeze a little extra performance out of the solver, we worked on reducing the time required to use the solver. We added a “next word” button to help the user quickly page through the suggestions. We added a quick entry box for experienced users: quickly type all the letters in the 4 x 4 grid into the box and it will populate the grid for you. Simple stuff, but no sense in losing performance by neglecting basic UI elements…

Finally, don’t be reluctant to coach your users. The idea usage pattern for this particular solver is actually NOT to use it to play every word. I’ve gotten the best results by using the solver to identify the highest scoring words (juicing my score by 100 – 150 points), then using “word stemming” (plurals, prefixes, suffixes) to crank out a bunch of related words. The “inspiration” option is also pretty useful (Zygna gives you three words).

The final product works pretty well.The solver is more helpful to middle-of-the-road players, where it gives them a few hundred extra points per round. A good natural boggle player often solves the letter grid in their head faster than with the solver.

Before we close, I’d like to point out some of the stuff that we didn’t do in this approach. We didn’t waste any time trying to get the solver to work for a mobile browser… since that isn’t the reasonable use case (can’t flip back and forth fast enough). We also focused our work on only a handful of areas, ignoring several additional improvements, and recycled our existing code. This let me crank out a first working solver in only two evenings of work (one for the solver, one for the UI).

This was a fun little project: while the solver itself is a pretty frivolous application, jsPlumb seems like a pretty useful addition to my toolkit going forward. There are definitely some real world applications for this great little library.

More importantly, I now have a hope of beating my wife at Scramble with Friends!

If you liked this article, share it!

The post Hacking Boggle: Designing A Fast Solver For A Timed Word Game appeared first on Hanging Hyena.

Give it a try and let us know what you think. It has the same basic look and feel as our regular Hangman Solver, which you are (hopefully) already using!

The post New Improved Solver For Hanging With Friends appeared first on Hanging Hyena.

The initial prototype was assembled relatively quickly (over the course of a few nights) using components from other projects. After a month of testing and tweaking under the watchful eye of my wife, a diehard Hanging with Friends and Words With Friends fan, we were ready to share it with the world! And now you’re looking at it…

So here are some features on the hangman word solver that we’re particularly proud of:

• Interactive Word Entry – the list of potential words updates automatically after each key stroke (through the magic of AJAX and JSON)
• Pagable Word List – words are displayed in a neatly digestible sets of 8 – you can page back and forth within your set. This is limited to a list of 50 words to keep the application quick…if you have more than 50 possible words, you should try…
• Dynamic Letter Guesser – helps identify which letter to guess – this is based on an analysis of all the possible words that fit the given set of clues and calculates the probability that a letter is in the set of available words.
• Can also be used to help identify words for a child’s letter bag…

Recognizing that the best defense is a good offense, we also assembled a hangman word builder  that helps you build words from the tiles on your rack at the beginning of the game. Some of the cool features of the word builder:

• Same basic look and feel as the solver (real time updates, page though words); enter up to 16 letters and page through the top scoring results
• Supports “tagging” a particular tile on the board for additional points (eg. double words, triple letter, etc.)
• If you wish, can filter the list of possible words to incorporate a preset letter – this allows you to use this as a simple scrabble solver and anagram analyzer…

It works nicely on the major desktop browsers and renders fairly well on mobile phones; go ahead and give it a Try! (word solver)

The post Building A Better Hangman Solver appeared first on Hanging Hyena.