Comments (21)
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?
from engo.
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.
from engo.
It may be optimal, just didn't see the point in it ;-).
Shall I make a PR for that as well?
from engo.
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.
from engo.
@EtienneBruines Yes. Are we anticipating people will want to make their own World
's though?
from engo.
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 System
s, Entity
s, 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?
from engo.
@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
from engo.
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.
from engo.
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).
from engo.
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.
from engo.
@EtienneBruines I'd like to see an implementation of this. It seems like it could be worth doing.
from engo.
@paked: it is a voluntary work, it would be unfair to require this from Etienne :)
from engo.
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)
from engo.
@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?
from engo.
@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.
from engo.
@matiwinnetou @EtienneBruines Sorry if I came off forceful with that comment. I only meant that it would be an interesting avenue to explore.
from engo.
@matiwinnetou Doesn't messaging a system that contains those entities solve that problem?
from engo.
I'd rather stick without handlers for the input interfacing
from engo.
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?
from engo.
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).
from engo.
Currently, that means checking their state on an Update
function, without special handlers.
from engo.
Related Issues (20)
- Update isometric demo to use tiles of different sizes
- WSL to build on windows
- Shape drawing problem HOT 7
- Circle fill transparency HOT 6
- About performance HOT 7
- Scale operation seems to move the entity to the wrong position
- shader
- Support WebGL and Android HOT 11
- TMX resources cannot handle tile sets that leave a rest at end of rows HOT 2
- TMX resources don't respect transformations when loading tiles
- Build on macos M1 / Apple Silicon fails (GL/mobile-related) HOT 2
- AudioSystem's Pause and Restart aren't working
- Question: Can you draw upon a transparent window/canvas? HOT 1
- Cannot Compile on m1 mac HOT 3
- Release v1.0.7 appears to be tagged incorrectly HOT 1
- Properly handle gifs
- Add function to disable cursor HOT 1
- quadtree to fast
- Do not use icon.png as default image.
- MacOS 11 removed from test runners
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from engo.