How software development actually works (and how Facepunch is Failing) - Rust

Let me preface with a couple things... 1. I work for a software company, and have performed in several roles.... 2. I have played around 1300 hours of Rust so I know a thing or 2 about whats been going on. Here is how it goes... A. Capture the main objective of the project (what is the desired outcome). B. Create a work breakdown structure of the tasks needed to meet the desired outcome. C. Create a sizing of the effort/cost of each line item, in order to form Milestones. D. Track to the milestones, to assess whether or not you are behind on where you wanted to be for the given deadline. Here is where Facepunch is failing: First, what is Facepunch's desired outcome? Is it to create a functional game that people will enjoy? If so, then why are they spending time adding bucket helmets, boots that look like frogs.. etc.. and not addressing the basic functionality of the game. Software development cannot be open-ended. There has to be a desired date of completion... in this context "completion" does not mean that all development is over... it just means that there is a basic game that is fully functional. There has to be a stable/solid product... that can then be upgraded. Seems facepunch is going for a Ferrari out of the gate. Give people the basic's, and then work on variations of cloths, weapons, tools, after you have refined all of the other major components needed to make the game functional. The recipe for Rust 2.0 is to get to a baseline of Rust Legacy, and then go from there. Facepunch may have some high level ideas of the tasks they need to perform, but their priorities are all over the place. They give us a little bit of this, a little of that... The more you introduce, the more bugs are created, the more time you spend addressing said bugs...the less time you spend implementing new things. There are software development strategies to mitigate what we are seeing with this game. Iterative development is best for a project of this magnitude... Create a solid (but very basic) release. Let people play on it... this is the nature of "Alpha", you let the game community be your testers... You then implement new code on top of your functional baseline, and you test it in the development region (unit and integration testing) to assess any major impacts (like if i spend a week implementing a new lock system... what happens if the server needs to be restarted)... Seems Face-punch is using a combo of Agile and waterfall methodology... They are not sure what direction to go, they pick a tangent and start moving on it, and their focus on an actual "baseline" is lost. The issue with this is that you spend time putting in new functionality, then addressing bugs that stem from them...then putting in more new things, while previous bugs exist... now dealing with a new set of bugs on top of old bugs... it becomes a tangled web. The solution here is Iterative Development with explicit goals of that implementation. Slower release cycles to vet out major issues, etc... Again... implement the basic elements to make the game functional. Address bug issues with the code you have released... and then implement variations of what has been implemented.

but the game is functional All they are doing right now is improving the systems already in place, whilst adding new ones, and "trivial" content like clothing

[QUOTE]Software development cannot be open-ended.[/QUOTE] Uh, why not? Not everyone wants to follow a strict development pattern. Many people just want to create something nice, so they just begin developing and see where it will go. Prime examples of this are Minecraft and Garry's Mod. If Facepunch were to focus more on getting the game completely stable all the time, there would be less time to spend on implementing cool features and balancing/removing other features. Also, as features can be removed, time spent on optimizing those features would be wasted.

[QUOTE=NitronikALT;46400063]but the game is functional All they are doing right now is improving the systems already in place, whilst adding new ones, and "trivial" content like clothing[/QUOTE] Is it? Right now i'm stuck in a house I built twice this weekend because of server wipes... Before that, I had to worry about people glitching into my base... my point is that there are a slew of bugs... get things more solid first... then move on to the "trivial content". [editline]3rd November 2014[/editline] [QUOTE=Darkwater124;46400072]Uh, why not? Not everyone wants to follow a strict development pattern. Many people just want to create something nice, so they just begin developing and see where it will go. Prime examples of this are Minecraft and Garry's Mod. If Facepunch were to focus more on getting the game completely stable all the time, there would be less time to spend on implementing cool features and balancing/removing other features. Also, as features can be removed, time spent on optimizing those features would be wasted.[/QUOTE] Thus the issue with Alpha and Beta games in general... they will never be a complete game... just a perpetual Work in Progress.

[QUOTE=NitronikALT;46400063]but the game is functional [/QUOTE] Not as a game. Yes, you can log in. But there are not a coherent set of features that make it a fun game experience (yet). Plus combat is not working well, all clothing except 2 items do not even have any armor value set for them. Also, many major bugs that prevent you from playing this as a game. I don't agree with the OP. They have taken on a lot of things, and this has slowed down progress the last few months. Lastly, nothing is wrong with having minor features in the game, made by some staff, while other staff tackle the major issues. You may have some valid points, but we do not know about their development practices and process. For me the main question is: is it a priority to make Rust 2.0 a good game experience right now, and should this be more of a priority? FP has the luxury of not caring about sales and number of players at this point (because they made so much money). But if they don't give current players a good, fun experience, then maybe they are making a mistake. Clearly they are losing a lot of players right now because of the many bugs and state of experimental. And because, for example, combat is quite bad compared to legacy, and bases can be hacked in to, or griefed so easily.

