ManofManyAliases posted:

Can I play the part of the super cool Asian lawyer that knows martial arts and gets to ban people on forums? Just curious.

a cyberpunk goose posted:

Unpacking why SC is doomed from a technical perspective is conveniently (for chris roberts) very tough because it's extremely hard to get people's attentions long enough to elaborate on why making games is hard and you can't just ideas-guy development teams into doing the impossible. let's try to break Star Citizen down by starting from the abstract:

game engines are, at their core, real time operating systems (RTOS)

you have disparate systems that need to be scheduled, informed of things like user input or network activity, share state + somehow send messages to each other (or, more dangerously, directly reference each other), be maintained to respect logical contracts etc. there's not a lot of shortcuts you can take between these systems without introducing serious consequences to your runtime stability or overall code maintainability, you need to design it Right™ and early and not let it slip when other people start helping you maintain/grow the engine.

the above outlines the overall concepts an "engine developer" has to maintain and grapple with. this is explicitly distinct from a "game developer" which I'll outline next.

engine development is all very complicated and often way more brittle than you expect. How many "complete" racing games have you seen on the Source engine compared to FPS games? The answer is obvious and influenced strongly by the products the original engine developers were aiming for. Some engines, like Unity, have done a great job at not being married to any one framework of gameplay but that ultimately results in a larger conceptual gap that a "game developer" might need to fill if they aren't an experienced "engine" developer or aren't good at building their own operating frameworks for the kind of game they want to make. In something like Unity there's no built in concept of guns or inventory or reticles or chat systems or existing game-like behavior. unity bridges this gap a bit with an asset store but then you are banging differently shaped puzzle pieces made by strangers together that might not fit nicely

The following are questions you need to answer and grasp the implications of when making any game and picking an engine that will suit your development style: first person? racing? strategy? turn based? multiplayer? single player? local multiplayer? physics a part of the gameplay or just aesthetic? persistent centralized accounts (ie: an MMO or something like it)? ad hoc p2p player servers? the list goes on, but you need answers to every question you can think of that is a core component of your game.

The answers to these questions will influence what kinds of problems you're signing yourself up to solve. If I know I'm making a 20 player arena based FPS shooter, I might as well go with UDK because out of the box it has templates and a lot of community discussion surrounding making FPS games and it has a history of being for that, the engine will present low friction for this problem set. If I try to make an FPS game in game maker or from scratch in C++, I'm going to be miserable and have to basically reinvent every single wheel.

Every system your game needs, that your engine may or may not make easy on you, needs to interact well with its dependent systems & providers at run-time and also be maintainable and ideally compartmentalized, you don't want to realize half way through development that upgrading your engine to the latest upstream (which comes with features you've been begging for) will break literally everything because you were coding around undocumented potentially-is-actually-a-bug behavior in the engine because you didn't really grok the intent outlined in the documentation and naively code-bashed your way into a solution. developers in all software need to develop a 6th sense for what "smells bad" when trying to make a framework do something it wasn't meant for, leading you to overarchitect some things in some cases, but also make extreme but convenient and well-weighed short-cuts in others. this specific skill along with the ability to set expectations reasonably ( ) is at the crux of being a good software developer.

Realistically it is impossible to design perfect game systems in a vacuum that you can plug and play together with any sort of configuration, there's always a compromise or some sort of edge case you're introducing with other systems and you end up having to write a bunch of special edge case marshalling to do things like: translate between one spacial system to another, or have one set of physics objects follow one set of rules while another set of physics objects follows another. and the way you implement these systems will concrete you into behavior that will exclude other potentialities for designs in the game.

Now let's talk about Crytek and Cryengine. Cryengine specifically set out to solve one very specific set of problems in game development: rendering huge amounts of space & geography efficiently and having such large space also work sanely in multiplayer. This made it naturally suited for cool homebrew games like Mechwarrior: Living Legends. The engine already had existing frameworks for things such as controlling vehicles, rendering day/night cycles, complex shader techniques for mapping textures onto bump maps in a way that doesn't stretch, conveniences in the editor for editing large amounts of geometry and placing & rendering roads (entire white papers exist for rendering/editing roads sanely in bump-map engines lol).

That said, it's clear why at first glance Cryengine seemed like a good fit for SC, you have huge swathes of space as a game problem you need to solve, lo and behold Cryengine offers a partial solution at first glance. Cryengine also featured some zero-g segments at times, which I'm sure made Chris Robert's eyes pop out of his loving sockets on one of his major coke fueled gaming benders in a sad poorly furnished mcmansion somewhere.

