Re: Software Architecture/Design

The PO's can do the transforms in-place, by copying, creating new output
objects or whatever else makes sense.
 
When I am using this notation:
 
A+B -> [X] -> B
 
I am basically saying that A is Read Only and B is ReadWrite. In C++ you
would typically just get a pointer to B and update B. In a functional
language with immutable values you will typically output a "new" B (that
might in reality under the surface share most of the input B's data -
Clojure is an example).
 
When I am writing this:
 
A -> [X] -> B
 
I am basically saying that A is Read Only and B is created by X (because
B wasn't given as input).
 
It is just a short hand notation that I find useful for designing the
architecture of applications.
 
The notation is very loose because this:
 
A -> [X] -> A
 
could be implemented as a thread X that reads from a semaphore protected
input queue and writes to a semaphore protected output queue. Or it
could be implemented as a simple:
 
void X(A* a) { ... }
 
that modifies A in place.
 
The data structures can be whatever makes sense.
 
For example, for performance reasons you might want to do the following:
 
void Physics::transform(Matrix* mMin, Matrix* mMax, Velocity* vMin,
Acceleration* aMin, float secs)
 
where mMin/mMax is an array of the transforms of ALL game objects in the
game. This will be super fast because you will minimize memory cache
misses.
 
Or you might do:
 
void Physics::transform(EntityList* os, float secs)
 
where EntityList is a traditional list of entities to be moved. Or some
other data structure that makes sense for your application.
 
The State Object/Process Object approach is a thinking tool for
designing your architecture more than a data structures tool.
 
Morten
 
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Alex
Lindsay
Sent: Friday, 4 June 2010 10:17 AM
To: [email protected]
Subject: Re: [Sweng-Gamedev] Software Architecture/Design



Hi, 

If examples in practice are coming, I'd like to know:

Do your POs/Transforms come in "in-place modify" and "new output"
versions? In-place might work in a single-threaded or certain SPU
configurations (their own local memory), but threading complicates this.

What structure would a Boids sim come in - e.g. when each boid is
interested in avoiding boids nearby? My quick guess is:

BoidList -> [BoidSpatialPartitioner] -> BoidsInSpatialPartitions[N]
for A in N
   BoidsInSpatialPartitions[A]+BoidsInSpatialPartitions[surrounding A]
-> [BoidAvoider] -> BoidBallistics[A]
BoidList + BoidBallistics + Time -> [BoidMover] -> BoidList

?

Cheers,
Alex

On Fri, Jun 4, 2010 at 6:06 AM, Phill Djonov <[email protected]> wrote:


On Thu, Jun 3, 2010 at 9:35 AM, Richard Fabian <[email protected]> wrote:
> Something I've been worrying about with my stuff is how unwieldy does
it get
> the higher you go, but you're saying that higher level stuff turns out
fine
> too?
> Can you go a bit deeper into how higher level and lower level stuff
gets
> figured out?


Not sure if Morten is talking about the same thing, but what I find
works well is to think of "high-level data" as "bag of low-level
data"* and "high-level logic" as "high-level data in disguise"**.

* Usually refined into a hierarchy of bags of related subsets of that
data. It helps keep data dependencies from creeping in when MoveMovers
takes an array of MoverState objects and a GameTime, rather than the
whole damn GameState.
** Decision graphs are great! I can write a bit more about these later
when I've got more time, if anyone's interested.

Cheers!
Phill

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.
com

_______________________________________________
Sweng-Gamedev mailing list
[email protected]
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com