The truth is, of course, that designers have access to the same power that programmers have: C++ and assembly language. We don't lock those tools away from the designers; they're welcome to use them. (As long as their code passes code review -- and sometimes it does ;)
FranTk, in contrast, removes power:
- I gave FranTk an expression language (GenEx) that has no "flow control statements", for example, no for, for-each or while loops, and no switch statements.
- That expression language also lacks any obvious way to create new types.*
- And you sure as heck cannot store values into a register.
So why on earth would a designer see this system, with all its omissions, and sing its praises, for the "power" it gives them?
Because they don't want more power and flexibility; they want more control and guidance.
A pilot would rather fly a plane than a rocket. Rockets have more power but less control. They might get you to your destination faster but the landing would suck.
And as a driver, I prefer roads with curbs and lanes to unregulated salt flats.
Likewise, C++ and assembly give you all the power and flexibility to squirt electrons all over the hardware, but those low-level languages lack commensurate facilities for control. In the hands of an expert, who has their own toolbox of controls, that power seems fine -- and in control -- but the control comes from the experience and training of the programmer, not from the language.
Designers choose to be experts at something else -- not at programming (not the same kind of programming anyway) -- but sometimes needing a programmer to translate their ideas just gets in the way.
Pictures with some words
Powerful and flexible systems are easy to make:
- Provide a few primitive types (bool, int, float, string).
- Facilitate defining aggregate types composed of primitives.
- Facilitate defining procedures (statements and expressions).
- Facilitate creating entities of any type.
- Facilitate invoking procedures on those entities.
You have to provide these fundamental facilities but you should not stop here. A harder problem is how to grant controlled power -- robustness -- to non-programmers. Analogous to how a word processor provides spell-checking and grammar-checking, make authoring tools that eliminate the possibility of syntax errors, and reduce the lifetime of semantic errors.
How do you eliminate syntax errors? One way is to eliminate syntax: program with pictures, instead of with words.
There have been other so-called visual programming laguages: Pure Data, LabView, Kismet and more. The idea is to draw a flow diagram, and convert that into something that runs. We took the idea a few steps further.
Larry Wall is famous for saying "there's more than one way to do it" (TIMTOWTDI, pronounced "Tim Toady" -- I'm not joking). Larry and his Perl minions are proud of this phrase. But it leads to a mess.
Different programmers have different ideas for solving the same problem. In a polite society, that's fine. But software development is anarchy. So FranTk strongly suggests that there are right and wrong ways to solve each problem. By strategically omitting features, we steer designers to solving each problem in a specific way.
Remember that the FranTk expression language (GenEx) lacks control flow. What if you want to make a choice among outcomes based on some information (if-then)? How do you iterate through a bunch of data (loop)?
We separate control flow (FranTk calls it "logic flow") and data flow. Logic flow is meant for branchy logic and data flow is meant for processing bulk data. A logic flow is a finite state automata (but that jargon repels designers so hush).
(Yes, the logic flow can have cycles. But the GUI always focuses on a single state. To the left of the state are the states that can transition to the one in focus one. To the right are states that the current one can transition to.)
A data flow is a pipeline for data, with sources, sinks and filters.
(A fringe benefit of ridigly structuring data flow is that FranTk can parallelize execution across an arbitrary number of threads. Designers need not know or care.)
We provide separate GUIs to create each of these separately. To reinforce their separateness, we depict their flow in orthogonal directions: Data flows top-down and logic flows left-to-right.
These logic and data flows can interact, so a data flow can use a logic flow and vice versa. Furthermore, they can use each other, so a logic flow can contain (and invoke) another logic flow -- even itself. So, if you really want to write a recursive state machine, you can. But I wouldn't mention that to a designer because they're just not in the market for push-down automata.
How about authoring expressions? Those are made of words, not pictures. We provide a GUI to author those too -- like an in-your-face version of IntelliSense. If the author really wants to type in their own expression, they can -- and the authoring tool runs the compiler on every keystroke. So the designer knows exactly what's wrong, instantly and continuously. The expression editor shows whether the expression has an error, where (precisely) the error lies, and usually provides a clue about how to fix it.
*How about creating new types? There's a GUI authoring tool for that also. And it performs plenty of type restriction, value restriction and dependency checking.
Curbs, not speed bumps.
Putting up all these protections can get in the way.
Eliminating errors and confusion is hard, but an even harder problem is how to make using this intentionally limited system more efficient than solving the same problem in Lua, Python, C#, C++, Java, Lisp or any other existing language. What if you just want a quick-and-dirty for-loop? Do you really have to make a dataflow for every little array you want to scan?
It's all about the GUI. We iterate on the authoring tools to make every branch in the workflow as smooth and fast as possible. In other words, we compensate for the abundance of structure by providing navigation tools that take you where you want to go.
Often, we run across cases where it would be simpler just to add a little for-loop here or a specialty widget there, to help with some particular niggly problem. This is where other projects fall apart, and where we want to keep FranTk pristine. We could add some new whiz-bang feature that makes whatever corner-case problem-at-hand go away. But we perpetually resist the temptation to simplify the implementation by complicating the system. (In contrast, see C++ or UnrealScript.)
It's a lot of hard work -- but it's hard for the programmers, not for the designers. And that's the way it should be.
FranTk is an experiment in increasing control and robustness by decreasing power and flexibility.
We'll see how it turns out. If I stop writing about it, that either means it failed miserably or succeeded so wildly that EA forced me to stop writing about it. Wish us luck.
Update: Connected Career Mode
I wrote this article in May of 2011 about a system we started in spring of 2010. Now it's summer of 2012 and results will come soon: This system is the engine behind Connected Career Mode (CCM) in Madden 2013. It's one of two core focus features for this product year. Madden won several awards at E3 including best of show, best sports game and best of E3. The press gush over it. In a few months, we'll find out what the fans think of it. But I also think the real potential for this system will manifest only after it's been in the wild for multiple cycles. The point, after all, is to facilitate giving designers more control and that will come in handy as their side of a sort of conversation with the users.
Meanwhile, you can tell from Josh's blog post that the designers are ecstatic about this system. And you can tell its scope is huge. The number of user-facing features is staggering, and most of these were developed during the past 12 months by a small army of programmers and designers, across multiple studios in multiple states and countries. FranTk facilitated that by virtue of focus on control, not power. FranTk replaces a system that arguably gave more power but less control and as a result that obsolete system did not allow for coordination among multiple designers. The old system, for example, relied on editing a live database. Using SQL queries gave the designers monumental power, but it was responsible for monumental numbers of errors. For example, in Madden 2011, 11% of all bugs were from career modes like Franchise and Superstar. But Madden 11 added zero new features to its career modes. Most of those bugs came from data errors due to the excess of power and the lack of controls on that power.
In sharp contrast, FranTk provides such coordination that we were able to employ an unprecedented number of authors simultaneously working on career mode logic and data. The result looks promising. Fingers crossed for release day.
Update: Release Day
It's been less than 24 hours after launch. Madden 13 already has the highest metacritic score of any release of Madden for this console generation. The most-cited reasons were character physics and Connected Careers.
(I worked on both. Toot toot!)
Quote from the press:
- "The next feature, Connected Career mode, is quite possibly the greatest addition to a sports game in history." -- Planet Xbox 360.
Update: Sharkies
On December 16 2012, FranTk won the EA Innovator award. Other EA Sports titles, including those at other studios, are adopting it.
Update: FranTk made public; new name: Connected Franchise
On May 30 2013, EA made FranTk public knowledge and discussed it in this developer blog where they announce renaming Connected Careers to Connected Franchise.
Update: FranTk covered by GoMadden.com
On May 31 2013, Madden fan website GoMadden.com covered FranTk.
No comments:
Post a Comment