Switch to Russian



This is manual for the graphical version of DCSnake. But
most of applies to the text-mode version.

DosCore Snake 0.8 Manual
 About
    ___           _____               ____          __
   / _ \___  ___ / ___/__  _______   / __/__  ___ _/ /_____
  / // / _ \(_-(/ /__/ _ \/ __/ -_) _\ \/ _ \/ _ `/  '_/ -_)
 /____/\___/___/\___/\___/_/  \__/ /___/_//_/\_,_/_/\_\\__/
 _ _ _ _ _                             _ _ _ _ _ _ _ _ _ _
|_|_|_|_|_|   www.dcsnake.narod.ru    |_|_|_|_|_|_|_|_|_|_|
        |_|   Version: 0.9 _ _ _ _ _ _ _ _              |_|
        |_|_ _ _ _ _ _ _ _|_|_|_|_|_|_|_|_|  For MS-DOS |_|
        |_|_|_|_|_|_|_|_|_|_|An Ultimate|_|          _ _|_|
   _           _ _ _ _ _ _ _ _          |1|         |_|_|
  |_|         |_|_|_|_|_|_|_|_|_ _ _     _     _ _ _|_|
  |_|_ _ _ _ _|_|Multiplayer|_|_|_|2|   |P|   |3|_|_|_|
  |_|_|_|_|_|_|_|Battleworm Simulator

You should  carefully read  this file  to know  of  all  the
features of  the game  and to  be able to understand and use
them.

You can  jump over this history section, especially since it
is under development is not readable yet...
 History

HISTORY

The main  idea of  the game was derived from a very old Rus-
sian game "Russkaya zmayka" for Win 3.1. Once upon a time, I
lost this  excelent game.  Seven (or more) years later I de-
cided to write a similar one...

Handling the  snake's motion was quite easy to implement. At
each step the head of the snake moves in a certain direction
(defined by  the player)  and the  last snake's  cell (e. g.
it's tale)  is cleared so that the next to last cell becomes
last. Sometimes  (for example,  when the  snake runs  into a
wall) the head should not be moved, and sometimes (for exam-
ple, if the snake has eaten a prize) the tale doesn't shift.

To check  collisions with walls and other snakes I embeded a
two-dimensional array  whose elements  denoted the  contents
the correcponding  map cells. Now the handling of motion had
to include  the modification of map-array elements connected
to the motion of the snake, and collision checking.

But there  was a bigger problem: keyboard handling. In Turbo
Pascal I  knew the readkey procedure which returned the last
key in  the keyboard  buffer. Hence,  I couldn't check for a
key if  it is pressed. The keyboard buffer is like a single-
line where  you type and sometimes press backspace which de-
notes reading  a key  and deleteng  it from  the buffer.  My
friend Peter  proposed a  way to  use this function for con-
trolling the  snake. I  the procedure  responsible  for  the
snake's motion  I called this function once and then changed
the direction  accordingly tothe  read key.  If no  key  was
read, the  direction was  not changed.  This worked well. Of
course, to control a snake you didn't need to press keys for
a long  time. You  just needed to "type" the desired key for
it to be read by the readkey
function.

When testing the game on various computers I found that it's
text menu  is displayed  in different textmodes, so that the
splashscreen made  by Peter  for the  game didn't look as it
had been  conceived. To  fix this, I decided to display menu
in graph mode. For this purpose I created text functions for
graph mode  analogue to  those of  the CRT  unit  (for  text
mode). Fortunately,  the Graph  unit  had  a  procedure  for
printing a  character at  the desired  place on  the screen.
Usin this  procedure I created an analog of the CRT unit for
graph mode.  Since this  time the  game  have  become  fully
graphical.

A grandiose  epic was  our (with Peter) struggle anainst one
stubborn bug.  The bug  was the following: sometimes (mainly
when the  snakes were combatting at a close distance, trying
to envolve the enemy into their long bodies and, if that was
not a  success, to  make the  opponent lose some cells or at
least force  the enemy back to a bad position) near the head
of a  snake insted  of one  of it's  cells appeared  a black
cell, which  wasn't moving,  so it seemed that the snake was
crowling through  this black  cell. When  it finally creeped
throug it, nothing resembled about this strange cell. On the
place where  it had  appeared there were nothig. It was free
of obstacles.  Here I should note that as the strange cells,
the cells  noting free  space (the  game is 2d, so read free
plains) were also black.

