Showing posts with label Building Software. Show all posts
Showing posts with label Building Software. Show all posts

Tuesday, March 22, 2016

Future: Audio Games with Amazon Alexa (or Siri)

The other day I attended an AWS user group where a Solutions Architect for Alexa Voice Service spoke about developing for Alexa. She showed off her Amazon Echo and a couple of skills that she had written for Alexa and urged us all to write our own skills with various AWS services.

I’m not a cloud expert, so much of the details went straight over my head.

She also talked about how voice UI and Alexa are new and will end up everywhere, even cars. We could build an Alexa client on a Raspberry Pi today!

Eliza

Could Alexa run Eliza? When I was in college I learned about Eliza, a program that can respond as a Rogerian psychotherapist (that target was chosen because the natural language processing could be really lame and it would still seam real). After college I bought a 286 computer and found a GWBasic version of Eliza. I played Eliza more like a game, sometimes her responses would make me laugh until it hurts!

The thing that made Eliza so much fun wasn’t the quality of the Natural Language Processing. She could change me to you and you to me and spit the sentence right back to you, track if she had “heard” certain references to your parents and “say” profound things like “I understand”.

I image that the text processing to be wired up as “YOU” and speech synthesis wired to “ELIZA”. I used an online version of Eliza.

Interactive Fiction

Back in the ancient times, in some computer games, you would type commands and the computer would present you with paragraphs of text describing where you are. Why can’t Alexa read the paragraphs to me? I looked around the internet and found a place where I can play Zork online.


Wow! How exciting. Unlike Eliza, Zork has a very limited vocabulary. Looking at the command list I thought I found a way out:


Anyway I was able to wonder around as a ghost. These games where great for the time, a time when 64KB was a huge machine.

Dungeons & Dragons’ Dungeon Master

Eliza is too stupid and classic interactive fiction commands are too primitive. I think the D&D Dungeon Master is a good character for Alixa (or Siri, or Cortana) to play. I’ve listened to Nerd Poker, it is one of many podcasts where people play D&D, they are audio only, so we, as the audience, experience the game without maps.

YOU: Alexa, Dungeon Master
COMPUTER: Welcome to Dungeon Master
YOU: Resume Goldmine
COMPUTER: You are in a timber braced earthen tunnel lit only by the torch you are holding. Up ahead you see a heavy wood door guarded by an orc.
YOU: I take out my sword and approach the door.
COMPUTER: The orc comes toward you displaying his battle axe.
YOU: I attack the orc with my sword

The DM could support higher level commands, In Zork, if I wanted to return to the white house, I would have to the tell the game how to get there (if I can remember). In D&D, I can tell the DM where I want to return to and she would role some dice and tell me if I get back there without any excitement (if she isn’t too uptight); if there is any, she would guide me through any necessary exciting events.

YOU: I would like to return to the Armory
COMPUTER: On the way you meet an orc in the Great Hall.
YOU: I take out my sword.

Future Improvements

Having Alexa’s native voice lead you through a Dungeon would be exciting in the beginning, playing with your ears and all, but after a while, it would get old. What does a future audio games should like? I don’t know, but I would look at other things audio. There is old radio and podcasts, I like the sound of the Black List Table Reads and its Ear Movies could serve a template for the sound design of future audio games.

Cars

With audio games it will be possible to play an audio game while you run down bicycles and mow down pedestrians on your way into the ditch as you conquer dragons and orcs! There is a dark side to new technology!

Sunday, April 19, 2009

On Small, Low Margin Projects

Part 3: Framework and Starter Application

To get off to a quick start, I would imagine finding or building (or a combination of the two) an application framework before I start selling my services to the small business-person. Most small business applications need CRUD and List forms; user accounts and various levels of access; logging;; an about window; error and audit logging; etc.

The platform doesn’t really matter as long it is robust enough to solve the business problem. You need something that is robust enough to solve the current business problem and accept the changes that will take place (sooner: you misread a requirement, later: new work and more revenue). The toolset should support modern scalable designs; the software may be the seed of an enterprise system.

I know that this is like having a hammer and making everything into a nail. At this kind of margin, you can’t afford to handle any technology that the customer may want to use. If it isn’t a nail and can’t be made into a nail, have someone else do it; margins are too tight to take anything.

The first few projects will probably be losers as you work out the kinks in the framework and your process.

With a starting point, we can get our customer something to show them after the first sprint. We can show the customer something quickly and have something to talk about when we plan the second sprint. If we come back to them quickly with something to show, they will feel involved in the process.

Monday, April 13, 2009

On Small, Low Margin Projects

Part 2: Short Interactions and Feedback

In a previous post, I wrote about some of the issues I have experienced with small projects and suggested that Waterfall, Cave of Solitude solutions tend to blow up in your face.

If we come back to the customer every 2 to 4 weeks, we can both learn about the other side of the transaction:


  • I can teach the customer how the process works, what is possible, what is easy and isn’t going to happen. If you are going to buy custom software you need to learn the process. It is like buying a new building; you aren’t going to use the gold plated faucets in the penthouse when we are still pouring concrete (I will restrain myself from going on for hundreds of words of half baked analogies).

  • The customer can teach me more about his business, what he expected the software to do and I missed on the first time around. What is important? What is a nice to have? I may have the opportunity to see the processes that are too complex to explain.

  • Customers like to feel that they are part of the process. If you are going to spend a few grand on something, you want a sense of what is going on. Buying custom software is a big part of the company’s activities and the owner may want to boast about it on his blog on in the local watering hole.

If we started at ground zero and only used Scrum like sprints but no initial framework, the first couple of sprints would give the customer little sense of satisfaction.

Sunday, April 12, 2009

On Small, Low Margin Projects

Part 1: The Problem

I have been involved in some small (low margin) projects for small business customers using a classic Waterfall type process where we get all of requirements from the customer and go into our digital cave for a few months to write our masterpiece. When we came back to the customer (usually late) to show them their shinny new program, we find that we got it wrong. On one program, we get calls from the customer as he discovers features.

The customer can’t tell us what they want in language we understand; they may know what they want, but not in our language. The customer may not have any experience buying custom software. We don’t know the business and its problems well enough. I think the effects of these problems can be mitigated by delivering more often (a la Agile).

If we were to go more agile, we would need a way to get something to the customer quickly. I don’t think a customer in this market would be impressed if, after the first sprint, I showed him a base list window, a base edit window and basic security. We need a base framework and possibly some modules that exist before the first sprint for the customer.