I don't understand. Why isn't what we're doing iterative? Because there's bugs in it? How do we make our software 100% bug free before we start developing properly?

software development != early access game development with software development it's ok for features to be finished by depth (ie you get feature a completely locked down, then go to feature b) gamedev requires you to do features by breadth (get features a-e working, then polish), otherwise you won't be able to fire your gun??

[QUOTE=Prescription;46399961]First, what is Facepunch's desired outcome? Is it to create a functional game that people will enjoy? If so, then why are they spending time adding bucket helmets, boots that look like frogs.. etc.. and not addressing the basic functionality of the game. Software development cannot be open-ended. There has to be a desired date of completion... in this context "completion" does not mean that all development is over... it just means that there is a basic game that is fully functional. There has to be a stable/solid product... that can then be upgraded. Seems facepunch is going for a Ferrari out of the gate. Give people the basic's, and then work on variations of cloths, weapons, tools, after you have refined all of the other major components needed to make the game functional.[/QUOTE] You seem to be completely missing the fact that the people making the models for the boots and helmets and all that are artists not developers. They are not the same people that add features to the game. They are doing art that will need to be done eventually. Art takes a lot of time to get right, but it doesn't take that much to get it in game once it's done, so if the artists are working in parallel you might as well implement their work as it's finished. That also means that if there's issues with how the art is being built you will catch them when they've only got a few models done instead of waiting to implement everything at once and realizing it's all fucked. [editline]3rd November 2014[/editline] [QUOTE=garry;46400126]How do we make our software 100% bug free before we start developing properly?[/QUOTE] Anyone with a real answer to this will be a millionaire hahaha

[QUOTE=garry;46400126]I don't understand. Why isn't what we're doing iterative? Because there's bugs in it? How do we make our software 100% bug free before we start developing properly?[/QUOTE] god hath spoken, lord hear my prayer

[QUOTE=garry;46400126]I don't understand. Why isn't what we're doing iterative? Because there's bugs in it? How do we make our software 100% bug free before we start developing properly?[/QUOTE] I'm glad you responded Garry. You take a step back from pumping new stuff into the game, and spend time analyzing what you have implemented to date. What are the major issues? Are the components where you want them to be...? You guys have turned the corner, and do have the outline of a basic functional game (almost)... so why not refine what you have in place the way you want it.... over the next few weeks... and then implement new features?

[QUOTE=Prescription;46400081]Thus the issue with Alpha and Beta games in general... they will never be a complete game... just a perpetual Work in Progress.[/QUOTE] Define "complete game." Many games these days keep getting new features until their developers abandon the games. Prime examples, again, being Minecraft and Garry's Mod.

[QUOTE=Darkwater124;46400340]Define "complete game." Many games these days keep getting new features until their developers abandon the games. Prime examples, again, being Minecraft and Garry's Mod.[/QUOTE] A complete game is one that a developer would be confident taking the Alpha/Beta label off of.

[QUOTE=Prescription;46399961]There are software development strategies to mitigate what we are seeing with this game. Iterative development is best for a project of this magnitude... Create a solid (but very basic) release. Let people play on it... this is the nature of "Alpha", you let the game community be your testers... You then implement new code on top of your functional baseline, and you test it in the development region (unit and integration testing) to assess any major impacts (like if i spend a week implementing a new lock system... what happens if the server needs to be restarted)...[/QUOTE] [QUOTE=Prescription;46400081]Is it? Right now i'm stuck in a house I built twice this weekend because of server wipes... Before that, I had to worry about people glitching into my base... my point is that there are a slew of bugs... get things more solid first... then move on to the "trivial content".[/QUOTE] I like how in one post you say they should let us test their game for them, and in the very next post you claim they should have these bugs figured out before they release the content to us. I don't get it, did we pay to alpha test their game for them, or did we buy a finished product because I'm pretty certain the game I bought said, "Early development; THERE WILL BE BUGS."

[QUOTE=KmartSqrl;46400167]You seem to be completely missing the fact that the people making the models for the boots and helmets and all that are artists not developers. They are not the same people that add features to the game. They are doing art that will need to be done eventually. Art takes a lot of time to get right, but it doesn't take that much to get it in game once it's done, so if the artists are working in parallel you might as well implement their work as it's finished. That also means that if there's issues with how the art is being built you will catch them when they've only got a few models done instead of waiting to implement everything at once and realizing it's all fucked. [editline]3rd November 2014[/editline] Anyone with a real answer to this will be a millionaire hahaha[/QUOTE] funny thing is, Garry IS a millionaire, isn't he?

