Game Discussions Star Citizen Discussion Thread v12

LittleAnt

L
How to increase your chances of survival during a hacking operation
o868ixhnz2k51.jpg
 

StuartGT

StuartGT
Ben Parry said:
I arrived a couple of years after the crowdfunding campaign, so far too late for any of that kind of discussion. I would still say that building an engine from scratch, even with the budget fully known in advance, would have been pure madness. It's not just about the glossiness of early demos, it's about having things like a level editor, uh, ever. Building a level editor that isn't total hell to use is a massive standalone software project that requires some skill sets that you don't usually even hire for on a game team. Then trying to build deep infrastructure features from scratch when all the other infrastructure is still a design document...
My guess is that you'd have seen slightly-less-glossy demos slightly later, maybe one or two ship exteriors flying about with nice lighting, but then a dead stall when it turned out those demos were just loading assets from a script, there was no LOD system, physics was convex hulls only, you could only have ten lights maximum, there was no mesh/texture streaming, etc.
Obviously an alternative to either of those would be to "build" an engine by licensing a bunch of third-party libraries to do the infrastructure stuff and gluing them together, but that really just seems like the worst of both worlds.
Click to expand...
I suppose it's a good thing that Chris and CIG told us all that the games had been in production for a full year prior to the Kickstarter, that everything shown was playable gameplay, and both Sq42 and SC would launch only a couple of years later 🤷‍♂️
lWZKEBy.png

tpSrf4L.png

oe1DhIr.png

5pJHb60.png


What are your thoughts on this album, Ben?
https://imgur.com/a/P9PZSNw
Source: https://imgur.com/a/P9PZSNw
 

romay

R
Ben Parry said:
I arrived a couple of years after the crowdfunding campaign, so far too late for any of that kind of discussion. I would still say that building an engine from scratch, even with the budget fully known in advance, would have been pure madness. It's not just about the glossiness of early demos, it's about having things like a level editor, uh, ever. Building a level editor that isn't total hell to use is a massive standalone software project that requires some skill sets that you don't usually even hire for on a game team. Then trying to build deep infrastructure features from scratch when all the other infrastructure is still a design document...
My guess is that you'd have seen slightly-less-glossy demos slightly later, maybe one or two ship exteriors flying about with nice lighting, but then a dead stall when it turned out those demos were just loading assets from a script, there was no LOD system, physics was convex hulls only, you could only have ten lights maximum, there was no mesh/texture streaming, etc.
Obviously an alternative to either of those would be to "build" an engine by licensing a bunch of third-party libraries to do the infrastructure stuff and gluing them together, but that really just seems like the worst of both worlds.
Click to expand...

Been there, done that.
Key is to not re-invent the wheel.
Typical solution for proprietary stuff (level data, action scripting):Take existing modelling software that's as close as possible to what you want to model, write plugin.
Once the plugin works (in my case, took about 3 months) pass it on to the pixel pushers so they can get started and have some UI coders extend it to a standalone application in parallel.
Some people actually enjoy UI coding and they are also generally cheaper than 3D coders.
If you don't like that route, just use an existing multi-purpose editor like ATF and work your way from there.
For less proprietary assets, just use industry standard (Blender, Maya) + fbx/glTF.
For all the other stuff, just rely heavily on middleware. There's a ton of physics / render / procgen stuff out there already, some of it open source. Take whatever fits your needs, if you need to extend something, make sure you have the sourcecode and no license issues, and hack away.
Framework (as in: basic routines for file access, user input, error handling, memory tracking, resource managment, render setup, maybe rendering backend) need to be hand-coded but a decent team can create a good foundation in weeks and extend it as they go.
May still take a year until your first iteration of the engine is running, but then it's smooth sailing.
Needs some careful planning, though.
 

Agony_Aunt

Agony_Aunt
Esvandiary said:
Oh come on, you know full well that the only answer any employee in this situation would be willing to give is "it has some nice pictures, and lots of words."
Having Ben around gives us some cool insights into the bits of SC he's worked on, don't scare him off again :p
Click to expand...

Yeah, no way can Ben comment on those.

Whatever his personal opinion of those things, he's got to tow the company line.
 

Skizomeuh

