croxis
-
Posts
87 -
Joined
-
Last visited
Posts posted by croxis
-
-
That's a good point. To add to that: target locking via manual aiming at enemies does not necessarily mitigate latency, esp. if the object aimed at is rather small (e.g. an infantry player). Thus, the problem of latency is often similar to using proper projectile physics. The main difference lies mostly in the computational costs, as pointed out by you, which are much cheaper for target locking in comparison.
I don't think the issue is computation as much as network latency. I live in US west and my ping times to Singapore and Japan is 0.3 seconds. At high relative velocities that is significant displacement from clients and server.
-
Could do some handwaving with a magic hand (ha!) replicator. Your on person inventory is converted to energy on stored in your battery (I haven't thought this fully through).
Another point in low gravity you can store more mass because the weight is the same. And zero gravity you can store as much mass as you want, acceleration becomes more challengine though.
-
It's not all about server load and computation, it's about how hard or easy they implement it for players.
Take KSP (yeah whole other idea and deep mechanics, I know): thousands of players needing to understand orbits first before they even manage to get to a station, manage their velocities, trajectories, insertion burns, brake burns and so on....that's kinda hard at first. I see no problem in implementing a much easier system which adds something to the game - all good with that. Making it too hard and speaking of orbits with all that includes, as I mentioned, would be not good whereas making orbits too easy and it adds simply nothing - that was all I said.
When someone writes about an idea, people should consider EVERY aspect of it and I just mentioned a problem when the idea would go to deep.
Right. My counter would be the ships have enough thrust that orbital mechanics don't have to be considered by most players. Then why bother implementing the mechanic.
The point I was making is that as long as a ship is under the influence of gravity it is under the influence of orbital mechanics. There is no way around this.
Space Engineers kinda does something like what I suggested, gravity falls off with distance and past a distance from the surface there is no gravitational influences. If planets were to revolve then some sphere of influence magic would be needed to pass reference frames around.
-
i have developed a technique that can reduce the cost of aerodynamics by a lot: take the ship, put an orthographic camera in front of the ship, to point in the inverse direction of the move vector, then draw the ships normals like in deferred rendering. using opencl-opengl cross compatibility, calculate the drag of each pixel and apply that force to a virtual ship construct in opencl memory, and then bring it back to cpu and apply it to the ral object. please note you have to have the center of mass of the ship in that specific camera space to be able to calculate the rotations.
that said, maybe PhysX has better to offer, but i never looked it up and it wouldn't be cross-platform. this is the most efficient way to do it by far, and is done in one draw call. Opencl supports async rendering so you may take advantage of multi threading while waiting on that step. for server calculations, it is a little inconvenient since you need a gpu, but it is worth it, i have worked with GPGPU quite a bit and would be happy to give you everything you can compute on maybe a tesla rack or else. ideally the server would use cuda, it has opengl interop too, and is way simpler and more powerfull to use, and the dev environment is cpp, and nvcc optimises like crazy. anyway, if interested i will be happy to help you.
one other thing: if you do so: do the accurate mathematical formulas(integrations), it's a little more expensive but the difference is massive on multiple iterations... i learned it the hard way is my physics sim sandbox.
The only issue would be this would have to be calculated server side, which who knows what constraints the cloud hardware has.
-
-
I think it's a wonderful idea to implement orbits of Planets and have them revolving around themselves. This would add at least a little bit of randomness and thinking before you attack (sucks when your fleet has to fly 3AU in addition).
BUT (and this is a big, bad nono as stated in the aerodynamics thread)
You simply can't implement orbits for ships. Then Players would have to think about periaps/Apoaps, slingshots to even get somewhere far (this could be countered by "I have a scifi engine"), escape velocities and then again orbital velocities (it's kinda hard to get to the inner most planet, because your falling to the sun...)
This proposal also includes then orbits for every structure in space. Like the first two drawings of https://what-if.xkcd.com/58/ : space is not vertical, its horizontal. A station/ship/satellite/debris needs SPEED in order to keep it's orbit (because gravity is always there). Try docking/landing on that moving thing with your just build ship from ground. Even with a minimalistic model it's not that easy - and again: if made too easy, why add it in the first place? Those calculations only consume ressources and don't add anything practical.
I agree, that it would allow for interesting strategies and tactics but it would not work out well.
Here is the problem. As long as there is gravity an orbit is needed. One option is make the gravity fall off faster, say an inverse cube instead of inverse square. Combo that with a sphere of influence (the stickyness onepercent mentioned) with a radius calculated based on inverse square -- so there is a zone of no gravity but is still in the planet's frame of reference.
Orbits are not *that* computationally expensive using patched conics/keplerian parameters.
-
A hippy commune floating in the air with balloons.
-
LImit player chat would be dumb, but in game drones/devices/programs could observer range (even speed) limits.
-
Server bandwidth could become non-trivial as the normal/bump map would have to be sent to every client, and either cached on every player's hard disk or resent on every view. Get a bunch of constructs together and you can risk gigs of data being thrown at every client.
-
-
This post is more me thinking out loud than taking any specific position.
I think about this in terms of player time. In 1 hour of play how many minutes does the player need to spend just to maintain their status quo vs how many minutes they have to better their situation. Item decay goes into the maintain status part and its so hard to balance. Too much and the player feels like they are treading water. Too little then why bother spending the dev time coding the mechanic at all.
In a game like Eve it isn't hard to replace a lost ship and loadout. Duals build system gets interesting because our ships have the potential to be very custom and personal -- so battles might need to have high survivability for both sides (unless it is easy for players to duplicate their designs). If high survivability is a thing then the economy is going to need additional sinks to help the money flow -- such as higher consumable rates and item decay.
IIRC item decay came about as a mechanic in the old RPGs as an additional punishment for death and damage. The problem is that there are a number of penalties to death -- one of them is time. I feel that the time penalty in a sandbox mmo is much harsher per minute lost than in a themepark or sp game, because other players will be advancing their agendas as the poor dead chap respawns at the nearest re-spawn point. This is on top of probably losing all the stuff the player had with them.
I'm just meh about item decay as an idea. "Oh you managed to survive all those encounters? Lets reward you by making your stuff break!"
-
Usually when most people talk about aerodynamics that speak of three specific things: Reentry heat, drag, and lift. Drag and reentry heat are based on the same principles. From a gameplay perspective re-entry heat just means you are going in too fast -- that can be solved when the construct hits the ground.
One thing that is a problem with planets, at least with other games, is that if the craft/camera goes fast enough the terrain gets a popping problem due to LOD switching. One way to solve it is code a speed limit for atmospheric flight based on the performance of the minimum system requirements. A soft limit can also be done via mechanics where, despite how well design the ship is, heat from drag will destroy the ship around the same threshold as the graphics limitations. Computationally this doesn't have to be that complex, a little pre-computed cross sectional area vs atmospheric density.
LIft... honestly I think it depends. It could be quite simple like robocraft. The issue be if the cost savings were worthwhile to the player. I'd rather see blimps/zeppelins for planetary goings, then spaceships for more suborbital hops.
-
It might take some hard-coded mechanics. One way is that each account can only manage x number of cpus at any one time. It could be tied to a skill to increase that limit, but the devs still have control over it.
-
#1 can be quite important if, and only if, traveling between planets within a solar system takes a non-trivial amount of fuel and time.
I real life example that I know of off the top of my head is Earth and Mars. Your best fuel use and travel time window (using Hohmann transfer orbit) is every 22 months and travel time is about 9 months with our current rocket tech. The further apart from the transfer window the longer the travel time and the more fuel needed.
This is a game after all, but there could be some interesting strategy and player decision making if an Earth/Mars anologe had the optimal transfer window every few weeks, transfer time was 10 minutes vs two hours (at worse), and fuel cost was 1:10. Numbers pulled out of my tush but you get the idea. Obviously as player and world tech improves the factors will improve, but never be non-trivial. I can see a possible progression where the first transfers to the next planet had to be in those launch windows, it would take a few hours to get there and fuel costs would be quite expensive.
-
Most of the research I've seen shows isolated tutorials not as effective an in situ. Portal is the best example I can think of off the top of my head. Player run experiences like eve uni are awesome, but can't capture every player (specally the casuals). Nor can they capture every player in that critical first 5-15 minutes. Nor would such an organization be ready to go on launch day. With construction being such a big and awesome feature I would say that in the first 15 minutes a player should have collected supplies and built their first (very simple) vehicle. In doing that they experienced some fun combat, resource collection, crafting, and market action. The trick is to make sure the chain of events in the tutorial can scale -- it is not fun having 200 people wait around for to kill 10 rats when the spawn rate was designed for 5.
-
They might be able to design the servers so that no regular downtime is needed.
-
I don't think it is cheesy at all, because what the player can do will be limited by the items and equipment they carry on them.
Players also get very attached to their avatar, yet their gameplay interests will drift over time. My character in Eve is 10 years old now I think, and it has done everything from nullsec miner living to mission running to wormhole explorer to pvp warp scrambler to logistic healing to battleship dps. And with time based skills I continued doing what I enjoyed while training for the next thing I was interested in, without having to start over with another character from scratch. My husband is different, he loves leveling alts in WoW.
What you propose is a player designed class system. And being humans who are natural min/maxers these classes will end up more or less just as ridged as if the devs hard coded them. The more I think about playing Dual over the course of years the more the idea of classes, be it by skill cap or hard code, makes me lose interest because my main would be perminatly shoehorned into a role that I may want to change over time.
-
It's your *assumed* simple game mechanics. Unless you are a developer you have just as much knowledge of the mechanics as everyone else on this forum. Dual can be coded with shield boosting mechanics, shield draining mechanics, both, or neither.
"No magic healing buffs in dual." Really, show me the quote from the devs. It is one thing to argue for or against a mechanic or you like or dislike an idea, it is another to state something as fact when it is not.
The flavor of the mechanic can be whatever it needs to be -- sleeper tech, mana, nanites, etc.
One of my criticisms of Eve is that combat seems mostly decided when you launch from the hanger with the ships and loadouts brought. If a game is a "series of interesting decisions made by the player" then most of those decisions happen before the fight. Combat should be fun for everyone. Without support roles the only actionable items in the fight itself for multicrew ships is piloting and weapons.
Support gameplay is something I am more interested in as both a player avatar and even as a multi crew ship. I love being the mechanic in Guns of Icarus -- prioritizing repairs, the tool I use to repair, and the types of buffs added to the different elements. I would enjoy similar mechanics being an engineer on a multicrew ship.
If we want to go with the nanite flavor a support ship could be equipped with nanite bombs. Shoot them at a baddie to do some damage or debuffs, or shoot them at a friendly to do some repair or buffs.
- Cornflakes and VerZalj
-
2
-
I'm going to have kids soon. Like all children they will decide to have meltdowns at the worse possible time, such as Daddy's computer game time. And I might not be able to hop back on again for 20 hours due to work, making dinner, actually playing with my children, etc.
Am I not going to be able to do anything outside of a safe zone just because I am a parent?
Granted this example is going to a care bear extreme, but in eve I know my ship will despawn in 15 minutes and I can adjust what i do and don't do accordingly. If i'm in high sec, or in my alliances null or wormhole space I can assume with reasonable confidence that my ship wont be destroyed in that 15 minutes. Not always, but a risk I can take/afford. I run a much bigger risk if my ship stayed spawned for the entire time I was logged out.
-
I think the more fundamental question is what does a support role look like? What does it play like? There is also two levels - support role as a human avatar and the support role as a ship in a fleet. There is agressive "crowd control" support such as sensor jamming, and defensive support like healing or buffs. So is there a way to give a support ship crew interesting gameplay in a fleet battle.
-
There are a couple of neat tricks Eve's time based skill system did. One of them is that the time from level 4 --> 5(the max) is always greater than the time from 1 --> 4. A newer player can get to be on par with a vet in terms of skill bonuses in not that much time. The other neat trick is how horizontal the progression is. The difference between a vet and newbie the amount of variation in the roles that player could take on.
The problem I see with the "gain the skill by doing it" is that it is still taking time: by grinding. Humans are natural min/maxers and player psychology has show time and time again that they will self inflict unfund grinding on themselves, even if the devs never intended it to be grindy.
-
I would much rather have an api (see: eve) that player organizations can utilize as they please, (And positional audio support in mumble would be fun)
-
The universe wont be infinite at first
-
It could be possible to do what paradox does with their games -- the expansion content is present for everyone but the player can't directly utilize it unless they bought the expansion. A stupid contrived example could be a component building expansion. Players who buy the expansion could design new components, but all players can buy/sell/build/use them.
DU Discord Community
in General Discussions
Posted
Shame it isn't IRC or Matrix