April 25th, 2014
I just returned from a trip to New York City; here’s what I learned:
New York City puts see-saws in the streets:
The dogs in New York City have had all the dog-ness civilized out of them. When out on walks, the dogs obediently scurry along beside their owners, looking neither left nor right, neither sniffing, barking, nor wagging their tails. They hurry along as impassively as any other New York pedestrian. At the small dog park, they play half-heartedly; getting too wild or rambunctious would be unseemly. Two women bring a black lab to the dog park and toss a ball for him. He bounds after it joyously, seizes it, and prances back to his owner and proudly places it at her feet, then looks expectantly up at her, tail wagging furiously. She is deep in conversation with her friend and doesn’t notice. He picks the ball up and drops it at her feet again; she ignores him. He continues this pathetic process a dozen more times. Eventually she tosses the ball for him, and his grateful, joyful response is a thing to see. But again she ignores him. Why do people own dogs if they don’t want to play with them?
I am there to attend a contest. I was selected as a finalist for proposing a prototype for an educational game about a moon shot. Here’s a description of the contest:
http://www.gamesforchange.org/2014/02/game-design-contest-schusterman-space-il/
I lost, and there’s an important lesson in that loss. I should have seen the problem at the outset; it’s plain to see in the linked web page above. Read it carefully; can you find the fatal flaw? It’s in this sentence:
“The challenge invites game designers to envision an interactive experience that encourages space exploration and at the same time captures comprehensive real-world data that will inform the mission of SpaceIL.”
The first hint is in the verb ‘envison’; the contest is to envision something, not actually produce something. Now, I can envision a lot of things that I can’t realize. I’ve been envisioning interactive storytelling for more than 20 years, but I haven’t been successful in translating my vision into reality. This may seem a trivial distinction, but it turned out to be crucial.
However, in the document specifying the contest rules, which you can see here (http://www.gamesforchange.org/g4cwp/wp-content/uploads/2014/02/FINAL_Space-IL_Guidelines.pdf), they say that they want a prototype. So which is it that they want: an envisioning or a prototype? What this demonstrates is muddled thinking that should be a red flag to any experienced software developer. I should have seen it; I didn’t.
Further down in the document, we find more detail:
“SpaceIL is seeking to create a crowd-sourced simulation generator that invites players to land a spacecraft on the Moon, producing comprehensive data that will enable them to optimize the real-world spacecraft design.
The game would allow players to have a first-person experience in navigating an unmanned spacecraft. Through customizing their spacecraft and navigating to the Moon, they will actually help SpaceIL optimize their real spacecraft and mission design. SpaceIL will gather data about the different orbits, paths, and maneuvers players choose and see how much fuel was burned to find more fuel-efficient orbits and optimize their trajectory design software—saving both fuel and money in the process.”
So they want a simulator about navigating a spacecraft to the moon. But there’s another important factor that they mention several times: they want “crowd-sourced” data that will help them optimize the actual design. Somehow, the game is supposed to meet two contradictory goals: it must be be educational, teaching young people about space travel, and it is also expected to produce design and/or navigational data for the actual mission.
At this point, you should be shaking your head in dismay at the idiocy of these contradictory requirements. This is where I failed; in my submission, I tried to explain that this is a stupid idea:
“A million students with a million computers could not in a million years produce results better than results calculated using the laws of physics. People have been guiding rockets through space for more than 60 years; this is well-understood engineering."
I was dumb enough to think that they would believe my explanation. I should have noticed that they declared this concept three times; it was fundamental to their thinking. A rational explanation of their error was not going to change their minds.
All three of the judges challenged me on this point: I was rejecting one of the fundamental design parameters of the contest.
The clients could not decide whether they wanted an educational game or an engineering simulation. An educational game must simplify, eliminating the engineering complexities to make the underlying principles shine through clearly. An engineering simulation, but contrast, must include every last detail to be of any use. If the engineering simulation fails to take into consideration such details as the variations in thrust due to temperature, or how the engine’s thrust varies with the acceleration of the vehicle, the results of the simulation will be useless.
But there’s an even more fundamental problem with the concept. They propose to get a million different inputs from a million different players. They’re thinking that a million monkeys with a million keyboards might somehow produce Hamlet. But you don’t need a million players to get random inputs: a computer can generate a billion random inputs in a few seconds; if you want to explore the search space thoroughly, you just put the simulation inside a loop with a random input generator, and in a few seconds you can find the optimal set of inputs.
Thus, the specification for the software was based on a gross failure to understand some basic concepts of software design. Sadly, the judges were just as ignorant of software development fundamentals as the client; they hewed to the flawed specifications and rejected my proposal.
The lesson here is that successful software projects require competence from BOTH the vendor AND the client. An incompetent client will ruin the project by making unrealistic demands on the vendor. Usually a wise vendor can manage the client’s expectations and keep the project on the right track. The two minutes I was given to explain the problem was insufficient to overcome the ignorance of the judges.
There really is something like karma at work in the universe; the same incompetence that animated the client and the judges assured the failure of the project. They selected a vendor who promised vastly more than they could possibly deliver. For $25,000, the vendor promised a “space training academy” in which players would learn all about space travel; a whole series of missions in which players would seek ore samples from a wide variety of moons scattered around the solar system (their explanation of this was a little fuzzy; perhaps I misunderstood them); a collection of puzzles; a social networky something-or-other; tons of useful data for the client’s engineering team; and a landing on the moon that was precisely configured to match the exact characteristics of the client’s vehicle. The only software they actually demonstrated was an image of an alien space fighter jiggling around over a background of the lunar surface, occasionally emitting a purple splash of fire.
In other words, the judges fell for a splashy sales job with no substance.
I’m sure that you’re thinking “sour grapes” or “sore loser” and I must admit that my objectivity here is seriously compromised. Fortunately, there is a hard, objective test of my analysis. The client also specified that the end result should be operational on its website (http://www.spaceil.com) within one year. So, all we have to do is watch that website. If, within one year, there really is a game with all those wonderful features, then the lesson is that Chris Crawford is a sore loser and an ugly person. If, as I expect, there’s nothing at all about any educational game, then there will be an important lesson for everybody about the dangers of software development. I wasted a month of my life, and several hundred dollars, because I was too stupid to see what should have been obvious. Don’t make the same mistake.
By the way, if you’d like to see the rought prototype I prepared (remember, this contest was for a proposal for a prototype, not the prototype itself, you can play with it here:
http://www.erasmatazz.com/library/software/rocket-science.html
Be warned: this is very preliminary, and might not work on Internet Explorer. Also, the numbers have been rigged so that, whatever your inputs, you always win. It’s a demo of a pre-prototype.
Postscript, April 13th, 2015
One year has passed, and it is now obvious that my predictions were right on the mark. There hasn’t been anything done on the developer’s website since May of last year; the client’s website (SpaceIL.com) doesn’t have anything like the game proposed. In other words, the whole thing was a disaster. I hope the judges are willing to accept some responsibility for their screwup.