Of course,  I turned  to the  source code,  namely -  to the
place where  snake moves  are performed. I examined the code
over and  over, but I didn't find a place where a cell which
wasn't the  tale was coloured black. Debugging was made even
harder due  to the  fact that  this bug  didn't like to show
himself very  frequently. You  could have  played for  10-15
minutes and  haven't seen  it. So,  after every chnge in the
code, I  spent a lot of time before the computer playing DC-
Snake for 20-60 minutes waiting for the bug. And every time,
sooner or  later, the  bug came  into view.  Several times I
thought I  had fixet it, but Peter or his companions at uni-
versity, found this bug.

Terrible as  it is,  it seemed  that my changes made the bug
come out more and more rarely, but not disappear!

When debugging  I didn't  make an effort to write good code,
highly readable  and optimal.  I just "piled up" expressions
on expressions,  yielding extremly  complicated logical  ex-
pressions, embranchments,  and  a  multitude  of  additional
variables, with names, not corresponding to their purpose.

One time  I made  an umpteeth chamge to one of the many com-
plicated logical  constructions, and,  as I always had done,
began playing.  I played for 30 minutes, than for an hour...
and there were no bug. For an umpteeth time I hoped that the
bug had  been finally  killed. I gave the new version to Pe-
ter, and  he distributed  it among the students of his group
at university.  For several  days there  were no  bugreports
concerning this bug. I breathed with relief.

But something  terrible happened.  I and  Peter were playing
DCSnake. Several  times we  went into  action with two bots.
The four  snakes got  entangled and coiled. And no bugs were
observed. We had already been playing for a quite long time,
when during  one of  such a  melee, two  snakes crossed! One
creeped through  another as  if it  had had  a hole  in it's
body! A  bit later  I understood:  i hadn't fixet the bug. I
had just hidden it. Now that empty clell had become colored,
but it was still empty. Oh no!

I examined  the whole game code trying to find a place where
a cell is colored but is left empty. And... I was unsuccess-
full!

Then I  decided to  automotiaze the debugging process. Peter
wrote a  procedure which,  for every  map cell,  checked the
following: if  the cell  was black  it swithced  to the next
cell, otherwise  it checked if the cell was empty. A colored
cell (not black) should never be empy, so if it turned to be
so, the  procedure paused  the game  and showed  the  broken
cell. Now,  to find  the bug,  a human  sisn't have  to con-
stently watch  the game.  You just needed to set the game to
the maximum  speed, let  bots play  for all  the snakes  and
wait. That is where Peter's Bot aided in game developing...

Now it  took 2-7 minutes to make sure the bug was alive. Now
I found that the broken cell always appeared on the place of
the first  body cell  of the  snake (next to the head). With
this powerful  bugtrapping instrument I continued the strug-
gle. I  was searching  the bug for about a week. Now I don't
remember if  I really  understood the  cause of  the bug and
what I  did to fix it, but I did something in the snake mov-
ing procedure and the bug finally disappeared.

Another fun  accident occured  when debugging  the Bot.  The
problem was  that the  initial bot  often algorythm made the
Bot to  get caught  in a  loop. Not a loop in the algorythm,
but a  trajectory loop.  The Bot crawled as if it had been a
train put  on a cycled railroad. His path was a closed line.
Peter designed an unnatural solution to this problem. In the
Bot code  there is  function which estimates how a given di-
rection is  good for  the next  move. And every time the Bot
calls this  function for  three cells:  the one  to the left
from the head, the one to the right, and the one in front of
the head.  The chosen  direction is  that for which he value
returned by the funtion is maximal. In order for the Bot not
to fall  is a  cycle Peter made the Bot to leave a tail area
behind the  snake's tail  - as  if the  snake was a slug and
left a  slime trail  behind itself. But that trail gradually
"evaporated" until the full disappearance. And the Bot algo-
rythm tried to choose a cell without that "footprint". Thus,
crawling in  a cycle would imply creepeng on "marked" cells,
but the  Bot now tried to avoid them. Evaporating rate could
be tuned.

