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

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

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.

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]

Thus the issue with Alpha and Beta games in general… they will never be a complete game… just a perpetual Work in Progress.

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??

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

Just seems like someone learned some pretty words.

god hath spoken, lord hear my prayer

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?

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.

A complete game is one that a developer would be confident taking the Alpha/Beta label off of.

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.”

funny thing is, Garry IS a millionaire, isn’t he?

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…

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…

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.