why automate?
by: akbar A (syedali011@earthlink.net)
may 5, 2000
automation?
why automate?
in this brief article i would like to explain why it is a _GOOD_ idea
to automate everything.
well today i happened to take a test on vector mathematics. the day
before, i wrote a program in my calculator to answer all the questions
as long as i gave it the correct data set.
when i got the test i zipped through in in approx less then 4 minutes.
since i could not turn in my test 4 minutes into the test i just started
to observe the other students. They seemed to be struggling with getting
the correct answers when it was only the concept of getting data putting
it in a sequnce of steps and getting an anwser.
after a few minutes of looking at the people in the class i came to
the conclusion that humas are extremly stupid creatures when it comes to
number computeration and anaylzing sets of data(graphically does not count).
i cam to the this conclusion after i handed in my test.
"the brain is not accelerated for number crunching"
it is accelerated for things of visual nature (recognizing faces,
sound recognization, names).
well at least for most people ;)
the program i wrote gave me a insight on the way we should run and
create our computer programs.
let the software code do everything except store the data.
basically in lamens terms.
*data driven software code*
Although developing software code that is not hardcoded and is data
driven is *much* more difficult. It is well worth the effort.
Another beauty of having data driven software code is that there
is no need for recompilation.
once you have your basic template laid out in the code base to load
up, you can say good bye to recompiling.
your software code, your newly written software code will load up the
data from your *database* and do whatever it has to do.
now we can apply these techniques directly to game design and devlopment.
for example.
instead of hardcoding our characters many game companies are guilty
of this, we can have a text file that has a list of the characters and
the models to load up.
in this text file, we can even have another links to another text file
that describes all the attributes of that character.
below is going to be a simple example of the *data* and how the text
file would appear to be like.
models.txt
{
"armyman";
"/model/armyman.mdl";
"armyman.txt";
}
this obviously is going to be much longer in a real game. but you get
the drift.
by allowing your specifc (player variables, enviroment varibales, maps,
sound) code to be data driven you can change all this data on the fly and
there is no need to recompile your data.
In taking this path it also helps a lot with making mods to the orignal
game, and did i also say that expansion packs are a breeze in the park
when you take this path.
when your game is going to boot up, one of the first things which it
will do is goto this file, load it up into memory, and do it's text parsing.
this is pretty trivial due to the fact that there is a semicolon at
the end of each *data set* and, you can parse in groups seperated by the
semicolon. the quations will designate what is the *data*. basically when
you hit an open quation it is time to read this data, when you hit a closing
quation it is time to set this read data as being completed.
the brackets will be a way of dividing diffrent types of models.
When you are done loading and parsing the file, you can load the models
and the specfic attributes found in the "armyman.txt" and run through that
for the player's variables (name, health, life, race, spellcaster, powers,
etc..)
trust me, by doing this you are going to save a lot of time in many
areas, compiling downtimes will be much lower.
Another cool thing about this methord is that in this way you can *tweak*
everything(players, ai, entities) without having to recompile. in doing
so you will have more time to *tweak* your environement and player
variables.
and my last thing of note, automate your sound files.
i have worked on to many projects where the sound variables where hardcoded
into the source code.
this is just plain out ridoclous, the sound files should not be written
in the software code, but be data driven and the locations of the sound
variables should be data driven.
peace,
akbar A.