But, for some reason, the Bot still was prone to cycling. To
debug it,  Peter decided  to draw  in each  map cell  on the
screen the  amount of  the "slime"  left by  the Bot. Now we
could observe  how the  Bot left  thaces and how they evapo-
rate. The  amount os  "slime" in  a cell  was denoted as the
height of the gray bar in it. No slime - no bar, a cell full
of slime  was whole  gray. The  colors of  snakes  were  not
drawn. So,  we just drew the slime map. When we launched the
game with  this built-in  debugger we  found that  the slime
trails were  not  correct.  But  there  was  something  much
stranger. From the snakes (on the slime map only their heads
could be  seen), controlled  by the Bot, gradually separated
two cells  seen due  to different amount of slime in them as
compared to the adjacent cells. And it seemed to us that the
two cells were moving on their own, independently of the AI-
controlled snakes. We got two ghosts on the screen! The pro-
gram no way could draw anything except the snakes. And there
were only  two snakes! We were amazingly watching the ghosts
roaming on  the screen  and remembering  fun bugs we had met
before. That  was definetly  the funniest.  How many  we had
seen, but a pair of ghost cells...

The explanation  was trivial.  I was disappointed when I un-
derstood. The  ghosts were the tails of the snakes. It was a
pity.

But one  day the time came to implement the two-player mode.
In every  cycle I  called my  motion procedure for the first
and the  second players. And initially I found that, strange
as it  may seem,  the game  worked, both the snakes could be
controlled by  the two  players. And  only in  extremly rare
cases I  felt that the key I had just pressed hadn't changed
the direction.  This might  be explained  by the  fact  that
sometimes I didn't fully press keys because a was hurrying.

At that time I was occupied by a more noticeable problem. It
was such  for me, a man who had played "Russkaya Zmeyka" for
win31. The  point was  that my game had a kind of unsymmetry
relative to  the players.  It the  situation  when  the  two
snakes were moving in the same direction and one of them was
just by the head ahead of the other, the leading snake might
turn towards  the other  snake so  that the former would run
into the  latter at  one stroke.  But this was possible only
when the  leading snake  was the first plaer's snake. Other-
wise, the  leading snake  couldn't do  this, it run into the
first snake and lost one cell.

After thinking  a while  I understood  how it  happened. The
fact was that my motion procedure moved the snakes in a cer-
tain order:  first, it  moved the  first player's  snake and
then the  second player's. That was the cause of he unsymme-
try. In the situation when the leading snake belonged to the
first player  it could  turn towards  the other snake becuse
it's move  was performed  first, but  in the  other case  it
couldn't because  by the  moment it  tried to turn the other
snake had already moved and the heads of the two snakes were
side by side.

A solution was found. It was in changing the snakemoving or-
der according  to who  is the  leading snake. But for this I
would need  to write  the code  which would  determine  such
"critical" situations where the order of snake moves matters
and, if  it does, correct it. But Peter proposed the follow-
ing method  of snake  moves order  correction. The order was
defined by  the order  of key  pressings of the players. Who
pressed a key first moved first. Who didn't press a key dur-
ing the  current cycle  had the  lowest priority  in moving.
This automatically  corrected all  unsymmetrical  situations
(except the one when the snakes collide head to head).

But this  method allowed chittering: in a critical situation
you could  disturb the  natural sneke  moves order  by  fre-
quently pressing  the key which corresponded to your current
direction (or  to the  opposite one). To fix it I decided to
check if  the pressed  key  changed  the  direction.  If  it
didn't, it  didn't participate  in the "competition" for the
snake moving order.

And at  that time only one key could be read during a cycle,
so, first  to move  in a  cycle was tha player who pressed a
key. Of two keys pressed in the same cycle was read the last
one. That  is why sometimes one noticed that his keys didn't
work. To  eliminate this problem I used a string variable to
store all the keys pressed in a cycle in the order thay were
pressed. If the string had twp or more keys bolonging to the
same player  I left  the last key. After that I could easily
derive the order of snake moves and new directions.

Another problem with keyboard handling was the following. As
I have  already said, of two control keys of the same player
pressed in the same cycle only the last was read. And if you
wanted to make a quick manuever, to turn around for example,
you had  to press yur keys exactly one per cycle, not having
missed one,  and not having pressed two keys in one. That is
quite hard.

