Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
Godmode Enabled
Jul 14, 2013

I AM A BETAGOON, ASK ME ABOUT PROPER GRIEF TO CASH RATIOS.
People justifying spending $1000+ thread :allears:
https://forums.robertsspaceindustries.com/discussion/376205/how-i-validate-spending-over-1-000-on-a-game#latest

Adbot
ADBOT LOVES YOU

Beer4TheBeerGod
Aug 23, 2004
Exciting Lemon

Colostomy Bag posted:

Yep, I'm looking forward to playing with my family org and having five year old Timmy haul around crates of dismembered bodies.

My friend have you heard of the wonder that is Rimworld?

Beer4TheBeerGod
Aug 23, 2004
Exciting Lemon

Technically he's right. Most people justify wasting money by showing the advertisements of the thing they just bought.

The difference is that most people get the thing they paid for.

Beer4TheBeerGod
Aug 23, 2004
Exciting Lemon
Also I care SO LITTLE about what other people think about how I spend my money that I insist on posting about it on a thread justifying why it's okay to spend my money.

trucutru
Jul 9, 2003

by Fluffdaddy

Beet Wagon posted:

Every time there's a serious content/news drought from CIG the citizens get spun up to the point of going past absurd into downright worrisome. Like... ordinarily I can scroll through /r/starcitizen and go "haha these people are mentally unwell in a very funny way" but holy poo poo there's something about reading page upon page of speculation about how the new delta patcher (estimated release date: never) will save Star Citizen that just boils my goddamn brain.

Remember when they added *persistence*? And that it would allow them to do all sorts of magical things. Well, now in order to get those same things they also need item 2.0, serialized variables, and network 2.0 so that they can build persistence 2.0.

Beer4TheBeerGod posted:

Also I care SO LITTLE about what other people think about how I spend my money that I insist on posting about it on a thread justifying why it's okay to spend my money.

What happened to that Odude who was always saying that he spent like 40k and was rich and would just not shut up about it? Or am I thinking of bitcoins?

Space Crabs
Mar 10, 2007

by FactsAreUseless

Drunk Theory posted:

Huh. I thought they fixed the bug that caused Parts of the station to drift/detach. You'd think with how little is in the patch notes, what is would be buttoned up. (of course it's not, and no one should be surprised)

Funny thing, when you are just modding something you can't really change the base game.

So if their hack for turning a building into a moving station starts to fall apart as the clusterfuck of their mod gets more and more confused then they have few options to actually fix the problem, and one of the only ones they have is to just remove the rotating rings entirely and have the entire structure be static.

Same way their reskinned NOCLIP crysis jeeps glitching out constantly was resolved by cutting the speed values in half and slowing down all the collisions so they are less buggy and it's less obvious they are in NOCLIP.

Same way they just made the water that comes default in Cryengine environments invisible with no velocity/mechanic changes for it but they can't actually get rid of the visors being splashed with water when you transition from below/above water.

Same way that anyone who played the original Crysis knows how inaccurate bullet tracking is in Cryengine, to where you could empty 200+ rounds from your weapon into an enemy that would just dance back and forth because he knew he was being shot at but the bullets weren't tracking. They've crammed everyone into tiny PVP hallways.

Same thing with FreeLancer mods, where people were creating ships that were too big to go through the travel lanes so they either designed special ship specific supercruise engines that traveled as fast as the superlanes to bypass them or copied the space lane mechanic onto a flat plane so you didn't have to be a certain size to activate it. If they had been able to code the engine they could have just made ships have a intra system jump drive that teleports you or wormhole generators or something.

AbstractNapper
Jun 5, 2011

I can help
In the unlikely event that CIG finally releases a working (yeah, it really needs this qualifier) delta patcher at least they might increase their productivity; I remember that they have confirmed that their disparate teams also exchange the full GBs of data and that takes up lots of time. Again, they are doing this for years, or at least since they actually started developing something that's not promotional ship videos.

