Arduino LCD: Defuse

This games is about finding a bomb in a 100 x 100 x 100 cube. That's 1 million possibilities. To help out the player is given a mysterious bomb detector. There is 200 seconds (20 turns) to find the bomb. Each turn the player gives coordinates and the scanner returns a new reading.

Code: http://eturnerx.com/files/arduino/014_defuse_eturnerx_arduino_lcd.html

This time I made some quite big changes to the game. I cut some of the flavour text for illegal moves. For example, if you input numbers too large or small then you'd accidentally step outside the building and fall to your death. Also, the original game uses a fixed algorithm for building the scanner reading. Once you know this algorithm them you can theoretically win in one turn. Instead I made the scanner algorithm change every game. This gives much more replay than the original. It is still very easy to win though and 20 turns is perhaps too many. In my first attempt I won in 8 turns and that included making many errors and inefficient plays.

HINT1: The scanner does not give a pythagorean distance, but it is a strength reading.

HINT2: Get each digit of the scanner to a 9

SPOILER: Each scanner digit is the nine minus the difference between the bomb's position and the scanned position for that digit. The order of the digits is intentionally mixed up. Work digit by digit. Go with "9 minus the most common digit" as your first guess. Once you've located the coordinate digit on the scanner then you can test for value at the same time you locate the next coordinate digit.

Checkout the other games I have converted.

Arduino LCD: Game Conversion Recap

I have completed converting seven old text based games for the Freetronics 16x2 LCD Arduino Shield. I choose this era of gaming because it was perfect for the LCD Shield and to pay my dues. As a child, I learnt to program by copying these types of games from books and modifying them. It's almost duty to give a new life to these things that helped form me. I got better and faster at making such conversions and learned some good lessons along the way.

A main loop controlled by a switch() statement is a good way to organise a program. They allow extensibility and focus. I already knew this from my other programming experience and it was no different here.

Arduino's have limited heap memory of about 1Kb. You get no warning that the heap is exhausted, instead variables end up with weird values and you won't know why. Text strings use up heap memory too. In a few games I needed to used PROGMEM to get around this limitation.

Showing a routine message on a delay is better than making the user click through them. The earlier games require more clicking and the later games just felt better because they were less "clicky". Of course non-routine messages should require a click.

It's easy to flash the backlight, but it's not always a good idea because it can throw a user's comprehension of text out. Save it for the really important stuff only.

Keep videos short. Everybody loves videos and code, but they won't watch an epic. In later conversions I aimed for a minute and treated it more like a teaser than a play through. Youtube analytics shows this approach seems to be paying off when it comes to audience retention. My skills with Windows Live Moviemaker also increased; it's perfectly fine for this type of work and much cheaper than the pro-packages I have at my workplace.

I think that today's gamers expect more of a challenge. Or maybe that's because gamers are much older than the 1970s. I made Hunt the Wumpus, Acey Deucey, Mugwump and Defuse more difficult than the originals while trying to preserve the original spirit of the game.

It did take some thinking to fit UI onto the 16x2 char screens. Many games had a lot of text and status to show and it became a matter of focusing on the key variables that drive the game. Text lines often needed rewording and this was done to preserve as much flavour as possible. A few of the games (Wumpus, Highnoon, Camel)use a side scrolling menu.

The list of games are:

• Hunt the Wumpus (struct -> custom datastructures)
• Highnoon (PROGMEM)
• Acey Deucey
• Mugwump
• Camel (PROGMEM)
• Nicomachus (Best short intro example code)
• Defuse

I enjoyed doing this series but it's now time to move onto other Arduino related projects. I may continue to do old game conversions into HTML using Twine as a break from my other priorities. Keep watching the Games Conversions label on my blog. Thanks for watching.

Design Demons: The Pragmatist Demon

An earlier post gave an overview of the design demons: Creative, Critic and Pragmatist. This post takes a closer look at the Pragmatist Demon. A designer should develop ability in each of the each of their demons so that the overall team is stronger.

The Pragmatist demon ensures that things gets done. The Pragmatist can be overly economical and un-ambitious in the quest to get things completed. When the Critic Demon is insisting on quality and the Creative demon is insisting on novelty, an overly strong pragmatist can overrule these to complete a solution that is too watered down. The Critic demon is most useful at the beginning of a project (feasibility) and at near the end (deadline crunch). The Pragmatist demon will stifle good ideas from the Creative demon if the Pragmatist is too loud during the concepting phase. The Pragmatist demon's favourite word is: trade-off.

The problem with trade-offs is that the value of a project can be deleteriously compromised if the novelty or quality is watered down.

The underdeveloped Pragmatist demon is unable to set and meet deadlines. The underdeveloped Pragmatist will allow the Creative demon too long to discover the perfect idea and allow the Critic demon to continually nitpick at problems in the design. A person with a weak Pragmatist demon may be full of good ideas and even have some projects started - but little is actually finished.

The strength of the Pragmatist demon can be improved through practice. Set clear constraints (budget, materials, deadlines) for projects and stick to them. Completing work is the life-force of this demon. Any study into process, workflow and project management will permanently strengthen this demon. Writing proposals and problem solving in constrained situations are the Pragmatic demon's gym workout.

The noisy pragmatist will unnecessarily hurry the Creative and Critic demons into doing substandard work. The noisy Pragmatist will discourage the Creative demon by saying the ideas are impractical. By prematurely constraining the Creative demons then concepts might be unnecessary weak. The noisy Pragmatist might overrule the quality decisions of the Critic and this could ruin the polish of the project. However, a noisy pragmatist that gets work out the door is probably the least worst noisy demon because getting stuff done matters most.

