Ripper
-
Posts
630 -
Joined
-
Last visited
Posts posted by Ripper
-
-
Well, What needs to be verified.
- Did the player actually hit the target?
- What did he hit the targe with?
- Where did he hit the target?
- How much damage did he do?
Answer:
- He had to be "locked on" or the target had to be selected via "RPG Targeting" - Server Verified
- Hit type ... (server supplied - see below)
- The location can be determined client side and trasmitted to the other client.
- A regularly updated damage table(once per second? balanced for load), that's queried by the damaged player. - Server Supplied
Let's consider how we prevent the attacker from changing that "Size 1 laser" to a "Size 5 laser".
I seriously doubt a hacker is going to be able to specify a certain voxel to hit. So, hit location shouldn't be an issue.
-
Thanks,
WHY does "RPG Targeting" exist? Its sole purpose is anti-cheat. I have to be in range, and hopefully facing my target to do damage to it. This prevents a malicious user from dropping a fireball on me from the other side of the game map.
Once targeted, the player can click to their hearts content to apply damage, and the server sends "pre-defined" damage packets to Player 2, based upon the type of damage inflicted.
Hit detection on the average FPS is verified server side, and can be extremely complex which creates a load on the server.
If the detection and location of damage were client side, those packets could be sent from client to client.
The only other consideration is magnitude of damage. There would need to be a way to indicate that the standard "Size 1 laser shot" does 20 points of damage, and an anti-cheat mechanism that would prevent player1 from modifying that value.
Maybe. The clients only transmit hit type and location. Then the damaged client would request the amount of damage from the server. In fact, the client would only need to request the "damage table" every so often. That way it would reference the table instead of making a query every single hit. This would prohibit the player from modifying the damage table, because it would be regularly overwritten.
-
A post on a previous thread got me to thinking.
In some probing of Nyzaltar, some time ago, he proclaimed the game will feature targeting mechanics over fps style. So at the very least you wont be expected to dodge bullets with reaction times.
This makes a lot of sense from the single shard approach. Hit detection becomes MUCH more difficult when the server has to account for rubberbanding.
Of course there are those of us that would like to be able to hit specific parts of a ship to disable it.
The player base is going to WANT "FPS Hit Detection" instead of "RPG Targeting".
Here's a thought:
Consider the missile "lock on" reticle. Your ship usually has to face the target and have it close the the cross hairs in order for your missiles to lock on.
Now imagine an invisible "lock on" reticle (because the player doesn't need to see it). This reticle is strictly an anticheat mechanism. This reticle is much more difficult to achieve, and the lock doesn't last very long. The game client transmits a "locked on to player 2" packet to the server, which is verified.
This is essentially an "RPG Target". Instead of clicking on a MOB the client selects it for me.
Then when Player1 shoots at Player2, the damage all hit detection is done client side. If they're "locked on", the damage is applied to Player2. (much like my lightningbolt hitting a MOB)
And consider this... The server only has to transmit "locked status".
All damage could be transmitted between clients (with the occasional additional anti-cheat mechanisms in place). This would reduce network infrastructure load. EDIT - See Post 5 & 7 for clarification
What do you think?
-
In some probing of Nyzaltar, some time ago, he proclaimed the game will feature targeting mechanics over fps style. So at the very least you wont be expected to dodge bullets with reaction times.
This explains a LOT.
From the previous "sniper" scenario, with hit detection I hadn't considered the following:
Long range targets may rubberband, due to the network mechanics. Hit detection would need to be verified by the server, which is required for protection from cheating. When two players are at close range, the server would need to have a stringent hit detection, and when they are at much longer ranges, the server requirements would need to "loosen up" to allow for rubberbanding. It's certainly doable, but much more complicated.
The problem of hit detection is resolved with targeting.
-
Here are the Dev Blogs of interest
Building with Voxels
https://board.dualthegame.com/index.php?/topic/378-devblog-builder-gameplay-voxel-tools-elements/
Tools:
https://board.dualthegame.com/index.php?/topic/14-voxel-tools-pre-alpha-game-design/
Rights Management:
https://board.dualthegame.com/index.php?/topic/272-devblog-rights-duty-management-system-rdms/
Economy:
https://devblog.dualthegame.com/2014/12/04/from-barter-to-market-economy/
My understanding is you buy the construct. Unless the builder actually offers the blueprint for sale.
Of course, there's nothing stopping the player from reverse engineering the construct.
-
Welcome to the forum.
The Dev blog on the Market Economy has a really good explanation of what they're wanting to do.
https://devblog.dualthegame.com/2014/12/04/from-barter-to-market-economy/
-
As a player that likes to bombard people and snipe them from a distance and then go and claim my bounty from their cold dea.... from the place they died, this makes me slightly worried when in populated areas that accuracy long range will not really be possible and that it pushes people to fight closer.
My guess is, hit detection is performed client side, and checked for validity at the server before transmitting a hit to both the attacker and victim.
The client will be able to extrapolate enough information from the updates to estimate a target's course.
My guess is that in a large battle, the ships that are closest to you will behave fairly accurately, whereas ships on the outskirts will likely have a rubberbanding issue.
However, consider this. In CoD, a player bouncing around by 10 feet is a problem. In DU, that cruiser that is 5 kilometers away can bounce 10 feet and not even be noticable.
-
Communication is a key part of community, but I don't believe position and damage states are.
I certainly want to be able to chat with my friend 3 systems away, but my client has no need to know my buddies coordinates or state of health.
At some point there needs to be a horizon, where position and damage state packets aren't sent at all.
Updates based upon proximity to the player makes a lot of sense.
Sniping DOES bring up a question. Consider this scenario:
A sniper is sitting on the edge of a large furball. He wouldn't be able to see everyone in the furball, but he can pick out a handful of enemies to target. He fires and destroys the target.
Now look at the scenario from the targets point of view. He's in the middle of a HUGE battle, where he sees everyone in the furball. Due to the size of the battle, his "Radius" is much smaller due to the density of the battle, so he isn't even aware that the sniper has him in his cross hairs. As he's looking around to make sure nobody is on his six, he's sniped from someone he can't even see.
Will this be an issue? And IS it even an issue, considering the first player is a sniper?
How will this effect combat? Will everyone sit back and snipe? What are the counter measures?
-
A single shard universe is very ambitious.
I'm not saying it cant be done. I have no idea how NQ intends to implement it. IF realistic distances were to be created, the most logical method of transportation between star systems is stargate technology.
If NQ created a wormhole cut scene, theres no reason to have a single shard infrastructure.
-
Hmmm... I wonder if I could build a stargate underground....
-
The Alcubierre drive is a possible FTL engine that "warps" space-time.
Its also been theorized that wormhole can be created and stabilized with exotic matter (not to be confused with antimatter). So creating a "gate" with exotic matter is also possible.
-
If it takes 6 months to travel to Alpha Centauri (our closest neighboring star) at 100 times the speed of light. In order for us to get there in an hour, we would need to travel at 70,000 times the speed of light.
I understand the game needs to have a decent travel time between star systems. I'm wondering how you can justify the concept of traveling 70,000 times the speed of light.
Now consider travel via a stargate. I jump through a stargate into a new star system. I then need to travel to a point of interest. Assuming the star system is the same size as our own solar system, I would still need to travel 30 minutes using the Alcubierre drive to get halfway across the system at 10 times the speed of light.
And this is to a known waypoint of something like a space station. You're not going to be able to explore the star system while traveling FTL.
Discovery and exploration of the system would need to be done via standard thrusters and sensors. Heck, ANY interaction other than point-to-point travel (including maneuvering) should require you to drop out of FTL travel.
I took a look at the PHYSICS thread, and you admit there needs to be some sort of FTL drive. But I didn't see your recommendation. I really don't have a problem with your suggestion regarding normal travel with thrusters.
All-in-all, I'd say this discussion is moot, because the devs already have a plan in place. This thread is just my personal opinion on how to implement travel across a galaxy within a game.
BTW the size of the engine (force applied) would only effect the acceleration, not the speed of the object. A small ship with a large engine would accelerate very quickly, while a large ship with a small engine would accelerate very slowly. Both ships have the potential to travel at any velocity.
-
Oh...
I like your ideas. I wonder if the granularity would cause game balance issues.
-
This solution would ALSO allow Novaquark to build out its universe at its leisure. You could design a handful of star systems, and interconnect them with star gates. The server clusters would be developed to handle the initial player base.
Then Novaquark could design additional content and server infrasturcture once the game becomes a HUGE success. All they would need to do is drop additional jump gates to these new assets, into the existing game.
-
Hey everyone,
These are my thought on FTL and Stargates. They also address the shardless/zoneless concept.
I'm not sure how you plan on instancing your servers, so take this for what its worth.
Space is like a desert, or ocean. There's VAST amounts of nothing, with a few pockets (relatively speaking) of interest. Even within our own solar system, it takes 5.5 hours for light to get from the Sun to Pluto.
What does this mean for space travel? There's a LOT of nothingness to travel through to get to something interesting. Traveling at the speed of light isn't conducive for dogfights, so I don't expect our standard mode of travel to reach those speeds. And I don't want to wait 6 hours to travel halfway across a solar system. And I CERTAINLY want to travel to other star systems.
So here are my thoughts:
- Standard thrusters would be used for normal travel and dogfighting.
- Alcubierre drives would be used for travel WITHIN the system.
- And Stargates would allow for jumps between Star Systems in a timely manner.
The Novaquark supplied Stargates would allow for travel to star systems, but users could still build their own to travel to discovered places.
With the VASTNESS of SPACE, I don't see why there couldn't be zones between star systems. Even an Alcubierre drive would take too long for me to get to Alpha Centauri. It takes 4.5 years for light to travel to Alpha Centauri. 10 times the speed of light, would mean I could get there in 6 months. Even 100 times the speed of light is too long for the game, and it's also unrealistic, but 10 times the speed of light would allow me to travel from the Sun to Pluto in less than 30 minutes, with an Alcubierre drive.
Zoning between stargates would allow for dedicated server clusters for individual star systems. Which would take the load off a centralized server farm.
Alcubierre drives would need to spin up and down, allowing for interdiction. However, its not realistic to have interdiction during FTL travel. Alcubierre drives would most likely be too large for smaller ships, necessitating the need for carriers.
Stargates would create choke points. Choke points will be needed to induce PvP combat. However, I see no reason why single seated ships couldn't travel through them like a capital ship.
Anyway, that's my 2 cents fwiw.
-
Hey Guys,
Just dropped in to introduce myself.
This looks like a very cool project.
-
This may have already been addressed, but being new, I haven't found the related post.
I'm assuming there are some initial parts, functions, or requirements that would be needed to build with.
Here are some things I would consider:
Power
Fuel
Data
Heat
Ammo
Item Health
Mass
Things that create or store the above items:
Reactor
Fuel Tank
Computer Systems
Radiators
Heatsinks
Magazines
Armor
Things that deplete the above items:
Thrusters
Shield Generator
Gravity Generator
Inertial Dampeners
Energy Weapons
Projectile Weapons
Propelled Weapons
Tractor Weapons
Sensor Arrays
Communication Arrays
Life Support
FTL Drive
Jump Drive
I would THINK that most of these items would need to be "controlled" by NovaQuark in the interest of balance.
But from there, players would be able to use the above items to construct whatever they like.
-
VERY COOL!
This will definitely work.
-
Regarding Hacking:
I'm sure everyone would agree that hacking should be available for certain powers, but not for stealing the blueprint.
I should be able to compromise that force field door, but I wouldn't be able to steal the blueprint from whoever designed it, and resell my own constructs.
-
Hi everyone,
It's important to establish a good foundation, and have a vision of what you want. Realistic goals must be set in order to achieve your vision.
This post will address two issues: Ship/Station Security, and delegating functions such as flight control to certain players when you're flying larger ships.
Consider this:
Imagine you have a decent sized ship. From a multiplayer perspective, you could have a boarding ship with a mixture of 50 players and NPCs in the cargo bay. Have you personally vetted EVERY player so that you're confident none of those players won't attempt to take over your ship? How do you keep certain players from entering certain parts of the ship, such as the bridge, while allowing other players to enter the bridge?
Another scenario:
You have graduated to a multi-player ship. Due to the ship's obvious increase in size and ship systems, how do you manage all of those systems effectively? How do you delegate certain functions to certain players or NPCs?
SOLUTION:
Establish security based upon player ID and allowing players to create groups and sub-groups. The player could then create "force field" security checkpoints on his ship that allows certaing groups or individuals through. He couls also assign certain functions to those groups.
HERE'S THE EXPANDED VISION:
The player's HUD/interface is grouped into several functions / Tabs:
Flight - Ship Controls
Navigation - Map and Waypoints
Weapons - Obviously killing stuff
Engineering - This is COOL ships are balanced with thrusters defaulted to 80% power. The engineer could adjust power levels to increase performance or compensate for a damaged thruster, with obvious trade offs of course. ALL individual ship systems would have a DEFAULT setting, but could be tweaked by the engineer, with associated pros and cons.
Communications - Breaker One Nine. Come in good buddy.
Science - Scanning of systems
Medical - Life support and medical
As a pilot of a single seater, the player would be responsible for all functions. But larger ships will have more things attributed to each function, necessitating the need for help. Initially, each function would be limited in capability, due to the size of the space craft, but each "function" could be fleshed out for much larger ships.
Multiplayer ship suggestion based off of the above:
The player can assign "rights" to users or NPCs. This includes rights to boarding the ship, but also includes creating groups, and group membership setup by the player. The group membership would allow the player to delegate the above functions to the other players and NPCs. A group could support multiple functions (like comms/sci/med). AND multiple groups could have identical functions. This would allow for player redundancy, in case one of the players or NPCs is killed in battle.
This would allow the primary player to captain the ship, with a bridge of players and NPCs. He could delegate what he wants, and continue to perform the functions he likes. He could also ask engineering to increase performance "Warp factor 10, Scotty"... Or tell the weapons officer to target a specific group of ships on the combat map.
Now imagine the weapons officer, who has also been assigned as administrator of his "group". He could create sub groups, with players and NPCs that would control specific weapons batteries. And the same could be said for any other group, "Science Officer", Navigator, etc..
So this suggestion could essentially scale out to capital sized ships.IMAGINE HACKING:
Consider the boarding party. They're going to need to bypass those force fields. Then they're going to have to take control of the ship. Each force field, or ship system would need to be hacked. This would create another level of immersion within the game.
Pretty cool huh?
My first post. What does everyone think?
Hybrid "targeting" / FPS combat??
in The Gameplay Mechanics Assembly
Posted
The Answer to hit type is the contents of the "locked status" packet.
The client would have a "Locked Table" array to account for multiple attackers targeting the player.
When attacker 1 "locks" The server verifies the lock, and transmits the attackers weapons loadout and playerID to the defender. The server also updates the damage table to make sure it hasn't been modified.
Hit detection is performed client side, and the attacker sends "Attacker1, Hit Player 2, voxel location, weapon 1"
The client looks up weapon 1 in the lock table, sees that its a "Size1 Laser" and cross references its damage from the damage table. Both of which have been provided by the server in the past few seconds.
UPDATE - The "Damage" table can be merged into the "Locked Table" with weapon loadout & damage.