What is the merge game plan?

Design
#1

Just want to make sure we’re all on the same page. How is it going with everyone? Should we decide on a deadline and how we plan to handle the merge? e.g. (modify this as needed) Current plan is as follows (pending additional team member input):

  1. Finish Engine prototypes (until roughly end of November)
  2. Finalize Common Design spec (can start before part 1 is completely finished)
  3. Merge, as follows:

Evaluate each of the following aspects of each engine:

  1. Components
  2. Events

according to these criteria:

  1. API / ease of use
  2. Performance
  3. Flexibility

And then even dive down into the lower stuff, e.g. “overall we should use X’s component system but it was brilliant how Y handled this and that should be integrated into it”, or something.

Is this what people were thinking? Or if not, what?

Lastly, could be good to have a few “use cases” to test all the engines against to help us work out what approach does which kinds of things best, maybe even now during development, e.g.

  1. Number of simultaneous transitionables at 60fps (both with, and without, physics)
  2. (add more here)
samsaraJS - first look
#2

Oh also, might be cool to get a brief update from everyone on their current work. And maybe use that for a public facing “Latest News” thread where we could do summarized, brief, weekly updates? Would be cool to have a single place where we could point people to.

#3

What about a design spec? Did we decide not to do one?

Having the discussions you mention are going to be that just discussions. It will be really hard to make decisions and come to a consensus without some agreement of vision for something that is not defined for an API when everyone is going in a different direction on their design.

1 Like
#4

Is that doable? I feel like I may need 1.5 to 2.5 months?

#5

Yeah, I think it may be too early to decide on merging, and would be better to start agreeing on the design spec. But then again, it may be prototypes that help refine the design spec. We may not forsee certain classes and hierarchies until seeing prototypes. I updated the class-list in infamous/requirements.

Design spec (classes, methods, etc)
#6

Hehe, I feel like that’s a lot more realistic… I’m kind of enforcing my own ideal deadlines here :> I had Sep to mid Dec to start and complete a prototype app, and had planned to do it with famous. Now i have to do the engine and the app :> But maybe using a draft engine for a real app will give useful perspective too.

I know it sounds weird (prototype before design spec) but what joe says makes sense and I agree. There’s a lot of stuff that I had pretty clear ideas of how to do but during implementation I had to adapt. Maybe after all our prototypes are ready or further a long we can have a more realistic chat about the design spec from everything we’ve learnt, and then use that to complete the design spec and then do the merge, does that sound good to people? So:

  1. Engine prototypes
  2. Design spec (can start before part 1 is finished)
  3. Merge (when design spec finalized, and according to criteria in top post)

How do people feel about that? (And about criteria and deadline?)

1 Like
#7

Oh and see also Design spec (classes, methods, etc) which I only saw after I wrote the above (despite @trusktr clearly making it a linked topic, above :)).

#8

This is ok as long as we do not have a 2 week timeline :smile:

1 Like
Intro, news, and status