Joined: 18 Jan 2003
Location: New Zealand
|Posted: Tue Apr 15, 2003 4:04 am Post subject: How Dawn Works
|The code is modular to a certain degree, there is the core engine, then spells/skills etc all hook into this system.
In order to understand how to hook stuff in, it helps to understand how the core engine works (at a high level).
main() is located within comm.cpp, basically it boots up the mud loads in the environment (system files, realm etc) then enters game_loop().
The core of game_loop() runs 4 times per second and does the following:
- syncronise to a clock (to prevent it running more than 4 times per second)
- accept new TCP connections (people connecting)
- disconnect connections in an network error state
- process one queued command per player (unless speed walking, which does 2 movement commands - enabling speedwalkers to move 8 rooms per second instead of 4 if using manual directions)
- run update_handler() (more on this shortly)
- send all queued output for all connections
update_handler() is responsible for a lot of things including (but not limited to): ticks, wandering mobs, combat, affects, weather messages, aggie mobs, olc autosave and the mob queue system.
game_loop() processes user input in various ways depending on the type of connection and state the connection is in. When a connections state is something other than CON_PLAYING (which is the state for logged in players) all input is routed through nanny() in nanny.cpp. This handles creation and redirects dawnftp transactions.
If a player is fully logged, their connection state will be set to CON_PLAYING and all input is directed interpret() - the only exception being if they are in an olc editor, which means it is first handled by run_olc_editor().
interpret() parses the user input using the cmd_table table to determine which command a player is trying to use (you can see this table in interp.cpp starting about 65 lines down).
For example the first command in the cmd_table is "north"... so interp matchs this with the user input and the player has access to that command, the command function will be executed - do_north() in this case. A number of attributes for entries in cmd_table are dynamically populated in at bootup and can be edited using "comedit".
Nearly all commands run via interpret() are prefixed with "do_"... this is part of the coding style, not something that is enforced by a compiler.
The "do_" functions are then stored in various files in the source, depending on the type of commands... for example the act_*.cpp files, store a number of do_ functions, act_obj.cpp typically stores do_ functions that manipulate objects. act_wiz*.cpp are generally immortal commands.
magic.cpp, contains do_cast() (and its variants) redirect to do_newcast()... which is the core of the magic system. do_newcast looks up spells from within skill_table and runs the spell function a simular was that commands are located in cmd_table. skill_table is dynamically created at bootup and can be edited using sedit.
An example may make things clearer..
Lets take what is involved to cast the spell acid blast...(contained in the function spell_acid_blast().
Lets assume a player is already connected, and logged in and has the spell etc.
The player types "cast 'acid blast' target", game_loop() recognises that there is input waiting from the player connection, it redirects the input to interpret() which finds there is a cast command... it then executes the function for this command - do_cast(). do_cast() redirects to do_newcast() which searchs skill_table for a spell called "acid blast", after finding it and confirming it has a spell function set, it then executes the spell function (Which is called spell_acid_blast() in this case), and that function does what it is supposed to do.
Some other files in the source, some a pretty obvious:
include.h - the main include file for the entire game.
macros.h - a LOT of compiler macros used to save time.
params.h - a LOT of hard coded limits and parameters are defined in here - have a look.
structs.h - almost all of the data structures used in the game.
prototyp.h - function prototypes
chardata.h - the definition of the char_data class.
chardata.cpp - the implementation of the char_data class.
act_move.cpp - functions to move players around (e.g. do_north()).
*edit.cpp - olc editors e.g. aedit.cpp, comedit.cpp.
colour.* - the colour system
dynamics.* and dyntable.* - the core of code enabling classes and skills to stored in text files.
fight.cpp, duel.cpp - combat system and related code.
ftp.cpp - dawnftp/mudftp implementation
gio.cpp - the generic IO system - this is the heart of most of the muds input and output.
magic*.* contains all the spells
global.h - global variables are defined in here using the "EXTERN" macro... this macro is rewritten into "extern" in every file within the source code other than global.cpp. In global.cpp it is renamed to "" so therefore the variable is defined to be 'physically' stored in global.cpp.
gsn.h - global skill/spell numbers
handler.cpp - a heap of utility functions
hreboot.* - the hotreboot system
intro.* - the introduction system
language.* - the language system
mob_*.* - the mobprog engine and systems.
msp.* - core msp libraries
websvr.cpp - the integrated webserver implementation
mud2web.cpp - support functions bridging websvr.cpp into the mud
mob_q.cpp - the mobprog queuing system.
mount.cpp - horse riding anyone?
mxp.*- mxp library functions
namegen.* the name generated accessed in creation
nanny.cpp - handles non playing connections
network.cpp - operating system specific low level network code
noble.cpp - the noble system
note.cpp - the notes system
offmoot.cpp - offline mooting
pipe.cpp - popen() and system() based commands. e.g. checklog, pipe.
mem.cpp and recycle.cpp - memory management system
resolve.* - dns resolver and ident related code
save.cpp - this file saves pfiles
socials.cpp - the socials system
special.* - mob specials
support.* - commands originally used by the dawn support council
tables.* - a LOT of lookup tables - have a look.
textsrch.* - the text search system
tokens.* - the token system used by mobprogs
track.* - the tracking system
trap.* - traps perhaps?
update.cpp - update_handler() and many functions it calls
who.cpp - the core of the who engine
whofmt.cpp - various display formats for different muds.
wizlist.cpp - dynamic wizlisdt.
In terms of starting out, I suggest adding a spell or two... that is probably the easiest thing to start with. Work with little things, get them reliable, then get more involved.