Mythruna
March 28, 2024, 02:09:07 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Welcome to the new forums. See "Announcements" for a note for new users.
 
   Home   Help Search Login Register  
Pages: 1 [2] 3 4 ... 8
  Print  
Author Topic: Productive tangents...  (Read 78094 times)
Rayblon
Donators
Hero Member
***
Posts: 1861


Hmmm...


View Profile
« Reply #15 on: April 05, 2015, 10:59:17 PM »

I have to keep it simple because man I'd love to make a persistent world sci-fi MMO... and I really have to be careful. Smiley  Down that path is major time suckage.

Hey, as long as you get your time's worth in money, right? Tongue
Logged

pspeed
Administrator
Hero Member
*****
Posts: 5612



View Profile
« Reply #16 on: April 05, 2015, 11:05:41 PM »

I have to keep it simple because man I'd love to make a persistent world sci-fi MMO... and I really have to be careful. Smiley  Down that path is major time suckage.

Hey, as long as you get your time's worth in money, right? Tongue

Indeed... but let's at least keep the horse within sight of the cart. Smiley
Logged
Rayblon
Donators
Hero Member
***
Posts: 1861


Hmmm...


View Profile
« Reply #17 on: April 05, 2015, 11:55:13 PM »

I actually want to say one last thing here, because it's something that I, myself have dealt with before. Even with the risk of losing upgrades and the like, there comes a point where the credits will essentially make losses of no consequence to you, because you have an ungodly amount of them. That's kind of why I wanted the walk-in bases; so that people had an outlet to blow those credits that they'll never end up spending otherwise because they've got 20,000,000 of them. That 20,000,000 might all get spent in a day upgrading their space base, and the next thing you know, they're back in risky territory... but also have something to show for their previously insane amount of money. Now, I'm sure you'd be able to buy cosmetic items for credits and such, but eventually you can buy all of that; a space base has near infinite room for additions. Call it a sort of prestige system, if you will. Bases would also allow you to show off things like trophies from big tourneys and events too, I suppose.

It makes you kind of feel like a celebrity sports player, too... Using your winnings to build a shaq mansion... in freakin' space, ma'an.


Of course, as you said, this would likely come as an enhancement later on rather than something you'd be shipping the first complete release with.

Also we both clearly have terrible sleep schedules xD
« Last Edit: April 06, 2015, 12:47:02 AM by Rayblon » Logged

pspeed
Administrator
Hero Member
*****
Posts: 5612



View Profile
« Reply #18 on: April 06, 2015, 01:53:40 AM »

Oh, my days are almost completely upside down.  Stress-insomnia means I don't even try until I'm exhausted.

I think there is another point that we'll have to wait and see how fast or likely credits sky-rocket.  If I've done my job right, only the really good/busy players get to that point of comfort.  And maybe the buy-in for a session goes up as your ship gets 'more expensive'... which would also make veterans less likely to pick on newbs... or at least they'd have to pay more to do it.

There could also be special events where the minimum buy-in is higher or something to get "I am the champion of the champions" bragging rights.  Maybe to get up on a server-wide leader board.

I'm not saying I don't like your diegetic interface ideas... after all, I love that... but there are other ways to postpone the necessity. Smiley

Logged
Rayblon
Donators
Hero Member
***
Posts: 1861


Hmmm...


View Profile
« Reply #19 on: April 06, 2015, 11:06:52 PM »

I got a bunch of my friends on the hype train already. Something tells me that means this is very marketable.

If there's any way I can be of assistance, just ask, by the way. That has always been my policy here, and always will be.
Logged

pspeed
Administrator
Hero Member
*****
Posts: 5612



View Profile
« Reply #20 on: April 07, 2015, 07:34:25 AM »

I got a bunch of my friends on the hype train already. Something tells me that means this is very marketable.

If there's any way I can be of assistance, just ask, by the way. That has always been my policy here, and always will be.

Cool, thanks.

I got an asteroid moving using a simple physics engine last night with the proper hooks to pump to the network layer eventually.  It was kind of nice to see as there was a lot 'this is real' code that needed to be implemented to make that happen.

Now I will have to decide if I write my own collision detection stuff or potentially look at integrating an off-the-shelf 2D physics engine like dyn4j or something... though that might let me use it just for collision detection.  The sprites I have are varied enough that simple circle/sphere collisions aren't going to cut it.  I'll have to see if dyn4j has anything to build a collision shape from a sprite as then it's a clear "saves me tons of time" winner.
Logged
Rayblon
Donators
Hero Member
***
Posts: 1861


