Prerelease:The Sims (Windows)/1995-1996

This is a sub-page of Prerelease:The Sims (Windows).

Dollhouse Demo at Stanford

"Imagine zooming into SimCity 2000, all the way down to the street level, and seeing little people walking around, waving at each other, asking for spare change, jumping up and down, gesturing, interacting with each other, living and playing in rooms with furniture and active objects, and you're one of them! Will showed me Dollhouse several years ago, and it was amazing then, and even more so now. It's not a product yet, but he's been working on solving some very hard problems. He's trying to give the people who walk around the world seemingly rational behavior."

- Don Hopkins, The Sims Engineer (1996)

In April 1996, Will Wright gave an insightful talk on Interfacing to Microworlds for a User Interface class held by professor of computer science Terry Winograd at Stanford. The original direction of the talk was the building of a reflection, along the audience of students/enthusiasts, about the strengths and weaknesses in the sense of the user-friendliness, replay factor and creative boundaries in previous efforts by his team at Maxis — most precisely SimCity 2000, SimAnt and SimEarth. Towards the end of the talk, an open Q&A session was done with many interesting questions by the people there at the class.

The one who caught Wright by (a good) surprise, however, was the one guest that raised their hand and, out of civil curiosity, inquired the Maxis co-founder about the projects that he was working on at that moment.

The mood of the seminar was increased from the moment that, influenced by that question, Wright commands his Macintosh to run what appears to be a slightly modified copy of SimCity 2000, this time allowing the player to see what was happening inside the buildings' walls and who lived in there...

Described as "a CAD program that a 10 year old could use", Wright goes ahead and tours a working, but extremely early draft of The Sims (yet, still titled as Dollhouse) to a public that very well knew when to stare out of fascination, and laugh at the first vision of a Wright-like rag doll perpetually sitting on a toilet.

• 

  At first, it all seems to be an ordinary SimCity campaign...

• 

  ...except Wright manages to zoom the world in a little more, now close enough for the perimeter of a lot to fill up the whole scene...

• 

  ...and it's editable, too! Here's a demonstration of the Wall Tool, that functions in a not that different way from how streets are drawn with the mouse by SimCity players.

• 

  The Window Tool.

• 

  The Wallpaper Tool.

• 

  A humble sorting of goods to buy, in comparison to the final catalogue, that surpasses the hundreds of items.

• 

  If Project X's biggest challenge was to have its perception expanded to something more complex than being summarized as a "game you have to use the toilet", that is precisely what invoked the smiles among the spectators that day, at Stanford.

• 

  Some other friends appear, attending their inner impulses by autonomously doing whatever the objects in the world lured them to...

Noteworthy Details

• This far ahead in development, Wright already envisions Dollhouse as a "hobby" more than uses "game" to describe his new project, and that's because he was already looking for ways of combining the characteristic open-endedness from his previous works with the possibility of making it viable for players to expand indefinitely and exchange their own resources and stories with other people online — and it's absolutely no coincidence that, in the following years, it would be precisely the strong potential of storytelling and the building of communities of players that made executives at Electronic Arts as Luc Barthelet to think highly of The Sims more than many of those at Maxis.

(Source: Stanford University, Computer Science Department, HCI Group, CS547 seminar videorecordings, 1990-2012 — Creative Commons Attribution license (reuse allowed))

Jamie Doornbos on Dollhouse

"I first saw what would later become the Sims as a prototype Will Wright was working on. This was in the summer of 1995, when we were pitching Will on our new game and company. He heard us out, gave us great advice, and then showed us his cool prototype (very much like Will overall). He had a little man (graphically made out of animated, unconnected rods) walking around a gridded floor space. Will wanted to show us something he'd just completed: he dropped a toilet onto the grid, and the man went over to it, sat down on it, and then after a moment got up (complete with flushing sound if memory serves me correctly). Very funny, and it gave a glimmer of what the Sims would become. The ability to have the animations needed to use an object bound to the object rather than in the Sim was in fact an important internal feature of the game."

- Mike Sellers, The Sims 2 Lead Designer

