“Resolver Games” are alive!

Resolver One competition

I admit I participated in the Resolver One competition in the first round in January as one of the losers. When Resolver Systems announced their challenge I got the impression they encouraged using their spreadsheet almost like a medium for expressing ideas and thinking out of the box. However, Resolver Systems is yet another company which exists solely to sell stuff and consulting, not a patron of modern art or hacking experiments. So the awarded spreadsheets are looking a bit conventional and are technically unsophisticated. Their sophistication lies in external factors like the scientific ideas which are exercised. Some make extensive use of graphic capabilities of .NET which is also outside of the Resolver One API. It’s good demo stuff nevertheless and this might be their main purpose in the end.

Resolver Games

I’m glad to see Resolver Games being online now which was my own contribution. Resolver Games is about simple learning games for word lists. The examples I used were from “Teuton” ( Teuton is a German Python dialect, inspired by an Artima posting of Andy Dent, which replaces Pythons English keywords and builtins by German translations of them – Teuton is one of my fun projects and a langlet demo for EasyExtend ), the other one is IPA – the international phonetic alphabet – which is just a great learning target.

A Resolver Game consists of a pair of Resolver One spreadsheets. One for the word-list/game data and the other one for the game board. The game data spreadsheet is conventional and stateless. The game board is designed to be generic and independent of the particular game. The game board was tricky to program because it uses the spreadsheet for event handling and user interactions. Writing an event handler is a bit like scanning a screen and notify changes by comparing the actual with the previous image point by point. Resolver One stores data in the background and those data affect re-computations. Sometimes I wanted to cause a user event doing re-computations without changing the displayed data. I used the following trick: add and remove a blank to the cell-data and swap between the two representations periodically.

"+" -> "+ " -> "+" -> "+ " -> ...

When the cell content is “+” change it to “+ ” and vice versa. This goes unnoticed because there is no visual effect associated with the blank. Once I got into whitespace oriented programming the hard problems with state changes in Resolver Games became solvable.

One could argue that Resolver One is simply not the right-tool-for-the-job and it is overstretched in this application. I don’t disagree but this line of argument always appeared philistine to me and I reserve it to those who simply don’t know it better. A more serious objection to Resolver Games might be the fun aspect. Is it really fun to play? Resolver Games are surely a bit poor in game dramaturgy and visual effects. So I’d rather say NO, but I’m not a gamer anyway.

This entry was posted in Python. Bookmark the permalink.

3 Responses to “Resolver Games” are alive!

  1. Giles says:

    Hey there,

    Sorry we some across as being just “yet another company which exists solely to sell stuff and consulting, not a patron of modern art or hacking experiments” 🙁 To be honest, we’d have loved to award the prize to a really cool game, we were hoping to see ports of Zork and other crazy stuff. Unfortunately, perhaps because Resolver One is a spreadsheet and so it attracts a fairly businessy crowd, almost all of the entries were very serious in tone — which also meant that the ones we thought were best were also serious.

    Still, if you want to see game apart from your own in Resolver One, there were some others:

    http://www.resolversystems.com/exchange/tags/game/

    All the best, and thanks for entering.

    Giles

  2. the really sad thing is that while resolver is a spreadsheet application written in python and using python for formulas and extended functionality – in other words, a consummation devoutly to be wished – it is still (1) proprietary software that (2) only runs on windows and is (3) slow as a slug, or worse.

    when i start resolver i have to wait several minutes before the interface shows, and when it does, i am greeted with the message that the re-calculation of the empty default sheet just took 0.8 seconds. not too bad for a sheet devoid of content, no? the ‘column level formulae’ deomo sheet reports 5750 milliseconds for its initial calculation; trivial edits cause re-calculation times of around one second. i wonder whether there is something wrong with my machine, but then this is not the first time i tried resolver, and the experience is always the same: moving around on the sheet and entering numbers is painfully slow, to the point of making resolver a completely useless piece of software. maybe it’s just me, and someone can comment on my preceived speed problems.

    that said, let me repeat that a working spreadsheet that is built on / makes use of python is highly desirable. it would be even better if such an application could avoid to become a complete clone of ms excel with all its bugs / design deficiencies / deliberate malfeatures, like the many spreadsheet applications out there… they clone the braindead excel formula language, and they clone the idiotic 65536 rows limit, something excel 2007 itself has gotten rid of. most of the competitors are worse in dealing with unicode, are ugly to perceive, or are just too dumb for the job, which means everytime i leave excel i come back to it after a short while. why use a dumbed-down clone when i can use the original? resolver could fill this gap if it wasn’t for the aforementioned issues.

  3. kay says:

    I didn’t check Resolver One with the latest IronPython. IronPython has reduced startup times considerably in favor for a more lazy compilation process. Unlike Jython which produces class files on the fly, IronPython doesn’t produce assemblies which means that compilation starts all over again. I’d say it was a wrong decision to create Resolver One using IronPython all the way down. Incidentally embedding Python is a little underdeveloped. It makes progress with the DLR but even there we find bugs in very basic functions.

    I don’t want to go deeply into the social implications of commercial software here but just mention that there is no moral duty for either starvation ( which might be my own option if I continue my current living ) or live in the chains of big corps and then having a clean consciousness because one contributes to OSS ( hi, Googlers! ). So I’m rather with the independent software developers who can make a living with the products they create and not just by customizing super-complicated infrastructures produced by anonymous agency or by other big corps like SAP.

Comments are closed.