But then again, if they are adding planets and more stuff, a delta patcher won't help much there. For bugfixes and small updates it's perfect, but I am looking forward to Citizens being excited for getting the delta patcher only to have to download a 1TB+ update because "we added one planet to the system".

Rad Russian
Aug 15, 2007

Soviet Power Supreme!

Kellanved posted:

All these physics glitches remind me of when I was messing around with Garry's mod some years ago, without any idea on how to attach things.

But I'm pretty interested, is there any speculation on what they messed up? Because they have bugs on every level, and that's not normal.

They have an idiot leading the project who decided that in order to do something that has never been done before, he will pick CryEngine to do that.

How did he come to this most important decision in the life of a game project? Crytek sent him a pre-rendered cutscene /trailer after they heard about him starting the project to promote the engine. It looked pretty, and without any further research into features and what it can actually do tech wise, he simply went with CryEngine. Basically swindled by pretty pictures like the rest of the Shitizens.

So he seemed to have a knack for great decision making as CEO right form the start. His next big decision was to outsource FPS portion of the game to Illfonic, which worked out great too and totally did not waste several million of backer money. After that, before reportedly spending close to $40 million on mocap, he diligently made sure that this mocap can actually be imported into CryEngine. All prior to spending all this money on it, of course. Otherwise there would be costly re-shoots to the tune of $20 million, and this time without all the A-list actors he hired before. That would not have been acceptable at all.

Let's get him to $200 mil guys.

Rad Russian fucked around with this message at 17:37 on Apr 3, 2017

D_Smart
May 11, 2010

by FactsAreUseless
College Slice

Rad Russian posted:

They have an idiot leading the project who decided that in order to do something that has never been done before, he will pick CryEngine to do that.

:perfect:

My first lol of Monday :grin:

a cyberpunk goose
May 21, 2007

Kellanved posted:

But I'm pretty interested, is there any speculation on what they messed up? Because they have bugs on every level, and that's not normal.

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 ( :siren: ) 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 ( :siren: )

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 :newlol:, 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.

thatguy
Feb 5, 2003

Space Crabs posted:

Funny thing, when you are just modding something you can't really change the base game.

So if their hack for turning a building into a moving station starts to fall apart as the clusterfuck of their mod gets more and more confused then they have few options to actually fix the problem, and one of the only ones they have is to just remove the rotating rings entirely and have the entire structure be static.

Same way their reskinned NOCLIP crysis jeeps glitching out constantly was resolved by cutting the speed values in half and slowing down all the collisions so they are less buggy and it's less obvious they are in NOCLIP.

Same way they just made the water that comes default in Cryengine environments invisible with no velocity/mechanic changes for it but they can't actually get rid of the visors being splashed with water when you transition from below/above water.

Same way that anyone who played the original Crysis knows how inaccurate bullet tracking is in Cryengine, to where you could empty 200+ rounds from your weapon into an enemy that would just dance back and forth because he knew he was being shot at but the bullets weren't tracking. They've crammed everyone into tiny PVP hallways.

Same thing with FreeLancer mods, where people were creating ships that were too big to go through the travel lanes so they either designed special ship specific supercruise engines that traveled as fast as the superlanes to bypass them or copied the space lane mechanic onto a flat plane so you didn't have to be a certain size to activate it. If they had been able to code the engine they could have just made ships have a intra system jump drive that teleports you or wormhole generators or something.


Rad Russian posted:

They have an idiot leading the project who decided that in order to do something that has never been done before, he will pick CryEngine to do that.

How did he come to this most important decision in the life of a game project? Crytek sent him a pre-rendered cutscene /trailer after they heard about him starting the project to promote the engine. It looked pretty, and without any further research into features and what it can actually do tech wise, he simply went with CryEngine. Basically swindled by pretty pictures like the rest of the Shitizens.