Hmmm...


View Profile
« Reply #21 on: April 07, 2015, 08:06:40 AM »

How are you going to be communicating the position of the asteroids, anyhow?

 I guess it can only either be positional or be like "Here is where it is now and here is the  directional velocity until it hits something", but I was just wondering. One of these things seems to make big servers easier to host, is all... not that I know much about networking. I just know about how raycasting can be used in 3D games to maintain smooth looking movement of projectiles even with high latency.
« Last Edit: April 07, 2015, 09:16:25 AM by Rayblon » Logged

pspeed
Administrator
Hero Member
*****
Posts: 5612



View Profile
« Reply #22 on: April 07, 2015, 11:53:30 AM »

How are you going to be communicating the position of the asteroids, anyhow?

 I guess it can only either be positional or be like "Here is where it is now and here is the  directional velocity until it hits something", but I was just wondering. One of these things seems to make big servers easier to host, is all... not that I know much about networking. I just know about how raycasting can be used in 3D games to maintain smooth looking movement of projectiles even with high latency.

If I understand the question... the server will sent the position and orientation.  The more detailed description is way more complicated than that.
Logged
Rayblon
Donators
Hero Member
***
Posts: 1861


Hmmm...


View Profile
« Reply #23 on: April 07, 2015, 12:53:58 PM »

If I understand the question... the server will sent the position and orientation.  The more detailed description is way more complicated than that.

Yeah, that was the answer I was looking for... I think.

So basically, I was asking if the asteroid data that the server sends looks more like:

Asteroid 1
Pos: [23,4]
Rot: 36*
Sprite/shape: 5

or...

Asteroid 2
Pos: [23,49]
Rot: 124*
Sprite/shape: 5
Travelling direction: 92*
Velocity: 12

Where direction and velocity "allow the client to make independent calculations between updates to prevent choppiness from a bad connection/bogged down server".
« Last Edit: April 07, 2015, 04:38:34 PM by Rayblon » Logged

Michael
Donators
Hero Member
***
Posts: 2166



View Profile
« Reply #24 on: April 07, 2015, 03:31:02 PM »

I got a bunch of my friends on the hype train already. Something tells me that means this is very marketable.

If there's any way I can be of assistance, just ask, by the way. That has always been my policy here, and always will be.

Cool, thanks.

I got an asteroid moving using a simple physics engine last night with the proper hooks to pump to the network layer eventually.  It was kind of nice to see as there was a lot 'this is real' code that needed to be implemented to make that happen.

Now I will have to decide if I write my own collision detection stuff or potentially look at integrating an off-the-shelf 2D physics engine like dyn4j or something... though that might let me use it just for collision detection.  The sprites I have are varied enough that simple circle/sphere collisions aren't going to cut it.  I'll have to see if dyn4j has anything to build a collision shape from a sprite as then it's a clear "saves me tons of time" winner.
The Java Box2D port is good for custom-defined shapes (vertices), if you'd like to look into that.
Logged
pspeed
Administrator
Hero Member
*****
Posts: 5612



View Profile
« Reply #25 on: April 07, 2015, 06:23:56 PM »

I got a bunch of my friends on the hype train already. Something tells me that means this is very marketable.

If there's any way I can be of assistance, just ask, by the way. That has always been my policy here, and always will be.

Cool, thanks.

I got an asteroid moving using a simple physics engine last night with the proper hooks to pump to the network layer eventually.  It was kind of nice to see as there was a lot 'this is real' code that needed to be implemented to make that happen.

Now I will have to decide if I write my own collision detection stuff or potentially look at integrating an off-the-shelf 2D physics engine like dyn4j or something... though that might let me use it just for collision detection.  The sprites I have are varied enough that simple circle/sphere collisions aren't going to cut it.  I'll have to see if dyn4j has anything to build a collision shape from a sprite as then it's a clear "saves me tons of time" winner.
The Java Box2D port is good for custom-defined shapes (vertices), if you'd like to look into that.

Many people I know who have used both prefer dyn4j for some reason.

...but if I have deconstruct a pixel sprite into shapes then I've already all of the hard work myself.
Logged
pspeed
Administrator
Hero Member
*****
Posts: 5612



View Profile
« Reply #26 on: April 07, 2015, 06:25:52 PM »

