ostris

I was under the impression the most up to date was something along the lines of: Standard engines - Capped at low speed(relatively speaking) used to travel from a planet to a moon or around a planet, what you use to fight and engage other ships Warp/FTL - Used to travel between planets within a system much higher speed cap and probably more fuel/tech and restrictive in movement Star Gates - Probes launched using Warp/FTL and when they reach their destination open a gate that allows for very fast travel between the launch point and the destination Note: you can use any type to travel anywhere it will just take crazy amounts of time.

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.

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!

Yeah i really hope we get some extra content due to gamescom and pax west. Alpha is only ~30-35 days away but would be nice to get an extra long dev diary or something

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.

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!

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.

My opinion the only place i would think is ok to have teleportation is between different places on the same construct. Basically a way for people to build fast travel stations on large bases or space stations.

A WHOLE DAY?!?! Unacceptably slow yama! get on your game. I kid looking forward to it and thanks!

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

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.

Fair enough feel free to pm about the half truths of those statements.

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.

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.

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.

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.

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

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.

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.

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

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

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.

So i think maybe some things are getting mixing up. This comment was in response to: 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.

That true in that they can scale out, but if you scale out that will cost money. Also in some ways they can be easier to attack because your server is running on shared infrastructure that could also be attacked.