So he seemed to have a knack for great decision making as CEO right form the start. His next big decision was to outsource FPS portion of the game to Illfonic, which worked out great too and totally did not waste several million of backer money. After that, before reportedly spending close to $40 million on mocap, he diligently made sure that this mocap can actually be imported into CryEngine. All prior to spending all this money on it, of course. Otherwise there would be costly re-shoots to the tune of $20 million, and this time without all the A-list actors he hired before. That would not have been acceptable at all.

Let's get him to $200 mil guys.


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 ( :siren: ) 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 ( :siren: )

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 :newlol:, 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.
I read all of this.

thatguy
Feb 5, 2003

thatguy posted:

I read all of this.
PSYCHE!

a cyberpunk goose
May 21, 2007


n-no... not like this

ManofManyAliases
Mar 21, 2016
ToastOfManySmarts


Can't post for 3 hours!

Are they paying you by the word?

edit: If so, how much?

ManofManyAliases fucked around with this message at 18:39 on Apr 3, 2017

a cyberpunk goose
May 21, 2007

ManofManyAliases posted:

Are they paying you by the word?

edit: If so, how much?

derek and I have an NDA about how much he pays me for shill posts

Runa
Feb 13, 2011

Hell, I laughed when I saw the gas chamber style sheet

ManofManyAliases posted:

Are they paying you by the word?

edit: If so, how much?

drat, son

(for real though, good post a cyberpunk goose)

a cyberpunk goose
May 21, 2007

it's in the easily 3.5 figgies tho

Quavers
Feb 26, 2016

You clearly don't understand game development

:five:

Regrettable
Jan 5, 2010



So, kind of SC related, but has anyone here seen Illfonic's most recent project? Friday the 13th: The Game

I watched some streams of the beta recently and it looks like it might actually be fun. It's a multiplayer game where you play as camp counselors trying to escape from or stop Jason Voorhees and one lucky person gets to play as Jason and try to find and kill everyone else. I do have a soft spot for 80s horror movies, though.

e: I forgot to mention that they hired Kane Hodder do a lot of the mocap for the game, which is pretty cool.

Regrettable fucked around with this message at 18:54 on Apr 3, 2017

RabbitWizard
Oct 21, 2008

Muldoon

But have you seen the features promised????? I guess you don't understand anything about game development, sorry.

Quavers
Feb 26, 2016

You clearly don't understand game development

ManofManyAliases posted:

Are they paying you by the word?

edit: If so, how much?

How is the project looking for you: are SC and Sq42 on track in your mind? (from Jun 21, 2016)

ManofManyAliases posted:

I know I said it a number of times: I really expect at least a mission or two out of SQ42 this year as a teaser, with release of SQ42 next year (summer maybe)? And I'm thinking we'll enter beta by the end of next year with full release in 2018. That said, my 'oh-poo poo' moment will likely be observation of progress by end of Q2 next year: if procedural tech, netcode and and other gameplay mechanics aren't more refined at that point, it's probably too far past a salvage point. Then again, I fully expect the grey-market to still be a viable alternative to offload most of my assets, even by Summer of next year.

a cyberpunk goose
May 21, 2007

RabbitWizard posted:

But have you seen the features promised????? I guess you don't understand anything about game development, sorry.

heh, check this out, obvious derek shill:

code:
sv_trading = 1
sv_cargo_system = 1
sv_fidelity = 9999999
sv_subsumption = 1
sv_planetary_simulation = 1
:ocelot:

Hav
Dec 11, 2009

Fun Shoe

a cyberpunk goose posted:

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.

Quality post.

a cyberpunk goose posted:

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.

https://en.wikipedia.org/wiki/Ninety-ninety_rule

Most developers go through this when they code an entire backend in two days, then spend eight hours on some minor loving thing that should just loving work, but doesn't....oh a non-printing space?

D_Smart
May 11, 2010

by FactsAreUseless
College Slice

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 ( :siren: ) 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 ( :siren: )

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 :newlol:, 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.

:perfect:

Quavers
Feb 26, 2016

You clearly don't understand game development

Chin
Dec 12, 2005

