<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Graphic design doc -->
<!--X-From-R13: Fuvahf Pneaneq <guvahf_oneaneqNovtsbbg.pbz> -->
<!--X-Date: Wed, 20 Jan 1999 08:29:27 -0800 -->
<!--X-Message-Id: 36A46378.B4F3953E#bigfoot,com -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Graphic design doc</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:thinus_barnard#bigfoot,com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00220.html">Previous</a>
| <a href="msg00225.html">Next</a>
]
Thread:
[ <a href="msg00227.html">Previous</a>
| <a href="msg00220.html">Next</a>
]
Index:
[ <A HREF="author.html#00224">Author</A>
| <A HREF="#00224">Date</A>
| <A HREF="thread.html#00224">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Graphic design doc</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: MUD-Dev <<A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A>></LI>
<LI><em>Subject</em>: [MUD-Dev] Graphic design doc</LI>
<LI><em>From</em>: Thinus Barnard <<A HREF="mailto:thinus_barnard#bigfoot,com">thinus_barnard#bigfoot,com</A>></LI>
<LI><em>Date</em>: Tue, 19 Jan 1999 12:50:32 +0200</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Hi,
Here is a doc on the graphical interface I am working on for my mud. I
hope the two figures are not too messed up. If you use a fixed width
font to display the message it should look OK.
--
GRAPHIC DESIGN
PROBLEMS
Speed! Speed! Speed! At the moment I feel it is a bit unrealistic to
have a mud where you send the graphic files over the net. If you have a
2mb pipe directly to the mud server you might disagree with me but if
you use a modem to dial into your ISP you propably understand what I am
talking about. To circumvent this problem create a couple of data files
which contains the graphics. The user will now, unfortunately, have to
download the data files to see the graphics. With a little attention the
process could become easy and painless for the user. All the logic still
remains on the mud server, the server just tells the client what to
draw. If something changes the server will send the client an update and
the client can redraw the view. Now we come to the doom syndrome.
Everybody expects a doom type interface these days or at least an Ultima
type interface. Both these interfaces need a fast and reliable
connection, you also have problems with keeping things in sync and logic
resides on the clients.
APPROACH
I am not a graphics guru. I have decided to implement a static interface
to start with. The static interface will be a 1st person perspective.
There will be 6 possible directions to face (n,s,e,w,up,down). To handle
a structure like this I will need a 3D map. I also have to check for
when the visible environment changes and then to update the display. I
will use a x,y,z coordinate system to indicate locations inside the
world. The x-axis will control east/west, the y-axis north/south and the
z-axis up/down. It looks like this:
+ mod - mod
x-axis east west
y-axis north south
z-axis up down
Extra checks will be needed for up and down movement to facilitate
flying and falling (gravity gets me down), also climbing with ropes and
ladders etc. The server will have to send all the relevant information
to the client. The client will draw the environment for the user. All
images will be located in data files. The server will supply the client
with the name of the data file and the image to display. This is a bit
of a simplification as the server will pass the client details of 35
rooms at a view depth of 2.
ROOM
So what does a room need? A room must specify an image (or empty) to use
for each of its 6 directions. All images will be kept in a data file and
the room will only need to specify the index of the image. The room will
also need to define a method to accomplish the travelling in a specific
direction. There will be standard methods for the standard movement in
rooms, if you want to do something special like put in a door or a
hidden lever with sliding walls etc., then you can just override the
standard movement method.
VIEW
Now we have to build a view for the user. The user will be facing one of
the 6 basic directions. Note that looking up and down can be confusing
to the user so I will have to give these views special attention.
Drawing the north,south,east,west views requires a few decisions:
How far can a user character see?
This brings up some more questions. Will a character be able to increase
his sight? What will the maximum sight limit be? Will height affect
sight? Will darkness affect sight? Will the character sight be limited
by a light source in the room or which the chracter carries? The easiest
way to bypass all the technicalities is to specify a depth to the draw
method. The depth can be dependant upon race or size or light or
whatever.
How big is the viewport?
The client has to worry about all these details, getting the depth
perception and the sizing of the viewport right.
DRAWING METHOD FOR CLIENT
The client will receive all information about which graphics to display,
the view depth etc. We want to draw a 3D view but we will first look at
a 2D view as the principles should be the same (and I cannot draw 3D in
text).
To make it easy I will work with a view depth of 2. Note that the
character will get a visual representation of its current location
(depth 0). Look at fig. 1 to see how a character views the environment.
Fig. 2 shows the rooms visible to the character.
Fig. 1: 2D view
\--------------/ Max view
\ /
\ / Depth 2
\--------/
\ /
\ / Depth 1
\--/
\/ Depth 0
oo Eyes
Fig. 2: Visible rooms in 2D view
__ __ __ __ __
|1 ||2 ||3 ||4 ||5 |
|__||__||__||__||__| Depth 2
__ __ __
|1 ||2 ||3 |
|__||__||__| Depth 1
__
|1 |
|__| Depth 0
oo Eyes
To draw this we have to start drawing at the back. We draw the furthest
rooms and then move up a depth level. We repeat the drawing for this
depth and move up another depth level until we have drawn depth 0. So we
will first draw room 1,2,3,4 and 5 at depth 2. If the character is
facing north then the north walls must be drawn first because that will
be furthest from the character. Divide the width of the viewport by 5 to
obtain the width each image should be drawn and divide the height of the
viewport by 5 to obtain the height. For the 2D view the vertical
position of these 5 images will be the centre of the viewport.
Now we have to draw the walls at depth 2. Look at fig. 2 again. The eyes
are actually on the wrong place. The eyes should be in the middle of
room 1 depth 0. If you now draw 2 lines from the middle of this room,
one to the left corner of room 1 depth 2 and the other to the right
corner of room 5 depth 2 you will have a better idea of what the
character can see. The left wall of room 1 depth 0, room 1 depth 1 and
room 1 depth 2 will not be visible. The same goes for the right wall of
room 5 depth 2, room 3 depth 1 and room 1 depth 0. So which walls are
visible on depth 2 (assume the character is facing north) :
Room 1 top
Room 2 top, left
Room 3 top, left, right
Room 4 top, right
Room 5 top
Why didn't I include room 1 right wall? If there is a wall there it will
not be visible from this angle. The visible part of the wall will be
defined in room 2 left wall. This forces the builders to pay close
attention to what they are doing and to make sure the bitmaps they
supply for walls are consistent between rooms.
Now we know which walls are visible. The roof and floor is also visible
in the 2D view. To draw the walls we have to start with the outside
rooms first because they are the furthest from the character. So we will
draw room 1,5 roof and floor first. Then we will draw room 2 left wall,
floor and roof. Then room 4 right wall, floor and roof. Finally room 3
left wall, right wall, floor and roof. To achieve a 3D effect the walls
will have to be scaled. The nearer the wall is to the character the
larger it should get. When we draw depth 1 we will divide the viewport
width by 3 to get the width of a room. If you look at fig. 2 it is easy
to see that the top wall of room 1 depth 1 is connected to the bottom
edges of the left and right walls of room 2 depth 2. Now all we need is
a scaling algorithm to scale the wall. To draw the roof and floor for
the edges is a bit tricky. If the view cuts the room in half only half
of the floor and roof should be visible. The easiest way to accomodate
this is to make the off-screen drawing surface slightly bigger than the
viewport and then just clip the visible part and copy it to the
viewport.
To draw depth 1 we do exactly what we did for depth 2. For depth 0 we
just have to draw the top wall.
3D
To convert this drawing technique to 3D is quite simple. Instead of
using 5 rooms at the back we will now have 5x5 rooms. We still draw the
furthest walls first. Now the visible roofs and floors will just change
for the higher and lower rooms. The same technique we use for the walls
we also have to use for roofs and floors now.
OTHER GRAPHICS
We still have to draw all the items and characters etc. How to display
these images is up to the client. The client can draw the images in the
room or maintain a list of objects in the room and only show an image
when the user requests it. I will go with the second method as it will
look a bit crowded if you draw 20 characters in one room. The only
important thing is that the server should tell the client what the
visible objects in a room is and which images are associated with the
objects.
ADVANTAGES
Easy to use and maintain
Graphics manipulation is not complicated
Animation problems elliminated
Server overhead kept to a minimum
Fits comfortably into room based system
DISADVANTAGES
No animation
View limited
Client has to be developed to make use of graphic capabilities
FURTHER POSSIBILITIES
Attacking from behind can now be implemented
Hiding in shadows
Light begins to play an important role
Sneaking behind a guards back
Flying, falling, trapdoors, etc.
Tiling an image.
IN CLOSING
I think this is an interesting project. I have set myself achievable
limits. All the logic seems straightforward and uncomplicated. The most
crucial part is the protocol to use between client and server. I will
only get to that later in the design phase.
--
Cheers
Thinus Barnard
<A HREF="mailto:thinus_barnard#bigfoot,com">mailto:thinus_barnard#bigfoot,com</A>
"Players learn the game, ultimately the game must learn the players." -
Jeff Kesselman
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00220.html">[MUD-Dev] ADMIN: List server and Kanga.Nu host changes</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00225.html">[MUD-Dev] Sockets and fibers</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00227.html">[MUD-Dev] Re: Sockets and fibers</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00220.html">[MUD-Dev] ADMIN: List server and Kanga.Nu host changes</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00224"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00224"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: Sockets and fibers</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00295" HREF="msg00295.html">[MUD-Dev] Re: Sockets and fibers</A></strong>,
Dr. Cat <a href="mailto:cat#oldzoom,bga.com">cat#oldzoom,bga.com</a>, Tue 26 Jan 1999, 21:56 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00225" HREF="msg00225.html">[MUD-Dev] Sockets and fibers</A></strong>,
Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Wed 20 Jan 1999, 17:15 GMT
<UL>
<LI><strong><A NAME="00226" HREF="msg00226.html">[MUD-Dev] Re: Sockets and fibers</A></strong>,
Jo Dillon <a href="mailto:emily#thelonious,new.ox.ac.uk">emily#thelonious,new.ox.ac.uk</a>, Wed 20 Jan 1999, 17:26 GMT
</LI>
<LI><strong><A NAME="00227" HREF="msg00227.html">[MUD-Dev] Re: Sockets and fibers</A></strong>,
Adam J. Thornton <a href="mailto:adam#phoenix,Princeton.EDU">adam#phoenix,Princeton.EDU</a>, Wed 20 Jan 1999, 17:55 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00224" HREF="msg00224.html">[MUD-Dev] Graphic design doc</A></strong>,
Thinus Barnard <a href="mailto:thinus_barnard#bigfoot,com">thinus_barnard#bigfoot,com</a>, Wed 20 Jan 1999, 16:29 GMT
<LI><strong><A NAME="00220" HREF="msg00220.html">[MUD-Dev] ADMIN: List server and Kanga.Nu host changes</A></strong>,
J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Wed 20 Jan 1999, 05:31 GMT
<LI><strong><A NAME="00216" HREF="msg00216.html">[MUD-Dev] Matrix Game</A></strong>,
Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Mon 18 Jan 1999, 11:59 GMT
<LI><strong><A NAME="00214" HREF="msg00214.html">[MUD-Dev] Re: Reputations, More Mazes</A></strong>,
Eli Stevens (KiZurich) <a href="mailto:c718157#showme,missouri.edu">c718157#showme,missouri.edu</a>, Sun 17 Jan 1999, 09:26 GMT
<LI><strong><A NAME="00211" HREF="msg00211.html">[MUD-Dev] From Devmud: Database module, draft 3</A></strong>,
Greg Connor <a href="mailto:gconnor#nekodojo,org">gconnor#nekodojo,org</a>, Sun 17 Jan 1999, 02:35 GMT
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>