WebHack

OK, back to coding. I was doing other things for the last three weeks. I was surprised to find out that quite a few people have been heavily playing the game since I last checked in. Cool! :)Well, the basic framework is done. Now to craft the code the rest of the (currently non-functional) menu items. The multi-player interaction/combat will become my highest priority after a clean up some of the other items this week.I'm going to keep the hand-drawn graphics just for the home-brewed feel. If anyone is feeling artistic, feel free to send your stuff to bkimball@home.com (Make it black background and in .png format. No transparencies until we see all the major browsers (IE, Netscape, Opera) support .png transparencies well. Currently only IE has that working right.Visit the ROTFOH (How to say that? I say Rot-Foe) MessageBase to ask questions and addsuggestions. Ideas are good! Later, gotta go code!

I am changing the game interface quite radically at this point. You will now see a multi-framed display., After being stuck on the combat routines for way too long, I have decided to go with this interface which will allow for the game to display relevant information in a more useful manner. This will allow for near-realtime interaction with other players and monsters. I have to take a few steps back and write a server-side application that will handle things needed to implement this. It will be very cool when finished, allowing for pseudo-intelligent monsters, weather, interaction between players, and all kinds of other things still to be dreamed up.Currently you only see activity in the bottom frame, but soon you will see a constant display of your character status in the upper-right frame (HP, XP, links to your inventory, etc.). The top left frame will have (at least) two modes: One in 'normal' mode which will display any objects (weapons, coins, chests, staffs, levers, etc.) in the current room and allow you to interact (drop, take, use, pull, etc.) with them. The frame will change to combat mode when you get in a fight with another player or monster(s), which will allow for quick attack selections and display of critical information needed during the melee.Display in all the frames will be coordinated by a fourth, hidden frame that will be a non-displaying frame used for higher speed communication with the web server. When it senses that something needs to ...

The threaded messages following this message are taken from the original WebHack Roundtable which was created with the FrontPage discussion bot.

I finally found the (almost embarrassingly obvious) magic line of code to make WebHack work correctly with Netscape! Previously, whenever you moved from room to room while using netscape, the browser would cache the room display info, so the display would stay the same and the exists would stop working. The only way to play it under Netscape was to hit the Reload button every time you moved to a new room.If you view source now, you will see the first line with the mysterious "pragma:NoCache" in it. That causes the browser to not cache the information. I had previously been trying to do this with either the ASP code or by a setting in IIS that supposedly should set all content to expire immediately. This worked fine for Internet Explorer, but it seems that it is a Microsoft-centric thing that is ignored by all other browsers. Now I just have to find out what the trick is for the Opera Browser which is still not working. There's gotta be a way, I just have to find it.Anyway, some definite good news! :)

WebHack is a web-based MUD (Multiple User Dungeon). If you are familiar with MUDding (Or MUSHing/MOOing, or any other mutation of the basic concept), WebHack is an adaptation of the classic telnet/text-based game so that it can be played via a web browser. WebHack (Accessible at http://www.llabmik.net/WebHack) is currently in the very early stages. You can create a character, walk around the (right now very small) dungeon, and pick up or drop any objects you encounter. I am currently designing the best interface for player/monster interaction, which due to the limitations of HTTP, has been the biggest stumbling block to the project. With the original telnet-based interface, the MUD server "owned" the user screen. At any time, if something changed in the environment, such as a monster entering the room, another player attacking the player, or anything else, the server would instantly be able to update the user screen. This allowed for near real-time interaction. However, with the browser/http interface, the user effectively "owns" the screen. The only time the server can let the user know of a change in the environment is to wait for the user to request new information (to move from room to room, check inventory, use an object, etc.) and then send the new information to the user. This creates some unique interface programming challenges in designing how to modify the gameplay to support the lack of a real-time interface and instead use only a request-driven interface. I am playing around with several different approaches to it, such ...