[QUOTE=Zipper Bear;46400381]I like how in one post you say they should let us test their game for them, and in the very next post you claim they should have these bugs figured out before they release the content to us. I don't get it, did we pay to alpha test their game for them, or did we buy a finished product because I'm pretty certain the game I bought said, "Early development; THERE WILL BE BUGS."[/QUOTE] What I said was "You then implement new code on top of your functional baseline, and you test it in the development region (unit and integration testing) to assess any major impacts (like if i spend a week implementing a new lock system... what happens if the server needs to be restarted)... " I was not saying the community should test this out... I was saying Developers, within the development region should...

[QUOTE=Prescription;46400405]What I said was "You then implement new code on top of your functional baseline, and you test it in the development region (unit and integration testing) to assess any major impacts (like if i spend a week implementing a new lock system... what happens if the server needs to be restarted)... " I was not saying the community should test this out... I was saying Developers, within the development region should...[/QUOTE] Why would the devs waste time testing their own game when they have an entire horde of alpha testers SITTING AT HOME WAITING TO TEST IT FOR THEM?

Because they have pride in their code? You obviously have no experience with software development... please stop typing in this thread...

[QUOTE=garry;46400126]I don't understand. Why isn't what we're doing iterative? Because there's bugs in it? How do we make our software 100% bug free before we start developing properly?[/QUOTE] Incremental is not iterative, and iterative doesn't imply 100% bug free code. Rust is being developed incrementally, but not iteratively because features aren't being balanced as you go. I'm not convinced early development of a game can be done iteratively, but right before the rewrite, I'd say legacy was being done iteratively because there was a point at which the game was fairly balanced (weapon damage, resource costs, building vs. raiding, etc.), even if wasn't calibrated for a longer session of game play yet.

For the most part I agree with the OP. If I only had a rock, a shack, and a bow but the game played perfectly I'd be happy. Then from there they could add everything else. Look at many of the successful alpha games out there and how their development worked. There was a solid but basically playable foundation for the game. Content was then added to that foundation. Right now it feels like they're trying to put up the ceiling, window, walls, and foundation of a house all at the same time and are constantly tripping over each other in the process. Build the foundation, put up the walls, install the ceiling, then start adding the finishing touches. Frog boots should be the last thing we see in the game.

Rust is one of the most innovative and fun games I have ever played, so I would say they are doing something right. Software development theory doesn't mean shit compared to results, and there are countless examples of well organized development churning out AAA boring crap.

[QUOTE=DavidBowie;46400512]Rust is one of the most innovative and fun games I have ever played, so I would say they are doing something right. Software development theory doesn't mean shit compared to results, and there are countless examples of well organized development churning out AAA boring crap.[/QUOTE] I agree, Rust Legacy is awesome... I'm simply making suggestions for how it gets to that level of fun and beyond, in a calculated and organized fashion.

