most efficient way to draw a line

[systemlord01]

Hey guys another question.

 

What is the most efficient way to draw a line and then remove it again after a short amount of time?

In the image bellow you will see that some orange lines (not the red or the blue traces but the straight orange lines).

These are supposed to represent shots being fired between the blue and the red particle trails. (these are space ships) 

With a lower amount of  spaceships this seems to work fine. But when the numbers get highter the lines get added and removed to late and are not positioned from and to a ship anymore. They also take alot longer to get removed.

 

I am using setTimeout to remove them. Maybe this is not the most efficient way. Or maybe there is a more efficient way to draw a line and then remove it. 

 

I am using:

 

this.shootingGraphic.strokeLineShape(line)

 

setTimeout(() => {

this.shootingGraphic.clear();

 

}, 50);

 

[mattstyles]

Hi @systemlord01

Welcome to the forums!

Nothing wrong with using a setTimeout to clear things, but, it becomes a little detached from your game state.

Maybe consider putting those lines in to the state of the game and rendering them every frame?

When they _should_ disappear, delete them from the state and they won't be rendered anymore.

An array would do just fine, iterate over it drawing lines and remove them from the data when it makes sense to do so.

16 hours ago, systemlord01 said:

With a lower amount of  spaceships this seems to work fine. But when the numbers get highter the lines get added and removed to late and are not positioned from and to a ship anymore. They also take alot longer to get removed.

This is what leads me to think that your rendering state and your game logic states are becoming de-synced.

Maybe think about ownership.

If ships own bullets and they keep a record of their previous shots, and these shots have a lifetime then periodically you can remove them.

i.e. 

A ship could have an array of 'alive' bullets. When a ship fires they add an 'alive' bullet to the list.

Each game tick you iterate over this alive bullet list and perform some logic. That logic could be moving the bullet, checking for collisions, removing them etc etc

Your rendering loop then uses that alive bullet to draw graphics (bullets, lines, etc).

This decouples your game state and your rendering state. Almost always this is a good thing.

Of course, ships don't have to own bullets, when they fire they could add it to a game 'alive' bullets list. The important thing is just that there is a list somewhere that you iterate over periodically to update and render. Where this is kept is up to a number of factors including (but not exhaustively) developer preference and game logic patterns the project follows, note that you can change this stuff as your game grows, sometimes it is easy to do so, sometimes very hard, learning where and how to make these decisions can be tough and is largely driven by experience, even the very best will get it wrong frequently, the most important thing is not be frozen by this, get something working, then make it better as you need to.

Good luck with your game, the screenshot looks pretty exciting and your scope sounds pretty big, best of luck with making it a reality!

[systemlord01]

Thank you for you reply. 

This is indeed the core problem. When i update the state (with rxjs) i also add and remove things from the scene.

Instead i should update the state and reflect the state in the game update loop.

I am correct in my interpretation of your reply? 

[mattstyles]

Yep, exactly.

If you're using rxjs you're probably comfortable how stuff like React, NG2, Vue, etc work and it isn't too different from that. You decouple state and render, render is then based on state. It's up to you if you use a redux-style single state object or not, you'll probably not do that and have state managed in multiple places, which is totally fine. It's just the concept of rendering based on the state.

If you check-out how Pixi works, then it has the concept of a scenegraph which holds the data for the scene, the renderer then does its thing based on that scene graph. I think this is pretty standard for many rendering pipelines.