Implement health for ships/asteroids

[ntpeters]

Ships and asteroids need a way to keep track of their health.

[ntpeters]

Should we also include player score within the ship entity? This would make things easy when implementing multiplayer and sending the data to the server.

[dementeddr]

I thought they just got destroyed the first time they got hit by something.

On Mon, Oct 29, 2012 at 4:28 PM, Nate Peterson notifications@github.comwrote:

Ships and asteroids need a way to keep track of their health.

— Reply to this email directly or view it on GitHubhttps://github.com/stryderinnovations/Broids/issues/57.

"I know you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." --Robert McLosky

[ntpeters]

Um, not for multiplayer. For multiplayer we would want some sort of health system, otherwise things would get too crazy and players could potentially die too quickly.

[dementeddr]

I've been working on that. On creation, the bullet saves the current system time in milliseconds. During each call to the draw method (or maybe somewhere else, still working on it) the method checks the current time against the saved time. If it is more than, say, three seconds, then the bullet dies.

On Tue, Oct 30, 2012 at 1:26 PM, Nate Peterson notifications@github.comwrote:

What if they don't hit anything? There has to be a way for them to die. We don't want the number of bullets on the screen to grow unbounded.

— Reply to this email directly or view it on GitHubhttps://github.com/stryderinnovations/Broids/issues/57#issuecomment-9914847.

"I know you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." --Robert McLosky

[ntpeters]

Okay, cool. That sounds good. You would probably want to look into using delta time though instead of system time. There may be issues if different clients have different system times. Delta time is created and managed by LibGDX, so there should be some way to access it. Look at where GameScreen is getting it from.

[dementeddr]

I'll look into that, although it shouldn't matter in multiplayer. Isn't each client responsible for their own bullets and other entities?

On Tue, Oct 30, 2012 at 1:43 PM, Nate Peterson notifications@github.comwrote:

Okay, cool. That sounds good. You would probably want to look into using delta time though instead of system time. There may be issues if different clients have different system times. Delta time is created and managed by LibGDX, so there should be some way to access it. Look at where GameScreen is getting it from.

— Reply to this email directly or view it on GitHubhttps://github.com/stryderinnovations/Broids/issues/57#issuecomment-9915607.

"I know you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." --Robert McLosky

[ntpeters]

No. We need to sync all entities to all clients. If you start shooting on client 1, client 2 should be able to see the bullets as well. Also, don't change draw. That should only be used for drawing. For game programming the delta of each frame should really be what is used for all calculations.

[dementeddr]

Right, all clients should see them, but doesn't client 1 manages them because it's the one that generated the bullets in the first place?

On Tue, Oct 30, 2012 at 1:53 PM, Nate Peterson notifications@github.comwrote:

No. We need to sync all entities to all clients. If you start shooting on client 1, client 2 should be able to see the bullets as well.

— Reply to this email directly or view it on GitHubhttps://github.com/stryderinnovations/Broids/issues/57#issuecomment-9916010.

"I know you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." --Robert McLosky

[ntpeters]

No. That involves there being a 'host' device. We don't want any single device to host the game. We will be passing all delta data regarding entities to the server for it to send sync frames to all of the clients. When each client receives the sync data from the server, it will update all of the the entities it has stored and the backend will handle all calculations. After the calculations are completed it will then send all updated delta data back to the server. Rinse and repeat.

[ntpeters]

To clarify, we are going to have a "host" device, but it will strictly be in charge of spawning asteroids and power-ups. It will not be handling any game logic. All game logic will be handled individually on each client based upon the data received from the server. Likewise, the server will not contain any game logic, it will essentially be acting as a central hub holding all data about any active games and sending/receiving the relevant data to all clients for each game.

If anything else is unclear, feel free to ask.

[dementeddr]

Health is implemented. Shield is not.

[krgauthi]

Huh? It won't be server side talk to kaleb and stop pushing to origin On Dec 7, 2012 10:53 PM, "Rex Baumeister" notifications@github.com wrote:

Health is implemented. Shield is not.

— Reply to this email directly or view it on GitHubhttps://github.com/stryderinnovations/Broids/issues/57#issuecomment-11154570.

[dementeddr]

I talked to Kaleb. The way it is implemented will be simple to add to the server. Also, I didn't push to origin.

[krgauthi]

Alright I'm on my phone it looked like it went to origin sorry bout that On Dec 7, 2012 11:25 PM, "Rex Baumeister" notifications@github.com wrote:

I talked to Kaleb. The way it is implemented will be simple to add to the server. Also, I didn't push to origin.

— Reply to this email directly or view it on GitHubhttps://github.com/stryderinnovations/Broids/issues/57#issuecomment-11154817.

[dementeddr]

'Sokay.

[dementeddr]

Shield is now completely implemented.