Fast turning around:

 1       ***************************X       right


 2       ***************************        down
                                   X

 3                 ******************
                          X**********       left

I wanted  that it  was possible to press two or more keys in
one cycle in order for the keys to be read one after another
in the  current and followinf cycles, one key per cycle. For
this purpose  I created  a keyboard buffer, with the help of
wich key sequences for every player were stored and executed
in following cycles.

Thus, using  only the  readkey function  from the CRT unit I
made  a   comfortable  keyboard  handling  for  my  realtime
multiplayer game.  Now all  pressed keys  were read  without
fail.

In parallel  with this  work Peter  was working  on the  Map
Generetor and  on the Bot (Computer Control for snakes). The
map  generator   was  aimed  to  fill  the  game  area  with
obstacles, given the filling density. It was not a very hard
task for  a  primitive  generator.  However,  a  filled  map
dramatically changes  the gameplay,  as we  found  it  after
testing the Map Generator.

The Bot  was even  more important.  Here is what Peter tells
about it and it's development.
 REST




In the  beginning this  was a  simple snake game. But now it
have become the full featured and highly customizable multi-
player flatworm  simulator with  AI players, running prizes,
and more.

It is  the best  snake game  I have seen. And I say this not
because I  am the  author, but  because I  really  think  so
(however, it may be caused by my being the author ;). I made
a search  in the web and tried some snake games, and,  IMHO,
they all  turned to  be less  interesting than mine. What do
you think, the User?



SOME FEATURES:

1. Up  to 4 players can take part in the game. Up to four of
them can  be AI  controlled players (Bots). Now AI is at the
development stage,  so we  ask you to treat indulgently lots
of AI bugs and inform us of them.

2. The  game doesn't  come to the end if a snake runs into a
wall, another  snake, or  itself. In  this case  the snake's
head stops,  but it's  tail continues  moving, so  the snake
loses it's  sections, until  it's head  begins to move. If a
snake has lost all it's sections it dies.

3. Arbitrary map size can be set.

4. It  is possible  to edit  the map  using the  map  editor
(mapedita.exe) or  to automatically  create random maps with
the map generator.

5. You can set arbitrary game speed, the speed being device-
independent.

RUNNING TIPS

This is  a protected  mode application. To run in under DOS,
you should run cwsdpmi.exe first.
Make  sure  that  no  files  in  the  distributive  have  an
attribute read-only.

SETTINGS

After you run the game the following menu appears:

1. Start game
2. Number of players
3. Game speed
4. Bots settings
5. Map settings
6. Define keys
7. Other
8. Screen resolution
9. Quit

The item 9 do not require explanation.

1. Start game
After you  press '1'  the game  screen will  apear. But  the
snake(s) will  not move  until you  press any key (including
your control keys) to turn pause off. To turn pause on press
'p'.

2. Number of players. The total number of snakes taking part
in the game (including AI-controlled ones)

3. Game speed
This is the number of game steps per second. A step consists
of one move of each snake (by one cell).

4. Bots settings

4.1 Number of bots
If one  bot is  chosen it  will control the first snake. Two
bots -  the first  and the  second snakes.  In order to play
without bots set this parameter to 0.

5. Map settings

5.1. Density of the map
The more  this parameter is the more walls the map generator
generates. If  you don't  want the map generator to work set
this parameter  to 0.  If somebody have created a better map
generator let him send the algorithm to the authors.

5.2. Size of the map cells
Cells of which snakes consist are meant. In other words, the
more this  parameter the  less the  map. It  is  defined  in
pixels. Anyway The map is scaled to fit the screen.
This parameter can assume the following values:


  +-------------+--------------+-------------+
  | Resolution  |  Min. value  |  Max. value |
  +-------------+--------------+-------------+
  |  640x480    |      08      |     48      |
  +-------------+--------------+-------------+
  |  800x600    |      10      |     60      |
  +-------------+--------------+-------------+
  |  1024x768   |      13      |     76      |
  +-------------+--------------+-------------+


If after  you have  changed the  resolution and the map cell
size have  become incorrect it will be automatically changed
to a correct value.

