 |
|
07.10.03 |
|
|
|
code news |
|
html => |
- the whole html namespace and all of its containing classes have been created.
- so many entries for it that i wouldn't dare list them.
|
|
|
ramblings |
|
web => |
- the 'castle' webpage is ready for launch. still need to do the sidebar
thingy and also a heading for what it is that is on the page. but that'll
be a few days/weeks. kinda tired of the webpage now, need to get back to the
castle engine.
- i also need to fix the top left graphic. it doesn't quite
blend in right, but later. the todo section is pretty broken also as you can
see.... not quite sure where i wanna go with that so....
- it seems that tr doesn't have style borders. was trying to seperate the
different tiers (where the classes are on left), and tr wouldn't do it. yeah
well.
|
|
|
todo |
|
html => |
|
|
07.08.03 |
|
|
|
ramblings |
|
web => |
- the webpage is coming along well; meaning, almost finished!!!=) i'm luving
the layout of the site. the main problem i'm having now is that i cant
really tell browsers (thru html) to confine my cells to a certain height=(.
this is a big issue.
|
|
06.30.03 |
|
|
|
code news |
string =>
regex |
- added a number of regexp_match functions to string
- added a number of regexp_search functions to string
- added substring class to user::util
- added helper functions for boost interface to regex_match & regex_search
|
|
optional => |
- fixed const return type in dereferencing function
|
|
|
ramblings |
string =>
regex |
- the regex project is finally up and away. had to learn the syntax, but that
is nothing compared to the amount of time it would have taken me to code it.
- the only problem now is there seems to be a memory leak in the boost regex
dlls. so now i cant see if i've got a memory leak in my code or if it's
regex=(. that pretty much sux. i will have to see if i can turn off memory
leak detection for certain dlls. hopefully a new release will fix this.
|
|
06.29.03 |
|
|
|
ramblings |
|
general => |
- shannon's b-day was yesterday.... and i didn't call her. doh.
|
|
web => |
- been working on deploying my new site for the last couple of days. was doing
some searching on the internet for the best way to actually get it up and i
really didn't find anything on the best methods of getting it up. plenty of
tutorials on specfics, but nothing really basic.
- so you know me, i turned it into a c++ adventure. added a few html classes
to my user dll and presto. now its more an unautomated cgi script. it
probably needed to be a program anyways because i need to turn this very
text into the content on the website. also, with it being a program i can
continue to type in this .txt file and then run the program to get the new
updated web page. spiffy.
|
|
regex => |
|
|
06.25.03 |
|
|
|
code news |
|
omni => |
- initialize() now creates and initializes engine
- finalize() destroys engine
|
|
engine => |
- initialize() creates managers
- finalizes destroys managers
|
|
simple_object => |
- added a CRAETE_OBJECT macro
|
|
map => |
- added empty_map()
- added is_empty()
|
|
|
ramblings |
|
ai => |
- been thinking, fsm (finite state machines) are really just perfectly trained
nn's. the brain(nn) would be able to do everything in a fsm if it were to be
trained properly. someone could train a nn to, say, make your object run if
they wanted too. but maybe such a task is just way too much time to do when
all you have to do is program a fsm. this leaves more time to train nn's to
do more interesting things that you might not be able to achieve the same
realness with in programming (though a nn would probably make running more
realistic also).
- think about it. your brain (a more sophisticated nn) can make you run. and
if you were to video tape you running, every stride would probably be
different. so a nn might make a object running look very realistic.
- yet if you were to ask someone a question like, "what's 2 + 2"... the person
would be able to give you that same exact answer everytime. this is a great
observation, and one i'm sure is being researched plenty. of course even
with my little experience with nn's, i'm sure i could train a neural net to
memorize the addition table up to say, 9 + 9. now whether i could somehow
get it to extend that to double digits with breaking the number down to
tens/hunderds/thousands/ and carrying the remainder then looping that output
back into the nn to calculate the next digit; and then remember all those
digits and spit them out in order... is another question=).
- so fsm are really finely tuned nn's minus the hassle (and minus the
extensibility). so with that said then, fsm or their states, which are really
part of the brain, shouldnt have direct contact with the outside world. your
brain has no direct link to the world, it just uses all the sensors availible
to it to filter in all the messages: eyes, nose, skin, ears. while these are
sensors, they are not exclusively; your skin does more than just feel, it
protects and everything else skin does =p.
- um, this is a game right, so where the game stuff=). i go though all that to
make my engine design the easiest and most intuitive to use. someone may go
though the engine and think, why is the brain controlling X or where in the
world is Y being called at. if you've got an intuitive design then less of
those questions come up. and if different parts of the engine map directly
or close to directly with the real world then you've got as intuitive a
design as possible (in mose cases =).
- so if the brain have no direct contact in the real world, then the brain (and
it's flukies, fsm and its states) should not have any contact with the real
world (engine) in the castle world. uh, previously i had the only thing the
engine would talk to was the object's brain and states, so now what?? well,
i'm thinking there should be a sensor class that deals with talking to the
engine (the outside world).
- so every object would have sensors. these sensors would do nothing but
accept (and send) messages and events from the engine and turn those into
signals that the brain could accept. the brain then processes the input,
possibly sending it to a fsm, or a script, or a nn, or whatever thinking
concept is in place. that thing would then act on the actual object.
- previously i had the only thing acting on the object being a 'plan' which is
really just a fsm. i think i will stick with this concept, only i wont
confine plans to be just fsm, they can be fsm, or nn, or scripts, or
whatever. i think we need a new object ascii tree =):
|
|
object_design: body => |
- this would be an object's model, its position, mass, velocity, textures,
sounds..... etc.
- these things will be stored in the actual object. or should i have a
seperate body class, then derived objects would have to have derived bodies
from the objects body class.
|
|
object_design: plans => |
- these are the actions an object can do. a plan knows how to make a body do a
certain thing. it can run animations, move bones and vertexes, play sounds,
change textures, change velocties and masses... basically anything in the
object's body can be chnaged by a plan.
- plans can also consist of other plans. so if theres a plan to jump, and a
plan to shoot weapon, then a plan can possibly combine these two things to
just and shoot weapon at the same time.
|
|
object_design: sensors => |
- sensors are the boundry between a object and the world, as far as
communication goes. the engine sends object messages to the sensors, which
then filter and modify those messages into inputs that can be understood by
the brain. the brain also send message to the world via it's sensors.
-
|
|
object_design: brain => |
- the brain simply takes the inputs it is given from it's sensors and converts
those into either plans (liking the word actions better) and/or outputs for
the sensors to give to the world.
- the brain can be either nn's, fsm's, scripts, or any combination. how that
all glues together, who knows.... =(
|
|
06.24.03 |
|
|
|
code news |
simple_object =>
class_factory |
- updated the create_instance and release methods in these classes.
- now initialize and finalize are called for all *unknows correctly.
- for simple_objects, m_parent and name are updated before initialize is ever
called. also the parent/children is updated after the finalize method of the
simple_object is called.
- made initialize and finalize callback methods.
- got rid of the double get_*manager functions in simple_object.
|
|
global => |
- got rid of the PASCAL in callback definition.
|
|
omni => |
- got rid of fake class_factory in omni. now omni creates and used the real
one, and will pass it to engine after it has created it.
|
|
|
ramblings |
|
general => |
- decided that the news section is really and code update section under
disguised. if it donsn't have to do with actual code changes in the project,
then it doesn't belong in the news section. i should probably change the
name of the news section something like, code=).
- while i'm talking about name changes, while the name ramblings describes this
section well, i think the name should more reflect my forward thoughts on
where the project should or shouldn't go. research comes to mind but, i'm
not really researching anything... just thinking. thoughts?! seems to
simple. www.thesarous.com time =) exegesis!!!! now there's a word (you dont
see everyday =). may go with that, or comments, design... who knows.
|
|
ai => |
|
|
ai:tank demo => |
- the tank demo i found at ai-junkie was very easy to understand, and made the
learning fairly fun. the tanks were bumbling about at first but and a few
generations were mining like semi-pros (go check it out).
- i made a few modifications to the program to further my understand and am
pretty happy with my results. i made one change so that the tanks would
avoid each other. i gave the nerual net inputs to the closest tank and
deducted points from the tanks fittness if a collision occured. this proved
dismal, and the tanks just started circling in one spot. thought they were
doing this to avoid each other, so i deduted points for staying to stationary
(not an easy task trying to formualte away to detect circles). but this
didn't help as the still circled, so i thought maybe i would deduct more for
circling and less for collisions. nothing really worked, i was like "neural
nets suck." by the end i had 20 inputs going into this mess and nothing.
then i somehow figured out that the supplied genetic algorithmes "roullette
wheel" was buggy: it wasn't designed for negative fitnesses and was breeding
all the dummies (poor tanks). once that got fixed, my neural net took off.
they were dodging and mining in pure blist. beauty i tell ya.
- that said, they still collided with each other at times and drove pass
obvious minds frequently; though i did seem to manage to curb circling; this
was probably because circling caused more collisions, more circling
deduction points, AND fewer mines mined, so circling hurt everything. and i
had little clue on how to fix it. maybe a few hundrem more generations would
have helped, or a new algorithm. it was only a learning expieriment so the
outcome didn't matter much so i just left it. but if this were a real program
where i needed the neural to work correctly more often, i'd be exhausted
trying to figure out the problems.
- that's the problem with nn's. they dont have any, let's say, 'hardware' you
can fix to make them work right. i read somewhere that the authors of
black & white hand tweaked the numbers for the creatures to make them at
right when they were being stubborn: i dont envy them (well maybe a little).
that has got to be something i wouldn't want to go through - unless of course
i knew my game was gonna make me millions of dollars. if you do go tweaking
these number by hand you have little way of knowing how this is gonna effect
some other out in the nn (heck, how do you know that the number you're
tweaking is the right one in the first place). obviously the b&w people have
more expierience than me (at the moment =), but it's got to be one steep hill
to climb to get there.
- a properly functioning nn is like a full grown adult in some ways. if you
start your nn today, you cant expect it to act correctly right off the bat.
it has to be trained, but more importantly, it has to be trained correctly,
giving it the proper inputs and correcting it correctly for the proper
outputs. and if anything is wrong with the training, and things will be
wrong, your nn will fail, and you wont notice that it is failing until so
much of your time is lost that you still wont want to giveup; even though you
know you've goffed.
- that all said, i think i will try to use nn in some form in the game i build
from the castle_engine =p (i'm a trooper glutting for punishment).
|
|
|
todo |
|
ai => |
|
|
06.21.03 |
|
|
|
code news |
|
coding style => |
- more updates to new prefix notation:
- that pretty much takes care of all the prefix notation updates except for the
user::bnf section. which pretty much sux.
|
|
|
ramblings |
|
ai => |
- i look back and see that all of that information about ai(plans) really isn't
ai: it's post-ai. it's the actions that would happen after ai had done it's
ai. i guess it's a part of the ai system because the ai needs to have it's
result end up being which plan to run, but the whole ai system is mostly still
up in the air.
- cox@home is slipping and i have no internet now =(
- i do luv the tracking i'm doing... let's me think my code out.
|
|
|
todo |
|
util => |
|
|
06.20.03 |
|
|
|
code news |
|
coding style => |
- updated some of the files in object to use the new prefix notation:
|
|
|
ramblings |
|
general => |
- sure wish i had built my code around this from jump, would have saved me a
lotta key strokes. i just thank GOD for 'replace', hotkeys, and visual assist.
as well as the whole vstudio 7.0 ide =).
|
|
ai => |
- well... i like some of the things discussed in the AOM engine. but it seemed
firmly geared toward a rts game, which i'm pretty sure not doing (though not
opposed to, just thinking more an RPG, zelda-ish like, which proably doesn't
need that great an ai system to begin with, but i want it anyway=). so i can
take some of the constructs i found there and try to use those as building
blocks to a more generic ai engine.
- firstly, i like the way the generalized everything so that they could easily
make collections of items, and then have the ai draw out relevent information
from it. but the everything they generalized was all rts based stuff so,
finding more general things to generalize around will be the stumbling block.
|
|
ai:plans => |
- next i just luv the idea of the big state machines which provided the "know
how* to perform any and all actions in the game. this way, there is no code
duplication for task since it would be alot easier and smarter to use the
already built machines. not sure if the word plan is the most intuitive word
for it though. (course if i keep using the word plan in these rants, i'll be
stuck with it).
- also with the plans, i like the way plans had preconditions that needed to be
filled before the plan could start execution. but in AOM, the precodition was
only having x amount of unit X and y amound of unit Y. so to generalize
precondition would be the key to making this more genric (how many times and
ways am i going to say the word 'general' before i'm through=] with words like
this, i'll never finish).
- another point with the plans, in AOM the plans had no owner, they were just
loose entities that could do stuff based on some preconditions. this worked
for AOM because the computer controlled player had one task, which was to
build up its squad and kick everyone elses' ass (of course to that, alot of
different things had to happen, but the goal was pretty straight forward).
they did this for a reason because they didn't want the scripts to be micro
managing resources.
- so these plans were just hi level actions for the scripts. so they are great
in that respect, but this still leaves something to need to micro-manage.
from what i understood from the article, whoever wrote the c++ code for the
plans was also doing the micro-managing. to me, this seems a little too high
for the micro managing (of course, the article couldn't cover everything in
6-7 pages so...). i think that more state machines could be doing more of the
rudametary things, which may well be the case with AOM. in fact, i think that
state machinces should be preforming every action in the simulation. this may
proove infeasible with the amount off message/events that would be flying
around but, that's how this engine is going to happen, so there=).
|
|
ai => |
- so in castle, i'm thinking that an object should be divided into three levels:
- object (physical)
- plans (actions)
- *reactions (plans that automatically occur from an event)
- *involutary actions (plans that happen periodically)
- brain (thinking)
- object
- this would hold all the physical information that the engine needs to be
able to display the object. the object's model and textures. its location
in the world, maybe things it is carrying. anything physical that an
object needs.
- it would also hold infomation that allow the engine to interact the object
in the world. things like mass, velocity, maybe hit points and health.
things of that sort.
- plans
- these are the actions that any one paticual object can perform. so an object
'running' would be a plan. depending on how detailed the particual game
was on running, this plan can be: hurl the right foot infront at
force f1 => check the world for when the right foot has landed on ground
=> thrust the right foot against the ground at force f2 => etc. or the
plan can be as simple as run the models "run" animation and add force f
to the objects acting forces variable.
- one is a complex state machine while the other is a state machine with one
maybe two states. ok, the first wasn't not that complex, detailed maybe.
but maybe if the "right foot hit ground state" took too long, the state
machine has to perform some balancing which happens in another state. and
if that state happens way too late then we end this state machine(plan) and
go into the falling plan (still not complex, but you get the idea)
- of course, for this plan to know that there is also a 'falling' plan for the
object it is acting on, it would have to know something about the object it
is 'planning' for. which i am very kewl with. the thing i didnt like about
the plans in AOM was that they were too general. not the plans
themselves, cuz they accompolised very specific task, but it was like the
plan knew about and how to use every single object in the AOM world. like
it knew how to use a foot soldier, and it knew how to use knights, and
tanks and scouts, or the rock hurling machine (fogot the name =p), or
whatever unit in the game, because in the end, they were all there to
inflict damage on something else. and so that makes control over any one
unit fairly uniform (not to bash anything, they solved the problem they
needed to solve, it's a RTS for christ sake, fight and build, not many
actions that they have to plan for). [scrap this: AOM plans were more
like the ai's plans - the actions that the ai(scripts) could peform]
- this worked for that game, but in other games and more general applications,
the plans are going to need to know the objects they are 'planning' for
more intimattly (or the objects will have to be able to decribe their self
in a general way, yet have very specific actions happen for them, yuck,
the plans will need an ai system just to understand the object they are
planning for, lol =) ( and if the objects are very different, then
describing them in a general way would be next to impossible anyway)
- one last thing (proably not), just like in AOM, without a plan, an object
cant do anything but sit there and look pretty. plans are the actions so
there should be a lot of them.
- brain
- the brain decides when a particualy object needs to preform a particaly
action. that's pretty much it in a nut shell, but this is definately the
most daunting of the three. (neural-net perhaps, or stick with scripts,
not that i have scripts to stick with=)
- i'm thinking that the brain is the only thing that the world or engine
talks to. if the engine needs to talk to an object, it talks to the
object's brain (makes sense =). i say thinking becuase i know the plans
will proably need to query the world alot to find out about it's objects
surroundings. so how limited these talks are haven't been decided yet.
- so it seems that a brain would need to know not only about an
object's plans but also the object itself; how can the brain know to tell
the object to do the "duck" plan if it doesn't know how tall the object is.
- the plans need to be able to communicate their actions to the brain. this
is one of the harder things to solve for this to work. we could solve
this problem by simply writing a brain for each object, that way the brain
knows what it can and cant do. but somehow that seems limiting.
- need to do some thinking for this section..... for now i think i'll just
write code for dumb objects.... objects, plans, no brains. atleast i'll
have something on the screen=).
- ok, we've got a "play sound" plan for the rock. this sound may vary based on
what hit it; a sword, a person's head... whateva=). so maybe the rock has
serveral different sounds to choose from. so the brain may choose which sound
to play basad on what hit it, hmmm. uh oh, that really doesn't sound like
something a brain should be choosing anyway; this (sound) should just happen.
well maybe the brain just passes the event on to the "play hit_event sound"
plan. well... that's better, but really, a plan is something planned on...
but it kinda works.
- maybe we need a reaction's level also. so then when the rock get's hit the
engine sends the hit_event to the rock's brain, and the brain first checks if
it has any planned actions for the event... then does unplanned actions
(reactions). [scrap this: this is like involuntary actions; like breathing
(of course no action would be sent for breathing since the object itself does
this, so involuntary actions aren't much like reactions at all since they are
self induced)]. if we let plans use reactions and vice versa then we wont even
have any duplicated code. let's think about it.
- reactions would be plans that would be in a different list in the brain. the
brain would only need to know what caused them (which event, or maybe more
than a sinlge event causes a reaction) and maybe what group of variables to
pass the plan.
- maybe the brain could also have involuntary plans (another different list of
plans in the brain). these would only need to know what elapsed amount of
time caused them to execute and maybe what group of variables to pass the plan.
|
|
06.19.03 |
|
|
|
code news |
|
coding style => |
- updated some of the files in user::util to use the new prefix notation:
|
|
|
ramblings |
|
general => |
- happy birtday to me!!!!
|
|
ai => |
- read some kewl things about AI in the new gamedev magazine. the creators of
AOM talked about the AI they used in the game. key points in their system:
- first they had a knowledge base (kb) - in the bkb system.
- in this kb they could represent every single unit they found in the game
in a fairly general way. only problem i saw in their implementation was
that it was geared towards a RTS. so the information they generalralized
was mostly hitpoints and is_enemy/ally. i guess for a different type of
game they would have to find even more general information.
- the kb serves as the ai's memory. it's a passive system: simply storing
information that a computer controlled player has seen. so the kb can be
queried by code/scripts to find out not so general information like: how
many enemy military units are in a certain area, or how many buildings
have i lost in a certain area. so the ai can determine who has control
over certain areas a map; it can also judge the danger posed in a
particular area.
- to help with queries (speed wise) there's a kb_resource object witch
groups information about common resources. this helps speed up queries.
so the ai can determine where food resources quickly without having to
do a search on every single item in the kb.
- next up, AOM employed the use of a bai. they labeled this the bkb's more
active sibling: because it controls the actions the ai makes. the bai is
divided into 3 seperate layers: goals, plans, and units.
- plans
- plans are the mechanics of the ai. plans are complex state machiens
that know how to accompolist specific objectives. there are plans to
create building X, and to attack certain targets, or to gather a certain
resource.
- everthing the ai does requires a plan [since are the things that do the
doing]
- plans have plan variables witch is the information that a plan uses to
accompolist a task. like an attack plan would a plan variables of a
list of units to attack. or a build plan would have the unit type of
the building/unit to build. however this information got in the plan's
varialbes, the plan uses this information to execute.
- they gave plans many customization points via the plan variables so that
scripters could alter the behavior of a plan. [this customization thing
is probably the kewlest part of the system, yet it's workings are the
most elusive to me, figures.... =p ]
- goals
- goals are completely created and controlled in the script realm. AOM
says their the strategic ai. the are super-high level contructs like
build forward base in player #3's direction, or attack plaer #4, or
fortify base.
- so once their are scripts that define these super-high level contructs,
then scripts using these construts can be created like. build forward
base: if success, build another forward base and gather resources: if
fail, fortify old base.
- units
- basically the generalized infomation that every unit has.
|
|
06.17.03 |
|
|
|
ramblings |
|
general => |
- new tracking record kept!!!
- the engines is named "CASTLE" and has been going for a minute now. i've had
a few engines go the way of the dodo bird, and this one may too but, i think
i have a design now that even if all else fells, this would be my base for the
next engine. which is a good thing, because everytime i have something in an
engine that i disagree with, but cant find a way around and proceed anyway, i
later, months later, while i'm in the midst of my work, find a very sound way
to do the engine so that those problems dont exist. at which point i toil over
the decision to incorporate it, knowing that it would probably destroy all
the work i've got so far and then the engine just caputs.
- this engine has been built off of all previous failed attempts and i am
totally (fingers crossed=) confident wont change much, snag here, fix there,
but nothing to drastic to the existing code. so the goal now is to make sound
additions, piece by piece of well thought out and designed code that i will be
happy to see in the base months, and hopefully, years from now =).
- currently we have a engine that has messaging, event, and class factory
[object creation] managers in place. and eviorment_manager
- today came across the autoexp.dat file which allows the debugger to display
class types with meaningful information. couldn't get the file to recognize
pointers though [user::util::runtime_class*]......... grrrrrrrrrrrrr...
|
|
system => |
- engine looks like:
- omni is the topmost class we have (yet very simple). it contains
a pointer to a engine and a few functions that allow the user to store info on
how to construct the_engine and all of it's contained managers. (this is
explained later in the enviorment_manager section)
- a singleton version is avaible though a member function in all simple_objects
- the enviorment_manager holds info about how the engine should create classes.
the enviorment_manager can say that if the engines wants a certain object 'A'
that the engine should create the object 'B' instead. the object 'B' has to
be derived from the object 'A'.
|
|
behavior => |
- we have a behavior system that is basicaly a state machine. is that good?!?
i dont know but from my thought so far seems to be ok.... this is pretty much
how unreal does it anyways [atleast in the unreal I engine] but, who knows.
- every object has a behavior_system which i plan on using from anything from
fake AI, to handling events [which is what AI would do anyway] for things such
as buttun_presses and mouse clicks, to line-of-sight events and on_draw events
|
|
|
todo |
omni =>
classfactory |
|
|
messaging => |
|
|
coding style => |
|
|
general => |
|
|
object => |
|
|
behavior => |
|
|
graphics => |
|
|
|
terms |
|
|
 |
