Comments (4)
Good points, need some time to think about it, but first ideas:
textEntity and Background: key point of MarteEngine is easy of use and simplicity. Thinking about all in our engine as Entity simplify all in your game, when you design it and when you debug it. So I think that these classes for now are ok: simply and easy to use. Maybe introduce an interface for updating and one for rendering could help, but I think that in the end the code will be not so readable.
movers for motion: same as above.. but we can think about this, can you provide some examples?
physics as an interface: this is a good idea and I'm thinking about this topic in version 0.4, see #18
from marteengine.
The problem about TextEntity and BackgroundEntity is that they only need to be rendered, but they're inheriting all this code they'll never use. I understand that we want everything to be simple, but if we make them inherit from something called Renderable, for instance, and give them all the same initialization and expose the same methods (for rendering and updating), then why not?
The reason I'm concerned about this is because I want to do some stuff with scrolling text and things like that, and that's going to have to render completely differently than an entity. What are your thoughts?
I think that movers for motion is better is that it works hand in hand with abstracting the physics engine (as mentioned here and in issue 18). There are two possible implementations: the Mover class, or the Mover interface.
If they're an interface, then you can define different motions for each class that moves uniquely.
Okay, now that I've seen that issue, I'm even more convinced that we need to make our current 'lite' physics a separate logic. We have to separate the functions of a physics engine and a mover:
The physics interface should only calculate forces and come up with that frame's animation, and then the Mover should handle actually moving the Entity.
from marteengine.
Not sure about movers and physics.
The simple physics entity stuff is kept in one package with it's only dependencies on Entity (I think).
Complex physics entities using Fizzy for example could also be based on Entity and use their own package.
So the user can choose between one or the other.
If you add an interface for physics behavior you'll have to force both approaches (PhysicsEntity and FizzyEntity) to fit the one interface which is bad design in this case IMHO.
Just offer two implementations that are independent of each other. My two cents.
from marteengine.
I'm doing it a different way. Basically, my PhysicsEntity holds nothing but data. The mover calculates the forces on an entity, updates their location, and does movement logic (like switching direction when you hit a wall).
In your example, you would simply have a different method for 'calculateForces()' depending on which engine you use. It would still only use one mover, and still be decoupled from the entity itself.
from marteengine.
Related Issues (20)
- java.lang.NullPointerException when using setGraphic() HOT 11
- Compiling Help HOT 7
- Collision detection problems (0.2) HOT 8
- World forces the extending class to call super HOT 2
- Any way to delay? HOT 5
- marte engine jar file? HOT 1
- World problem HOT 2
- Tween example isn't working HOT 4
- Renaming sheet parameter width and height in resources.xml HOT 3
- Resource Copies HOT 2
- Background in Starcleaner HOT 5
- World.removeAll() HOT 3
- Entity speed is a Vector2f HOT 2
- default constructor HOT 6
- Problems with the camera HOT 9
- After changing an animation, everything brokes HOT 6
- setAnim() not functioning HOT 3
- resource xml validation HOT 2
- Allow to resort entities HOT 5
- What is an entity? HOT 10
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 marteengine.