Java-Gaming.org Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (808)
Games in Android Showcase (239)
games submitted by our members
Games in WIP (872)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Implementing tween engine with entity system?  (Read 4119 times)
0 Members and 1 Guest are viewing this topic.
Offline bmanmcfly
« Posted 2016-12-04 22:39:09 »

Hi,

I was looking at the tween engine, and was thinking about how useful that seems like it could be to sequence events, like introductions into levels, etc...

So, I was hoping that someone who has used this tool could help me, potentially to save some time figuring out how to add this in.

The setup I have right now is that the program starts with a loading / screen, then the main game is on a screen, that screen loads the map.  The game screen creates the "world", the world builds all the game objects (terrain, player, other game objects), then the world updates handles the updating of all the entities.

So, based on the tutorials, which all seem to take the simplest projects to add to, makes me think I should have started with that... anyway,

What is needed :
- the accessors
- The registration
- The manager to update

Ultimately, I'm just putting this question out there to potentially prevent any issues and to minimize the time it will take to add the tween engine to this project...

So, I have the accessor class, which I've made a number of different accessors to handle different possibilities (sprites, though the location of the sprites and the animations will be tied to the polygon, so I have a polygon and a vector accessor, which I think I could simplify to an "entity" accessor to be able to manipulate a wider range of variables).

I wasn't quite so certain about the tween manager, I was thinking a tween manager for the different screens, and then a tween manager in the "world" class for the game screen? The important one being the world, which would update the tweens while updating all the entities...

Does this make sense?

A follow up question on this one, also a potential time saver;
Is there a reason why a person would not want to use tweens for player movement (ex: acceleration / deceleration for movement), the idea I was thinking was that each state change would initiate the relevant tweens on that object (ex: falling off an edge would take the downward speed and accelerate to the max falling speed)?

or is this an idea I should reconsider now ?

Thanks for any pointers on this one.
Offline VoidBuffer

Junior Devvie


Medals: 4
Exp: 2 years



« Reply #1 - Posted 2016-12-05 17:30:41 »

Are you talking about the Universal Tween Engine(aurelienribon), or the built in tween engine within libgdx(Interpolation)? Either way I personally haven't come across a use case for either yet that wasn't something I could have easily done myself or through Actors. In your example of using tweening for screen's, this is something you could achieve with the built in Actors which have Actions. For example I use Actor.Actions in order to fade/move/rotate various entities. For example the fading effect on my splash screen is simply:

1  
splashImage.addAction(Actions.sequence(Actions.alpha(0), Actions.fadeIn(FADE_TIME), Actions.delay(FADE_TIME)));


So you can get away with a lot in terms of just using the Actors within LibGDX without having to worry about using a tween engine.

For your second question, this really just depends on how you want to approach your design. I don't personally use tweens for player movement, but instead move a player around by their Vector2 position, which is variable of Vector2 velocity. From there I can modify the players position by adjusting their position.x and position.y, likewise with velocity. If your moving via velocity, you can add that to your position data as such:

1  
position.add(velocity.cpy().scl(Gdx.graphics.getDeltaTime() * SPEED)); // Updating position of player


I hope that helps Smiley This post was a bit broad so I kind of pulled out my shotgun and spray fired a little.
Offline bmanmcfly
« Reply #2 - Posted 2016-12-05 19:45:00 »

Are you talking about the Universal Tween Engine(aurelienribon), or the built in tween engine within libgdx(Interpolation)? Either way I personally haven't come across a use case for either yet that wasn't something I could have easily done myself or through Actors. In your example of using tweening for screen's, this is something you could achieve with the built in Actors which have Actions. For example I use Actor.Actions in order to fade/move/rotate various entities. For example the fading effect on my splash screen is simply:

1  
splashImage.addAction(Actions.sequence(Actions.alpha(0), Actions.fadeIn(FADE_TIME), Actions.delay(FADE_TIME)));


So you can get away with a lot in terms of just using the Actors within LibGDX without having to worry about using a tween engine.