I wonder what software company op has made anyways albeit rust should be made in the same way as overgrowth (where the devs just optimize, optimize, optimize new and improved features and that's it, before even trying the actual game itself). I suppose that's what OP is suggesting anyways which makes sense.

I quite like the organic approach they have to the creation of the game. I was super skeptical about the game when it was first playable, now I'm sad that I lost my account and would probably buy it if the rust subforum wouldn't make me feel like being in preschool.

I'm really curious as to what software OP has helped developed because it's bound to be a LOT different than making a video game you don't have to worry about art assets and a ton of other things (maps, animations, models, more UI, how the game 'feels') all a video game is software that is interactive but that doesn't mean its even nearly the same thing

[QUOTE=Prescription;46400370]A complete game is one that a developer would be confident taking the Alpha/Beta label off of.[/QUOTE] And what's wrong with a game being labelled alpha/beta?

[QUOTE=Darkwater124;46400663]And what's wrong with a game being labelled alpha/beta?[/QUOTE] The developers would not be accountable for making a complete game... They can pull the plug tomorrow, and that's it... they can leave a half broken/half finished product on the market. I think its unfortunate that more games are going this route, but I understand that's what helps Indy game makers to establish the capitol they need to move forward.

[QUOTE=Prescription;46400701]The developers would not be accountable for making a complete game... They can pull the plug tomorrow, and that's it... they can leave a half broken/half finished product on the market. I think its unfortunate that more games are going this route, but I understand that's what helps Indy game makers to establish the capitol they need to move forward.[/QUOTE] You obviously don't know Facepunch to assume they'd do that. Garry's Mod has been in a complete state for years, yet there's continuous development on it. Garry's Mod has been an open ended game for almost ten years (December!), and look at the figures that game has pulled and look where Facepunch is right now. I'm doing a degree in game development currently, and sure the methodology in the OP you're talking about are professional approaches to software dev. But Facepunch is doing [b]really well[/b] with their own approaches and development methodology. You're thinking that Facepunch are under publisher deadlines and worrying about crunch time. If they don't need to run against stressful but efficient methodology, just straight up don't use it and make the product with the time you need. [url]https://twitter.com/garrynewman/status/436914904948547584[/url] Whatever your argument is trying to stand for, apply what you're saying to Garry's Mod and see the outcome of that.

[QUOTE=Prescription;46399961]Let me preface with a couple things... 1. I work for a software company, and have performed in several roles.... 2. I have played around 1300 hours of Rust so I know a thing or 2 about whats been going on. Here is how it goes... A. Capture the main objective of the project (what is the desired outcome). B. Create a work breakdown structure of the tasks needed to meet the desired outcome. C. Create a sizing of the effort/cost of each line item, in order to form Milestones. D. Track to the milestones, to assess whether or not you are behind on where you wanted to be for the given deadline. Here is where Facepunch is failing: First, what is Facepunch's desired outcome? Is it to create a functional game that people will enjoy? If so, then why are they spending time adding bucket helmets, boots that look like frogs.. etc.. and not addressing the basic functionality of the game. Software development cannot be open-ended. There has to be a desired date of completion... in this context "completion" does not mean that all development is over... it just means that there is a basic game that is fully functional. There has to be a stable/solid product... that can then be upgraded. Seems facepunch is going for a Ferrari out of the gate. Give people the basic's, and then work on variations of cloths, weapons, tools, after you have refined all of the other major components needed to make the game functional. The recipe for Rust 2.0 is to get to a baseline of Rust Legacy, and then go from there. Facepunch may have some high level ideas of the tasks they need to perform, but their priorities are all over the place. They give us a little bit of this, a little of that... The more you introduce, the more bugs are created, the more time you spend addressing said bugs...the less time you spend implementing new things. There are software development strategies to mitigate what we are seeing with this game. Iterative development is best for a project of this magnitude... Create a solid (but very basic) release. Let people play on it... this is the nature of "Alpha", you let the game community be your testers... You then implement new code on top of your functional baseline, and you test it in the development region (unit and integration testing) to assess any major impacts (like if i spend a week implementing a new lock system... what happens if the server needs to be restarted)... Seems Face-punch is using a combo of Agile and waterfall methodology... They are not sure what direction to go, they pick a tangent and start moving on it, and their focus on an actual "baseline" is lost. The issue with this is that you spend time putting in new functionality, then addressing bugs that stem from them...then putting in more new things, while previous bugs exist... now dealing with a new set of bugs on top of old bugs... it becomes a tangled web. The solution here is Iterative Development with explicit goals of that implementation. Slower release cycles to vet out major issues, etc... Again... implement the basic elements to make the game functional. Address bug issues with the code you have released... and then implement variations of what has been implemented.[/QUOTE] I have your answer, which ill give you in relation to my company. I work for a very large commercial jet manufacturer. I have absolutely NO idea how to build any parts of the airplane. You could put me at any point along the manufacturing process and i would royally fuck it up and make it worse, they would have to scrap the entire part and purchase a new one. How ever! what i can do, is i can calibrate every single one of the tools that they use to build the planes. Any form of measurement calibration i can do and figure out, because that is my job and its what i do well. So if you weren't able to grasp what I'm trying to point out here, It's that i don't think Garry himself made the bucket helmet so calm your shit down and realize there are multiple people at work here and they all have different skill sets. You're acting is if facepunch is one person with all the skills and abilities to develop the game by themselves. End of disccusion.

[QUOTE=Silentfood;46400826]You obviously don't know Facepunch to assume they'd do that. Garry's Mod has been in a complete state for years, yet there's continuous development on it. Garry's Mod has been an open ended game for almost ten years (December!), and look at the figures that game has pulled and look where Facepunch is right now. I'm doing a degree in game development currently, and sure the methodology in the OP you're talking about are professional approaches to software dev. But Facepunch is doing [b]really well[/b] with their own approaches and development methodology. You're thinking that Facepunch are under publisher deadlines and worrying about crunch time. If they don't need to run against stressful but efficient methodology, just straight up don't use it and make the product with the time you need. [url]https://twitter.com/garrynewman/status/436914904948547584[/url] Whatever your argument is trying to stand for, apply what you're saying to Garry's Mod and see the outcome of that.[/QUOTE] I'm not saying Facepunch is not successful, or questioning their effort, etc... Here is my main point to all of this: If they take what they have currently implemented, and spend the next couple weeks really working it over, and refining it, knocking out bugs, etc.. they will have a very efficient and functional baseline. That's not to say in the interim, they cannot be doing artwork, LOD's, sound work, etc.. Once they have a clean baseline, they should take a methodical approach to implementing a new component or feature, and spend the time assessing the impacts of integration. If someone thinks that the developers should keep implementing new stuff rapidly, and slowly addressing issues with the current code, that's their opinion. I was just pointing out that it may be good to take a step back from all that and really refine what they have....

I had to Google the term iterative. For the record, Garry's bank account disagrees with the OP.