Reading Books

[trollson]

I'm pulling out one topic from the Interacting with the Map thread for further scrutiny. While that topic covers a lot of features; the one I keep thinking would have the most impact is that of readable books...

 

Making All Books Readable

All book objects in game can be read. Players can and should seek out books for background information, and game secrets.

 

Rather than announcing new recipies, spells, items, etc. on the forums; add this information directly into the game, where it can be discovered by players in their own time. They can then choose to keep it a secret, use it to get an advantage, or tell people.

I suspect there would be less moaning if people have found a secret, than if it was announced as a new feature to all'n'sundry; for example, look at the enhanced forms of the new weapons and armours which where not announced, but discovered over time.

Players perspective: Use any book object in the game and the book window opens, displaying the contents of the book. Return to the same book some time later, and you can expect to get the same content displayed again.

 

Developers perspective: To add new information to the game, write a new book-file and add it to an appropriate directory (simplest implementation) (active on server restart). To update some information, update an existing book-contents file (new information available immediately).

 

Implementation, server-side:

I assume that objects currently only respond to user interaction if they are specified in the DEF file, or if they are generic harvestables.

 

To allow interaction with any object, we would need to add default event handlers based on the 3D object model (ie, the filename of the 3D object), which are used when no other handler is specified (eg, harvestables or DEF files). Pass these default handlers the object model ID (filename) and the object instance ID (number on the map), along with any usual context information; both these are readily available.

 

So, for this case we have a default book object handler, which is used for all of the book object models. Its purpose is to respond to the player with a READ_BOOK (?) message, with a book reference from the "library".

 

The book reference is determined from the object instance id modulo library size; so the same book is returned so long as both the map and library size are unchanged.

 

Example pseudo-code:

default_book_handler (model_id book, instance_id number, ... )
{
send_read_book ( library_list [ number % library_list_size ], ... );
}

 

There is a coverage issue: The instance ids cover all objects, not just books, so the indexing into the handler will be sparse. So long as library size is small compared to the typical number of objects on a map, this shouldn't be too much of a problem. As library size grows, it may be useful to add an offset into the index based on, say, the book object id.

 

Coverage of the library can be determined by off-line analysis of the maps in play, to get a list of any library indices not reachable.

 

Implementation, client side:

 

The client already has the necessary functionality. However, since the library is 'server-side' (and should not be cached), bandwidth may be an issue.

 

Extend the book API (books.c) to take a URL to a book-file, allowing the library to be seperated from the game server.

 

Other options:

• Create seperate lists from the global library for each book model, so "magic books" have appropriate information, and green books have information on flora and fauna etc. More work and library management though.
  
• I18N: Clients could look for translations of books by adding/inserting a locale to the URL.
  
• The library server should be protected from spiders and scrapers etc. No point having secret information to be discovered, if somebody can come along and scrape the contents. Possibly use CGI script and a validating key in the URL.
  

Well, I obviously don't know how the server is implemented; but this should be quite possible...?

Edited November 3, 2006 by trollson

[trollson]

Update: Library Management Moved completely to a library server

 

If we use a seperate library server (cgi) to provide the contents of the books to the clients, then the game-server doesn't need to know anything about the contents or size of the library.

 

The 'default_book_handler' would just compose a URL to send back to the client, of the form (if I remember GET syntax):

http://library.eternal-lands.com/book?map=MAP&type=MODEL&book=ID&ck=CHK

Where:

• MAP identifies the map the book is on. This may be used to include area-specific books (eg, guild contributed books on a guild map).
  
• MODEL identifies the 3D object model for the book. This may be used to associate book titles with appearance; a title may always be found as a red book.
  
• ID is the index of the object in the map (integer). The CGI is now responsible for applying the modulus into the (appropriate) book list; the server doesn't need to know the size of the library.
  
• CHK is a checksum based on MAP, MODEL, ID, and maybe the client IP. For additional security, it should decode to give a timestamp, which must be within some interval of the current time for the connection to be accepted. Alternatively, a seperate timestamp parameter could be passed and included in the checksum calculation.
  
  

The client can append a standard locale code to the end of the URL ('&loc=fr_FR') to retrieve a translation if available.

 

The purpose of the checksum is to prevent an agent from scraping the library automatically. As such, its formula should remain closed-source.

 

This approach means that the library is independant of the game server; new books can be added without interfering with the game server.

Notes:

• The client already has the means to download from a URL, used for auto update. Less work required to implement client-side part.
  
  
  
• The only part which requires the game server is the checksum. If you were not concerned about data-mining, then the book URL could be generated by the client. However, I'd prefer to keep access controlled by the game-server; require players to go and read the books.
  
  
• Player run web sites will gather and compile game information, so not every player has to search out common stuff by themselves. Its up to the players then to decide what information is 'secret' and what should be promalgated.
  
  
  

Other uses:

If you look back at the original topic, there was an entire rumour system, which covered writing on note paper and content of newspapers. This could be handled in a similar fashion, with the actual work off loaded to rumor servers.

 

In the case of user-added notes, the game-server would send an 'upload' URL to the client, which would append the (short) text message, which the notes server would enter into its db (overwrite).

POST should be used, rather than GET, for uploading information to a rumour server.

Edited November 6, 2006 by trollson

[Roja]

Well, we already have both client and server support for books. WE can have server only books where the info is not on the client side, when you click the book you get the book from the server only. I don't think we used it anywhere yet.

[trollson]

Yes Roja, I've seen the server side book code, and using that is one option. There is also code to download files from URLs (downloads to files, whereas here we'd want to download to memory). Combining the two, to receive a book as a URL, would not be challenging.

 

My concern with downloading content from the game-server is of bandwidth. If a lot of game information is placed in books (every book containing something), then it may become a lot of information to push out from the server.

 

Since the information is (relatively) static, its an ideal candidate to be deferred to secondary web servers. This decouples the details of the library access from the game server, so adding books doesn't require server restart (since the size of the library needs to be known, and the server isn't set up to accept parameter changes at runtime afaik).

 

It doesn't matter where the library server is, so it can initially it could be hosted on the game server as a seperate process, and moved at a later date if bandwidth is significant.

 

Additionally: Thinking about Guild maps and books there; the DEF file could specify a URL for a book to be displayed, it being the guilds reponsibility to post the file to an accessible location. So their own content would not need to be shipped with the client. This does not impact on the other book/library issue, but on distributed content.

 

Possible issues are:

1. Reliable guild hosted websites. The client needs to cope gracefully with a URL book not being readily accessible (must not hang the game).
   
2. Vetting content; are the game hosts responsible for content displayed though the game from an external URL?
   

2007-01-22

A brief add-on that isn't worth bumping this thread over...

 

Building a Personal Encyclopedia

Add to the client records for a character a personal notebook or encyclopedia, into which they can save snippets of information. This can include the ingame notepad.

 

Include in the Book XML schema a markup for a block which indicates that it should be added to, or updated, the reader's notes. The markup should include a tag which says where the information should be stored (inserted).

 

So, the encyclopedia becomes a personal record, extended as the character explores and reads.

 

Of course, we could decide not to spoon feed the players; if the client notebook feature works then they could make their own notes, which may be more realistic. In which case, character notes may still need an indexing scheme?

Edited January 22, 2007 by trollson