Code and fix

Dear facepunch,

I love this game, but…

"This code re-writing is kind of like a virus. The more you change, the more you need to change. "

I’m kind of disappointed in the perceivable code and fix approach the dev team is appearing to have taken.

Yes, I paid my twenty dollars, and I know the devs can quit tomorrow if they feel like it. That doesn’t bother me. I know that this is an alpha state project. I got my twenty worth already and could easily enjoy the game more by firing it up in the current state. but…

Eh, Gary and bros this isn’t a mod. I hope that I’ll see it release completed, whatever it turns out to be, and that i’m wrong about how you are building it…but for fucks sake if i’m right, show some humility. Plan some requirements, make some models of the objects, organize the code, and so on, generally get your shit together. Hire some fuckers if you got to, that doesn’t mean you can’t make it your game.

Its a wonderful idea for a game you have here, but you’re taking a piss on it by using a code and fix approach. That may have worked for pong, space invaders, and the NES to n64 generation, but you’re building a much more complex machine here, on top of someone else’s engine. So you have to build it right or it may fall apart or become a nightmare to run and maintain.

Always and forever,
-LaOwlLol

Seems you think you know what you are talking about, why don’t you apply for a position and code it

It’s just my ranty opinion, not a fact I claim to know by any means.

If they hired me, they’d probably be the developers I assume they are. Developers who don’t know what they are doing.

I know only enough to know its not just about coding it.

This says hi.

Well, hello!

It is not “code and fix”, it is rewriting a prototype to something that can support further development.

From what they have said, they are currently in the middle of getting shit together. As far as requirements go, they have ideas but they have also talked about an iterative process where ideas will be tried and some might be discarded. In a game where the freedom and choices of the players defines it as much as the code, it is not so easy to just define everything, then write it. In development like this the alpha stage and feedback is a big part of how requirements solidify.

Furthermore, a proper requirements stage (if that was the best way) could mean tools down for weeks or months.

Which is exactly why they are currently rewriting and refactoring the code. You tell them they need some “humility”, then you explain to the developers who wrote the game basic truisms about software development. Do you really think that they don’t know they need to “build it right”? They are literally ignoring the loud voices crying for immediate updates so they can get the foundation correct.

This is a shit thread. Congrats on the superiority complex OP, glad to know someone is keeping those darn devs in check with legitimate claims and sassy wit. Bye!

:rolleyes:

I THINK you are giving them too much credit.

Or they are struggling to make progress because every new addition requires changes to the existing code, and takes more effort and time as the code base grows. Thats what I heard from the first line of the latest update. But hell, I admitted from the start I could be wrong.

Criticism is bad.

The fanboy/fangirl rebuttal is a great way to invalidate your side of an argument or opinion.

Also, it’s Garry, with two R’s. It’s not hard.

Which is why you rewrite and/or refactor the code. According to what has been written they are starting with a messy prototype that contains the problems you have described and are fixing those so they can move ahead.

I don’t think enough non-programmers understand how complicated and time consuming it is to rewrite large parts of a game.

This too. Rust was more of a Unity test thing for garry, and he never expected to blow up like it did.

^^ This.

I’ve started working with UDK and coding in UScript… I was so out of my depth at first and i’ve been doing it for 3 months now and there is still things i cannot comprehend. It takes paragraphs of code to get camera views set up… Then you have to try and make everything efficient… Then replication/simulation for multi-player games… Makes me feel ill. Good luck to them.

+1

Its so easy to have a change in the code that effects more than expected.

Take for example the FOV slider that will be coming out soon. The FOV was written in a way where it would be static. and now it needs to be dynamic… well, you now have to search the code for every reference to the FOV and make it dynamic.

Putting together a prototype a lot of programmers will introduce hacks to solve certain problem (solving the symptom not the problem) and these must be removed and fixed properly later on.

Here are some informative (and somewhat entertaining) videos as to the problem at hand:

Think of it like this:

You build a car. It works pretty well, not great, but it runs and drives around. But that’s all you need it to do so you’re pretty happy with it. You start to realize “hey, I could have done this part a lot better,” so you replace a few things like the mirrors, the door handles, and the shift knob. Those are easy things to change.

Well, the timing belt wears out because it’s not heavy enough for your application. Ok, so you’ll go to a chain- oh, crap, you need to change the whole pulley system. That’s gonna be a few days of fabbing and wrenching, for sure.

