ARENABALL (v 0.2.0)

INTRODUCTION:
We congratulate you on (and apologize in advance for) your download of the latest
Arenaball source code. We hope you have fun (and wish you luck).

REQUIREMENTS:
The latest version of SDL must be downloaded from www.libsdl.org, and
depending on where it gets installed, the simlink might need to be altered
to point to the location of the SDL/ headers folder (currently points to
/usr/include/SDL/ ). This program also requires an X session to be running,
and that the bitmap files are located in the same location as the executable,
as well as a game script file currently unimaginatively named "arenaballscript".
Once the tarball has been unzipped ("tar -xvzf arenaball.tar.gz"), change into the
directory, run make, then run "./arenaball". That should do it. If it doesn't, as
with any instruction that's given here, please email "wrinkledshirt@hotmail.com"
with your complaints.

DIRECTIONS:
At the moment, you are the red player with the red square at his feet.
The player's direction is controlled using the keypad (5 does nothing). Running
over the ball causes the player to gather it up. The left control key throws it.
The left shift key is used to tackle, and you can tackle a player while running
(like you're giving him a straight-arm, no special animation yet...). If you score,
a big ugly "Scored!" graphic shows up (but only in the top left corner of the
screen, will fix later) and the players are reset to their starting positions. To
see the score as the game develops, you must run the game from within a console,
as text has yet to be implemented (part of the reason for the big ugly "Scored!"
graphic).

The Esc key quits the game, and if left alone, the game will terminate after
a hard-coded time runs out. The x key will create a "screenshot.bmp" file in
the game's directory. This screenshot will be overwritten if you press x again.

SCRIPTED SETTINGS
The game is being moved towards a separation of data initialization and
game engine mechanics. Hopefully this will allow all data to be controlled
and set via a script file. Currently, this script file is "arenaballscript"
and is located in the game's main directory.
The script file works on the following rules:
A line must start with an appropriate heading, and be followed with a
"follow-up" line containing the relevent data that goes with the heading.
Currently, acceptable headings are PLAYER, BALL, SCORED, BACKGROUND, and
DELAY. As the game evolves a cleaner implementation will be put in effect
(with default values to handle any errors or omissions). Any graphics files
must be bitmap file (.bmp) and must have the ".bmp" extension. Right now,
the game needs to have the BACKGROUND graphic first as settings colors
for the game is also done with this initialization.
	PLAYER:
Information must be entered in the following order, separated by a single
space: standing graphic, running graphic, throwing graphic, falling graphic,
player's number, player's team, power, speed, endurance and aggressiveness
ratings.
	BALL:
The ball graphic.
	BACKGROUND:
The background graphic
	SCORED:
The ugly scored graphic
	DELAY:
The amount of delay in milliseconds between frames. Do not take this as
an accurate FPS rating, as this amount of time is inserted after all rendering
takes place, which is steadily growing.
A line that starts with '#' is ignored, unless the game has just read a heading
and is looking for the "follow-up" line in which case if there's one there, the
game will likely crash.
	DEFAULTX, DEFAULTY, DEFENSEX, DEFENSEY, OFFENSEX, OFFENSEY
These are the x and y coordinates for the default, defense and offense coordinates
that a player will go to after play has been started (or restarted), a team has
gone on defense, or a team has gone on offense respectively. They are done completely
from the point of view of the home team, and the away team's settings are mirrored
automatically in the script reading engine. Play with these if you want, although
they're set up to reflect approximately where players should run to. If ball changes
possession, the offense and defense coordinates are checked in automatically and
the player will run to his position if he's not there yet. It gets a little more
complicated than this for zone and some man defences and offenses, but that'll be dealt
with more fully as the game continues to grow.

FUTURE NEEDS
Don't really need any help just yet. I do foresee problems with some of the
following but I'm too far away from that to try adding an extra coder to the
project:
1. Code Optimization - I know nothing about assembly or code profilers and I
haven't even broken down the code enough to figure out what needs tidying up.
Eventually, with all the players running around and potentially fan animation,
I'm going to need a way to get the fastest blits possible and the most complex
decisions reduced to minimal impact. Notice the game is running in 320 x 240 mode.
I want to get that up to at the very least 640 x 480, and preferably 800 x 600,
with better color depth. There's no way I can do that without some optimization.
2. Deployment - I'm very proud of my makefile, which should worry all of you.
I don't know anything about setting up a configure script or autogens or anything
like that.
3 - Artwork - The quality isn't bad for what it is, but I don't want this to
be relegated to cartoon silliness until the end of time. Assuming this one gets
finished, I'm going to even want to implement a 3D version, but we're a long way
away from that yet. SDL has extensions for OpenGL, which might be where I end up
going in a future (ie: 2.0 or 3.0 version). If you think my graphics suck and know
you can do better, please email me and show me what you've got, you might end up
being the one doing graphics work for the game (if you want). I'd say it's an
excellent opportunity for the future if only sprite-based games got the respect
they so rightfully deserve, dagnabbit.
4 - Testers - People with nothing better to do with their lives than perform one
of the most important and underappreciated free services possible.
5 - Code Critics - I'm a self-taught C coder. This should frighten whoever wasn't
already worried by the pride I have of my makefile. If anybody wants to look at
my code and email me with various "WTF? Are you a moron?!? Look here..." messages,
I'd appreciate it.
6 - Sound/Socket Coders - Yes, I want to have sound and go online. No, I haven't
explored that part of the SDL yet so I don't know it's capabilities in either of
those departments. No, I'm nowhere near ready to start implementing it.

So far, this is it.

Saturday, April 7, 2001
