Jump to content

ostris

Alpha Tester
  • Posts

    235
  • Joined

  • Last visited

Posts posted by ostris

  1. I think another important aspect of gameplay to consider is shipping costs of goods. NQ can easily implement mechanics that make it beneficial to process material on site. Example raw Iron ore weighs 10 and refines to something usable that weighs 1. If you want to be safe and process the ore at your MSA you have to transport 10x the weight as someone who risks refining on/close to the source of ore. Another example is fuel/power, small bases may only require some solar panels to keep the lights on. Large factories may require harvest-able material to generate large amounts of power. If you want to have a "safe" factory you will have to import/transport both material for ships and for power. You are far better of partnering with a mining company and building your factory with them, sharing the protection bubble and making it stronger and greatly saving on transport costs and risks(pirates). So the only thing that would be safe at MSA would be finished products which I am ok with, there is still lots of opportunity to pvp, steal, and pirate.

  2. Honestly i dont really view this as delaying anything. In my eyes what they are describing as a "pre-alpha" was exactly my expectation for alpha. When they released the dev diary saying they wanted a game loop etc in alpha i thought of it as them giving a pre-release vibe to alpha. All in all i understand why NQ is doing this. With the game having a healthy amount of skepticism around it already and the rapidly changing idea in the game community to what an alpha is(the lines between alpha, beta, pre-release are pretty blurry now), i see why they are afraid to release what i would consider to be a real alpha without an NDA.

     

    TLDR; This was exactly my expectation so yay!

  3. 19 hours ago, Lethys said:

    Don't like the idea of killing offline players at all, that's just bad gameplay - a guy who disconnected/prepares a logoff trap/just has no time to log in loses all his stuff on person and has 0% chance to avoid it

    I guess this is just where you and I disagree. I think giving offline players some magic immunity will open the door to huge abuses with stowaway issues, log in traps, or just plain trolling. I would say it needs to be a combination of protected offline players for the correct reasons(in their own base or in neutral areas on a planet), and protect online players for the correct reasons or not give offline players some massive level of protection. I feel like this is more important in DU because you will always be able to lose valuables when you are offline. Constructs and bases will be able to be attacked when you are offline and that has far more value then a players body.

  4. 50 minutes ago, Elildar said:

    It is a difficult subject, because we don't want people to get abused when they was careful, and we don't want offline people to become a problem.

     

    I have a solution that I think will resolve all these problems in a realistic way. It's good to see that some of you already proposed some parts of this solution.
    Of course, I assume that people disconnecting in a construct should reconnect in the same construct, whether the construct has moved or not.

     

    - We already know that we should not teleport offline people because it would be abused (except for death = RN).
    - We also should not allow to build where people are diconnected, because they would reconnect in a wall.
    - And we also should not force people to disconnect in specific area, because disconnections can happen anywhere/anytime. (and the RDMS already allow you to go in places you are not welcome)

     

    So, we need a way to see where people are disconnected, and we need to be able to do something about them.

     

    So, my proposal is :

     1. When a player disconnect, he let an invisible signature (or ghost) in the current voxel grid.

     

     2. Online players can see these ghosts only when activating an option (or skill) and depending on their RDMS rights. (see rules in next points) So you don't see hundreds of ghosts all the time.

     

     3. Online players can move or kill these ghosts depending on their RDMS rights. (see rules in next points) We should keep it realistic, so if you disconnect in a dangerous area, it is normal that you can be killed.

     

     4. When a player move or kill a ghost, the ghost keep a mark. So when reconnecting, the player will have a message telling "Player1 killed you" or "Player2 moved you". This will avoid any mystery about what happend to your ghost. If you're not carefull enough, players can abuse of your ghost, but you will know who did it.

     

     5. If you disconnect in a safe zone, your ghost can only be seen and moved inside the safe zone by the owners of the zone where you stand.

     

     6. If you are the owner of a construct, you have all the rights to see and move the ghosts inside it. This solve the problem of the stowaway, and doesn't stop him from trying. Before taking off your ship, you may want to check if there is no intruders on board. If you find a ghost that has no rights on this construct, you can also kill it.

     

     7. You cannot build on a ghost because he would reconnect in a wall. But if you have the right to build in this construct, you can see and move the ghost somewhere else.

     

     8. If something happen to the blocks where your ghost is, you suffer the damages. For example, if you are offline in a big ship during a battle, and the ship have an explosion in the corridor where your ghost is standing, you are more likely dead. Another example, if you disconnect on a landing plateform, and a ship land just on your ghost, you die, crushed by the ship. (IRL you don't go to sleep on a runway, so ingame don't be stupid as well).

     

     9. If you attack an ennemi base, it would be unrealistic that people can reconnect in a part that you have secured. But you have no rights in an ennemi base. So it would be good to implement a skill allowing you to detect ghosts and to move or kill them. But all this depend on the PvP gameplay that is not defined yet.

     

    All these points make the online/offline concept more realistic and push you to be more careful about where you will disconnect. If you are not careful, or if you don't choose well your friends, people can still abuse yourself.

     

    PS : I volontarily skipped the part disconnect when flaged PvP, maybe a timer before disconnect is a good idea, but I think it's another subject.

     

    This is very similar to what i was thinking. I feel like there will always be a trade off but i would be ok with this system. Adding to it, if there is a ghost in the game it could also handle player weight on constructs and handles moving players to a large construct if they logged off on a smaller attached construct; such as after a battle a fighter lands on a large ship and the pilot forgets to get out of the ship before logging off(this person is an ally). Now you can move him to the large construct instead of kicking him from the small fighter into the void of space. I still do not like the idea of log in traps but this system has at least some level of protection against it which is really all I personally want. I don't like people being able to take advantage of the fact that for some silly reason they exist in some untouchable pocket dimension when they log off, this system prevents thats so ill take it.

     

    Kudos!

  5. 2 hours ago, Kurock said:

    If you log out on a construct you will log back in on that same construct. This is great because the Internet is not always stable with disconnects happening at any moment. 

    But why is this abusable? Jump onto any construct and log out. Now that person can be taken anywhere that construct goes and is undetectable. An invisible stowaway which could just be hitching a ride or have more nefarious ideas.

     

    The first question is does this warrant adding some mechanism to prevent the invisible stowaway problem? The 95% case is one where players have the right to be on the ship so is it really a problem? Adding a mechanism, no matter how small, takes away from dev time in which another feature could be built.

     

    But, for arguments sake, let's say it *is* a problem so how could it be "fixed" to add gameplay opportunities rather than removing them?

     

    1) No rights, no logout. RDMS dictates whether logging off is allowed on the construct. If not, the person is shunted into the planet (or space) outside the construct. This doesn't switch off stowaways since a hacker could get around the RDMS (potentially), but it does make it much more difficult for long hauls since they player must be logged in the entire time.

     

    2) Detection. Part 2 and 3 are meant to be used together.

    a) Make them visible. After logging out a hologram (or ghost) of the player is left behind. Perhaps this could be for a short amount of time before 2b needs to be used.

    b.) Make them detectable. A special hand held or construct wide scanner could be used to give a count of ghosts and eventually, though gameplay, pinpoint them. Think of this as the stowaway trying to hide, perhaps this could get bonuses from stealth skills to hide and likewise the scanner could get bonuses from scanning skills to detect.

     

    3) Action after detection. After detecting a ghost using 2 above, what can a person do about it?

    a.) Nothing. Being able to do anything to stowaways is abusable in its own right.

    b.) Move em. The owner of the ship (with the correct rights) can boot the ghost out of the construct. Potentially into space. This is potentially a death sentence.

    c.) Kill em and be done with it. They won't stowaway on your ship again.

    d.) Confinement. A holding area could be placed on larger constructs. This is not imprisonment: A person could still shoot their way out or kill themselves. It does serve as a way to give the stowaway a chance to have a talk first.

     

    My personal preference would be 2b and then the ability to choose any of the 3's in a case by case basis.

     

    What would you choose?

    I agree almost completely with 1, 2 is an decent idea but i don't think it solves all the problems and 3b is good with some exceptions for logged off avatars on constructs on constructs. The only change i would make to 1 is that your avatar simple stays in a afk state(sitting) and killable if you do not have rights to the construct possibly for some set amount of time. The idea of a time limited persistent avatar in the game is required, cant just have people alt f4 and instantly ghost.

     

    To me login and logout has so much more depth. If it was just the stowaway issue i think 2b would be fine. However the issue has so many more little problems with it like: I'm attacking a base, the members of that base have all their alts logged out in groups around the base. I now have to account for what basically amounts to phantoms because i cant know which detectable player logins are real and which are just alts. I have to respect that a group of players COULD log in behind me in some room my org and I have already cleared. Since I am attacking I don't have the right to remove these logged out players so that's not an option either. In my eyes you have to have designated login areas/elements for constructs, its the only real way to solve that problem that 2 brings up in all cases.

     

    Something else to consider is what happens to the weight of a player logged off on a construct. In theory if i can log off on your construct and there is no way to remove me(3a) I can literally add weight to your ship that you can never remove until I choose to log in and walk away or i guess you destroy your ship?. If you don't handle logged off player weight, with enough players, you can move unlimited cargo on a tiny ship by just getting 50 players with max weight logged off on your ship. There has to be some way to account for it and see it.

  6. Honestly i kinda hope they don't bother unless is it shown to be very high demand.  I was a big fan of SLI, but bottom line with unified engines and games being designed for console, PC and mobile, SLI is being dropped(as console has no SLI, and even among pc its not common), many games wont support it and those that do usually do so very poorly. This is why I moved to the 1080 instead of 2 1070's

  7. I think log out should be controlled on a construct level, logging in should be controlled by an element/special voxel w/e.  When you log out you would get a message like you are logging out attached to "construct name" when you log back in you spawn in/next to the designated login element. This login element would probably default to something like above the ships core or the cockpit but could be specified later to the reserved login element.  This is the best way in my eyes to avoid issues with disconnections(what happens if you lose power and cannot go to the logoff element) , modifying the construct when allies are logged off(i remove the block you were logged off on for some reason) or using log in as some tactical advantage in AvA combat(logging in 20 people in some empty room behind someone invading your base). Since login is linked to the construct itself, every construct will simply have a login section that can be set via RDMS tags. If you do not have permission to log in you die and respawn at the arkship or closest res node. If you try to log out on a construct you do not have login permission to log in on the game will warn you that when you log in you will either die, or maybe be dropped at that point in game space as long as another construct isnt occupying that space(this could be hard to implement so maybe just death is best)

     

    I feel like this hardest part about login/logout mechanics is making sure they cant be abused or minimize the abuse that can be there.

  8. Just to be clear. There is a difference between Tab Targeting (This is something the User does by using his Keyboard ) - what OP wrote - and the game mechanic of not being a FPS but being a 'lock on' game. To give a famous (at least in Germany) quote: "It's like comparing an apple and a Pear . The one thing is a mechanical Part of the User giving Input to the game and the other thing is a gameplay Part of the Game being 'lock on' and not FPS. I was just  stating the OP's mistake in making clear what he meant.

    That a 'lock on' System (Also known as Ray Tracing) is less stress on the Server than an actual '(FPS) - Projectile - Collision' - System is given.

    Btw: your description of less server updates and less precision is just plainly wrong #(2) in your Reply. The server just does not have to make as much calculations in the 'lock on' System (because it does not have to calculate Projectiles and their Collision but only one line (a Ray Trace) - the constant Collision calculation of a moving Object is the costly part on the other System). They both are precise and accurate (The 'lock  on' System just has a given Target, the 'Projectile' System has no target but a direction and just happens to maybe hit something on its way through space). I mostly feel like people here talk about stuff they have no clue about (I mean there is no problem with that - the thing I have a Problem is if those people make it seem like their wrong statements where facts. Because then other People who don't know about such stuff believe you and have the wrong Idea too without even realising it).  What you talked about was something about networking and Server side Interpolation of Client input. What you stated in #1 is mostly correct though.

    So what i said in 2 is correct. Its not just a technical issue, its a game play issue. The server does not need a higher update rate to know what was happening in many cases but the player will hate the game if you have a classic fps "projectile system" with low update rates.

     

    As an example in a true fps if each players sends 1 update per second(for the sake of argument assume 0 ms response time). The shooter is always behind in time compared to the person being shot. The shooter sees your last update(or in some cases 2 or 3 updates behind) to the server which is sent to the shooter. If my last update shows me in a door,  the shooter sees me in a door, takes a shot and hits me. On my screen i was far past the door(i am 1 second in the future compared to the shooter) and should not be able to be hit, but i wont get the info that i was shot until 1 second later(this assumes favor the shooter mechanics). This creates a very bad feeling in my eyes that i was "shot behind a wall" the more updates to the server the less time delay between action and result the better the combat feels. in an active lock/tab target on this type of mechanic is less troublesome because the assumption is oh the shooter locked me in the door and fired then the bullet simply traveled through the wall. He did lock me at some point and that's all that matters

     

    As far as precision: update 1 is A the next update is B. how does the server know what i did between A and B. Normally it doesn't, it knows i was at A and went to B so it renders my character going from A to B on the shooters screen, this is server interpolation. The server knows where i was and knows where i will be so it can assume i move from A to B probably at w/e speed i was going at A. If you are doing high update rates for the most part this is fine. there isn't much variation in movement between A and B when dealing with 1/60th of a second. however in a situation where you only update 1 time a second. lets say A I'm on one side of a thin poll, one second later at B I'm on the other side of the poll. My body was never fully covered by the poll but at the time of the shot my head was. Did i run behind or in front of that poll? I know i ran behind it but the server cant know. In a true fps if i ran in front of it and someone shot at me i die to a headshot, behind it and the bullet hits the poll. In a tab target or lock on system I'm never fully covered by the poll, line of sight isn't lost so in this example the poll isn't relevant. In short people expect far less precise aiming in a tab target system(seeing as how you cant aim) so devs can be far more liberal with the use of server interpolation without a negative impact on game play experience because precise aiming is not core to that game play experience.

     

    What this means is to have a satisfying "projectile system" you MUST update far more frequently then a tab target system. Which causes far more server load. Tab targeting, since precise aiming is not required, has much more forgiveness from the players gameplay experience and server interpolation techniques can be used with larger blocks of time, 5-10 updates per second(maybe even less) instead of 60.

     

    Edit: im not saying any game would ever use 1 tick systems just using it as an example. All the same stuff i say here still applies between 5 ticks or 20 or 60 just to a lesser extent.

  9. Yeah, similar to the guy above me: I don't know where you got the Idea of the Tab Targeting and then on top of it concluding it creates less server load. The actual Targeting Method (You choosing your Target) is Client sided. It has nothing to do with the Server.

     

    To the rest of your article: I got the feeling that you are basing most of your Ideas on speculation and somewhat incomplete knowledge about the topic regarding UI-Design. I don't want to offend you, but thats what it seems to me. Also: I would not worry too much about this right now. You can see that they are treating the whole User Interface Experience serious (they show that in a lot of the Dev-Diarys) and without actually playing the game I don't think we will really know what a good UI should be like for this MMO. Since there is none out there that you really can compare it to.

    So just to add some clarification to server load. I'm not sure exactly what OP is referring to but tab targeting/active lock on systems are considered much less server intensive then your standard FPS style. I believe start citizen is trying for a more standard fps style of combat.

     

    The 2 primary reasons:

     

    1)In a standard fps the projectiles from your gun/ship must exist in the world as objects on the server. This allows the handling of things like collision with something other then the intended target. In a tab target system the projectiles are simply graphics in many cases rendered purely on the client. If someone passes in front of them the projectile will go through them since the target is the targeted/locked enemy.

     

    2)In a tab target/active lock on system high levels of precision are not necessary. This allows devs to use far less frequent server updates. If a standard fps has low update rates to the server you will see a lot of dying behind walls, missed shots that look like they hit and the game will feel very poorly done. In tab target systems since you dont need to have the hyper accurate position of the projectile and the target you can use less frequent updates and interpolation techniques to still create a good combat feel. To put numbers to this in most fps games you will update the server with your position 60 times a second. Many games the server will update you 20-60 times a second. With DU's proposed targeting and combat system you could probably get away with as little as 10 (maybe even less) on close targets and less then 1 if the target is far enough away.

  10. I think this topic is kinda get mixed. Seems to be 2 issues.

    1) how difficult should it be to place voxels/elements and shape/smooth them(building)

    2) will those voxels fly(design)

     

    Personally i think the placing of voxels/elements should be very simple and made very easy to do, almost without restriction in build zones. The design should be where the gameplay can be felt and enjoyed. With the amount of control over voxels, shaping them/smoothing them it would be very annoying to have this functionality be restricted.

     

    Empyrion had an interesting solution to this problem. you had a drone of sorts that could fly, access your inventory and place blocks making those hard to reach spots where your want to add voxels or shape voxels much easier.

  11. Yeah I see melee in this game being more situational and last resort type play. For it to be a main role or way to play they'd also need stealth and various other distance closing mechanics. By the way have the talked about stealth?

     

    But yeah just seems like with the type of game DU will be weapon combat will be the main focus. Different ranges on different types of weapons should fill that short/close range niche. Perhaps more of a mix of like handguns and the melee moves OP suggest above.

    I agree. I hope melee is kinda placed on hold for more important combat systems. PUBG is a great example of a game with horrid melee combat and just makes the game feel bad.

  12. Personally i like the idea of requiring multiple people to crew any ship that is larger then a fighter. I feel like this will have a big impact on how ships are designed. However, I hope that the concept of 1 person manning 1 gun that JC mentioned on the facebook vid is not exactly how it works. I think NQ should focus on the majority of ships being crewed by 1-7 people. There is a reason basically every game(league, overwatch, dota, pubg, hearthstone/card games, Diablo 3, h1z1, cs:go) are all solo/small group oriented. Older games like WoW are shifting focus to groups of that size being a focus with recent mythic dungeon changes. This seems to be a group size that most people enjoy and works well. Orgs can be larger and there will always be that group of people who want to make huge ships with 50 person crews but i feel like the vast majority of the player base will want to have the solo-7 player ship they fly and can interact with the org they are part of by landing on the orgs space station or w/e.

     

    Restricting players to a single gun will greatly limit ship design in this small group range. So i hope that as a player develops they can use several of the same gun, grouped with a penalty, or rotate to different guns while others are on a cooldown. There will still be a max that any one player can ever effectively fire and it would still be better to have 1 person per gun but not hard required. This method would hopefully have a positive impact on small group ship designs and diversity.

     

    Edit: forgot CS:GO

  13. NQ has stated they want to avoid collision mechanics as much as possible and its a decision i agree with. While bouncing off other ships is unrealistic and kinda sucks the alternative of adding complex systems and other forms of damage is far worse. My largest current concern with combat is how the balance of skills, weapons, armor, damage, tackling, stealth etc etc will all play together. So many combat aspects and how they all have to work together to feel like there isn't just one ultimate ship or solution. The more types of damage and systems you add on the harder it is to balance it all out.

     

    While i think twerks solution could work I can start to see some holes with it. To start with its confusing for players to understand but also requires a lot of information about materials to be added to the game. Once again all these strengths and weakness will need to be factored in to the world economy and balanced properly with other elements like damage resistance etc.

     

    Another simple issue is there is now a way to lose a huge ship nearly instantly. Flying towards an asteroid or some large space station and lag out for 20 seconds, BUMP and your ship is possible gone or heavily damage. This is the type of mechanic that would make people quit the game right away. Expecting perfect connections to the server is unrealistic and the first time someone loses their expensive ship because of some crappy server lag may be the last time they play the game.

     

    "You tried to play chicken with your battlecruiser by trying to joust with another battlecruiser but you forgot to engage your maneuvers and dodge AWAY from the path of the enemy battlecruiser? You both explode."

     

    This right here i can think of TONS of great reasons to take that trade. Easy example i have a ship with no guns/extremely similar build as another ship, maybe even the same base BP. They add 10 guns to their ship to make it a more standard fighting ship. We know that means they have to add 10 more players to man those guns. They also need ammo to fire those guns. I fly my ship with no guns and possibly no one else on it, into that ship. We both explode. I die but all 10-11 of them die and they possibly lose all their ammo and guns they added to the ship. The rest of the 9 members of my org are on some other cheap ship. They loot up what remains of both ships and we come out ahead in the battle/war.

     

    As i stated originally this is just something that should be avoided entirely, i don't see way to put this in the game that isn't going to drastically effect balance and not come with a huge amount of issues.

  14. Unless they take your weapons and lock you in a padded cell...

     

    ... unless there's like an automatic suicide button or something...

    I think the nature of this game will require a suicide button. NQ seems to be kinda unspecific about survival mechanics like food. Those mechanics usually act as suicide buttons of sorts. Without that it would be incredibly easy to trap an offline player forever in some box.

  15. I would agree if Python would be slower by factor of 5.. even 10 but not 100+. It's 100x more concurrent calculations being handled on a single blade.

    Difference in number crunching algorithms is even higher, sometimes we talking 400x. 

     

    I know Python is easier and cleaner and.. cheaper, since got so popular in US as one of the main langue to teach kids at school.

    C++ is not overrated, it's just forgotten, developers got lazy. But is the only way for close to the metal performance critical operations and writing robust server is one of them. Hell, even old Java server for Flash MMO games were way better!

    The idea that python is slow is kinda overused or misused. Python can compare to C in many ways if handled correctly. The website mentions that game objects are programmed in python but "Scripts can utilize C++ when required for optimization of regularly used functions." Tells me they are probably using something more then pure python.

     

    If i had to guess they are probably using Cython. if they are using pure python that would be interesting.

     

    https://en.wikipedia.org/wiki/Cython

     

    Neat page showing speed comparison:

    https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization?lang=en

  16. I'm sure they will plan for it and make adjustments as needed. They will probably be able to predict how the first month or two of the game will go based on Beta and advertising data. I'm sure that if there is a concern about an extremely large day 1 influx, they will brace the servers for it. 

    If i were less lazy I would get the gif of Samuel L Jackson in Jurassic park saying Hold onto your butts.

  17. If you wanna get hypothetical, technically, a fire in the datacenter is a DDoS attack.

     

    Sounds like a Direct Denial of Service to me, if the datacenter is turned to ash.

     

    Unless a Botnet can exceed whatever number of machines NQ manages to secure in a contract as of servicing strengths, the server is safe from DDoS attacks.

     

    P.S. : Make an argueement about ingress points. It's 2017 and it's AWS. Cheers!

     

    If you want to get technical a fire is not a DDoS attack. This is primarily because DDoS stands for Distributed Denial of Service, not direct.

     

    Not sure what the strict definition of a DoS attack is but I'm pretty sure its considered a cyber attack so a fire is not a DoS attack either.

    I think a fire "attack" in a data center would be called Arson...or maybe an accident.

  18. Alright so I'm just going to flat out say no. As far as I have seen the view distance is not actually truly affected. What I have seen them do in the videos was actually throttle the number of update packets going to a client based on distance from said client. This makes the movement less smooth (viewing) for people far away but still functional. This also helps a lot with the exponential growth of packets being sent for players in an area because of how much you can cut down due to client side smoothing and interpolation that can take place without the need to a ton of extra data. It just normally isn't as accurate

    So i think maybe some things are getting mixing up. This comment was in response to:

     

    You do realise that a city with that amount of players is less than the 20KM safe zone in surface area, yes? Also remember that there are timezones, so not everyone will spawn in at once. It is going to be chaos to begin with, but it would be the same when these hundreds of thousands of people have just woken up after they have left their planet of birth.

     

    Only a few 'chunks' radius will be rendered on the client, so the more people/activity nearby, the lower your view distance (due to smaller chunks)

     

    Remember that the devs can learn from alpha/beta world start, so they will have accurate models for how to approach the problem.

     

    This was not an issue about network traffic. this was an issue of client side rendering of 100k player models(or however many were in view). The amount of updates isn't the primary issue that I'm addressing as NQ has a proposed solution to that. I hadn't heard of reducing view distance as being an actual solution to the problem proposed by NQ. I didn't really question it cause its doesn't address the larger issue that all of these performance increasing techniques should be used for a purpose not just because everyone is clustered together at the start. Meaning if i go in to a huge player owned city and a cost of that is reduced view distance/refresh rate I'm ok with that because it has to be done to allow that city to exist. Dropping everyone in the same start zone means that these techniques will be used a huge percentage of the time just running around the ark because of the player density at the start. This could have a negative impact on player experience and first impressions of the game.

     

    @lord_void i agree. I stated originally "I think the only reason they would have multiple start zones is if the hype train goes out of control and they have 100k-200k players all trying to get in day 1" and that its not likely to happen but hopefully they plan for it.

×
×
  • Create New...