GET LOST 2013
-RALPH
Read and upvoted.

RabbitWizard
Oct 21, 2008

Muldoon

a cyberpunk goose posted:

heh, check this out, obvious derek shill:

code:
sv_trading = 1
sv_cargo_system = 1
sv_fidelity = 9999999
sv_subsumption = 1
sv_planetary_simulation = 1
:ocelot:

:stare: OK you seem to know everything there is about programming. I'm sorry for what I said before.

(I hope Derek doesn't take something off my paycheck this month!)

TheAgent
Feb 16, 2002

The call is coming from inside Dr. House
Grimey Drawer
I'm happy LOD is selling well so Derek can hire more people like me

Ghostlight
Sep 25, 2009

maybe for one second you can pause; try to step into another person's perspective, and understand that a watermelon is cursing me



It's not really outsourcing when you're just giving your work to another arm of the company to do.

RabbitWizard
Oct 21, 2008

Muldoon

TheAgent posted:

I'm happy LOD is selling well so Derek can hire more people like me

Did we have a goon yet that bought LOD out of spite to stick it to SC?

TheAgent
Feb 16, 2002

The call is coming from inside Dr. House
Grimey Drawer
I bought some copies of Derek's games to spread around here

Also some other space games

ManofManyAliases
Mar 21, 2016
ToastOfManySmarts


Can't post for 3 hours!

a cyberpunk goose posted:

heh, check this out, obvious derek shill:

code:
sv_trading = 1
sv_cargo_system = 1
sv_fidelity = 9999999
sv_subsumption = 1
sv_planetary_simulation = 1
:ocelot:

I'm sold. Let's commit it and get this going.

ManofManyAliases
Mar 21, 2016
ToastOfManySmarts


Can't post for 3 hours!

TheAgent posted:

I'm happy LOD is selling well so Derek can hire more people like me



It's not LOD silly. Derek made his millions from Battlecruiser-Alganon-Galactic Command-Warhammer-Planetside-Tactics-All Aspect Warefare Mod. LOD is completely new and not even released yet, closed beta and all.

TheAgent
Feb 16, 2002

The call is coming from inside Dr. House
Grimey Drawer
I'm about to buy my PC gaming obsessed friend star citizen because he won't shut up about how amazing it is yet hasn't played it

TheAgent
Feb 16, 2002

The call is coming from inside Dr. House
Grimey Drawer

ManofManyAliases posted:

It's not LOD silly. Derek made his millions from Battlecruiser-Alganon-Galactic Command-Warhammer-Planetside-Tactics-All Aspect Warefare Mod. LOD is completely new and not even released yet, closed beta and all.
Moma you are actually a cool guy and I wrote you way better than I originally did

fyi I'm working on a star citizen game in rpgmaker, I figure the fidelity layering will come afterwards

Hav
Dec 11, 2009

Fun Shoe

Ghostlight posted:

It's not really outsourcing when you're just giving your work to another arm of the company to do.

Technically they're individual companies under the aegis of the brand, but yes, I misused 'outsourcing' in the classical vernacular, but I was making a stab at this not being a department a floor down. Geography actually matters.

I was more getting at the whole 'The other guys phoned it in' nature of this when ultimately there's someone going 'sure, that seems fine for going gold'. Especially given the reported reasons behind it. There's a weird context there.

ManofManyAliases
Mar 21, 2016
ToastOfManySmarts


Can't post for 3 hours!

TheAgent posted:

Moma you are actually a cool guy and I wrote you way better than I originally did

fyi I'm working on a star citizen game in rpgmaker, I figure the fidelity layering will come afterwards

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

MeLKoR
Dec 23, 2004

by FactsAreUseless
:agreed:

TheAgent
Feb 16, 2002

The call is coming from inside Dr. House
Grimey Drawer

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.
actually yea

Adbot
ADBOT LOVES YOU

MilesK
Nov 5, 2015










  • 1
  • 2
  • 3
  • 4
  • 5