7. Other

7.1. Double head prize.
The probability  of the  fact that  a prize  has double head
bonus in  it. When such a prize is eaten, the snake gains an
extra head  instead of the tale. And in this state the snake
can easily  switch the  leading head,  e.g. turn over. To do
this just press the key corresponding the direction opposite
to the  current snake's  direction.  In  tens  of  percents.
Allowed values: 0,1,2,..,10.

7.2. Double head steps
The number  of steps  which can  be passed  by a snake which
have eaten  a double  head prize  until it  becomes a normal
snake.

7.3 Vampire mode
If on,  in case  you have been hit by another snake you gain
as many sections as the snake, which hit you, loses.

7.4 Turn over prise.
The probability  of the  fact that if a snake eats the prise
all other snakes will turn over. In tens of percents.

7.5 Temporary immortality.
The probability  of the  fact that if a snake eats the prise
it will  become immortal.  If its  hits an obstacle, it will
not loose it's sections. In tens of percents.

7.6 Number of immortality steps.
Number of steps in the game before an immortal snake becomes
mortal.

7.7 Transparent walls.
If on,  when a  snake hits  a border  of the map its head is
teleported to  the opposite  border.  (Cycled  space).  This
drastically changes gameplay.

7.8 Keyboard buffering.
It's function  can be  explained in  the following  example.
Your snake  is crawling  left. To turn over you need to turn
up (or  down) and,  then, right.  You press  the keys up and
right very quckly. Without keyboard buffering, it may happen
that your  snake won't  do anything, because you pressed the
keys during  the same game step, and only the latest pressed
key will  be treated.  But (if  your  snake  is  not  double
headed) a  snake can not change direction to the opposite at
once. And,  nothing will  happen. Keyboard  buffering  fixes
this.

7.a Relative  control. [Under Development] When on the snake
is  controlled  only  by  two  keys:  left  and  right.  The
direction  is   defined  relative  to  the  snake's  current
direction.

8. Screen resoluton.
!!!New resolution  will be  applied after  you  restart  the
game. Do  not set a resolution other that 640x480 unless you
have troubles  with it. For example, if you have an LCD with
another native resolution.

Colors of snakes:
1. Magenta
2. Green
3. Red
4. Yellow

To know  the control  keys just  choose Define keys from the
main menu.  Here press  a number 1..4 to define the keys for
the corresponding player or 9 to exit this menu.

Default control keys:

     Left   Right  Up     Down
1:    a      d      w      s
2:    4      6      8      5 ----On the numeric keypad
3:    j      l      i      k     With NumLock ON
4:    f      h      t      g
If Running  Prize is off, the prize can be controlled by the
cursor keys and the key '/' puts a shield.

DURING THE GAME

'p' - pause on/off
Escape - finish the battle and return to the main menu.

USING THE MAP EDITOR

1. Run mapedita.exe

2. The map editor creates the map with the size which is set
in the  'Size of  the map  cell' in the game menu. So before
you create a map set the desirable size.

3. The cursor can be moved by keys 8, 4, 5, 6 of the numeric
keypad with numlock on.

4. The editor creates only vertical and horizontal walls. To
create a wall set the cursor where you want the beginning of
the wall to be, press 's', set the cursor where you want the
end of the weall to be and press 's' again.

5. To  enter the  delete mode  press 'd'.  The  cursor  will
become blue.  The process of deleting walls is equal to that
of creating walls in the drawing mode.

6. To clear the entire map press 'c'.

7. To save the map and exit press '0' (nil).

8. Do  not create  walls to  limit the screen area. They are
created automatically.

Be free to send us all questions, proposals, bug reports and
advices.

And I  will be  very glad  if you  send us  this manual with
corrected contents, grammar and spelling mistakes.

If you have an idea of the AI for this game consult with me.
I will  explain what  information AI  must receive  from the
game and  what information it must give the game. I can help
you with  realizing your  algorithm and  including it in the
game.

Any feedback will be appreciated.

Sorry, for  my English and for spelling mistakes. That is on
account of  my  symbol generator  which  sometimes  does not
support the required typematic delay.

Anton Shepelev.
22.01.05 0:50:37

Используются технологии uCoz