Coining terms is always an important step, it makes things clear, it makes people confident, it accelerates communication and most importantly, it allows one to break out from the loop of continuously thinking about the term's details, making it a building block, a box, that is understood and can be built upon.
I am therefore Coining the Term 'Brain Cache'.
As usual, this is a topic I recurrently think about, the cost of switching between different parts of a project or different projects. Being mostly the only developer working on World Of Football, it used to happen that I would need to switch between different components of the project, this would mostly happen when we need to add some features to our xml based world in order for our genius designer to be able to independently work on some new things, or try some new assets and their related functionality.
This almost always proves to be quite taxing, it seems there indeed is a brain cache, and when you are working in depth on something, and you get interrupted, you get ... a brain cache miss, it breaks the rythm and is much more annoying that one might think, the rythm is broken again when you get back to continue what you were doing before you were interrupted.
Of course, sometimes it is unavoidable, but it better be kept to a minimum with a plan that minimizes the need for such situations by batching related tasks together, even if they should not necessarily be coded together featurewize. This means if 2 features are related in that the mental context to code them is cache friendly, they better be batched together even if the second feature is not really needed in the time the 1st one is being implemented, of course, as with all things, it is a balance, this time between feature progress and brain cache thrashing.
The real point here is that the thrashing cost should not be understimated, it is fairly high, specially when small tasks keep interrupting big and complex ones. So better batch together all those editor features you know will eventually come!
And don't Thrash my cache!
Wednesday, July 23, 2008
Saturday, July 19, 2008
'a**hole driven development' coined at last
http://www.scottberkun.com/blog/2007/asshole-driven-development/
Bull's Eye!!
but don't stop there, there are even more words in this great blog that materialize thoughts I (and many) always have, but never feel the need to cleanly write them down.
quoting (http://www.scottberkun.com/essays/45-work-vs-progress/):
---------------------------------------------------------------------------
.............
............
.....
---------------------------------------------------------------------------
bull's eye again!!! please ... bookmark this blog and read it!
Bull's Eye!!
but don't stop there, there are even more words in this great blog that materialize thoughts I (and many) always have, but never feel the need to cleanly write them down.
quoting (http://www.scottberkun.com/essays/45-work-vs-progress/):
---------------------------------------------------------------------------
.............
I’ve seen organizations that measure things like:
- How many hours you were in the office
- Number of Reports, specifications written
- Presentations given
- Calls made
- Lines of code written
- Number of bugs fixed
- E-mails sent
............
Measuring individual progress:
- How much closer did your work today get us to finishing the project?
- Does the quality level of your work match what we need?
- How many people on the team have you positively influenced?
- What challenges did you overcome?
- What challenges did you prevent from ever happening?
- What difficult, but essential, questions did you ask that others forgot?
- How did you make us more efficient towards our goals today?
- What roadblocks are you currently facing that prevent faster progress?
Measuring team progress:
- How much closer are we to fulfilling our goals?
- How close are we to the needed levels of quality?
- What unaddressed problems are slowing us down?
- Is our remaining schedule accurate? What would make it more so?
.....
---------------------------------------------------------------------------
bull's eye again!!! please ... bookmark this blog and read it!
Friday, July 18, 2008
meta programming a gene pool
I was having a walk, and suddenly, my light bulb flashed with a new revelation.
There is no escape from specialization (context specific optimization).
I always used to wonder why is that we humans can only function under very constrained limits, be it temperature, humidity, regular food / water consumption, radiation ....
there are animals and insects that have much better tolerances, but taking it to the extreme, a piece of stone per example, has even better tolerances. The price is obvious, it cannot 'do' much.
The light bulb flash was that there is no escape from specialization, we are really good, at least better than a stone in acting and actively 'being' (whatever that means) in our environment, so we got specialized to do really good living here, with the disadvantage of not being good at all living in 'other places', a stone can live in both places (here and mars per example), it is not specialized / optimized for life here ... but pays for it by having 'no life' :P (here or on mars).
If per example we were to be able to live on earth and under water, we would need additional mechanisms and organs to be able to do that, which would make us probably slower and less efficient both here and under water, same for temperature conditions, radiations ... to be able to live on mars AND on earth, we would probably need to be less efficient living in any of the places because we would be bloated with stuff we don't need in the place we're currently in.
TO better formulate it, the wider the range of constraints we want to be able to live in, the less we will be efficient living in a place with constraints spanning only a small range of the potentially livable range of constraints we support.
The light bulb also flashed because of how this applies to software development:
It seems to be an unsurmountable law, that the wish to write completely general reusable code is bound to fail, I already wrote about my thoughts on code materialization in a previous post, and it seems I am still thinking about this topic from time to time. so it seems its bloated, heavy, complex and general in one extreme and specialized, light, easy to use and fast, on the other.
The only way I see around this is meta programming, if designed and implemented nicely (like in the loki library per example) using policies per example to customize code at compile time, it could be a good way to go, it needs more work of course, because it means actually implementing all the potentially needed functionality, or at least a good part of it, or in the minimal case only the currently needed implementation, but then the design of the policy has to be well thought-out, since in the absence of different implementations, the design could turn out to be flawed and would need to be changed when new implementations come.
So again, this would be like a pool of potential functionality, and the nice thing is, the end compiled code would not be bloated, since only the used parts (genes) go into the final product (creature) .
The effort to do this is obviously not small, specially for the unexperienced, furthermore, although the end product might not be bloated, the source code, might become bloated and too complex if again, care is not taken.
Unfortunately, meta-programming, although pretty flexible in c++, is not flexible enough for my taste, but still better than in other languages, but more on that next time.
There is no escape from specialization (context specific optimization).
I always used to wonder why is that we humans can only function under very constrained limits, be it temperature, humidity, regular food / water consumption, radiation ....
there are animals and insects that have much better tolerances, but taking it to the extreme, a piece of stone per example, has even better tolerances. The price is obvious, it cannot 'do' much.
The light bulb flash was that there is no escape from specialization, we are really good, at least better than a stone in acting and actively 'being' (whatever that means) in our environment, so we got specialized to do really good living here, with the disadvantage of not being good at all living in 'other places', a stone can live in both places (here and mars per example), it is not specialized / optimized for life here ... but pays for it by having 'no life' :P (here or on mars).
If per example we were to be able to live on earth and under water, we would need additional mechanisms and organs to be able to do that, which would make us probably slower and less efficient both here and under water, same for temperature conditions, radiations ... to be able to live on mars AND on earth, we would probably need to be less efficient living in any of the places because we would be bloated with stuff we don't need in the place we're currently in.
TO better formulate it, the wider the range of constraints we want to be able to live in, the less we will be efficient living in a place with constraints spanning only a small range of the potentially livable range of constraints we support.
The light bulb also flashed because of how this applies to software development:
It seems to be an unsurmountable law, that the wish to write completely general reusable code is bound to fail, I already wrote about my thoughts on code materialization in a previous post, and it seems I am still thinking about this topic from time to time. so it seems its bloated, heavy, complex and general in one extreme and specialized, light, easy to use and fast, on the other.
The only way I see around this is meta programming, if designed and implemented nicely (like in the loki library per example) using policies per example to customize code at compile time, it could be a good way to go, it needs more work of course, because it means actually implementing all the potentially needed functionality, or at least a good part of it, or in the minimal case only the currently needed implementation, but then the design of the policy has to be well thought-out, since in the absence of different implementations, the design could turn out to be flawed and would need to be changed when new implementations come.
So again, this would be like a pool of potential functionality, and the nice thing is, the end compiled code would not be bloated, since only the used parts (genes) go into the final product (creature) .
The effort to do this is obviously not small, specially for the unexperienced, furthermore, although the end product might not be bloated, the source code, might become bloated and too complex if again, care is not taken.
Unfortunately, meta-programming, although pretty flexible in c++, is not flexible enough for my taste, but still better than in other languages, but more on that next time.
Friday, July 4, 2008
Project 'Loco', a low level animation AI 'project'
Motivation
I don't know where it will go ... but I realized it is better to write down the stuff I think about while sitting bored in the train (or other places) than to simply think, forget a part, think again ... and eventually forget the whole thing because of lack of time. So it even might never reach the level of a demo or even source code ... but still ... as I decided, better document it.
Also of note is that I unfortunately do not need this in any of the game development projects I am currently involved in, and I never worked on anything similar before, so why am I doing this? because I wish I was involved in anything of this kind ...
'Loco' is our human like character and the first goal I thought, would be to make him be able to move (or locomote) in a 3D environment, credibly moving through obstacles: climbing stairs, climbing smaller obstacles (crates), jumping, crawling under obstacles, and so on.
The only input coming from the user would in this case be the movement direction (or a target point) and possibly speed.
Here are my first thoughts on this (boring 1.5h. train ride)
as a note, I will present here just the summary (not full details) of a chain of thought, and even though I am sure all of this is probably covered in the 1st chapter of many robotics books (but maybe I'm wrong), or that many people will just laugh when reading it, I still am documenting it here, for myself if for no one else, and absolutely prepared for the very probable fact that it will sink down into blog oblivion the minute I click the 'publish post' button.
Why do we stand on 2 feet?
Because based on our skeletal structure (feeding back into locomotion, feeding back into structure in a loop called evolution), a good, stable and fast way for us to move is to walk on 2 feet.
When we cannot walk, we can crawl as an alternative.
Irrespective of what state we choose (walk, crawl, stand, ...) we need a way to maintain that state, stay balanced, if per example, there is a small bump is in our way.
Basic Loco thoughts
so Loco basically would have a repertoire of locomotion states we will call moves:
stand, walk, jump, crawl, sit, lean, ...
Higher level AI of Loco would plan what combination of states to choose to achieve its locomotive goals.
but what exactly is a move? how does a 'stand' differ from a walk? the definition of a move is therefore important! because it will give us the constraints we need to maintain in order to maintain the move.
We have to watch out that states can be dynamic, so this might get complicated.
Plan Of Attack
How to define a move
The first version of Loco will be a 'simple' skeleton in 3D, that is points with weights connected with joints, so a 3D stickman (think robotics...).
now let's try to think about what defines a 'stand' move:
a simple definition that comes to my mind is: 2 feet on their constrained targets and head at the highest position achievable by the skeleton (on the gravity axis). this should also be stable.
Stable probably always means that the center of gravity's projection should be inside the 'area' created by our feet.
how will loco achieve a move
On first thought, solving this mathematically could be real slow, but let's ignore that and think about it a bit.
to solve we would
next we would try to move loco's feet and see him readjust, this would definitely not look human, but much more robotic, since this is how they probably do it in robotics (think Inverse kinematics).
but that's no problem for now, we might try to humanize this later by:
Doubts already...
there is also one big issue, we need to handle dynamics, when we run per example, we are not balanced the whole time (try running in slow motion, or even walking, there is a moment where u are in disbalance just before you put your next foot on the floor), we use inertia and dynamics to stay balanced, which makes the solution even more complex with an explosion of valid solutions, which is also the case for static moves.
but, this is normal!! we humans can do a huge amount of moves!
this means that 'solving' for the move is actually a stupid thing to do... and not only from the point of view that it would definitely be very slow, I can't really estimate it at all for now, but more importantly because of the fact that there are MANY ways to achieve a move.
but let's think some more...
Imagine you suddenly forgot all your locomotion instincts and had to sit down and plan how to move every muscle in order to walk... a daunting task!!
Reducing a million years
at this point I realize it is all too easy to forget the amount of evolution-hours (like man-hours in a project) that have gone into the development of our moves...
it is easy to forget because we take it for granted, but it really is a humongous million year effort, it is like being in some post-apocalyptic world, back to very basic technology and wanting to develop a game! you would have to invent electricity, electronics, and all what's needed for that, materials, processing, ... even though we use those everyday, we really couldn't be able to achieve it at all ... a humongous million year effort.
so going back to Loco, is it really ok to expect to be able to solve this with some trivial mathematical algorithm? (trivial compared to the work done by evolution), I now start to doubt this and think it is also a stupid way to approach the problem.
a better approach now i think is is to give Loco our instincts, a set of moves (dynamic as well), and give him a simpler task, try to keep them balanced when faced with deviations from the ideal case, a small bump on the floor, road going down instead of being straight, getting a small push ... that is probably more manageable. which is what Natural Motion probably does, and it is then clear why they had to use a neural network, controlling those muscles with math is probably an impossible task, I am trying to think about how many neurons do we use for locomotion, and if current computers even have the necessary computational power to do this at least in real time...
ok, the train ride is over, continue next time.
Break
are you already laughing at my naivety? (yes I keep repeating this, but I guess this is a normal feeling of fear that naturally emerges and haunts one's psychology when making one's ideas naked and public for the first time) I expect yes and secretly hope no, and that eventually this 'will have been' a useful mind exercise looking back some months in the future at hopefully a series of posts building on this one.
I don't know where it will go ... but I realized it is better to write down the stuff I think about while sitting bored in the train (or other places) than to simply think, forget a part, think again ... and eventually forget the whole thing because of lack of time. So it even might never reach the level of a demo or even source code ... but still ... as I decided, better document it.
Also of note is that I unfortunately do not need this in any of the game development projects I am currently involved in, and I never worked on anything similar before, so why am I doing this? because I wish I was involved in anything of this kind ...
'Loco' is our human like character and the first goal I thought, would be to make him be able to move (or locomote) in a 3D environment, credibly moving through obstacles: climbing stairs, climbing smaller obstacles (crates), jumping, crawling under obstacles, and so on.
The only input coming from the user would in this case be the movement direction (or a target point) and possibly speed.
Here are my first thoughts on this (boring 1.5h. train ride)
as a note, I will present here just the summary (not full details) of a chain of thought, and even though I am sure all of this is probably covered in the 1st chapter of many robotics books (but maybe I'm wrong), or that many people will just laugh when reading it, I still am documenting it here, for myself if for no one else, and absolutely prepared for the very probable fact that it will sink down into blog oblivion the minute I click the 'publish post' button.
Why do we stand on 2 feet?
Because based on our skeletal structure (feeding back into locomotion, feeding back into structure in a loop called evolution), a good, stable and fast way for us to move is to walk on 2 feet.
When we cannot walk, we can crawl as an alternative.
Irrespective of what state we choose (walk, crawl, stand, ...) we need a way to maintain that state, stay balanced, if per example, there is a small bump is in our way.
Basic Loco thoughts
so Loco basically would have a repertoire of locomotion states we will call moves:
stand, walk, jump, crawl, sit, lean, ...
Higher level AI of Loco would plan what combination of states to choose to achieve its locomotive goals.
but what exactly is a move? how does a 'stand' differ from a walk? the definition of a move is therefore important! because it will give us the constraints we need to maintain in order to maintain the move.
We have to watch out that states can be dynamic, so this might get complicated.
Plan Of Attack
- figure out how to define moves (constraints on skeletal points)
- can loco mathematically figure out how to achieve a move and keep it balanced?
- test moves
- level AI uses moves to achieve high level goals
- add a mesh for loco, this would be achieved with the mesh animation trying to 'follow' the skeleton using probably some form of parametric animation blending.
How to define a move
The first version of Loco will be a 'simple' skeleton in 3D, that is points with weights connected with joints, so a 3D stickman (think robotics...).
now let's try to think about what defines a 'stand' move:
a simple definition that comes to my mind is: 2 feet on their constrained targets and head at the highest position achievable by the skeleton (on the gravity axis). this should also be stable.
Stable probably always means that the center of gravity's projection should be inside the 'area' created by our feet.
how will loco achieve a move
On first thought, solving this mathematically could be real slow, but let's ignore that and think about it a bit.
to solve we would
- constrain the requested move constraints (feet, head)
- figure out what to do with all other points while staying balanced
next we would try to move loco's feet and see him readjust, this would definitely not look human, but much more robotic, since this is how they probably do it in robotics (think Inverse kinematics).
but that's no problem for now, we might try to humanize this later by:
- using precomputed solution
- or precomputed parts of solutions
- adding more constraints, so solver must be able to handles those as well, probably making the whole thing even slower (CUDA?)
- the first way of doing this would be of course, some kind of a tree search.
- the second would be of course solving analytically, this is definitely not a new topic... inverse kinematics, rag dolls, ...
- the third is to predefine the solution for loco.
Doubts already...
there is also one big issue, we need to handle dynamics, when we run per example, we are not balanced the whole time (try running in slow motion, or even walking, there is a moment where u are in disbalance just before you put your next foot on the floor), we use inertia and dynamics to stay balanced, which makes the solution even more complex with an explosion of valid solutions, which is also the case for static moves.
but, this is normal!! we humans can do a huge amount of moves!
this means that 'solving' for the move is actually a stupid thing to do... and not only from the point of view that it would definitely be very slow, I can't really estimate it at all for now, but more importantly because of the fact that there are MANY ways to achieve a move.
but let's think some more...
Imagine you suddenly forgot all your locomotion instincts and had to sit down and plan how to move every muscle in order to walk... a daunting task!!
Reducing a million years
at this point I realize it is all too easy to forget the amount of evolution-hours (like man-hours in a project) that have gone into the development of our moves...
it is easy to forget because we take it for granted, but it really is a humongous million year effort, it is like being in some post-apocalyptic world, back to very basic technology and wanting to develop a game! you would have to invent electricity, electronics, and all what's needed for that, materials, processing, ... even though we use those everyday, we really couldn't be able to achieve it at all ... a humongous million year effort.
so going back to Loco, is it really ok to expect to be able to solve this with some trivial mathematical algorithm? (trivial compared to the work done by evolution), I now start to doubt this and think it is also a stupid way to approach the problem.
a better approach now i think is is to give Loco our instincts, a set of moves (dynamic as well), and give him a simpler task, try to keep them balanced when faced with deviations from the ideal case, a small bump on the floor, road going down instead of being straight, getting a small push ... that is probably more manageable. which is what Natural Motion probably does, and it is then clear why they had to use a neural network, controlling those muscles with math is probably an impossible task, I am trying to think about how many neurons do we use for locomotion, and if current computers even have the necessary computational power to do this at least in real time...
ok, the train ride is over, continue next time.
Break
are you already laughing at my naivety? (yes I keep repeating this, but I guess this is a normal feeling of fear that naturally emerges and haunts one's psychology when making one's ideas naked and public for the first time) I expect yes and secretly hope no, and that eventually this 'will have been' a useful mind exercise looking back some months in the future at hopefully a series of posts building on this one.
Subscribe to:
Posts (Atom)