It's not insanely difficult, if you have any game programming experience, to hop into an engine like Cryengine and start prototyping some things. Let's create a blank level, let's make the skybox be a nice starry sky texture, let's set gravity to 0, let's subclass the vehicle class and drop in one of our models. The engine is very low friction for this hello world smoke test. So you start flying around in your lovely 3d mesh and are feeling like a programming/game development god, zooming around thinking "Wow this is gonna be EASY", then you fly to far down on the Y axis and start drowning. "what the gently caress" you whisper as you squint. It's too late though, your boss, Chris Roberts, saw this early smoke test of assets and quickly started drafting up earnest estimates on how long OTHER systems will take, as if the demo you threw together is actually complete (when it's not). If you dont know how to hire devs you might put a senior dev in place who also doesn't grok how much actual work is left to be done and enforces your boss' stupid promises based on what isn't real game development. Guns are now pointed at you to fix the "small" issue or you'll be holding up the schedule (that no one consulted you about). so you work a weekend and dive into wtf happens when Y axis < CRY_WATER_LINE_HEIGHT. You find an instance in the base player controller logic and fix it, thinking you're done, but -- gently caress it turns out the physics subsystem also uses that same CRY_WATER_LINE_HEIGHT constant to do some optimizations, so you start grepping the code for that code instance and try flipping it off, except you don't realize there are some extra subsystems hidden somewhere that don't reference that constant like they should also do their own weird rendering tricks or optimizations when Y approaches that magic value.

there's a phrase in software development and especially games: 90% of the time is spent on the last 10% of polish. the last mile problem is super loving real in gamedev, seemingly tiny things in the grand scope of what you're delivering can make or break your game experience for players, and it's always those "tiny" things that are the results of weird edge cases from literally hundreds of subsystems interacting with eachother through the engine.

now, take the water example and apply it to basically everything. most likely every single system in cryengine has some kind of limit to what it was built to do originally and there are always unexpected results when you push engines into territory they werent developed for or tested for. now if you consider how Chris is pushing people to ship lovely demos and move on instead of developing a strong foundation for the rest of the game: you start to imagine how one could half rear end a system for an effect in demo and how "ok but it wont work outside of this or with any of the other things we talked about" might fall on deaf ears to a demonstrable cant-actually-delegate-or-listen-to-reason dingus like CRoberts.

now i want to introduce the final nail in the coffin. I could write like an essay on the basic MMO problem space but I wont, i'll keep it simple: MMOs are one of the hardest possible problems to tackle in a game development context from a resource management perspective. the amount of resource expertise (developers, architects, planning) and continued cost of servers and CPU/network time are as big as it gets in game development, and not only that but your game needs to be architected incredibly precisely to fit into the featureset your MMO imagination describes. you really can spare no unnecessary complexity when attempting an MMO, your scope needs to be VERY specific for your first release ( )

Even on a basic employee headcount level, Star Citizen doesn't employ nearly the number of experienced developers required for a project of this size, not only that but we all have plenty of evidence as to CRobert's awful management styles given how many rewrites and "refactors" occur for even the existing unfinished systems. there are clear, glaring signs of bad software development planning and inexperienced game developers rushing a product (while senior ones seem to keep leaving , weird!! ).

absolutely none of this is conducive to shipping the PU as shitizens imagine. they will never see their game. making games is really complicated, making multiplayer games is even MORE complicated, making MASSIVELY multiplayer games is THE most resource intensive & complicated from a project management perspective.

MilesK posted:

TheAgent posted:

why did I just buy persona 5, a known anime

Truga posted:

it's probably good

the animes are in jail

Tijuana Bibliophile posted:

Why is a bar in her head

Is this the new SC amine shader

Tijuana Bibliophile posted:

Why is a bar in her head

Is this the new SC amine shader

Wuxi posted:

There is crazy, then further down the spectrum is Star Citizen crazy

And at the end of it all is the crazy that produces these photoshops

TheAgent posted:

what the gently caress is wrong with these people

Ghostlight posted:

As much as you are here.

ManofManyAliases posted:

Are you not entertained?

ManofManyAliases posted:

It has come to my attention that I'm wanted in the Discord chat because I'm "almost trolling at this point." Sad - Don't meant to give that impression. I know that if I were to join, it would take up too much of my time (moreso than posting here) during my busy workday. Plus, I wouldn't even join the voice channel, so what use would I be?

Dooguk posted:

https://forums.robertsspaceindustries.com/discussion/comment/7601775/#Comment_7601775.

I am lost for words.

ManofManyAliases posted:

It has come to my attention that I'm wanted in the Discord chat because I'm "almost trolling at this point." Sad - Don't meant to give that impression. I know that if I were to join, it would take up too much of my time (moreso than posting here) during my busy workday. Plus, I wouldn't even join the voice channel, so what use would I be?

Nicholas posted:

this belongs in OP.

Beet Wagon posted:

Nobody joins the voice channels, except for during the big CitCon stream.

Quavers posted:

Uh-oh, it's all kicking off on INN Relay:

https://www.youtube.com/watch?v=i_-9J1x4GoI&t=4050s

"ok it's now time for the 3.0 production schedule"

"we were promised a Sq42 schedule, and a 3.0 schedule. It's been a quarter of a year. We need to know what's going on"

ManofManyAliases posted:

Are you not entertained?

Jobbo_Fett posted:

You'd think that MOMA would have a good understanding of how Discord works after Spectrum copied it wholesale

a cyberpunk goose posted:

a cyberpunk goose posted:

Unpacking why SC is doomed from a technical perspective is conveniently (for chris roberts) very tough because it's extremely hard to get people's attentions long enough to elaborate on why making games is hard and you can't just ideas-guy development teams into doing the impossible. let's try to break Star Citizen down by starting from the abstract:

(&c...)

a cyberpunk goose posted:

Unpacking why SC is doomed from a technical perspective is conveniently (for chris roberts) very tough because it's extremely hard to get people's attentions long enough to elaborate on why making games is hard and you can't just ideas-guy development teams into doing the impossible. let's try to break Star Citizen down by starting from the abstract:

game engines are, at their core, real time operating systems (RTOS)

you have disparate systems that need to be scheduled, informed of things like user input or network activity, share state + somehow send messages to each other (or, more dangerously, directly reference each other), be maintained to respect logical contracts etc. there's not a lot of shortcuts you can take between these systems without introducing serious consequences to your runtime stability or overall code maintainability, you need to design it Right™ and early and not let it slip when other people start helping you maintain/grow the engine.

the above outlines the overall concepts an "engine developer" has to maintain and grapple with. this is explicitly distinct from a "game developer" which I'll outline next.

engine development is all very complicated and often way more brittle than you expect. How many "complete" racing games have you seen on the Source engine compared to FPS games? The answer is obvious and influenced strongly by the products the original engine developers were aiming for. Some engines, like Unity, have done a great job at not being married to any one framework of gameplay but that ultimately results in a larger conceptual gap that a "game developer" might need to fill if they aren't an experienced "engine" developer or aren't good at building their own operating frameworks for the kind of game they want to make. In something like Unity there's no built in concept of guns or inventory or reticles or chat systems or existing game-like behavior. unity bridges this gap a bit with an asset store but then you are banging differently shaped puzzle pieces made by strangers together that might not fit nicely

The following are questions you need to answer and grasp the implications of when making any game and picking an engine that will suit your development style: first person? racing? strategy? turn based? multiplayer? single player? local multiplayer? physics a part of the gameplay or just aesthetic? persistent centralized accounts (ie: an MMO or something like it)? ad hoc p2p player servers? the list goes on, but you need answers to every question you can think of that is a core component of your game.

The answers to these questions will influence what kinds of problems you're signing yourself up to solve. If I know I'm making a 20 player arena based FPS shooter, I might as well go with UDK because out of the box it has templates and a lot of community discussion surrounding making FPS games and it has a history of being for that, the engine will present low friction for this problem set. If I try to make an FPS game in game maker or from scratch in C++, I'm going to be miserable and have to basically reinvent every single wheel.

Every system your game needs, that your engine may or may not make easy on you, needs to interact well with its dependent systems & providers at run-time and also be maintainable and ideally compartmentalized, you don't want to realize half way through development that upgrading your engine to the latest upstream (which comes with features you've been begging for) will break literally everything because you were coding around undocumented potentially-is-actually-a-bug behavior in the engine because you didn't really grok the intent outlined in the documentation and naively code-bashed your way into a solution. developers in all software need to develop a 6th sense for what "smells bad" when trying to make a framework do something it wasn't meant for, leading you to overarchitect some things in some cases, but also make extreme but convenient and well-weighed short-cuts in others. this specific skill along with the ability to set expectations reasonably ( ) is at the crux of being a good software developer.