So you got the belt changed out for a chain and now you decide you want more power and you’re going to put in a turbo charger. You fiddle with the intake and put a pull-through turbo system in place because it’s easier, you don’t see yourself needing that much more power, and it doesn’t require that you rebuild the whole intake.

You’re happy for a few months, but then you realize you need even more power, and you’re going to need an intercooler on your turbo to really do it right. Well, CRAP, now you scrap your whole intake design and rebuild it as a blow-through with an intercooler. There goes a week or two.

Now it’s a monster, it goes like hell, and you’re totally happy forever, except… gee, if it had a six speed transmission instead of a five you could get better take-offs and put in a taller cruising gear… Ok, fine. So you tear out the shifter, the cables, the transmission, you get another one to mount to the engine, you have to tweak the mounting brackets, maybe weld some stuff, grind things down…

Ok, so days (or weeks, if you had a hard time finding / making parts) later, it’s all done. What more could you want? hmm… well, a rollcage would be nice, come to think of it. Ohhhh, but then you’d need to rebuild the interior and probably replace the suspension to account for the extra weight…

And programming is the exact same way.

You are describing a code and fix job, where the project was not planned out before jumping into and coding it up. Yes, this is somewhat needed for a prototype, and i’m glad they made such a good ‘high fidelity’ playable prototype.

““Code and fix” development is not so much a deliberate strategy as an artifact of naïveté and schedule pressure on software developers. Without much of a design in the way, programmers immediately begin producing code.” -from wikipedia

This is a programmer mentality.

Software engineers, (and the engineers who design automobiles) plan each feature of the product (sometime in repeated iterative stages) before starting to code. The purpose of this planning is to limit the number of refactors needed, and make the time to market and budget predicable.

OP has no idea how a development process works.

Not really. The car was designed to meet the requirements designated at the time, just like the Rust engine, but the requirements changed. Maybe a race in a new division popped up and that’s why you needed more power; you didn’t ever think you’d need it, but now you do. At the time of initial completion, however, it was done, and you just had to put the finishing polish on it.

You are making the mistake of thinking everything is foreseeable. Just like with a car, there are just some things you can’t know until you drive it for a while. Your suspension is designed on paper to give “optimum shock protection” but it handles like crap when you drive it. Your gas cap rusts into the fill spout after a year because water collects under the hatch due to the curves of the body. Your wiring shorts out because you routed it under a spot where water from the condenser ran down (a car company just had this problem not too long ago).

These are things you can’t see about until you test things and see them happen. Unless, maybe, you spent years in the planning stages you could find all these problems before you got it off the drawing board, but that’s hardly a good plan, either.

And it’s not just problems you don’t see, it’s enhancements. Sometimes you don’t get a great idea until you play with the prototype long enough to think “you know, if you could do this, too, that’d be really awesome.”

You might be missing my point. Yes, requirements change and enhancements are nice to add at early stages of development (which the game is indeed still in).

I agree, refactors are appropriate in some cases. The idea is to have a well designed and organized code base which can be extended without a refactor for each addition. Major additions and changes are worthy of a refactor, but if every new addition or enhancement requires a existing code to change…they call that code and fix.

Again, I have no idea what the team is doing, or what the designs or code for this game look like. Its just that:

"This code re-writing is kind of like a virus. The more you change, the more you need to change. You get into the situation where it’s quicker and easier to replace existing code than integrate it with the new system. "

screams of a code and fix approach.

As someone who is excited about this game, who is excited that the devs are creating the game they (and I) want to play and not some user centered mass appeal crap, and who hopes the developers complete their vision, its disappointing to hear they maybe doing a code and fix job.

To a certain extent you are right, but again I know this:

Code and fix. This approach is also known as “hacking”, “hack and slash”, or “no-process at all”. This approach to development is chaotic and often unplanned, or when it is planned the plan is quickly abandoned. Estimates and schedules, when made at all, are rarely met in practice.

And then you spend the rest of the post talking shit about the devs as if you do know.

And this is why I say you are demonstrating the Dunning-Kruger Effect.

You know enough to think you know more than you actually do. You are confusing prototyping and rapid iteration for cowboy coding, and it’s really getting stupid, because you’re in effect repeatedly accusing garry of being incompetent without having the guts to say it outright in this thread.

It’s really getting repetitive and boring. Please stop. garry has ten years of game development experience, and Helk and the rest of the team aren’t novices either.

From Garry himself:

Source