Cleanup: engi has both responder and Wo - global about engo

[EtienneBruines]

And I wonder if we should keep the distinction between Responder and World? It looks nice, but is there any implementation of Responder that isn't World, that would make sense?

[paked]

I originally made World different to Responder because it would make it easier to implement... I see now that is isn't an optimal solution. I'd suggest removing Responder altogether.

[EtienneBruines]

It may be optimal, just didn't see the point in it ;-).

Shall I make a PR for that as well?

[EtienneBruines]

Found out, Responder did serve a useful purpose.

One could easily create his own (Game), overriding some functions (such as Setup), and then pass that along.

[paked]

@EtienneBruines Yes. Are we anticipating people will want to make their own World's though?

[EtienneBruines]

We at least want them to pass a Setup() function, and perhaps a Close() / Cleanup() function?

Downside is, that they'll want to manipulate that World within those functions.

Perhaps this is an idea:

func (g *someGame) Setup(w *engi.World) {

}

func (g *someGame) Cleanup(w *engi.World) {

}

(the latter could be optional)

And have them pass that instead, create the World when we want to, and pass it along as parameters?

---

Note that we want them to do some kind of Setup, to define Systems, Entitys, etc.

---

The question in this case, becomes: do we want them to pass the Setup-function, or ask an interface which requires a Setup function?

[paked]

@EtienneBruines I believe it is more idiomatic to use the second option. Unless we were to go full events (ie. Worlds.HandleFunc(e engi.SetupEvent, f func(c engi.Contenxter))), which I do not think is the direction we should be heading in

[EtienneBruines]

So, to be sure, we'd want something like:

type Game interface {
    Setup(*engi.World)
}

to which we could possibly add stuff if we'd want to.

[paked]

Ok. Do we know if this would kill the existing implementation of Responder?

On Fri, Oct 30, 2015 at 1:20 AM Etienne Bruines [email protected]
wrote:

So, to be sure, we'd want something like:

type Game interface {
Setup(*engi.World)
}

to which we could possibly add stuff if we'd want to.

—
Reply to this email directly or view it on GitHub
#35 (comment).

[EtienneBruines]

Yes and no.

Those things that are happening in Preload(), will now have to happen in Setup() - which is OK, since they basically were meant for the same thing.

[paked]

@EtienneBruines I'd like to see an implementation of this. It seems like it could be worth doing.

[matiwinnetou]

@paked: it is a voluntary work, it would be unfair to require this from Etienne :)

[EtienneBruines]

Still, doesn't sound like a lot of work ;-).

I won't be able to do this in a separate PR; but I can manage to do this in the major changes I've done to AudioSystem and CameraSystem?

(Then again, if anyone else would like to do it instead; I don't want to take away potential nice tasks)

[EtienneBruines]

@paked @matiwinnetou The idea / implementation is fairly simple, I now have this:

type CustomGame interface {
    // Preload is the place where you define assets/files you might need, before they will be loaded
    Preload()
    // Setup is where you define your Entities, Components and Systems. 
    Setup(*World)
}

The tricky part is this. For keys that are pressed, one just had to check whether their State was .Down() or not. However, in the current (read: old) implementation, the Scroll was handled by a Scroll method on the interface.

Now I'm wondering, what the best way is to handle the Scroll events. Perhaps allow for the same construction as with the keys (check if their State is Scrolled Up or something), and on top of that, implement some kind of MouseMessage, to which their Systems can listen for events?

---

I don't know if the idea of SetMouseButtonCallback or AddMouseButtonCallback would be idiomatic for ECS?

[matiwinnetou]

@paked @EtienneBruines For me there are some generic things I would like to discuss with design of world. In our implementation, we allow people to loop through all entities in the world and do something for certain components in those entities. Here I can see this is missing, update function takes entity and delta time. It doesn't seem like I have access to other entities.

[paked]

@matiwinnetou @EtienneBruines Sorry if I came off forceful with that comment. I only meant that it would be an interesting avenue to explore.

[paked]

@matiwinnetou Doesn't messaging a system that contains those entities solve that problem?

[paked]

I'd rather stick without handlers for the input interfacing

[EtienneBruines]

And by handlers you mean Callback handlers, or a function people need to implement as part of an interface?

Or would you rather have them check the state of the last input in a way that the Keys are done currently?

[paked]

I'd rather keep it analogous to the rest of the input methods

On Sat, Oct 31, 2015 at 9:50 AM Etienne Bruines [email protected]
wrote:

And by handlers you mean Callback handlers, or a function people need to
implement as part of an interface?

Or would you rather have them check the state of the last input in a way
that the Keys are done currently?

—
Reply to this email directly or view it on GitHub
#35 (comment).

[EtienneBruines]

Currently, that means checking their state on an Update function, without special handlers.