TEXT   27

liquidwar source

Guest on 17th August 2022 02:12:02 PM

  1. Liquid War (v5.6.4) - Source code
  2.  
  3. General remarks
  4. ===============
  5.  
  6.  
  7.   Modularity
  8.   ----------
  9.  
  10.     Liquid War 5 is basically a big C program. I've splitted the source code in
  11.     many small files for I do not like to have to handle big monolithic
  12.     sources, but this does not mean Liquid War is very modular. In fact Liquid
  13.     War 5 is quite bloated with global variables and other ugly stuff 8-(
  14.  
  15.   Coding style
  16.   ------------
  17.  
  18.     To be honest, it's a big mess. You won't find 2 files coded in the same
  19.     maner... OK, I'm exagerating a bit. From now I try to make an effort and
  20.     stick to basic rules such as:
  21.  
  22.     * use the GNUish-style indentation - the default Emacs mode in fact
  23.  
  24.     * prefix global functions / variables / constants / types with
  25.       lw_<NAME_OF_THE_file>_. For instance, a "do_it" function in myfile.c will
  26.       be called lw_myfile_do_it
  27.  
  28.     * use capitals for constants, globals and types only. All functions are in
  29.       lowercase with "_" to separate words
  30.  
  31.     * keep on using 8.3 filenames for .c source files. This is for better DOS
  32.       integration. DOS version of Liquid War is still maintained, you know 8-)
  33.  
  34.     * use English only for code and comments
  35.  
  36.     I might decide to rename and cleanup everything some day, for it would help
  37.     other coders to understand what I wrote, but well, this is certainly not a
  38.     thrilling task 8-/
  39.  
  40.  
  41.  
  42. Source files organization
  43. =========================
  44.  
  45.  
  46.   Main game code
  47.   --------------
  48.  
  49.     Here you'll find the main() function, the main game loop, application-wide
  50.     constants and other global stuff.
  51.  
  52.     It might be a good start if you want to hack the code.
  53.  
  54.     * base.h: contains global constants used in many different files.
  55.  
  56.     * game.c / game.h: contains the main game loop.
  57.  
  58.     * main.c / main.h: the file where the main C function is declared. Doesn't
  59.       contain much except calling init functions and running the GUI.
  60.  
  61.   Menus
  62.   -----
  63.  
  64.     The menus are coded using the Allegro GUI system. While this system is very
  65.     powerfull, it's IMHO not adapted to very complex GUIs, and one of its
  66.     drawbacks is that it's not so easy to redesign something once you've coded
  67.     it.
  68.  
  69.     Besides, when I started coding the GUI in 1998, I did it in a rather ugly
  70.     way, and now I'm paying for my being lazy at that time, since I spent hours
  71.     coding when I want to change something 8-/
  72.  
  73.     * about.c / about.h: contains the code for the about menu.
  74.  
  75.     * advanced.c / advanced.h: contains the GUI advanced options menu.
  76.  
  77.     * connect.c / connect.h: contains code for the "connect" menu which
  78.       displays which players are connected to the server, before the game
  79.       actually starts.
  80.  
  81.     * controls.c / controls.h: contains the code for the controls menu.
  82.  
  83.     * graphics.c / graphics.h: code for the graphic options menu.
  84.  
  85.     * internet.c / internet.h: contains the code for the "Search for Internet
  86.       games" menu, where one can pick up a running server automatically with
  87.       the help of the meta-server.
  88.  
  89.     * language.c / language.h: contains the code for the "Language" menu.
  90.  
  91.     * level.c / level.h: contains code for the menu where the player can select
  92.       a level and its options (texture or color).
  93.  
  94.     * menu.c / menu.h: contains the code for the main menu.
  95.  
  96.     * netgame.c / netgame.h: contains the code for the net game menu.
  97.  
  98.     * options.c / options.h: contains the code for the options menu.
  99.  
  100.     * play.c / play.h: contains the code which ties the menu to the main
  101.       gameloop.
  102.  
  103.     * rules.c / rules.h: code for the rules menu.
  104.  
  105.     * score.c / score.h: functions to display the scores at the end of the
  106.       game.
  107.  
  108.     * speeds.c / speeds.h: contains the code for the speeds menu.
  109.  
  110.     * team.c / team.h: code for the team menu, where one choses which teams
  111.       will play.
  112.  
  113.     * volume.c / volume.h: code for the sound menu.
  114.  
  115.     * wave.c / wave.h: code for the wave menu.
  116.  
  117.   GUI tools
  118.   ---------
  119.  
  120.     These files contain various utilities which are used in the menus.
  121.  
  122.     * alleg2.c / alleg2.h: contains some tweaked allegro functions. I wanted to
  123.       use bitmaps with sevral colors for my fonts, and change some of the
  124.       allegro default behavior. So rather than modifying the allegro source
  125.       code right in the library I copied it in this file and then modified it.
  126.  
  127.     * back.c / back.h: this modules displays the background image.
  128.  
  129.     * dialog.c / dialog.h: contains code for standard dialog boxes.
  130.  
  131.     * error.c / error.h: contains functions to display error messages once the
  132.       game is in graphical mode.
  133.  
  134.     * help.c / help.h: generic functions to display the various help pages.
  135.  
  136.   Core algorithm
  137.   --------------
  138.  
  139.     Here's *the* interesting part. All the rest of the code is just sugar coat
  140.     to display stuff, receive players commands, communicate with other
  141.     computers, handle errors, etc... But the real thing is here!
  142.  
  143.     It's funny to note that these files have almost not been modified since
  144.     Liquid War 5.0.
  145.  
  146.     It's also interesting to note that they represent a small percentage of the
  147.     total amount of code in the game. This tends to prove - and I'm convinced
  148.     of it - that game programming does not only consists in having great ideas,
  149.     but also requires a lot of "dirty" and boring work. Honestly, coding an
  150.     option menu is as boring as coding Liquid War algorithm is fun.
  151.  
  152.     * fighter.c / fighter.h: contains code to move the armies, once the
  153.       gradient has been calculated.
  154.  
  155.     * grad.c / grad.h: this module calculates the gradient for each team. One
  156.       could say it's the "kernel" of the game, since most of the CPU time is
  157.       spent in this module (except if you have a slow display...).
  158.  
  159.     * mesh.c / mesh.h: contains code to set up a usable mesh with a map. Mesh
  160.       are re-calculated at each time a new game is started, the reason for this
  161.       being that meshes are *very* big so it would not be reasonnable to save
  162.       them directly on the HD.
  163.  
  164.     * monster.s / monster.h: assembly functions to speed-up the game. It's a
  165.       replacement for some fighter.c functions.
  166.  
  167.     * spread.s / spread.h: contains assembly replacements for some functions of
  168.       grad.c. These replacements do the same than the original ones from
  169.       grad.c, but faster. Could still be optimized.
  170.  
  171.   Moving cursors
  172.   --------------
  173.  
  174.     It looks like nothing, but moving a cursor and deciding where it should go
  175.     if there's a wall in front of it is not that easy, especially if you want
  176.     things to work nicely.
  177.  
  178.     * autoplay.c / autoplay.h: contains the code for the computer AI. This
  179.       module simulates keypresses from the computer, then the computer is
  180.       handled as any other player.
  181.  
  182.     * move.c / move.h: provides an API to move the cursors.
  183.  
  184.   User input
  185.   ----------
  186.  
  187.     Until 5.4.0, Liquid War did not have network support. As it is designed to
  188.     be multiplayer, one needed to have several players on the same computer.
  189.     The mouse also needed to be handled in a special way since cursors can
  190.     *not* pass walls in Liquid War. Additionnally, I wanted all input channels
  191.     (keyboard mouse and joystick) to be handled in a unified way.
  192.  
  193.     This explains why there's so much code for user input, when one would think
  194.     at first sight that "polling the keyboard is enough".
  195.  
  196.     * joystick.c / joystick.h: contains code to support joystick input. It
  197.       wraps joystick buttons to virtual keyboard keys, so that joystick and
  198.       keyboard behave exactly the same.
  199.  
  200.     * keyboard.c / keyboard.h: contains code to handle key presses.
  201.  
  202.     * mouse.c / mouse.h: wraps the mouse movements to virtual keyboard keys.
  203.       This way the mouse can be used to control the players.
  204.  
  205.   Initialisations
  206.   ---------------
  207.  
  208.     These files contain functions to intialize various game components. 100%
  209.     boring code.
  210.  
  211.     * area.c / area.h: contains functions to create the game area. Basically it
  212.       contains functions to create the data structures in which the level is
  213.       stored during the game.
  214.  
  215.     * army.c / army.h: functions to create the armies, and place them on the
  216.       battlefield.
  217.  
  218.     * asm.c / asm.h: various constants, macros and utilities to ensure that
  219.       asembly code works correctly.
  220.  
  221.     * bigdata.c / bigdata.h: I had a really hard time with the malloc function
  222.       with DJGPP under Win95 dos box. I tried to have it working for hours and
  223.       hours but my program kept being buggy. So I decided to allocate the
  224.       memory myself, in a memory zone I create at startup. This is what this
  225.       module does: create a huge memory zone and then give parts of it to the
  226.       rest of the program.
  227.  
  228.     * config.c / config.h: contains everything that is related to the game
  229.       configuration. This module contains in global variables all the
  230.       parameters that are stored in the config file.
  231.  
  232.     * cursor.c / cursor.h: contains the code to init the cursors and place them
  233.       on the battlefield at the beginning of the game.
  234.  
  235.     * decal.c / decal.h: This module makes the link between teams and players.
  236.       Its coding is quite ugly, for some modules in LW assume that when 2 teams
  237.       are playing they are always teams 0 and 1. So when 3 teams are playing
  238.       are playing and the second team loses, one has to make team 2 become team
  239.       1. That's what this module is for.
  240.  
  241.     * exit.c / exit.h: contains code that is executed when the game ends, it
  242.       shuts down Allegro and displays messages on the console.
  243.  
  244.     * gfxmode.c / gfxmode.h: contains code to set up the various video modes,
  245.       and defines which modes are available for each platform.
  246.  
  247.     * init.c / init.h: contains code to initialize Allegro with proper options
  248.       and analyze failures.
  249.  
  250.     * palette.c / palette.h: contains function to set up the current color
  251.       palette. Liquid War uses different palettes, depending on what colors are
  252.       chosen for teams.
  253.  
  254.   Graphics
  255.   --------
  256.  
  257.     Here lies most of the graphic functions in Liquid War. There's not that
  258.     much code since Liquid War's strength is not its visual effects, but rather
  259.     its gameplay.
  260.  
  261.     The only "funny" thing is the wave effect. I'm quite happy with it, and
  262.     honestly, I do think it is rather fast, given the fact that it uses no 3D
  263.     hardware at all.
  264.  
  265.     * disp.c / disp.h: contains functions to display the battlefield.
  266.  
  267.     * distor.c / distor.h: this module contains code to create the "wave
  268.       effect". It uses a lot of data tables, and is quite complicated to
  269.       understand...
  270.  
  271.     * glouglou.s / glouglou.h: assembly module, it is a replacement for some
  272.       functions of distor.c. It goes much faster but does the same.
  273.  
  274.     * info.c / info.h: contains code to display the info bar. The info bar is
  275.       the bar which display the time left and the amount of players for each
  276.       team while the game is running.
  277.  
  278.     * message.c / message.h: provides an API to display messages during the
  279.       game. Very useful if you want to debug the game: you can trace and
  280.       display anything.
  281.  
  282.     * pion.c / pion.h: contains code to display the cursors.
  283.  
  284.     * viewport.c / vieport.h: code to allocate and resize the zone where the
  285.       map is displayed, also called "viewport".
  286.  
  287.   Sound and music
  288.   ---------------
  289.  
  290.     Sound and music routines required some encapsulation, since the game must
  291.     be able to run even if the sound and/or music did not load correctly.
  292.  
  293.     * music.c / music.h: contains the code to control MIDI playback.
  294.  
  295.     * sound.c / sound.h: functions to play sound.
  296.  
  297.   Data management
  298.   ---------------
  299.  
  300.     These functions handle the datafile contents and also the custom data.
  301.  
  302.     Note that the various utilities such as liquidwarcol, liquidwarmap and
  303.     liquidwartex do not share code with the main executable. This is obviously
  304.     a design error, for liquidwarmap will handle maps in a very poor way and is
  305.     unable to autodetect map errors, whereas the game does it rather well.
  306.     Blame the programmer.
  307.  
  308.     * disk.c / disk.h: contains all the code to access data from the hard
  309.       drive. In fact, all the HD access is done at startup.
  310.  
  311.     * map.c / map.h: contains code to load the maps from a datafile raw data or
  312.       a user defined bitmap to a usable structure in RAM.
  313.  
  314.     * maptex.c / maptex.h: contains code to handle the "use default texture"
  315.       option, and associate a map with a given texture automatically.
  316.  
  317.     * texture.c / texture.h: contains code to handle textures. Textures are
  318.       stored in a special format which uses 5 bits per pixel.
  319.  
  320.   Random map generator
  321.   --------------------
  322.  
  323.     Liquid War has a "generate random map" feature which is available within
  324.     the game and also as an external program. The source code for the external
  325.     program is in ./utils/lwmapgen in Liquid War source distribution. This
  326.     program has been coded by David Redick, is also available on
  327.     http://www.cs.clemson.edu/~dredick/lwmapgen/ and works on GNU/Linux.
  328.     Compiling this program under DOS and/or Windows is untested and
  329.     unsupported.
  330.  
  331.     The random map generator within Liquid War - which of course works on any
  332.     platform support by LW - uses for its greater part the same source code as
  333.     the external lwmapgen program.
  334.  
  335.     * random.c / random.h: wrapper for the map generator written by David
  336.       Redick. It basically does the same as ./utils/lwmapgen/main.c except that
  337.       it does it within Liquid War as it is running and not in an external
  338.       independant program.
  339.  
  340.   Time handling
  341.   -------------
  342.  
  343.     Time handling is fundamental in a game. Time is used for visual effects
  344.     (waves...) during the game, it's used to generate some pseudo random stuff,
  345.     well, it's used everywhere!
  346.  
  347.     Note that on the client, I use 2 "different" clocks. The first counts the
  348.     "real" time, in seconds. The second one is counts "rounds" and is
  349.     incremented by 1 at each game round.
  350.  
  351.     * srvtime.c / srvtime.h: code used to handle time on the server, where
  352.       Allegro's functions are not available.
  353.  
  354.     * ticker.c / ticker.h: sets up a timer callback.
  355.  
  356.     * time.c / time.h: functions to know how long the game has been running,
  357.       knowing that it can be interrupted.
  358.  
  359.   In-game utilities
  360.   -----------------
  361.  
  362.     These are various utilities use to monitor and control the game while one's
  363.     playing.
  364.  
  365.     * capture.c / capture.h: code used to capture the video output of the game
  366.       and store it in .bmp files while playing.
  367.  
  368.     * checksum.c / checksum.h: utilities to generate a checksum from a given
  369.       game state. Used in network code to make sure all the clients stay
  370.       synchronized.
  371.  
  372.     * code.c / code.h: This file contains the code to handle key presses during
  373.       the game. That's to say the pause key for instance.
  374.  
  375.     * profile.c / profile.h: provides tools to calculate how fast the game is
  376.       runnning and what operations slow it down.
  377.  
  378.     * watchdog.c / watchdog.h: this module waits for "secret codes" to be typed
  379.       while the game is running, and traps them.
  380.  
  381.   Command line handling
  382.   ---------------------
  383.  
  384.     OK, now to all the UNIX guys, I *know* there are many ways to do things in
  385.     a better and simple way than I did. But keep in mind that in 1998, under
  386.     DOS, I had a rotten command line and even now I need everything to work on
  387.     both UNIX and Microsoft platforms.
  388.  
  389.     These utilities are not perfect, but they work, that's all I ask them.
  390.  
  391.     * basicopt.c / basicopt.h: handles basic command line parameters such as
  392.       "-v" or "-h".
  393.  
  394.     * parser.c / parser.h: contains code to parse and analyze the command line
  395.       parameters.
  396.  
  397.     * startup.c / startup.h: analyzes the command line parameters and stores
  398.       them into global variables.
  399.  
  400.   Locale support
  401.   --------------
  402.  
  403.     Liquid War now has locale support. Basically, all the labels and texts in
  404.     the UI are stored in constants. There's simply file per language.
  405.  
  406.     Note to translators: if you decide to translate the menus in another
  407.     language, keep in mind that all the translations must fit in the various
  408.     buttons and textboxes. The best resolution to test this - the one where
  409.     letters take most place - is 640x480.
  410.  
  411.     * lang.c / lang.h: contains code to handle language dependant stuff.
  412.  
  413.     * langen.c / langen.h: contains code to handle English specific stuff.
  414.  
  415.     * langfr.c / langfr.h: contains code to handle French specific stuff.
  416.  
  417.   Log and various messages
  418.   ------------------------
  419.  
  420.     OK, the API of the log routines is a piece of crap. Now I'm simply too lazy
  421.     to change it. It works, that's all I ask.
  422.  
  423.     BTW, there's a clear advantage in using custom-made log functions instead
  424.     of plain calls to "fprintf(stderr,...". It might not be obvious for UNIX
  425.     users, but think about Windows. Nothing like a "tail -f" there, nor a
  426.     proper output redirection system. When a user clicks on the Liquid War
  427.     icon, I want "console" information to be logged in a file!
  428.  
  429.     * log.h: common header for logcli.c and logsrv.c.
  430.  
  431.     * logcli.c: contains code to display messages on the console. It's usefull
  432.       for console may have different behaviors when the games is used on
  433.       different platforms. This file is used to compile the client.
  434.  
  435.     * logsrv.c: contains code to display messages on the console. This file is
  436.       used to compile the server, which does not use Allegro at all.
  437.  
  438.     * popupgen.h: common header for popup functions.
  439.  
  440.     * popupw32.c: code to handle popup on the Win32 platform. Popups are a
  441.       must-have under Windows for error diagnostics, since the average Windows
  442.       user never gives any look at any log file...
  443.  
  444.   Macros, utilities and string support
  445.   ------------------------------------
  446.  
  447.     As usual, I needed to prepare a small set of usefull macros.
  448.  
  449.     * macro.h: contains basic wrappers/macros for snprintf like functions. This
  450.       mostly to ease up string manipulation which is - as always - a nightmare
  451.       in standard C.
  452.  
  453.     * path.c / path.h: code used to handle filenames and paths, for instance
  454.       remove path and file extension from a filename.
  455.  
  456.     It's also important to note that Liquid War uses snprintf instead of
  457.     sprintf, for using the latter is very likely to cause buffer overflows.
  458.     Under Linux glibc provides this function but Microsoft does not provide it
  459.     natively on Windows. Therefore I used a third party snprintf implementation
  460.     by Mark Martinec: http://www.ijs.si/software/snprintf/ and its source is
  461.     available in the ./utils directory of Liquid War source distribution.
  462.  
  463.   Byte order and endianess
  464.   ------------------------
  465.  
  466.     As you might know, PC Intel based computers are "little-endian" while Sun
  467.     Sparc stations and Mac computers are "big-endian". This is an issue for LW
  468.     since in network games maps are transmitted in binary format. Therefore I
  469.     needed to set up some (un)serialization fonctions.
  470.  
  471.     * serial.c / serial.h: code used to transform integers and map headers into
  472.       an uniform cross-platform byte stream which is readable by both little
  473.       and big endian machines.
  474.  
  475.   Thread support
  476.   --------------
  477.  
  478.     Liquid War does have thread support, but it is a "limited" thread support.
  479.     I mean that the game is generally monothreaded, but a few functions use
  480.     threads. For instance, calls to the meta-server are done within threads.
  481.  
  482.     Basically, I do not really enjoy programming in a multithreaded
  483.     environnement. So when possible, I chose the monothread path, and used
  484.     threads only where I simply would not be able to find another acceptable
  485.     solution.
  486.  
  487.     I also needed to use some mutexes to prevent crashes in the user interface.
  488.  
  489.     * mutxdos.c: provides fake mutex support under DOS. This module is here
  490.       only to make compilation easier.
  491.  
  492.     * mutxgen.h: header for mutxdos.c, mutxunix.c and mutxw32.c.
  493.  
  494.     * mutxunix.c: provides mutex support on UNIX.
  495.  
  496.     * mutxw32.c: provides mutex support on Win32.
  497.  
  498.     * thrddos.c: provides fake thread support under DOS. This module is here
  499.       only to make compilation easier.
  500.  
  501.     * thrdgen.h: header for thrddos.c, thrdunix.c and thrdw32.c.
  502.  
  503.     * thrdunix.c: provides thread support on UNIX.
  504.  
  505.     * thrdw32.c: provides thread support on Win32.
  506.  
  507.   Launching external programs
  508.   ---------------------------
  509.  
  510.     Liquid War might sometimes launch external programs. This is (for security
  511.     reason) not a default behavior and has to be activated and configured by
  512.     yourself, using the "-callback" command line option on the server for
  513.     instance.
  514.  
  515.     * execgen.h: header for execunix.c and execw32.c.
  516.  
  517.     * execunix.c: code to launch external programs on UNIX.
  518.  
  519.     * execw32.c: code to launch external programs on Win32.
  520.  
  521.     * exec2.c: code to launch external programs within the client, without any
  522.       interaction with the user, ie no unwanted popping window for instance.
  523.  
  524.   Low-level network code
  525.   ----------------------
  526.  
  527.     There are network packages for Allegro, but I decided not to use them.
  528.     Socket support is not that hard to implement under UNIX and Win32 and
  529.     besides, I've done it for my job recently, so I just knew how to do it.
  530.  
  531.     Another reason which decided me to code my own toolbox is that I did not
  532.     want Liquid War to have external dependencies - except Allegro of course.
  533.     This way, UNIX gamers to not have to set up and/or download a specific
  534.     network library. It's also easier to integrate the game in projects like
  535.     Debian if it has few dependencies.
  536.  
  537.     This network code is not a masterpiece, it's just a little set of tools
  538.     that have proven to work. That's all.
  539.  
  540.     BTW, it's important to notice that when linking with Allegro, most blocking
  541.     UNIX calls ("sleep" or "recv" for instance) stop working: they alwasys
  542.     return immediately. This led me to implement weird ugly hacks, like calling
  543.     "recv" in a loop until it gets what it wants... This is theorically and
  544.     practically a performance killer, but I found no other way to fix this. And
  545.     FYI, this is not an Allegro bug, it's a feature 8-)
  546.  
  547.     * dnsutil.c / dnsutil.h: wrapper code to issue DNS requests, without having
  548.       to handle the hostent struct.
  549.  
  550.     * sock2cli.c: sode used to wrap low-level network function on the client.
  551.  
  552.     * sock2gen.h: header for sock2cli.c and sock2srv.c.
  553.  
  554.     * sock2srv.c: code used to wrap low-level network function on the server.
  555.  
  556.     * sockdos.c: network API for DOS.
  557.  
  558.     * sockex.c: netowrk routines shared by sockunix and sockw32.
  559.  
  560.     * sockgen.h: header for sockdos.c, sockunix.c and sockw32.c.
  561.  
  562.     * sockunix.c: network API for UNIX.
  563.  
  564.     * sockw32.c: network API for Win32.
  565.  
  566.   High-level network code
  567.   -----------------------
  568.  
  569.     These files contains network utilities which are Liquid War specific.
  570.  
  571.     * chat.c / chat.h: functions used to handle chat messages in network games.
  572.  
  573.     * keyexch.c / keyexch.h: functions to send and receive keys to the server.
  574.       Used on the client.
  575.  
  576.     * netconf.c / netconf.h: code to send and receive the config of the clients
  577.       over the network.
  578.  
  579.     * netkey.c / netkey.h: contains some tools to manipulate key strokes over
  580.       the network.
  581.  
  582.     * netmap.c / netmap.h: code to send and receive the maps over the network.
  583.  
  584.     * netmess.c / netmess.h: contains a parser to interpret plain text
  585.       messages. Used when exhanging information over the network.
  586.  
  587.     * netplay.c / netplay.h: contains the code to set up and start network
  588.       games.
  589.  
  590.     * network.c / network.h: contains some network related functions and
  591.       constants used on the client.
  592.  
  593.     * ping.c / ping.h: code used on the client to estimate the average ping
  594.       time with a server.
  595.  
  596.     * protocol.c / protocol.h: contains the sequence of messages send and
  597.       recevied by the client when connecting on the server.
  598.  
  599.     * startinf.c / startinf.h: contains struct and tools to handle some network
  600.       informations while starting a network game.
  601.  
  602.   Communication with the meta-server
  603.   ----------------------------------
  604.  
  605.     The meta-server is called by both client and server. Basically, the server
  606.     registers itself, and the client asks for a list of servers.
  607.  
  608.     The meta-server itself is just a set of simple PHP scripts with a simple
  609.     MySQL database. I chose PHP because my provider allows execution of PHP
  610.     pages, that's all.
  611.  
  612.     The protocol is *very* basic, and uses HTTP 1.0 for requests. Answers are
  613.     received in plain text, with one information per line. There's no garantee
  614.     that this would work with any HTTP server, but experience proved that it
  615.     works with my provider 8-)
  616.  
  617.     * httputil.c / httputil.h: low level functions to handle http requests.
  618.  
  619.     * wwwcli.c / wwwcli.h: code used on the client to communicate with the
  620.       meta-server.
  621.  
  622.     * wwwsrv.c / wwwsrv.h: code used on the server to communicate with the
  623.       meta-server.
  624.  
  625.   Server code
  626.   -----------
  627.  
  628.     The Liquid War server is a rather small program. The only thing it does is
  629.     accept new players, transmit map and game parameters between them, and then
  630.     "replicate keys".
  631.  
  632.     By "replicate keys" I mean that the server asks each client what keys have
  633.     been pressed during the last round, and then dispatches this informations
  634.     to all clients. This implies that the server has absolutely no idea of
  635.     who's loosing, who's winning, etc...
  636.  
  637.     All the "logic" of the server is coded in these files, the rest is only
  638.     utilities and helper functions.
  639.  
  640.     * server.c / server.h: main code for the server (equivalent of main.c for
  641.       the client).
  642.  
  643.     * srvchan.c / srvchan.h: code used to handles channels on the server. A
  644.       channel is associated to a given computer and may manage several teams.
  645.  
  646.     * srvcont.c / srvcont.h: global network controler used on the server.
  647.  
  648.     * srvteam.c / srvteam.h: code used to handle teams on the server.

Raw Paste


Login or Register to edit or fork this paste. It's free.