For your second question, this really just depends on how you want to approach your design. I don't personally use tweens for player movement, but instead move a player around by their Vector2 position, which is variable of Vector2 velocity. From there I can modify the players position by adjusting their position.x and position.y, likewise with velocity. If your moving via velocity, you can add that to your position data as such:

1  
position.add(velocity.cpy().scl(Gdx.graphics.getDeltaTime() * SPEED)); // Updating position of player


I hope that helps Smiley This post was a bit broad so I kind of pulled out my shotgun and spray fired a little.

Thanks for the response.

Yes, I was referring to the universal tween engine.  I have used the "interpolation" class for other things, like the camera class so that it's not keeping the player pixel perfect in the center of the screen...

In the general sense, I have the player controls working (but incomplete), and I had the thought that it might simplify matters if I could change things so that instead of calculating speed and having a damping to slow down or whatever, that I could just interpolate the speed... 

I put the question up because I had reservations about heading down another rabbit trail, like what I wound up doing because I was adamant that  I wanted to have slopes in a platformer (had to learn SAT algorithm, figuring out way points between terrain transitions, etc... probably cost me several months in what little time I do spend coding)...

Your suggestion about using speed and position vectors to handle motion, that's what I've got setup as it is...

So, my player update is effectively :
- if airborne: calculate X part of the speed vector, calculate Y part of speed vector
- if grounded: check the direction of the terrain, calculate the speed on the terrain, scaled to the direction
- check collisions for the desired position
- adjust speed if needed and move to the new position.

So, at this point in particular, it's not so much of an issue of a "need" to add in the tween engine for controls, I just had the idea that using tweens might simplify controls, but even overnight in starting the setup of integrating tweens into the controls, I'm starting to see some potential problems (things like transitioning from one tween to the next)... I could still see some uses for it, like if the player is hurt would make the player flashing to show invulnerability....  anyway.

You do raise a different question, I hope that I ask it the right way to be most pertinent :

If you are using actors, doesn't that involve using a stage and all that?  Or can that be made to work with the screens?

While, I intend to look into this a bit deeper, it is starting to look like just manipulating vectors is the easiest approach anyway, though I think I will use the tween engine for periods where the player does not have control over the character... like in interlude sections, or where story is being developed.  Too bad I still need to get the player controls complete first before I start worrying about issues like 'movie sequences'...



Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline VoidBuffer

Junior Devvie


Medals: 4
Exp: 2 years



« Reply #3 - Posted 2016-12-06 00:13:48 »

I'm having a hard time understanding exactly what you would be using tweens for, especially when you mention that you want to apply tween to movement. My understanding of tweens is the manipulation of sprites and effects such as your example of a sprite flashing, not necessarily physics. If you need something to handle physics and angles, you could try and look into Box2D physics which could make your life easier, or maybe even just apply your own collision. As far as tweens go, I feel you can get away with using Actors or Shaders in order to apply effects to your character. All in all I feel it just depends on your approach to how you want to make things like cut scenes. For cut scenes in games, I've seen developers directly manipulate the velocity/position of their models. For example a warcraft cut scene where your character is being controlled, or even in the classic mario brother games when you win a level and he jumps on the flag at the end. Alternatively the larger studio games actually have amazing cinematic scenes that overlap the real game screen, like world of craft and many others... It just depends on how you want to do it.

Just to answer you question, yes an Actor will use a Stage which can be used on a Screen. If you are using Sprites with Spritebatch, then you'll be familiar with having to use spritebatch.begin()/end(). Actors and their Stage object are just like a Sprite/batch with their batch object, but they just offer more features. Check out this post: http://stackoverflow.com/questions/10619394/when-to-use-actors-in-libgdx-what-are-cons-and-pros

Here is my personal example of my main game Screen, which is by no means a definitive go-to guide. I just feel it's helpful to show a different approach to different problems:

Actors - I use them for my in-game UI, because I like applying effects/actions to certain UI buttons. It's as easy to make Actors and have them part of a Stage, because all you need to do is just put that stage into your render() method, and run it. Going deeper, I add my Actors to a Table, which helps me organize my UI so that it's easy to align on my screen. It also helps with resolution scaling because I'm making a desktop game, and my Table will automatically re-scale the properties of all my UI depending on the resolution.

Sprites - I use these for my player/enemy entities. Since I'm making a 2D game, I can get away with simply rotating my sprites when I'm changing direction, and you can swap textures of those sprites with other textures if you want to emulate some sort of complex animation(Or just use 2D Particle Editor).

Shaders - You can use shaders for different types of transition/color effects. This is applied to mostly my sprites, but I already try and make my own solutions before I may use shaders.
Offline bmanmcfly
« Reply #4 - Posted 2016-12-06 17:10:53 »

I'm having a hard time understanding exactly what you would be using tweens for, especially when you mention that you want to apply tween to movement.

So, here's what I had imagined in my head when looking at the examples of what can be done with the tween engine :
First, and most importantly, I was thinking that it could be useful to control NPC movement, or someone runs past to tell you something when crossing a checkpoint type of thing, then I thought it would be useful for the flashing effect...

Then, I got creative, and I thought, "hey, I could use it for controls too, like when you start running the speed could be interpolated from the standing (speed = 0) to max run speed, or a jump could change the speed from the jump speed to max fall speed, etc...

Having had the chance to look a little deeper, it seems that this type of interpolation would get real messy real quick, and it seems that it's best that there be "triggers" and while the trigger is active start a set of tweens and return control (except things like flashing which doesn't impact motion on its own)


Quote
My understanding of tweens is the manipulation of sprites and effects such as your example of a sprite flashing, not necessarily physics. If you need something to handle physics and angles, you could try and look into Box2D physics which could make your life easier, or maybe even just apply your own collision.

Actually, I already have the collision detection scheme working (why I would only play with speed, not position)... I tried with box2d, and I could not find a way to get the controls as "fast" as I wanted without the player treating every slope up as a ramp to fly off of.

I did find a bit more about using tweens for controls, and while it does seem like it's doable, it seems that it would require a fair bit of refactoring... and I've done that too many times as it is (first go, I was using box2d, which I could not figure out how to get the controls the way I wanted... so, I ripped out box2d.  Then, I had poorly planned the project structure, so I refactored to make an entity system.)

What I wound up using was the intersector class with libgdx, where the desired position is calculated, any intersections are calculated from that position, and if needed speed gets recalculated to exactly arrive at the collision.... it works even with absurd speeds.

Quote
As far as tweens go, I feel you can get away with using Actors or Shaders in order to apply effects to your character. All in all I feel it just depends on your approach to how you want to make things like cut scenes. For cut scenes in games, I've seen developers directly manipulate the velocity/position of their models. For example a warcraft cut scene where your character is being controlled, or even in the classic mario brother games when you win a level and he jumps on the flag at the end. Alternatively the larger studio games actually have amazing cinematic scenes that overlap the real game screen, like world of craft and many others... It just depends on how you want to do it.

I'm still a noob, so the tweens / cut scenes I'd be looking at would be FAR CLOSER to Mario style than world of Warcraft style...

Quote
Just to answer you question, yes an Actor will use a Stage which can be used on a Screen. If you are using Sprites with Spritebatch, then you'll be familiar with having to use spritebatch.begin()/end(). Actors and their Stage object are just like a Sprite/batch with their batch object, but they just offer more features. Check out this post: http://stackoverflow.com/questions/10619394/when-to-use-actors-in-libgdx-what-are-cons-and-pros

Hmm... thanks for the link, I'll look it up...

As it stands, I have :
baseEntity: has the shape, position, speed, and whether or not it will be updated
groundEntity: is a base entity that has the extra data for handling terrain collisions (like the walkpath of terrain)
player: adds the sprite....

it might be worth looking into to make use of extra functionality if it doesn't add too much grief.


Quote
Here is my personal example of my main game Screen, which is by no means a definitive go-to guide. I just feel it's helpful to show a different approach to different problems:

Actors - I use them for my in-game UI, because I like applying effects/actions to certain UI buttons. It's as easy to make Actors and have them part of a Stage, because all you need to do is just put that stage into your render() method, and run it. Going deeper, I add my Actors to a Table, which helps me organize my UI so that it's easy to align on my screen. It also helps with resolution scaling because I'm making a desktop game, and my Table will automatically re-scale the properties of all my UI depending on the resolution.

Sprites - I use these for my player/enemy entities. Since I'm making a 2D game, I can get away with simply rotating my sprites when I'm changing direction, and you can swap textures of those sprites with other textures if you want to emulate some sort of complex animation(Or just use 2D Particle Editor).

Shaders - You can use shaders for different types of transition/color effects. This is applied to mostly my sprites, but I already try and make my own solutions before I may use shaders.

Actually, that's what I thought was the use for actors / stage was to handle UI, but that it would be possible to use it for simple collision detection, etc...

That's more or less where I'm at now with sprites, although I don't bother rotating the sprites for slopes... and I'm still debating if I want to mirror the sprites (at least the main player character) or if I want to do like Metroid and ensure that no matter what the gun arm is always on the right...

I have a feeling I'll have to learn more about shaders... but that can wait until I'm a little deeper in.  I gotta stop talking about it so much because it's still in a state that's even too pathetic to put on WIP.
Offline Gornova
« Reply #5 - Posted 2016-12-07 10:01:14 »

I've made a simple Tweener for my library, you can find it here

Blog | Last game Number+
Offline bmanmcfly
« Reply #6 - Posted 2016-12-08 20:21:21 »

I've made a simple Tweener for my library, you can find it here

Thanks for the link. 

I took a bit of time to look through the repository, and it was somewhat comforting to see just how similar you setup the entities and a few other things is with how I wound up setting things up.

I do look forward to testing out that shade one, I can see from that one that can do some favors for things I aim to do in the future.
Offline Gornova
« Reply #7 - Posted 2016-12-09 09:11:05 »

you are welcome! Most of MarteEngine design philosophy came from Flashpunk and be aware that an entity model (without thinking about tweening) it's useful, IMHO, for small games: be aware that for "big games" could be really a mess!

Blog | Last game Number+
Offline bmanmcfly
« Reply #8 - Posted 2016-12-09 15:57:54 »

you are welcome! Most of MarteEngine design philosophy came from Flashpunk and be aware that an entity model (without thinking about tweening) it's useful, IMHO, for small games: be aware that for "big games" could be really a mess!

In what way?  I find code to be so much more readable with entities, and where sorting is required, everything just goes through large switch statements for different types of entities...

It seems the alternative of keeping everything as classes got a lot more confusing for games a lot faster?

Mind you, I'd be happy to complete 1 "small game" (I'm aiming at something the scale of "ninja gaiden" for nes / snes currently), and worry about the complications with something bigger once I start not feeling like quite the noob...
Pages: [1]
  ignore  |  Print  
 
 

 
mercenarius (4 views)
2020-06-04 19:26:01

mercenarius (2 views)
2020-06-04 19:13:43

Riven (850 views)
2019-09-04 15:33:17

hadezbladez (5834 views)
2018-11-16 13:46:03

hadezbladez (2635 views)
2018-11-16 13:41:33

hadezbladez (6251 views)
2018-11-16 13:35:35

hadezbladez (1504 views)
2018-11-16 13:32:03

EgonOlsen (4739 views)
2018-06-10 19:43:48

EgonOlsen (5797 views)
2018-06-10 19:43:44

EgonOlsen (3282 views)
2018-06-10 19:43:20
A NON-ideal modular configuration for Eclipse with JavaFX
by philfrei
2019-12-19 19:35:12

Java Gaming Resources
by philfrei
2019-05-14 16:15:13

Deployment and Packaging
by philfrei
2019-05-08 15:15:36

Deployment and Packaging
by philfrei
2019-05-08 15:13:34

Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!