Game - The Begining

[OWL]
Once upon a time we ([PNL] && [owls]) were discussing 'nethack' and we came to the conclusion that it was too much of a misnomer to be ignored any longer.

'Nethack' is, of course, not a version of 'hack' that can be played over a network, but a version of 'hack' that was developed over the net by a bunch of people. This is fine, but it does leave the net somewhat short of the interactive style game that 'nethack' is. After looking around for a net version of a 'hack'- alike game, we found only a strange thing that had too many SysV-isms and wouldn't compile on mackerel as the SysV stuff had not been installed.

Thus the task: design and code a game that looked similar enough to a 'hack'-alike to be playable by those who were used to it, but make sure it was a multi-player and multi- computer game. Well, something like that. [owls] was of the opinion that the server should be capable of being run on a distributed basis, with different machines running different parts of the map and all sorts of wonderful communication flowing between the various servers. This was roundly condemned by anybody within hearing range. Oh well. Maybe version 17.

So the idea was to have a server running the maps and controlling the positions of the players and objects and things, and clients connect to this server and get told what is happening in their bit of the map. We came up with a compressed (RLE) map diff format, and a few other bits to help reduce the size of the packets that would no doubt flood the net. This all took a couple of weeks to be properly discussed, and we worked out the basic commands and client-server communication stuff and player stats and whole piles of boring stuff. Then it was time to start coding the thing. [PNL] worked on the udp communication stuff, being the guru on network stuff that he is, owls did the file stuff like maps and the character files. We persuaded [COM] to start working on a text- based client while we merged the stuff we had done into a server.

A small digression - [owls]' plans for the clients went a little beyond the simple text- based interface that nethack has. As long as a client can communicate with the server, and present some usable information to the user, anything was possible. So, even though the map was a really just your standard, everyday, 2 dimensional, grid-based thing, if somebody wanted to get fancy and make some sort of Wolfenstein-style interface (and perhaps withhold some information from the user) this would be fine. This idea leaves all of the interface processing up to the client, the server then only has to worry about where the characters are and what they might be doing at any time. 'Turning around' is a possible 3D- client function, one that would involve no server communication as the notion of a player facing a direction is unknown in the current server version. If you can't understand this concept, well, [owls] has nothing further to say except "stay tuned..."

Soon several others around UCC got involved; [DDT] started evolving the almost-working client [COM] had written into an almost unbroken curses based client, [MTL] designed a couple of really pathetic maps and many others contributed with destructive criticism. We even got a usable map editor with popup help, cannibalised from the curses client. By about this time we realised that the code was being modified in too many ways by too many people, so we wasted time with things like 'vilock' and even a perl script to automate the makefile maintenance.

Eventually, enough of the bugs were ironed out to have a playable client connected to a non- coredumping server. This was tested with five or six players (all at once!) and thoroughly denounced for being boring.

"There isn't anything to do!"
"Where are the monsters?"
"Why can't I kill so-and-so?"
etc...

This led to code being added to handle some of the commands, namely:

quit [without dumping core]
open & close doors
say
get
inventory
drop
and this pleased a few people a little bit. But there was still no way to hack and slay, and nothing to hack or slay anyway. So [PNL] added code to handle events, and [DDT] wrote the basics of the first NPC, the being we know as '4'. '4' is a strange beast, able to wander the world all day, and every now and then '4' will stumble across a closed door and open it, or an open door and close it. This is great if you are just about to go through the door.
Unfortunately, '4' has a weak heart: if a player quits too close to '4', '4' is so shocked by the sight that '4' promptly turns into a statue. There is also no way to attack '4', nor any other being. You can, for what it's worth, pick up a carrot (and drop it again), but you can't throw it at anybody. If you are really tricky, you can even get three carrots and drop them all in one place. This confuses most people a lot more than saying "Watch out for 4", which they get the hang of pretty quickly.
We got really foolhardy and decided to implement limited vision, ie. if you are in a corridor you can't necessarily see all of the room at the end of the corridor, nor see through doors, etc. After looking at the vision code in nethack, we decided it must be easier than that (it was *huge*) and did it from scratch. The code currently assumes you can see about six units in any direction, but it isn't a 13x13 square, we cut the corners off to make it more like a circle of vision. See the following Diagram examples.
Details of following diagrams:
1. the actual map, as known by the server alone.
2. the calculated map prior to encoding and sending in the packet to the player at 'Y', the ',' areas represent stuff obscured by the walls, this area would be the maximum visible area if 'Y' were in a large open room.
3. The map 'Y' is sent assuming 'Y' just teleported to that location, normally only a diff between the last known surrounds of 'Y' and the current surrounds are sent.
Legend
```
'#'            Wall
'.'   	       empty
' '   	       too far
','            Obscured
'Y'            You
'O', 'X', 'K'  beings
'*'            object
'g'	       thingy
'-'	       open door
'+'	       closed door
```
```
#.O..........
#####+##$####
#...*..##....
#...g..X#..##
#.......#..#*
#.....###..-.
#.....Y....#K
#############
```
Figure 1 Physical
```
    ,,,,,
  ,,,,,,,,,
..,,,,,,,,,
#...,,,,,,,,,
#....,,,,,,#*
#.....###..-.
#.....Y....#K
#############
,,,,,,,,,,,,,
,,,,,,,,,,,,,
 ,,,,,,,,,,,
  ,,,,,,,,,
   ,,,,,,,
```
Figure 2 Logical
```
..
#...
#....      #*
#.....###..-.
#.....Y....#K
#############
```
Figure 3 Visible
This is currently the state of GAME - although there is no server running at this time on any UCC machine, as and when time permits [owls] promises to recompile the code on one of the machines and do some more work on the bits that need work done on them.
Also, [CJP] has mumbled something about an X-client for GAME once he has the packet specs. [owls] will forward the details to him as soon as both [CJP] && [owls] are at the same space-time location.

David Bennett ([email protected])
Murphy's Law Newsletter - Volume 4 Issue 1
Feburary 1995 for the University Computer Club

Game - The Begining

Figure 1 Physical

Figure 2 Logical

Figure 3 Visible