The power of plaintext in Tim Sweeney's work notes from the 90's
An interesting story with a boring lesson…
In our fast-paced digital world, we often overlook the simplest solutions in favor of more complex ones. This article revisits the enduring value of plain text, a format that has stood the test of time, proving its worth in both historical documentation and everyday note-taking.
In their seminal work, The Pragmatic Programmer, David Thomas and Andrew Hunt dedicate a chapter to the importance of plaintext (Chapter 3, Section 16). They argue for plaintext’s simplicity, adaptability, and longevity:
With plain text you can achieve a self-describing data stream that is independent of the application.
As a personal testament to this philosophy, all my notes and to-do lists are in pure plaintext. This practice not only simplifies my life but also aligns with the KISS principle and the UNIX philosophy of keeping things simple and effective.
Tim Who-ney?
From Wikipedia:
Timothy Dean Sweeney (born 1970) is an American video game programmer and businessman. He is the founder and CEO of Epic Games, and the creator of the Unreal Engine, one of the most-used game development platforms.
Yep, to some he’s the Unreal Engine Guy. To a younger audience, he’s the Fortnite Guy. To an older audience, he’s the Unreal Tournament Guy.
Anyways, so I got his work logs. Keep reading.
Wait… What?
On a particularly boring night during my college years I found an interesting torrent that had… a lot of historical stuff that’s related to Epic Games and Tim Sweeney in particular. To sum up, it had:
- Source code for a pre-release version of Unreal Engine 1
- Source code for a number of alpha versions of Unreal (the 1998 videogame)
- Some docs regarding the above
- Bits of source code and models for what could possibly be Unreal Tournament (originally planned as an expansion pack for Unreal)
- Various programs Epic Games (called Epic Megagames) used for development of the game. Examples include, but not limited to:
- BRIGHT 1.2 “Best palette Reduction for Industrial Grade High quality Textures”. Industrial grade? You don’t say…
- “The Unreal MeshViewer” made by some guy from Legend Entertainment
- The “SoundMk” or “Unreal Sound Maker” program, created for the purpose of aiding the debugging and testing of the sound engine itself.
- Tim Sweeney’s historical logs which is what this post is about.
- Somewhat playable alpha versions of Unreal
That was over 6 years ago and I only kept the log files due to needing lots and lots of storage space on my laptop and not willing to use cloud storage services.
What’s in it?
Sweeney’s logs are a goldmine for understanding the intricacies of game development during the 90s. They reveal the challenges and triumphs encountered in creating groundbreaking technology and art. For instance, an entry from 1996 details the process of optimizing early versions of the Unreal Engine, while another from 1997 captures the excitement and pressure surrounding Epic Games' presentation at E3.
We’ll start of with something that sheds light onto development of the engine, editor and the game:
///////////////////////////////////////////////////////////////////////////////
5-2-96
+ Kill unused cameras after load-for-play
+ UnrealEd: Sort mesh viewer list
+ UnrealEd: Strip quotes from strings, reappend during export
+ UnrealEd: F4 cycle through list of result messages (Next Error)
+ UnrealEd: Class browser, no Close button
+ UnrealEd: String properties are acting up
+ UnrealEd: Map save-as + cancel doesn't work. Other save-as's also? Check it out.
+ Actors have ambient brightness property
+ Set player's starting yaw accoring to PlayerStart
+ Implemented UClass::IsKindOf
+ Test all CPT_String references
X InstantHit projectile class - use a function instead
+ Pyrotechnics class with
+ Explosion, TeleportIn, TeleportOut, WallDamage, MonsterDamage, PickupRespawn, PlayerRespawn, PlayerDie
+ Property arrays
+ ImportActorProperties
+ Don't allow editable arrays except for strings
+ AActor::QueryReferences
+ AddParentProperties
+ ExportActorProperty
+ ExportMultipleActors - skip arrays except for strings
+ Export headers & actors
+ Import
+ Test ugly stuff, including array of names + array of resources
+ Export class, only fwd declare classes that are necessary
///////////////////////////////////////////////////////////////////////////////
1-11-96
Things which Unreal software rendering can do that Quake can't:
1. Software bilinear filtering.
2. Software trilinear filtering.
3. Bump mapping.
4. Translucent and transparent polygons.
5. Dithered lighting.
6. Hicolor and truecolor for greater texture variety.
7. Ambient lighting.
8. Colored lighting.
9. Volumetric lighting and volumetric fog.
Things which Unreal software rendering can do that Rendition can't:
1. Software trilinear filtering.
2. Texture size limited only my RAM.
Things which Unreal software rendering can do that 3dfx can't:
1. Truecolor rendering.
2. Trilinear filtering.
Where Unreal is behind.
1. Quake: Speed.
2. Rendition: Edge antialiasing.
3. 3dfx: Speed.
Here Tim lists a number of things he has done on the specific day indicated above. Pretty minimalistic!
Some days are less eventful, but not necessarily less impactful:
///////////////////////////////////////////////////////////////////////////////
5-6-96
+ Volumetric lighting works. Very cool.
Back in ‘96 Epic Megagames didn’t have Github, they had to physically drive to Waterloo, Ontario to sync their work with Digital Extremes:
///////////////////////////////////////////////////////////////////////////////
5-12-96
+ Merged sound code
+ Answered 150 waiting emails. Email still sucks.
On 5-19-96 he went through E3 hangover:
///////////////////////////////////////////////////////////////////////////////
5-15-96 through 5-18-96
+ At E3
+ Demos went ok but certainly not great
+ We have a hell of a lot of work to do before Unreal is truly impressive
///////////////////////////////////////////////////////////////////////////////
5-19-96
+ E3 recovery
Microsoft was busy fighting in the “browser wars” and had to rush out a Visual C++ release.
///////////////////////////////////////////////////////////////////////////////
5-26-96
+ Catchup
+ Visual C++ 4.1 = unstable slow ass compiler from hell, reverted back to 4.0
UnrealScript is born!
///////////////////////////////////////////////////////////////////////////////
5-29-96
+ FScopeLink
X Action/EndAction, Repeat <n> -> Messy implementation
X Generic add-parent-properties that takes an iTree as input -> Overly complex
+ Scripting infrastructure (pre code gen)
+ Maintain FStackTree entry 0 (global)
+ PushNest, PopNest be cognizant of FStackTree
+ Parse all stack tree types correctly
+ If-ElseIf-Else-EndIf
+ While/Do-Loop/Until
+ Select/EndSelect
+ Case/Default
+ For/Next
+ Handle local variable dims
+ Resolve length-aware string parameter passing
+ Script disassembler called at end-of-compile:
+ Display stack tree dump
+ Display global variable dims (implemented in FClassProperty, not UClass)
+ Display local variable dims
+ Display var intialization values when nondefault
Early rendering optimisation work:
///////////////////////////////////////////////////////////////////////////////
5-31-96
+ Timings:
+ * Can write 4 cached megs at full speed = 1/2 cycle per dword write
+ * Can write 4 uncached megs in 50 msec = 8 cyc/dword written
+ * Can insert 7 cycles of cached instructions in the loop for free
+ * Time rises to 90 msec if you add one uncached read in the middle (write buffer
+ and read buffers colliding).
+ * Can read 4 uncached megs in 112 msec = 18 cyc/dword read
+ * 8 c/p = 17 msec/frame at 166 mhz
+ * Traversing the entire actor list 100 times takes 40 msec, and half of the time
+ is due to the lack of caching.
+ Conclusions:
+ * Drawing 4x4 blocks across the screen, then copying to vid memory will just cost
+ an additional f-ing 8 cycles per pixel.
+ * There's no point to having a texture mapper that writes faster than one DWORD
+ or one QWORD per 8 cycles.
+ * Don't write a lot of data - better to compute stuff on the fly.
+ Reduced frame setup work by using a better point/vector caching system (no huge memclears)
You and me both!:
///////////////////////////////////////////////////////////////////////////////
6-4-96
+ Conference calls all day long. This is pissing me off beyond belief.
///////////////////////////////////////////////////////////////////////////////
7-20-96
+ Slept
///////////////////////////////////////////////////////////////////////////////
8-16-96
+ Returned to USA
+ Travelling sucks
///////////////////////////////////////////////////////////////////
Lost a ton of log entries because fucking Microsoft
Windows NT 4.0 the supposedly reliable enterprise server operating
system crashed yet again and trashed my doc files. Anyway I've been
working on the new software rendering code and the file format.
///////////////////////////////////////////////////////////////////////////////
2-15-97
+ D3D continued.
+ Build execute buffer.
+ D3D execute buffer helpers.
+ Direct3D immediate mode SUCKS CRAP!
+ Fill background.
+ I can't believe that Microsoft would create such a shitty library.
E3 1997:
+ E3
+ We kicked ass
+ Our major competition is Quake 2
+ The other 3d first-person games are pretty weak
My notes… in plaintext?
This exploration into the world of plaintext demonstrates its enduring relevance and utility. As we navigate an increasingly complex digital landscape, sometimes the simplest tools offer the most effective solutions. I encourage readers to experiment with plaintext for their note-taking or project management needs. Its simplicity might just surprise you with its power.
Yes! You don’t need an iPad with a pen to write down your diary entries, plans or to-do lists. We often don’t realize the simplicity and power of plain text for such simple things as notes or diaries. People go out of their way to have their own automated Trello boards (or Notion or whatever else, you name it) set up for their personal things, yet we fail to realize the simplest way to memorize things is just to write them down on a piece of paper… or a text file that’s just sitting there on your desktop. Is this approach superior? At least by the KISS principle and/or UNIX philosophy it is.