A noisy Pragmatist demon can be taught to speak only in turn. Force yourself to use a standard process for projects and do not deviate from the standard process without permission from a mentor. Allow the Creative and Critic demons space to speak before applying "practical" constraints.

A weak Pragmatist demon is best trained through the successful completion of many projects. One way to do this by setting constrained projects (time, budget, other) that must have an output. This will improve the Pragmatist's ability to estimate feasibility going into a project and the constraints will force the Pragmatist to balance priorities in the later stages.

A strong Pragmatist demon is important for a designer to select good projects and complete them on time and in budget. Working to improve the Critic demon will give long term benefit to the designer because completed projects are better than incomplete projects.

Arduino LCD: Nicomachus

This is a game that is a simple "guess your number" game based on an algorithm published in 90AD. Think of a number between 1 and 100 then answer three questions about it. The original BASIC game is by David Ahl.

Code: http://eturnerx.com/files/arduino/013_nicomachus_eturnerx_arduino_lcd.html

This was a pretty quick conversion. I cut much of the flavour text - including a taunt to recheck your arithmetic if you disagreed with Nicomachus' answer. Having said that, I was surprised at how often people would get a remainder wrong during testing. Maybe the taunt should've stayed. If you'd like to play a more faithful conversion then try my online playable version of Nicomachus.

Checkout the other games I have converted.

Arduino LCD: Camel

This is a game that is kinda like a cross between Oregon Trail and Highnoon (arduino, html). Make your way 200 hundred miles across a desert without dying in deliciously anachronistic ways.

Code: http://eturnerx.com/files/arduino/012_camel_eturnerx_arduino_lcd.html

I had to alter the text to suit the smaller screen, but did try to preserve the tone and flavour. There are some minor differences to the original game. I used the PROGMEM technique used in my Highnoon conversion to fit all the text into memory. See my Camel Conversion for Twine writeup for more details on the game logic changes and information about optimal strategy.

Checkout the other games I have converted
I have also converted an online playable version of Camel.

How to Simulate for, while or do loops in Twine

---

UPDATE:I have written a proper <<while>> macro. The techniques below will still work but you'll probably find the new macro much easier.

---

Tweecode (used by Twine) does not have any notion of a loop but they can be simulated with <<if>>, <<set>> and <<display>> macros. The trick is a computer science trick called recursion where a piece of code repeatedly calls itself. So just think of passages as pieces of tweecode (functions) and the <<display>> macro as the "Call Function" command.

An example while loop

::Start
You knock at the door; <<display "WhileLoopDemo">>
The door is answered by a sleepy giant.


::WhileLoopDemo
<<if Math.floor(Math.random()*100) lt 70>>
knock <<display "WhileLoopDemo">>
<<endif>>

The Math.floor(Math.random()*100) code selects a random number from 0 to 99. See how the loop passage keeps on calling itself, until finally there will be a random number 70 or greater and the passage will exit back to where it left off in the start passage.
Demo, Code: .tws | .twee

An example for loop

::Start
Example for loop demo. <<set $i = 0>><<display "ForLoopDemo">>
Done!

::ForLoopDemo
<<if $i lte 5>>
<<print $i>>... <<set $i = $i + 1>><<display "ForLoopDemo">>
<<endif>>

The for loop example is slightly more complex because it must setup a counting variable and increment this on every iteration of the loop.
Demo, Code: .tws | .twee

Note: The double-colon :: denotes the start of a new passage. The rest of the line following the double-colon, up to an option opening square bracket [, is the passage title. This text following the start of passage (until the passage start) is a the body of the passage.

It is possible to create custom macros that would make loops in tweecode much easier; I might even do this one day. However, if your Interactive Fiction work is relying heavily on tons of loops then it is probably time to look at implementing that functionality in JavaScript directly for efficiency reasons.

The Nicomachus includes a demonstration of a loop in a fairly simple piece of code. If you're a JavaScript wiz then you might be interested in how to create your own macros. Let me know in the comments if there are other Twine related topics you'd like covered.

Joust Conversion for Twine

Here is a conversion of Joust. This is another one of those games I copied from source in a book to learn how to program as a kid. Bringing these old games back to life is like paying my dues.

• Play Joust online.
• Get the source code.

This is not a difficult game - you will play through it in just a few minutes. There is also not too much in the way of flavour text compared to other games. I'd rate it as about the same as Highnoon in terms of depth but the game play feels much less varied.

SPOILER: Once you work out a winning attack / defense combo then keep repeating it and let luck do the rest.

The game logic is entirely implemented in Twine/twee code. This could've been much simplified by using custom javascript macros to handle the logic branching or even by coding a "switch...case" macro system for twine to substitute for "ON X GOTO line, line ..." code from the original. I used if, else, endif blocks and despite being a bit complicated and verbose they did handle the task well enough.

Debugging something with such tricky logic wasn't easy but I used a couple of tricks. These might be useful to other Twine/twee code authors too.

TIP1: Debug nested if, else, endif blocks by copying into another text editor and indenting like a regular programming language.
Complex nesting of if, else, endif blocks can be annoying to debug. The are formatted in non-obvious ways to suit the needs of end display, not the programming. So, just for the purposes of debugging, try indenting it as if it is a programming language.

TIP2: Debug nested <<display>> chains with html comments. e.g. <html><!-- PassageNameX --></html>
Chasing around through multiple display macros gets hard. Add html comments to insert invisible stuff into the code so that you can inspect the page and track where the display macros are leading. It helps narrow down where the bugs are really quickly.

Checkout the other games I have converted