Game Discussions Star Citizen Discussion Thread v12

Well if you think you can sink one of these.

SK6ee18.jpg



With one of these.

OFtb6y3.jpg


Go for it, i'll watch :D
2 tomahawks go boom
 
Well if you think you can sink one of these.

SK6ee18.jpg



With one of these.

OFtb6y3.jpg


Go for it, i'll watch :D

Real life != game

But if a plane with air to ground missiles couldn't severely damage a ship i'd be quite surprised. And the Japanese in WW2 found ways for small aircraft to damage ships, even if the solution was a bit extreme.

But ok, you think its right that small ships can't damage big ones. i think its pretty sucky and just confirms SC as a P2W game. ;)
 
The Gladius is the hero fighter in SQ42, its always the first to get new tech lavished on it.
It opening up like a Swiss Army Knife is for component access, all ships have it to varying degrees, depending on its age, for example the MSR has full component access while the Connie has some and some of it is wrong, ships with interiors its all internal, small fighter like the Gladius have component access on the outside, so there are panel's that open up on the outside, all over the ship like you see there, the Gladius is the first but eventually yes every ship without an interior will be covered with panels that open up with components inside.

The idea is when a component gets worn-out or damaged you physically remove it and replace it, during combat in larger multicrew ships its your egeneers job to maintain those components, so he will be running round putting out fires and replacing components.
Does it punch above it's weight?
 
Real life != game

But if a plane with air to ground missiles couldn't severely damage a ship i'd be quite surprised. And the Japanese in WW2 found ways for small aircraft to damage ships, even if the solution was a bit extreme.

But ok, you think its right that small ships can't damage big ones. i think its pretty sucky and just confirms SC as a P2W game. ;)

Most big ships are useless on your own, Hamerhead, Carrack ecte.... as the pilot you don't even have access to guns, you need a crew.

Even my MSR is pretty useless in a fight, i have a pilot operated turret with 2X size 2 guns, the average fighter has 2X Size 2 and 1 size 3, i need someone to operate the other turret, if i meet an Anvil Arrow on my own, a ship a third its price i'm toast.

Larger ships than that, like the Carrack or Hammerhead the Arrow can shoot at it all day and never get through its shields.

The idea is you don't a buy $600 ship solo, you pool it with 6 or 8 of your mates, that's the only way you can operate it effectively anyway.
 
Most big ships are useless on your own, Hamerhead, Carrack ecte.... as the pilot you don't even have access to guns, you need a crew.

Even my MSR is pretty useless in a fight, i have a pilot operated turret with 2X size 2 guns, the average fighter has 2X Size 2 and 1 size 3, i need someone to operate the other turret, if i meet an Anvil Arrow on my own, a ship a third its price i'm toast.

Larger ships than that, like the Carrack or Hammerhead the Arrow can shoot at it all day and never get through its shields.

The idea is you don't a buy $600 ship solo, you pool it with 6 or 8 of your mates, that's the only way you can operate it effectively anyway.

Yeah, again, i don't like that idea. I don't like being locked out of stuff just because i tend to fly solo and don't have the time or freedom to fly with friends most of the time.

Basically what i'm hearing from you is if i play Star Citizen i might as well forget about flying the bigger ships.

Yeah, no thanks.
 
Yeah, again, i don't like that idea. I don't like being locked out of stuff just because i tend to fly solo and don't have the time or freedom to fly with friends most of the time.

Basically what i'm hearing from you is if i play Star Citizen i might as well forget about flying the bigger ships.

Yeah, no thanks.

I play the game solo far more than in multicrew, even when playing with mates.

This was entirely solo, my mates are in the Hammerhead, 7:30 you can see it glide in from the right with the party members markers in it.

You can play solo or multicrew, that's the point.

Source: https://www.youtube.com/watch?v=AoA4IrPTJYI
 
I play the game solo far more than in multicrew, even when playing with mates.

This was entirely solo, my mates are in the Hammerhead, 7:30 you can see it glide in from the right with the party members markers in it.

You can play solo or multicrew, that's the point.

Source: https://www.youtube.com/watch?v=AoA4IrPTJYI

But, according to you, not in a big ship.

EDIT: hold on though, whatever happened to NPC crew that will be indistinguishable from players you could hire to serve on your ship? Pretty sure that's still planned (even if its a load of tosh).
 
I'd be interested to hear any thoughts you have on how other teams may be impacted by the wait for server meshing. Like we see an obvious fallout in their missed deadlines on getting a 2nd system into the game. But presumably design and engineering in other departments will also be fairly roadblocked in what they can do until the networking architecture is in a firmer place?

Meshing is a large scale architecture system; I don't think it acts as a roadblock to other mechanisms so much as overly complex mechanisms will act as a roadblock to it; the less stuff you have to pass over server boundaries the better, and as SC is aiming to work on a flexible/dynamic zone of control for each 'server', complex objects at the overlap of those zones as they expand/contract are something you want to avoid, yet as has been mentioned they're still slathering on the complexity like it's cheap relish. Some form of definitive network culling (of objects within the world scenegraph) in addition is probably needed, but how you define that is reliant on the game design. SC seems to have overcomplicated that in my opinion.
 
Meshing is a large scale architecture system; I don't think it acts as a roadblock to other mechanisms so much as overly complex mechanisms will act as a roadblock to it; the less stuff you have to pass over server boundaries the better, and as SC is aiming to work on a flexible/dynamic zone of control for each 'server', complex objects at the overlap of those zones as they expand/contract are something you want to avoid, yet as has been mentioned they're still slathering on the complexity like it's cheap relish. Some form of definitive network culling (of objects within the world scenegraph) in addition is probably needed, but how you define that is reliant on the game design. SC seems to have overcomplicated that in my opinion.

Cheers :)

Yep can definitely see as a layman how the sheer amount of data being handed between servers with the ships, while supporting twitch gameplay, must be a crazy challenge (and one they haven’t helped themselves with). Throw in any hard-to-predict 'mobile' boundaries between servers, and it seems like… nothing that exists currently, let’s put it that way ;)

On blockers I was thinking primarily of stuff like:

  • How do you design Multicrew PvP combat without knowing ballpark figures for player caps (and potentially per-ship caps)?
  • How do you design capital ship crewing / combative boarding / player control of external weapons etc if you don’t know whether your ship interior has to be supported by a server in its own right or not?
  • How do you establish large weapon range and type if you don’t know the nature of the data handover restrictions, the size of the liable play space, the frequency of handover liability? Stuff like that.

Essentially player owned Idrises (and potentially other large ship professions) seem like they’re a bit stuffed on the design front until you have answers in areas like those, to me ¯\(ツ)/¯
 
Last edited:
Cheers :)

Yep can definitely see as a layman how the sheer amount of data being handed between servers with the ships, while supporting twitch gameplay, must be a crazy challenge (and one they haven’t helped themselves with). Throw in any hard-to-predict 'mobile' boundaries between servers, and it seems like… nothing that exists currently, let’s put it that way ;)

On blockers I was thinking primarily of stuff like:

  • How do you design Multicrew PvP combat without knowing ballpark figures for player caps (and potentially per-ship caps)?
  • How do you design capital ship crewing / combative boarding / player control of external weapons etc if you don’t know whether your ship interior has to be supported by a server in its own right or not?
  • How do you establish large weapon range and type if you don’t know the nature of the data handover restrictions, the size of the liable play space, the frequency of handover liability? Stuff like that.

Essentially player owned Idrises (and potentially other large ship professions) seem like they’re a bit stuffed on the design front until you have answers in areas like those, to me ¯\(ツ)/¯

1) This is sort of what the object container streaming / network lod system is (far as I can tell, anyway). The idea is that (for example) the ship (as a container entity) becomes the primary object for propogation. Component / contained objects I'd think would then be prioritised (ship weapons, turrets, internals including players at the windows etc low down the list). I touched on network object culling, this is where it should come into play - you don't update or propogate objects to other network nodes (as a priority) that don't need to know. I've seen systems that use modified octrees for this sort of culling, the system I was working used a seperately defined 'relevance graph (sorta like a nested set of oldschool MUD rooms), but I'm not entirely sure what SC is doing behind the scenes.They've talked about spacial bubbles so I think it may be a range based nesting type affair. I suspect that a client is connected to multiple servers at multiple scales, though how they intend to sync all that or determine authority on the fly is gonna be fun.

2) Assuming scale is the determining factor I'd assume the ship object as a whole (and it's governed systems like life support etc) would be governed by an authoritive server, though it could be possible that there are server boundaries within a very large ship, which may be responsible for child objects.

3) You have a scenegraph of sorts, as per usual. Whether you divide and step that spatially (octree) or through a dynamic graph is by the by,
 
But, according to you, not in a big ship.

EDIT: hold on though, whatever happened to NPC crew that will be indistinguishable from players you could hire to serve on your ship? Pretty sure that's still planned (even if its a load of tosh).
They're making NPCs... erm... rather complex. Not sure why it's important (or desirable) that my crew may want to go buy takeout food from the galley, but hey. Pretty sure they haven't got them manning turrets yet.

But yes, for big ships you will need crew. At live (or some point before) they should be able to be NPC if you want. You will need to pay them. It's planned, and is for some god-knows reason required for SQ42, which is starting to not look much like Wing Commander to me.
 
I suspect that a client is connected to multiple servers at multiple scales, though how they intend to sync all that or determine authority on the fly is gonna be fun.

Ok that’d be an interesting scenario for designers / gameplay engineers to be working with. (As you say though, how it could actually be executed still begs a lot of questions, even to this layman ;))

I guess my question to you is: If you were designing such a system, at what point do you think you could let designers etc rip on it? (IE give them firm enough guesstimate parameters to work with: You can have X entities in Y space etc)

Or if it’s an easier question: At what point were gameplay designers brought in with the system you worked on? For example.
 
Designing data encoding is first principle; so game designers are briefed on things like minimising variables to send very early on. The actual number of simulated entites you can propogate or bounce around (and synchronise) depends a heck of a lot on deployment (hardware, network infrastructure, routing between disparate data centres). It was this that I ran into issues with in my system (worked great on a lan, as soon as I started farting around with longer or variable waits, things were not so fun. I've been out of the game for a very long time (about 15 years since I last coded) so my knowledge is now a very long way from current, never mind cutting edge. I believe the networking / data propogation is something AWS handles well which was one of the reasons why CIG switched over to Lumberyard. I've not actually looked at it in much detail though. I'm much happer just playing games than I was trying to write them. As a job, anyway.
 
Cheers again :)

Designing data encoding is first principle; so game designers are briefed on things like minimising variables to send very early on.

That sounds like good practice, but as you note with the ship complexity, that doesn’t seem to be what they’re doing ;)

(There’s a vague parallel in the infamous Jennison letter to HR, whereby CIG were seemingly ignoring sensible art budgeting [tris numbers etc]. It’s possible that they’re being less than circumspect here again. Perhaps due to art-driven directives from above.)

I believe the networking / data propogation is something AWS handles well which was one of the reasons why CIG switched over to Lumberyard

I’ve heard differently in this area. Mainly from guys who’ve worked with AWS/EC2 in a non-gaming setting, but their take is that it’s built for a pretty different use case to server meshing etc. IE 'robust delivery of data eventually'.

It seems it can do the business for arena-style shooters with a single dedicated server etc. But when it comes to communicating between them, due to the 'get what you’re given' nature of the system, and shared occupancy on the servers meaning you get a lot of variability in performance, the handshake will likely be less than ideal for twitch gameplay ;)

Supposedly only top end enterprise clients really get to interrogate the servers heavily too (and CIG’s contract doesn’t appear to be close to that league). So that would be another stumbling block if so.

It seems that in-house servers would have a lot of benefits in those areas for a server meshing style approach, comparatively. (Certainly PlanetSide 2 chose that route.)

(Another aspect that might be worthy of note is Amazon/Lumberyard’s own struggles to get their own MMO [New World] out the door. And that’s doubtless with top-tier access to all server facilities etc)
 
Last edited:
Back
Top Bottom