Where direction and velocity "allow the client to make independent calculations between updates to prevent choppiness from a bad connection/bogged down server".

This is called prediction and it has noticeably jarring artifacts of its own as the predictions could be inaccurate.

At the risk of providing too much information, these articles are good if you are interested in the subject and they are largely the method I employ:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
Logged
Rayblon
Donators
Hero Member
***
Posts: 1861


Hmmm...


View Profile
« Reply #27 on: April 07, 2015, 07:29:33 PM »

Where direction and velocity "allow the client to make independent calculations between updates to prevent choppiness from a bad connection/bogged down server".

This is called prediction and it has noticeably jarring artifacts of its own as the predictions could be inaccurate.

At the risk of providing too much information, these articles are good if you are interested in the subject and they are largely the method I employ:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

I found this in the second article that seems to fit my description fairly well.

"For extrapolation, the other player/object is simulated forward in time from the last known spot, direction, and velocity in more or less a ballistic manner. Thus, if you are 100 milliseconds lagged, and the last update you received was that (as above) the other player was running 500 units per second perpendicular to your view, then the client could assume that in "real time" the player has moved 50 units straight ahead from that last known position. The client could then just draw the player at that extrapolated position and the local player could still more or less aim right at the other player."


I understand the possibility of the extrapolations/predictions being inaccurate... But with the behavior of traditional static-velocity asteroids I can't imagine extrapolation leaving you any worse off filling in the gaps with asteroids than lag compensation, however interesting the system may be.

I can't say that extrapolation is a good choice when dealing with player ships and the like. I just see the possibility of lowered network usage for those annoying little space rocks. I figure it'd be light on big servers... But as I always say... I'm not a networking specialist.
Logged

Rayblon
Donators
Hero Member
***
Posts: 1861


Hmmm...


View Profile
« Reply #28 on: April 07, 2015, 07:42:35 PM »

I found an article on the making of Asteroids, if you're interested.

http://www.rawbw.com/~delman/pdf/making_of_Asteroids.pdf


Turns out you're working on a remake of a remake, so to speak. xD


« Last Edit: April 07, 2015, 08:11:46 PM by Rayblon » Logged

pspeed
Administrator
Hero Member
*****
Posts: 5612



View Profile
« Reply #29 on: April 07, 2015, 08:02:09 PM »

Where direction and velocity "allow the client to make independent calculations between updates to prevent choppiness from a bad connection/bogged down server".

This is called prediction and it has noticeably jarring artifacts of its own as the predictions could be inaccurate.

At the risk of providing too much information, these articles are good if you are interested in the subject and they are largely the method I employ:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

I found this in the second article that seems to fit my description fairly well.

"For extrapolation, the other player/object is simulated forward in time from the last known spot, direction, and velocity in more or less a ballistic manner. Thus, if you are 100 milliseconds lagged, and the last update you received was that (as above) the other player was running 500 units per second perpendicular to your view, then the client could assume that in "real time" the player has moved 50 units straight ahead from that last known position. The client could then just draw the player at that extrapolated position and the local player could still more or less aim right at the other player."


I understand the possibility of the extrapolations/predictions being inaccurate... But with the behavior of traditional static-velocity asteroids I can't imagine extrapolation leaving you any worse off filling in the gaps with asteroids than lag compensation, however interesting the system may be.

I can't say that extrapolation is a good choice when dealing with player ships and the like. I just see the possibility of lowered network usage for those annoying little space rocks. I figure it'd be light on big servers... But as I always say... I'm not a networking specialist.

It's the same amount of data either way... and I highly compress that data and only send what changes, anyway.  I'm able to get like 70-80 object updates in a single (typical) MTU (1500 bytes).  Actually, in your case you need more data  because you need to send linear and rotational velocities with position.  I send the messages using UDP so I must implement some redundancy ack/nack scheme on top of that so you can't even get away with dead reckoning, really.  That would mean you have to force reliability... where I don't.  If I send all position histories for a certain period back in time I can ignore any updates that are older than some time.

Extrapolation is a problem because it gets worse the higher your lag is or the more chaotic your objects.  Asteroids may not always travel in a straight trajectory because they are affected by other things... and in any case, the ships themselves are going to be super chaotic.  And once you have one thing that you have to use the interpolated history approach on then you have to do it for everything.
Logged
Pages: 1 [2] 3 4 ... 8
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.20 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!