Hacker News Reader

Comment by krychu | Hacker News Reader

> The implementation is mostly concerned with creating the correct series of data-structures, which are essentially arrays of objects. Because if we can make the game table-based we simplify the coding that needs to be done - we don't need to write per-object handlers anywhere, we can just add pointers to tables/structures.

Interesting model, could you share how this worked out for you? Good and bad?

View on HN

It worked out really well, saving me from writing a lot of fiddly code.

For example imagine you wrote an "EXAMINE" command, and you wanted to allow all objects to be examined. The horrid way to do it would be something like this:

     if target == "desk"
       print( "The desk is ..\n" );
     if target == "book"
       print( "The book is ..\n" );

With a table-based approach you just define your struct (in C) or item-table (in assembly) and your code now looks like this:

       item = find_item_by_name( object );
       print( item.description );

Sure you have to write the lookup function to find the object, but it means you don't have to duplicate the logic for every action (get, drop, examine, use, etc).

Using tables for items, and locations, basically saved me a lot of custom code, cut down on repetition.

The most interesting text adventure I saw years ago (with online connection", was a person who had written a fairly good frame of a text adventure, and was also sitting at the keyboard choosing which macro to hit or typing things in. It took me awhile to catch on, because it was mostly automated.

Reply on news.ycombinator.com