Realistically it is impossible to design perfect game systems in a vacuum that you can plug and play together with any sort of configuration, there's always a compromise or some sort of edge case you're introducing with other systems and you end up having to write a bunch of special edge case marshalling to do things like: translate between one spacial system to another, or have one set of physics objects follow one set of rules while another set of physics objects follows another. and the way you implement these systems will concrete you into behavior that will exclude other potentialities for designs in the game.

Now let's talk about Crytek and Cryengine. Cryengine specifically set out to solve one very specific set of problems in game development: rendering huge amounts of space & geography efficiently and having such large space also work sanely in multiplayer. This made it naturally suited for cool homebrew games like Mechwarrior: Living Legends. The engine already had existing frameworks for things such as controlling vehicles, rendering day/night cycles, complex shader techniques for mapping textures onto bump maps in a way that doesn't stretch, conveniences in the editor for editing large amounts of geometry and placing & rendering roads (entire white papers exist for rendering/editing roads sanely in bump-map engines lol).

That said, it's clear why at first glance Cryengine seemed like a good fit for SC, you have huge swathes of space as a game problem you need to solve, lo and behold Cryengine offers a partial solution at first glance. Cryengine also featured some zero-g segments at times, which I'm sure made Chris Robert's eyes pop out of his loving sockets on one of his major coke fueled gaming benders in a sad poorly furnished mcmansion somewhere.