Skizomeuh
romay said:
Been there, done that.
Key is to not re-invent the wheel.
Typical solution for proprietary stuff (level data, action scripting):Take existing modelling software that's as close as possible to what you want to model, write plugin.
Once the plugin works (in my case, took about 3 months) pass it on to the pixel pushers so they can get started and have some UI coders extend it to a standalone application in parallel.
Some people actually enjoy UI coding and they are also generally cheaper than 3D coders.
If you don't like that route, just use an existing multi-purpose editor like ATF and work your way from there.
For less proprietary assets, just use industry standard (Blender, Maya) + fbx/glTF.
For all the other stuff, just rely heavily on middleware. There's a ton of physics / render / procgen stuff out there already, some of it open source. Take whatever fits your needs, if you need to extend something, make sure you have the sourcecode and no license issues, and hack away.
Framework (as in: basic routines for file access, user input, error handling, memory tracking, resource managment, render setup, maybe rendering backend) need to be hand-coded but a decent team can create a good foundation in weeks and extend it as they go.
May still take a year until your first iteration of the engine is running, but then it's smooth sailing.
Needs some careful planning, though.
Click to expand...
And during that time, as a director, write the damn design! Something a little more detailed than "I want it all, everything and the kitchen sink with no compromise". And listen to your specialists, and accept when they say no.
 

Viajero

Volunteer Moderator
Viajero
romay said:
Been there, done that.
Key is to not re-invent the wheel.
Typical solution for proprietary stuff (level data, action scripting):Take existing modelling software that's as close as possible to what you want to model, write plugin.
Once the plugin works (in my case, took about 3 months) pass it on to the pixel pushers so they can get started and have some UI coders extend it to a standalone application in parallel.
Some people actually enjoy UI coding and they are also generally cheaper than 3D coders.
If you don't like that route, just use an existing multi-purpose editor like ATF and work your way from there.
For less proprietary assets, just use industry standard (Blender, Maya) + fbx/glTF.
For all the other stuff, just rely heavily on middleware. There's a ton of physics / render / procgen stuff out there already, some of it open source. Take whatever fits your needs, if you need to extend something, make sure you have the sourcecode and no license issues, and hack away.
Framework (as in: basic routines for file access, user input, error handling, memory tracking, resource managment, render setup, maybe rendering backend) need to be hand-coded but a decent team can create a good foundation in weeks and extend it as they go.
May still take a year until your first iteration of the engine is running, but then it's smooth sailing.
Needs some careful planning, though.
Click to expand...
No expert here and prolly misunderstood this but that sounded a lot like a “Ben doesn’t understand game development”.😋
 
Last edited:

Mole HD

Mole HD
Tippis said:
The Peter Principle exists for a reason. 🙃
Click to expand...
That's all well and good...but how many other actual working devs from Ci¬G...or FDev for that matter... does anyone on this or any other forum ever hear from just passing the time of day like one of us regular peasants? I certainly appreciate Ben taking the time to post on here to drop the odd comment every now and then, even if to just say "Hi."....No matter where he works. :)
 
Last edited:

Ben Parry

Ben Parry
romay said:
Been there, done that.
Key is to not re-invent the wheel.
Typical solution for proprietary stuff (level data, action scripting):Take existing modelling software that's as close as possible to what you want to model, write plugin.
Once the plugin works (in my case, took about 3 months) pass it on to the pixel pushers so they can get started and have some UI coders extend it to a standalone application in parallel.
Some people actually enjoy UI coding and they are also generally cheaper than 3D coders.
If you don't like that route, just use an existing multi-purpose editor like ATF and work your way from there.
For less proprietary assets, just use industry standard (Blender, Maya) + fbx/glTF.
For all the other stuff, just rely heavily on middleware. There's a ton of physics / render / procgen stuff out there already, some of it open source. Take whatever fits your needs, if you need to extend something, make sure you have the sourcecode and no license issues, and hack away.
Framework (as in: basic routines for file access, user input, error handling, memory tracking, resource managment, render setup, maybe rendering backend) need to be hand-coded but a decent team can create a good foundation in weeks and extend it as they go.
May still take a year until your first iteration of the engine is running, but then it's smooth sailing.
Needs some careful planning, though.
Click to expand...
I absolutely agree with everything you've said here. All I'd argue is that (assuming equivalent quality) the end result of that assembly is going to be pretty similar to buying a license for a commercial game engine, maybe a few more annoying things that don't match up and a few fewer things that are messily coupled together when they shouldn't be. That said, I've never worked on something that was built that way.

Agony_Aunt said:
Yeah, no way can Ben comment on those.

Whatever his personal opinion of those things, he's got to tow the company line.
Click to expand...
My posts here have always been my own opinions, but I don't try to answer for or undercut people I work/worked with/for. As for toeing the company line though, uh... I actually don't work for CIG any more. I have a new job starting next week, so when I continue to appear whenever someone types the number 32 or 64, you'll see that I still have the same views ;)
 
You must log in or register to reply here.
Back
Top Bottom