As a secret side-project, The Sims productive momentum gradually increased when Wright tapped an ambitious Jamie Doornbos — a God-game enthusiast who had just graduated from Stanford — , to ensure his vision would be manifested with the highest precision; in fact, Doornbos wrote the first known code for the game, as his fellow Maxoid Jacquin Servin was committed to the original character animation engine until... you know, something hit the propeller.

It was starting to look like something, after all! Its was first targeted for the Macintosh, and provided a very small, but fundamental basis for SimAntics, the visual programming language that orchestrates the Sims' behaviors with ObjMaker (Edith's precursor) as its editor. While rudimentary, it had some use during the engineering of the intelligence from the own Sims of SimCopter, being one (but definitely not the only!) times when the stars from a work make an early debut.

Below is the comprehensive print of Doornbos' lost documentation on Project X, published at his old blog nearly one month after the first public launch of the game.

Image	Doornbos' Commentary
	Originally, before even project x was around, there was GORF, written by Will Wright from the code base of simcity 2000. You could select a tile in the city, and then "load" the tile, which would start a new house and populate the lot with the road tiles and trees to roughly match the SimCity tile. Unfortunately, I did not find a build of this, but I did find the source code. [...] From GORF, I did an initial port and polish into to my own application framework, based on Apple's "Sprocket" library. This is the earliest version of The Sims code base as we know it. There was no simulation, only architecture. The concept of an "object definition" had not quite evolved. "Behavior trees" were only an idea.
	Part of the port was getting the terrain to look right using the same basic fast-rendering "swatch" tile algorithm that GORF had, but allowing for a lighting model and not crashing. The lighting computation uses a lookup table that is saved as data by an external tool, written by me, called "Swatch". The tool also served as a test bed for new terrain rendering code.
	Also at this time, the future of project x was murky (it usually was, up until the last year). It was being considered whether to continue to develop project x as a "zoomed in" SimCity sequel, or to split it off into its own franchise. I advised Will that I did not want to work on a sequel, and eventually, as you know, the latter was chosen. Another really cool thing that Will came up with on the sequel front was genetic buildings. Basically, a building has different traits such as size, shape, number of towers, symmetry, windows, etc. Genetic techniques are used to evolve the traits based on the user's preferences (a really good looking demo written by Will in my framework).
	Soon after project x began, most effort was being put into "Doll Maker" by myself and Jacques Servin. Will was the original creator of the technology, where small component sprites were assembled by flipping and offsetting to create an animated person. I took on the project of taking his code, most of which was done using hard-wired offsets, and making it into a general system that could be used to produce different sizes and shapes of people. There were two basic components to this: bodies and animations. Bodies had bones and joints. The bones had names so that an animation could be applied to different bodies, as long as enough of the bone names matched. Animations recorded angles of bones relative to their parents. The code was architected such that different rendering styles could be applied to the bodies and animations. In project x, the people were rendered in the Doll style, the aforementioned creation of Will. The technology was later used in SimCopter with "primitive" rendering, where each bone was designated as either a line or circle with various parameters.
	[The previous snapshot's] window select[s] an animation and body. This window edits an animation.
	After Doll Maker was taken over by Jacques, Will and I were talking about the idea of a simple scripting language that would allow a simulated person to be guided in a top-down fashion. Each instruction in the language would correspond to one of the tasks a person could do, such as "Wake up" or "Eat breakfast". The full sequence might be embedded in another script, like "Morning". Each instruction could complete with a true or false return value, indicating whether the task finished successfully. Intrinsic in the concept was a graphical representation, where the instructions would be edited by drag and drop. The first prototype of the editor for the language was very simple. It used the Mac resource manager to store the scripts as BHAV resources in a file. One window showed a list of scripts in the file and another allowed editing the scripts. In the script editing window, the transitions (arrows, or in this picture, fuzzy lines) for a node are only shown if the node is selected, and return values are indicated by an arrow up to the T and F boxes at the top of the window. Of course, the scripts are nonfunctional since the interpreter did not yet exist. Eventually, after finishing DollMaker, Jacques took over the editor, and the scripts became known as "trees".
	After this prototype, I began work on the game's full editing pipeline, embodied by a tool called ObjMaker, later known as ObjEdit, TDSEdit, and finally Edith. The tool was to have all the functionality necessary to create an object with sounds, graphics, animations, and behavior scripts. Doll Maker and the script editor were embedded in the app. One of the very first prototype editing windows was the "Object editor". This window has no living descendants, essentially because it oversimplifies the problem of representing an object in data.
	In designing the graphics pipeline, I took all the code I wrote for the Widgets Workshop graphics pipeline (which was evolved from that of SimCity2000, written by Mick Foley), and generalized it to do things for project x, such as gray scale sprites that could be shaded at draw time for the people and pattern sprites so that small wallpaper patterns could be applied to a single set of wall graphics. Another major thing about the graphics was the concept of a "draw group" (this one is still in The Sims today). A draw group is basically a list of graphics that make up an object. By splitting up these graphics, there is often a tremendous RAM savings, ultimately allowing for more objects. For example, a tub that is filling needs only one large sprite for the tub and several small sprites to animate the pouring water. The window for editing the draw groups was later referred to as the 747 window because of the incredible number of controls, buttons, and editing fields. On my Mac, I could not even see the bottom half of it because I'm limited to 640x480. It took two screen shots to get the horizontal extent of the 747. The window allowed the individual sprites of an object to be added and removed from the draw group and positioned for each of an object's 12 views. The window was eventually replaced by a command line tool known as TDSB which builds the draw groups based on a simple text file and a bitmap spit out by the Sims sprite exporter for 3D Studio MAX, which was written later by Eric Bowman of the CTG group.
	The compressor for the sprites worked off of a data file, a ".comp" file, that specified the source graphics and the target sprites. The tool allowed viewing the pictures and setting up the sprite lists to be saved out as SPR# resources, a format still used in The Sims today. This compression step is now also embedded in TDSB.
	Along with the compressor was a testing app that allowed the clipping rectangle to be moved around so that the complicated decompression code could be tested for overwrite problems. A similar tool exists today called SprPreviewer that does not do the clipping tests.
	By and by, the editing tools reached their pinnacle on the Mac platform. A few months before the windows port, the project was renamed to TDS, and the tool to TDSEdit. At this time, the editor already had most of the basic components that it does today. It begins with an "Object Loader" window.
	From this window, the definition of an object may be brought up. This window has changed a lot but is still fundamental to Sims object development in its current form in Edith.
	Also from the object loader, a behavior browser may be brought up that catalogues the tree scripts in an object. Very similar to the modern version. One difference is that the node at the bottom right of the browser may be dragged into a tree editor window to create a new copy of the node in the tree. This is the origin of the "primitives" category, which is still in the modern version, but not useful since the dragging node is no longer present.
	Form the behavior browser, the tree scripts may be brought up and edited. This is pretty much the final revision of the tree editor on the Macintosh. The modern version is much, much better, after being ported to windows by Don Hopkins of the CTG group and vastly improved by him and myself.
	Another important editor was the tree table editor, which edits all the autonomous and menu driven actions that a person can perform on an object. The modern version is similar with some extras like being able to change the order, and being able to edit all the new interaction attributes, such as personality modifications and joining. This screen shot reveals how early on the simulation was planned to be much more expansive than it is today. The lower list shows all the motives that we initially thought would be needed. Today there are only 8.
	Meanwhile, the game engine was also coming along. All of the basic pieces are in place, but the UI stinks and the graphics are mostly programmer art or taken from SimPark or GORF. Far from playable, the people in this version just stand still (perhaps they would move if I waited longer).
	One thing that hasn't changed much is object errors. In fact, in the version I found on the mac, there is a persistent one in the chairs. Note that this error is in the "Customer" object, a carry over from the brief SimRestaurant exercise.
	When an object error occurs, and you choose to trace, the trace window is brought up. The speed of tracing is vastly improved now, but the old tracer has basically the same features, allowing a tree to be viewed and navigated as it is being executed. The current tracer also allows limited editing of a tree while it is running. One feature that was not brought over to the new tracer is "watch", which allows the tree to be redrawn after every instruction, creating an impressive flashing of tree code redrawing.
	If you're familiar with the current tracer, you'll notice that the "data" and "stack" controls are conspicuously absent. In this version, this info was only available in separate windows, so you would need to have 3 or more of them open to debug a script. This was rather appropriate for the macintosh custom of limiting the information that is shown in a window.

(Source: LUCPIX; Doornbos' Sims History ('95-96), March 1st 2000.)