event-based architecture (was: voice)

0 views
Skip to first unread message

daniel miller

unread,
Jan 31, 2009, 10:11:37 PM1/31/09
to realxtend-a...@googlegroups.com
On Sat, Jan 31, 2009 at 11:29 AM, Ryan McDougall <semp...@gmail.com> wrote:

>> My argument is basically that by putting a bit of extra work in the
>> beginning (designing our own message pipeline), we will reap rewards
>> later in the project because integration of the parts will go much
>> more smoothly. Again, it's a judgement call, and I'm not the main
>> judge, just making a proposal.
>
> I am willing to agree in principle; but without details, ones I can't
> really propose myself. We would need to start another thread with your
> hypothetical plan, and we can crunch the numbers. However the window
> for making a decision is soon closing. By the end of February to be
> exact.

I would like to make my proposal more concrete, and have it evaluated
seriously as an option.

I've been reading that Intel paper you posted a while ago (from the
Smoke team) and there are some concepts there I really like. If
nothing else, the paper outlines the issues sharply, and points out
the tradeoffs inherent in differing approaches (such as lock-step vs
free-step scheduling.)

Assuming this is still the choice for the underlying architecture, I
think I could formulate my proposal in terms of integration with this
paradigm. If something else is in the works, let me know so I don't
go off in the wrong direction.

-danx0r

Ryan McDougall

unread,
Feb 1, 2009, 2:13:55 AM2/1/09
to realxtend-a...@googlegroups.com
On Sun, Feb 1, 2009 at 5:11 AM, daniel miller <danb...@gmail.com> wrote:

> I would like to make my proposal more concrete, and have it evaluated
> seriously as an option.
>
> I've been reading that Intel paper you posted a while ago (from the
> Smoke team) and there are some concepts there I really like. If
> nothing else, the paper outlines the issues sharply, and points out
> the tradeoffs inherent in differing approaches (such as lock-step vs
> free-step scheduling.)
>
> Assuming this is still the choice for the underlying architecture, I
> think I could formulate my proposal in terms of integration with this
> paradigm. If something else is in the works, let me know so I don't
> go off in the wrong direction.
>
> -danx0r
>

The more I study game engine design, the more I see the principles
which the demo tries to embrace.

While the smoke demo is obviously of demo quality, not something you
could sell, it represents a sane base to start from, so lets consider
it for the sake of discussion, to be our engine.

Cheers,

Reply all
Reply to author
Forward
0 new messages