A BRIEF HISTORY OF HUGO - RELEASE NOTES --------------------------------------- by Kent Tessman (See the file changelog.txt for specific changes post-v2.5.01.) ----------------------------------------------------------------------------- v3.1 - 7-Aug-04 Version released in preparation for commercial release of Future Boy!, which included v3.1.01 on the CD-ROM. ----------------------------------------------------------------------------- v3.0.04 - March 2002 The next major step in the move away from v2.5. Most ports (including compiler and engine) are now v3.0, even if they don't provide the full set of v3.0 capabilities (including menus, video, etc.). Some ports are still compiled for v2.5, but are still able to run v3.0 games if compiled with the latest sources. (And, of course, v3.0 engines can run games compiled with a v2.5 compiler.) ----------------------------------------------------------------------------- v3.0 - July 2000 The final integration of the v3.0 and v2.5.x codebases is complete, and v3.0 finally gets released after its (lengthy) beta period. Version 3.0 packages are available for Win32 and BeOS x86/PowerPC. I will continue to release v2.5 packages for Win32 for the immediate future, even though they're essentially redundant (as v3.0 and v2.5 are intercompatible). ----------------------------------------------------------------------------- v3.0 beta - April 2000 Further developments to the v3.0 architecture, including: Video playback now takes optional volume and background arguments. Volume behaves the same as for 'sound' and 'music' statements. The background argument, if non-false, plays back independently of the normal engine loop so that game play, player input, etc. continue. video [repeat], "resourcefile", "resource"[, , ] New mouse functionality has been added (to v2.5, as well), so that a mouse- click now passes keycode=1 to hugo_keywaiting(); also sets display.cursor_column and display.cursor_row to the origin of the mouse- click (in screen coordinates, measured in the fixed-width font). (Various improvements have been made to the shared v2.5.02/v3.0 code as well, for the compiler, engine, and debugger. These are listed in detail in changelog.txt.) ----------------------------------------------------------------------------- v3.0 beta - April 1999 Lights, camera, v3.0 beta--now with support for new media types: MIDI, MP3, MPEG, and AVI. The new command for playing back a video resource is: video [repeat] "", "" The video image is displayed in the current window (as a still image is); regular Hugo Engine execution is suspended until video playback either finished or is interrupted. Also, support for contextual command menus via the 'addcontext' command, allowing, for example (under Win32), mouse-driven menus of relevant commands to be dynamically generated by the game at runtime. More details, including improved Latin-1 character set handling (actually for v2.5.01) and full v2.5.x-v3.0 intercompatibility. See the v3.0 addendum to the Hugo Manual for the full story. ----------------------------------------------------------------------------- v2.5 - August 1998 Sound, finally, in the forms of mod music (MOD, S3M, and XM formats) and WAV samples. To play a song or a sample: music [repeat] "", ""[, ] sample [repeat] "", ""[, ] And to stop them: music 0 sample 0 The 'repeat' token indicates that a module/sample should be played repeatedly until it is either stopped or replaced by playing another. If is given, it must range from 0 to 100, and will remain in effect until a new volume is given. New compiler switches and defaults, as well. The '-t' switch will list all printed game text to the screen or .LST file (if '-l' was also specified). Expanded-format error/warning messages and verbose compilation (updating the number of files/lines compiled) must now be explicitly with the '-e' and '-v' switches, respectively. Plus there are handy new warnings, such as one that warns you if a noun or adjective contains an uppercase character. Internal enhancements include a major optimization of the engine's call/ conditional stack management, resulting in substantial speed and efficiency gains. I've also revisited the printing mechanism in order to make the coordination of windowing, proportional printing, and font styles much easier for porters. A new display object property, title_caption, allows a program to optionally set the title of the screen/window (if the system allows it) via: display.title_caption = "Colossal Cave" The new library constants DEF_SL_FOREGROUND and DEF_SL_BACKGROUND (integer values 18 and 19) can be used in a 'color' statement to refer to the default statusline colors for the current port. I've also split hugolib.h, the Hugo Library, into hugolib.h and verblib.h, where the former contains the core game-world management and the latter is made up solely of verb routines. For consistency, grammar.g has been renamed verblib.g. (In conjunction with the library split, a VMessage routine is now called by verbs; Message is still the name of the message routine called by the core library.) The 'system' token has been revived, and can be used as a built-in function as: system(11) READ_KEY - return a key value if a keypress is waiting, or else 0 system(21) NORMALIZE_RANDOM - once called, random numbers will follow a reproducible pattern system(22) INIT_RANDOM - restores "random" random numbers system(31) PAUSE_SECOND - pauses the engine for 1 second system(32) PAUSE_100TH_SECOND - pauses the engine for 1/100th of a second Constant definitions (i.e., READ_KEY for 11) are contained in "system.h". A new engine global called 'system_status' may be checked after a resource operation or 'system' call. If zero, status is normal. If non-zero, it will contain one of the following values: -1 STAT_UNAVAILABLE 101 STAT_NOFILE 102 STAT_NORESOURCE 103 STAT_LOADERROR (STAT_UNAVAILABLE is the only potential response for a system() call.) Constant definitions are again in "system.h". A new parsing feature is an extension to ParseError where if a user ParseError routine returns 2 (instead of simply true or false), the entire grammar-matching mechanism is re-triggered. This is useful for cases where a peculiar syntax is trapped as an error, reconfigured by ParseError, and should then be re-parsed. Also a 'punctuation' extension has been added that works similarly to a removal, but instead of a whole word only removes a particular character from the input string so that a user can custom-define punctuation, as in: punctuation "%$" which will remove any '%' or '$' character from typed input. ----------------------------------------------------------------------------- v2.4 - August 1997 Version 2.3f became v2.4 when I realized that, gradually, v2.3 had advanced an appreciable bit with v2.3a-v2.3e--enough, at least, to warrant a new revision number. (Another reason is that adding the new graphics and windowing capability and object-orienting the display required a version change in order to ensure backward compatibility.) At the same time, a version jump enabled me to incorporate some other advances and features that had been put off for v2.3x releases because of the compatibility issue. The most noteworthy feature is that graphics-capable ports may now load pictures (in JPEG format) into the currently defined window using: picture "", "" Resourcefiles are created by the compiler via: resource "" { "" "" ... } A new 'display' object is created automatically by the compiler (if not otherwise provided). The display object has the following default read-only properties: display.screenwidth display.screenheight display.linelength replaces v2.3 linelength global display.windowlines replaces v2.3 pagelength global display.cursor_column display.cursor_row display.hasgraphics The 'window' statement has been enhanced as follows: window 0 restores full-screen output; there is no following {...} code block window n creates a window of n lines beginning {...} at the top of the screen window x1, y1, x2, y2 creates a window with the top-left corner {...} (x1, y1) and bottom-right (x2, y2) window with no parameters, redraws the last- {...} draw window Upon termination of the {...} code block, the main text window is re- defined as ending immediately below the last-drawn window. Enhanced conditional-compilation constructs '#if', '#elseif' and '#else' in addition to '#ifset' and '#ifclear' make complex source code easier to read. New compiler conditionals '#if defined' and '#if undefined' allow checking if objects, properties, etc. exist. Internally, the linker has been restructured for speed, accuracy, and clarity. A benefit to users on memory-rich machines is the ability of the engine to load the entire game file into memory at invocation. If not enough memory is available, it will continue to read text-bank strings from disk. Static print strings (i.e., using "print ...") are no longer limited to a single byte (255 characters) in length. Conveniently, the 'parse$' and 'serial$' read-only engine variables now represent constants that can be read in a wider range of contexts, and may be assigned to other variables or data structures, etc. The debugger now recognizes local variables by name, instead of "local:n". And finally, a player_character class has been added to OBJLIB.H with some additional flexibility in terms of built-in before routines, etc. ----------------------------------------------------------------------------- v2.3c/d/e/f - April-May 1997 I haven't been in the habit of updating these release notes for interim releases (i.e., same-version updates), but a couple of recent revisions are worth mentioning in addition to the usual polishing and tweaking--some of which, to the compiler's tokenizing methodology, have resulted in significant performance improvements using a rather guerilla form of hash-search string-matching. It is now possible to pre-declare locals as in: local i = 1, j, k The statement "colour" may now be used interchangeably with the original "color". Parentheses can be used where they previously could not, for example, in nested multiple-choice conditional sub-expressions such as if y = 4 and (x = 1, 2, 3) where the "x" sub-expression is now always evaluated first. The accompanying v2.3.2 library allows the player object to be referred to by the library in first, second, or third person depending on the setting of the player_person global. The player object must help out a bit by giving the correct set of pronouns. For example, the normal second-person player object "you" in SHELL.HUG now contains: pronouns "you", "you", "your", "yourself" Additionally, it is now possible to refer to an object with up to 16 words in the input line--i.e., up to 16 adjectives, or 15 adjectives and 1 noun. ----------------------------------------------------------------------------- v2.3 - March 1997 The month of fairly rigorous testing and refinement between v2.3's beta release and the official release resulted in at least a couple of highly functional extensions to object building: replace "name" { inherits , ,... ... } The "replace" directive is useful for replacing previously defined objects or classes without having to actually edit the file in which they first appear. A popular example is the room class from OBJLIB.H: often, programmers have wanted to give their basic room classes special properties. This is now easy via: replace room "room_class" { (...new room definition...) } The "inherits" instruction allows more than one class to be used to build an object. The precedence of inheritance is left to right, i.e., the properties of take precedence over , etc. (Both "replace" and "inherits" were based on suggestions by Jools Arnold.) Mark Bijster offered the following: object is [, [not] ,...] which is now valid in a line of code, so that multiple attributes can be set or cleared for the same object at one time. A couple of changes to the debugger accompany v2.3. An online help file is now available (HDHELP.HLP), giving information on the debugger's various functions and features. In terms of deletions, the ability to launch the compiler or an editor has been removed--mainly because in larger systems, it is relatively easy to switch back and forth between multiple programs, and on smaller systems (such as MS-DOS), memory constraints prevented launching a new process anyway. (In short, this sort of process spawning wasn't particularly portable.) A tidied up version of the libraries accompanies v2.3. ----------------------------------------------------------------------------- v2.3 beta - February 1997 A small step forward in refining the Hugo language, but a major leap in terms of expanding the functionality of the Hugo design environment. Version 2.3 includes a full-featured source(ish) level debugger enabling a Hugo programmer to utilize breakpoints, watch expressions, code tracing, and most other modern IDE features to debug programs. It is not technically a source-level debugger in that it is tracing the compiled object code, not the original source file(s), but the output is similar enough to be useful in the same way. Big thanks to my brother Dean Tessman for his input on the user interface. Enhancements to the language allow the use of efficient operators '++' and '--' for pre/post-increment/decrement, as well as '+=', '-=', '*=', '/=', '&=', and '|='. Those unfamiliar with these somewhat cryptic yet exceptionally useful operators are referred to the Hugo Manual for further explication. Another new feature is the "enumerate" directive, as in: enumerate start=5, step *2 { FIRST_CONSTANT, SECOND_CONSTANT, THIRD_CONSTANT } which is equivalent to constant FIRST_CONSTANT 5 constant SECOND_CONSTANT 10 constant THIRD_CONSTANT 20 Globals may also be enumerated via "enumerate globals [start..., step...]". (Both the efficient operators and constant/global enumeration have come into being at the urging of Mr. Jools Arnold.) As a final constant-initialization enhancements, constants no longer need to be declared with an explicit value. If none is provided, the constant is assigned a value that is unique from any other constants declared without an explicit value, so that in constant THIS_CONSTANT constant THAT_CONSTANT THIS_CONSTANT and THAT_CONSTANT can be referred to meaningfully as different values, flags, etc. Further compiler enhancements include stricter syntax checking to avert potential runtime errors, the ability to pre-initialize local variables, as well as compile-time warnings of unused locals, and the option (for legibility) of defining an event as "event in " instead of simply "event ". Other quick additions and fixes: - "array[]" now returns the number of elements in the array - "&(obj.property1).property2" no longer incorrectly takes the address of - it is now possible to specify the input color via a third parameter in the color statement: "color [, [, ]]" - quirky attribute behavior has been isolated and reined in A stylistic syntactical change involves constructions such as object.property1.property2 which used to be read as object.(property1.property2) These are now interpreted left-to-right, so that the order of processing is (object.property1).property2 This is a.) more consistent with other common object-oriented languages, and b.) plain old more intuitive. The behavior of FindObject and the engine's expectations for it have been refined so that, for example, object disambiguation is more accurate, and parse_rank now works properly in a wider variety of circumstances. As far as deletions to the language go, "~" and "^"--which existed briefly as equivalents to "\"' and '\n' in print statements for Inform users familiar with the former symbols--are no longer significant in printed text. Thanks to Dean Tessman, Julian Arnold, Jim Newland, Cam Bowes, John Menichelli, Jerome Nichols, and everyone else who has made contributions large and small. ----------------------------------------------------------------------------- v2.2 - July 1996 While on the surface not much different from v2.1, v2.2 contains a range of revisions, enhancements, and extensions. Here's a quick rundown: Text output has been greatly expanded in terms of flexibility and capability, allowing (if the system in question supports it) boldface, italics, underlining, and proportional type. Special characters such as accents are now easily printable. In conjunction with these changes, the library printing and listing routines have been revised, and (most of) the printed text has been localized at the ends of HUGOLIB.H and OBJLIB.H. Additionally, text may now be routed to a memory (array table) address instead of the screen. Changes in how expressions may be structured now allow if x = 1, 2, 3 to be used instead of: if x = 1 or x = 2 or x = 3, and if a = "apple" and b = "orange" and c = "banana" to be split across multiple lines, providing it ends in "or", "and", or ",". The Init routine is no longer called with the arguments (MAX_OBJECTS, MAX_LINE); these are now referenced by the new globals objects and linelength (and there is a new global pagelength). The random(n) engine function now returns a random value from 1 to n, a change that Jim Newland suggested was more intuitive and consistent (although the current manual incorrectly and unfortunately gives the range as 0 to n). Array references are now all word-based, instead of previously where references involving calculations such as a[b+3] were byte-based. Property routines may now be indirectly run with object..property. And grammar lines may now use the "word" token to specify any single dictionary entry. Extensions such as file i/o and command recording/playback have been added, as well as a machine-independent compressed saved-game format--and the engine now requires a confirmation if a save request will overwrite an existing file. Enhancements to the command line allow directories to be specified for different types of files. Finally, there has been the usual fine-tuning to the compiler (particularly with regard to source-file processing and temp file usage) and the engine (mainly the expression evaluator) to increase speed and performance. ----------------------------------------------------------------------------- v2.1 - March 1996 Version 2.1 includes a number of substantial (although not earth- shattering) improvements to both the compiler and the interpreter. Foremost among these are the increase in the number of available attributes from 32 to 128, more elegant compiling and linking (and error messaging), more explicit run-time tracing of loop constructs, and a much, much faster expression evaluator. As well, the (also faster) text-printing routine in the engine has been enhanced to allow the use of ~ and ^ in printed text to mimic \" and \n (the quotation mark and newline characters); this feature was added at the request of a number of Inform users who find them familiar and easier to work with. And string constants can now be extended over more than one line without using the backslash ("\") at the end of the unfinished line. (The backslash is still necessary for non-string-constant expressions, etc. that stretch over more than one line.) The author also managed to track down one particularly troublesome bug that prevented the coding of a complex assignment such as: . [#n] is (Also note: #n is no longer passed as the first argument to a property routine.) The library files include some major developments. Primarily, the object library (OBJLIB.H) now includes advanced classes such as plural and identical objects, attachables, and components. HUGOLIB.H has also been fine-tuned. The routines DefArt, CDefArt, IndefArt, and CIndefArt (hold-overs from the author's introduction to interactive-fiction programming via the early Inform library) have been replaced with The, CThe, Art, and CArt, respectively--a somewhat subjective choice, perhaps, but one that lends it self to clarity of reading, and which is both easily corrected in existing files using search-and-replace as well as being nicely less cryptic. Object listing has been enhanced--particulary the routines DescribePlace, ShortDescribe, WhatsIn, SpecialDesc, and ListObjects. The LISTTYPE global no longer exists; it has been replaced by FORMAT. As well, those users who have begun projects using the v2.0 starting-block program SHELL.HUG will want to remove the list_contents property from the player object. And of course, the obligatory enhancements of the Vault of Hugo sample game, Colossal Hugo, and Spur have been released to accompany version 2.1. ----------------------------------------------------------------------------- v2.0 - November 1995 (Those keeping score may have noticed that v1.3 was never officially released. And admittedly v2.0 is not the full-featured, bells-and-whistles, CD-ROM-driven animation and sound version. But the changes to the actual framework and functionality of the compiler have been so substantial since v1.2 that it started to seem less sensible to keep Hugo at a version 1 level.) The biggest new feature in version 2.0 is the ability to precompile header files like HUGOLIB.H into .HLB files that may be included using the #link directive instead of #include. A new compiler switch -h is provided to specify creation of an .HLB precompiled header instead of a normal .HEX Hugo object file. Thanks to the Hugo users who saw the value of allowing some form of linking, and thanks also to the author's lack of sensibility in vastly underestimating the work involved in reverse-engineering a non-linking compiler to accomplish the task. I'm going to get some sleep now. Other streamlining changes have included the removal of the -t, -m, -n, and -f switches (for compilation tracing, monitoring, numerical code generation, and full-object summaries) since 1.) the amount of output produced using any one of these become almost overwhelming when compiling a program of any significant length, and 2.) few programmers, if any, made use of them anyway. The performance speed of the Hugo Engine has been increased by redesigning the way it processes conditional statements. The engine is now able to work much more quickly through a complex series of 'if's, 'select's, 'do-while's, etc. Accompanying version 2.0 is also Spur, a western adventure written by the author, as well as an extensive demonstration of what Hugo can do. (In fact, the greatest use of version 1.3 was as an interim development tool for Spur.) (NOTE: A pre-Christmas touch-up release of v2.0 included some minor fixes to the compiler, engine, and library. Special thanks to David Kinder, whose feedback helped increase the portability of the Hugo source code.) ----------------------------------------------------------------------------- v1.3 - August 1995 Some significant enhancements to the compiler and interpreter, as well as the library--enough so, in fact, that the author considered making this v2.0, but held off as it has been suggested in the past that v2.0 will be the full bells-and-whistles, CD-ROM graphics and sound version. The most significant changes were to accommodate large programs, which would run into problems if the size of the total data space exceeded 64K. The fix required involved altering the internal format for storing reference addresses. And some further refinement of the file format has--thankfully--eliminated the need for a separate .H$$ text bank file; everything is now self-contained in .HEX. (These were the almost-v2.0 changes.) Also, property routines now always pass the number of the property element referenced as the first-defined local in the routine (if any is defined), so that if 'object.property #x' is called, and is a routine, is passed as the first local. The only effects on programmers are that 1.) It is now possible to return more than one value from a property routine, depending on how it was called, and 2.) The first-defined local can no longer be expected to equal 0, as is usually the case in a normal routine. It was decided that all compiler directives must now be prefixed with a C-ish "#"--i.e. '#include', '#ifset', etc. This not only makes the source code easier to read, but increases compiler speed. Other fine-tuning and optimizations increased compilation speed by as much as 25 percent. (And another directive, '#version', is provided--and used in the library files-- to ensure that #included files are compatible with the latest Hugo features.) Changes in format to engine commands and functions include: string(, , ) (making the StringCapture library function obsolete), and save, restore, restart, scripton, and scriptoff all of which must now be read as values instead of simply issuing a simple command. Return values (1 if successful, 0 if not) should now be checked where appropriate, i.e.: if not save: "Failed." An 'undo' function (checked in the same manner as save, restore, etc.) is now provided to undo the last player command. (Multiple-turn undoing is allowed as long as undo information exists in the undo buffer.) It is also possible to use the token 'string' in a grammar syntax line to allow the player input to contain a quoted string. The string is passed to the verbroutine in parse$, and may then be written to a string array via "string(, parse$, )". The new command 'dict', as in x = dict(, ) allows a new dictionary entry to be dynamically created at runtime (although space for the total number of entries that may ultimately be created must be reserved during compilation--in bytes--by setting the MAXDICTEXTEND limit). Additions to the library included the NumberWord routine as well as a (small to begin with) set of math routines. Properties such as inv_desc and list_contents now make it even easier to customize the listing of objects. As well, some work was done with how the library treats scenery objects--their contents (if any) are now listed by default, even if the object itself isn't. New string array routines include StringCompare, StringDictCompare, and StringEqual. New character script routines include CancelScript, PauseScript, ResumeScript, and LoopScript--not to mention the fact that RunScripts now checks before/after routines for the actor. A major improvement to before/after routines is in the usage specification, so that parent(object) DoGet replaces parent DoGet and the library now does checking for the special before property in the DoGet routine. What this means is that programmers may now check any before or after routine/object combination instead of the previously pre-determined object, xobject, location, and parent. Thanks again to Vikram Ravindran for excellent suggestions on where Hugo's functionality could be extended (particularly on supporting the implementation of 'dict' and 'undo', as well as library improvements big and small), and to Jim Newland for his extensive investigation into--and subsequent notes to the author on--how the character script routines might be expanded to further increase their usefulness. NOTE: Due to enhancements to certain key aspects of the Hugo language, it is recommended that programmers who may already be familiar with it take a moment to browse through the v1.3 manual, revisiting in particular the sections on before/after property routines, string arrays, and character scripts. --------------------------------------------------------------------------- v1.2 - July 1995 This time at the end of the month. Hugo version 1.2 was moved ahead mainly in response to requests by porters for more easily portable code. As a result, the H*HEADER.H files were changed somewhat, with the porting-required functions moved into separate .C files to make the job of adapting Hugo to different operating systems more manageable. (Thanks especially to Jesse McGrew for the suggestion.) Changes to Hugo at the most basic levels were relatively minor, except that compilation speed is about 20% faster (and engine execution is faster as well) because of Jeff Jenness's suggestion to limit the number of C strcmp() calls performed. The greatest changes here were in STRINGFN.C, and HCMISC.C in the SeparateWords() function. A couple of new constructs have been added to the language, particularly for in loops, the ability to specify values as ASCII characters as in 'A', 'z', '7' and print them as characters using printchar As well, it is now possible to specify an array address using a variable or other value, as in: x = testarray ! i.e, the address of testarray[] print array x[5] ! the same as: print testarray[5] And finally, there is now a STRING command string , , which reads the dictionary word into the array given by , to a maximum of characters. A number of string- manipulation routines were subsequently added to HUGOLIB.H: StringCapture, StringCopy, StringLength, and StringPrint. Error trapping is also considerably tighter, lessening the number of almost-correct lines which might slip through the compiler only to crash the engine at runtime. Thanks also to Vikram Ravindran for spotting a couple of problems in Colossal Hugo (mainly involving attributes that were not properly assigned when needed in certain object definitions), as well as identifying a problem in HUGOLIB.H's DoGo routine which moved the player to a null room upon entering 'go vault' in the sample game. Thanks to Markus Mattes for suggesting a better fix than the one the author had in mind... ----------------------------------------------------------------------------- v1.1 - July 1995 After a couple weeks of error-reporting and user-testing, I went about trying to address the two major problems with v1.0: i.e. memory shortages and the lethargic compile speed. Thanks especially in this case to Dr. Jeff Jenness, who pointed out to me that life does exist beyond MS-DOS, and that it may highly susceptible to stack abuse. Jeff also suggested moving dictionary search/store management into memory as opposed to doing it in a work file. This change alone practically doubled compile speed--on the trusty 8086, SAMPLE.HUG compiled in just over 300 seconds--and the programming required to implement the far-model arrays (MS-DOS programmers may flinch here in painful recognition) enabled many of the storage arrays such as for objects, properties, etc. to be changed from static arrays to dynamically allocated memory blocks. The benefit: increased limits for whatever storage types the user may desire, and no more memory problems when, for example, setting DEBUG instead of DEBUG_SMALL in COLOSSAL.HUG. Changes to HEHEADER.H: Far-model memory allocation and pointer declaration for objects, properties, dictionary, etc. Making the applicable MAX declarations dynamic integers instead of constant #defines. HEMISC.C: AddDictionary() now searches a memory-based array instead of a temporary work file. OpenFiles() takes care of allocating space for objects, properties, dictionary, etc. New functions ListLimits() and SetLimit(), as well as provision for $= specification in the invocation line via an addition to ParseCommandLine() (once again following in the footsteps of another of Graham Nelson's excellent ideas from Inform). Additionally, there were minor additions/changes to the other compiler and engine source files, as well as to the Hugo library files. (One change to SAMPLE.HUG was important--particularly to the author's self-respect. Seems that in revising the methods of player-character interaction, he actually omitted the means of solving the sample game.) ----------------------------------------------------------------------------- v1.0 - June 1995 Hugo v1.0 was essentially the first full-featured, portable version of the compiler and engine written in C (and based on a MS-DOS-only Microsoft QuickBASIC beta release). It was intended from the beginning to be a functional beta release--i.e. one which would serve to point out shortcomings and needed improvements with Hugo's design, but with which users would also be able to start developing programs that would be fully compatible with later releases. The most obvious shortcomings were in memory management and compilation speed. On the machine the author used for development--an 8086, the machine of necessity, not of choice--the sample game SAMPLE.HUG took more than 600 seconds to compile. And larger programs ran into memory limitations, in one instance prompting the creation of the scaled-down DEBUG_SMALL HugoFix command set instead of the regular set included via setting DEBUG in the source file. Also at this time, the first version of COLOSSAL.HUG was released--a Hugo port of Adventure based on Graham Nelson's Inform port of David Baggett's TADS adaptation of Crowther and Woods's original classic game. (Quite a lineage.)