It's not insanely difficult, if you have any game programming experience, to hop into an engine like Cryengine and start prototyping some things. Let's create a blank level, let's make the skybox be a nice starry sky texture, let's set gravity to 0, let's subclass the vehicle class and drop in one of our models. The engine is very low friction for this hello world smoke test. So you start flying around in your lovely 3d mesh and are feeling like a programming/game development god, zooming around thinking "Wow this is gonna be EASY", then you fly to far down on the Y axis and start drowning. "what the gently caress" you whisper as you squint. It's too late though, your boss, Chris Roberts, saw this early smoke test of assets and quickly started drafting up earnest estimates on how long OTHER systems will take, as if the demo you threw together is actually complete (when it's not). If you dont know how to hire devs you might put a senior dev in place who also doesn't grok how much actual work is left to be done and enforces your boss' stupid promises based on what isn't real game development. Guns are now pointed at you to fix the "small" issue or you'll be holding up the schedule (that no one consulted you about). so you work a weekend and dive into wtf happens when Y axis < CRY_WATER_LINE_HEIGHT. You find an instance in the base player controller logic and fix it, thinking you're done, but -- gently caress it turns out the physics subsystem also uses that same CRY_WATER_LINE_HEIGHT constant to do some optimizations, so you start grepping the code for that code instance and try flipping it off, except you don't realize there are some extra subsystems hidden somewhere that don't reference that constant like they should also do their own weird rendering tricks or optimizations when Y approaches that magic value.

there's a phrase in software development and especially games: 90% of the time is spent on the last 10% of polish. the last mile problem is super loving real in gamedev, seemingly tiny things in the grand scope of what you're delivering can make or break your game experience for players, and it's always those "tiny" things that are the results of weird edge cases from literally hundreds of subsystems interacting with eachother through the engine.

now, take the water example and apply it to basically everything. most likely every single system in cryengine has some kind of limit to what it was built to do originally and there are always unexpected results when you push engines into territory they werent developed for or tested for. now if you consider how Chris is pushing people to ship lovely demos and move on instead of developing a strong foundation for the rest of the game: you start to imagine how one could half rear end a system for an effect in demo and how "ok but it wont work outside of this or with any of the other things we talked about" might fall on deaf ears to a demonstrable cant-actually-delegate-or-listen-to-reason dingus like CRoberts.

now i want to introduce the final nail in the coffin. I could write like an essay on the basic MMO problem space but I wont, i'll keep it simple: MMOs are one of the hardest possible problems to tackle in a game development context from a resource management perspective. the amount of resource expertise (developers, architects, planning) and continued cost of servers and CPU/network time are as big as it gets in game development, and not only that but your game needs to be architected incredibly precisely to fit into the featureset your MMO imagination describes. you really can spare no unnecessary complexity when attempting an MMO, your scope needs to be VERY specific for your first release ( )

Even on a basic employee headcount level, Star Citizen doesn't employ nearly the number of experienced developers required for a project of this size, not only that but we all have plenty of evidence as to CRobert's awful management styles given how many rewrites and "refactors" occur for even the existing unfinished systems. there are clear, glaring signs of bad software development planning and inexperienced game developers rushing a product (while senior ones seem to keep leaving , weird!! ).

absolutely none of this is conducive to shipping the PU as shitizens imagine. they will never see their game. making games is really complicated, making multiplayer games is even MORE complicated, making MASSIVELY multiplayer games is THE most resource intensive & complicated from a project management perspective.

a cyberpunk goose posted: