Update Excitement

[weezl]

I felt like answering that because what you and maybe some others need to know is that this is always how it goes with Gamedevelopment - Updates in the beginning are always more frequent and gamechanging compared to later on. That is not because the Devs - Squad - are getting lazy or dont care about people, but simply how Work-progress applies to the project.

A simple example: You are working on a ball of clay. Every day you add a piece of clay at the size of your thumb. At day one you start with one of those pieces the size of your thumb. At day two you add another clump - your total mass increased by 100%. It doubled in size.

Ten days later, though, you add the eleventh piece of clay to your ball. The piece you add will still have the size of a thumb while your ball contains already ten pieces of clay and is ten times the size - your total mass-increase is only 10%, even though you added the same amount of clay you added back in day one.

To translate that in KSP-terms. Kerbal Space Programm is the ball of clay Squad is working on. Every week, lets say, they add another weeks worth of work to the game, making it bigger and more complex. With every Week that goes by the game requires more work to deliver Updates with the same 'potency'. Harvester published a blogentry about that very topic some time back and mentioned how it actually boggles him self.

So - if you feel different thats fine but I dont think you should waste your good mood on non-existing issues. Sqad didnt stop listening or working on KSP. Stuff just takes more time now and will always do. After all you should enjoy KSP for what it is anyways and not what might or might not come with the next update.

Exactly.. Most of the time the folks I work with refer to it as 'code inertia'. Code over time:

1. Gets bigger.

2. Bigger = more complex.

3. More complex = harder to change.

4. Harder to change = harder to test.

5. Harder to change/test = longer to change/test.

This is true of all softwares I've ever seen, and all software projects. Good design can mitigate some of these effects, but never can it be eliminated. Developers ignore this reality at their peril.

[weezl]

Sigh, why must it always devolve to an oversimplification of one thing I said.

I didn't say what Squad did was a cash grab, nor do I believe that what Squad did was a cash grab. What I that statement meant was that it looks more like a cash grab than is good for the future of the game.

As I've said in other posts, the early release model can work well when the devs communicate with the fanbase. Doing a poor job of communicate with the fan base during the development of an early release gives the impression that the developer is more interested in the fans' money than the fans' feedback even though that may not be true.

And for the record, I understand there is a finite amount of time in the developers day. I'm a graduate student about 6 months from defending my dissertation. Trust me, I get that time is limited. But if they want to use an early access development model, they also have to expect a longer development cycle because they need to communicate with their community if for no other reason than to manage their image. And that genie's out of the bottle. They can choose: Communicate with the community or risk generating bad word-of-mouth about the developer due to lack of communication.

I think Squad actually does care about the fans. But I think it needs to be demonstrated better than it is. The community's goodwill and patience will only get stretched so far.

You and Squad can chalk up anyone being critical of Squad's communication and image as just a bunch of internet malcontents looking for something to complain about and that are impossible to keep happy. Or you could try to see things from someone else's point of view.

Your choice.

PS Great that you're a developer and most developers are nice people. If they're great people, I'd love to see that side of them. But they'd have to take the time show it.

There are minuses to too much communication..

Read please:

http://www.commpro.biz/marketing/toeing-timeline-avoid-marketing-oversaturation/

I appreciate that you don't feel properly serviced by Squad right now.. but you might want to look at it from their perspective too.. that was my original point.

[technicalfool]

This is true of all softwares I've ever seen, and all software projects. Good design can mitigate some of these effects, but never can it be eliminated. Developers ignore this reality at their peril.

Or to put it another way, "entropy sucks".

Personally I bought the game knowing it was in development, knowing that things will break and change en-route to a finished product. Now, I'm a mere graduate of a computer games technology degree, but even that little amount of knowledge means I know that making anything more complex than Flappy Bird is incredibly hard work. I'd very much rather Squad put out small but well-tested releases, than throw out heaps of bug-ridden nastiness that leak memory like a sieve and break machines.

If that means that there is an "elite group" of testers that get the dubious honour of play-testing the development versions before they go to the public, then so be it. Play-testing is possibly the most boring thing you can do with a game, as I can attest to having done some unpaid play-testing myself. Hours and hours of trying every single last thing in the game, then trying it again, then trying it again just to see if you can break it? Yeah, you can have that and enjoy it.

Of course if it's paid play-testing, well it might beat pushing boxes around a warehouse, but only just.

In summation: Keep it coming, Harv. Some of us like what you're doing. And Darklight, keep going with that multiplayer mod, it's coming along nicely!

Edited June 11, 2014 by technicalfool

[MR4Y]

I felt like answering that because what you and maybe some others need to know is that this is always how it goes with Gamedevelopment - Updates in the beginning are always more frequent and gamechanging compared to later on. That is not because the Devs - Squad - are getting lazy or dont care about people, but simply how Work-progress applies to the project.

A simple example: You are working on a ball of clay. Every day you add a piece of clay at the size of your thumb. At day one you start with one of those pieces the size of your thumb. At day two you add another clump - your total mass increased by 100%. It doubled in size.

Ten days later, though, you add the eleventh piece of clay to your ball. The piece you add will still have the size of a thumb while your ball contains already ten pieces of clay and is ten times the size - your total mass-increase is only 10%, even though you added the same amount of clay you added back in day one.

To translate that in KSP-terms. Kerbal Space Programm is the ball of clay Squad is working on. Every week, lets say, they add another weeks worth of work to the game, making it bigger and more complex. With every Week that goes by the game requires more work to deliver Updates with the same 'potency'. Harvester published a blogentry about that very topic some time back and mentioned how it actually boggles him self.

So - if you feel different thats fine but I dont think you should waste your good mood on non-existing issues. Sqad didnt stop listening or working on KSP. Stuff just takes more time now and will always do. After all you should enjoy KSP for what it is anyways and not what might or might not come with the next update.

Software is not a physical object. You could write a big amount of code that does a small thing or a small amount of code that does a big thing. This example doesn't apply at all.

[Progressm]

When I bought this game, I bought it "as-is". The game is in development with no obligation on Squad's part to do anything further.

This. The whiny folks tend to feel a bit more entitled than they should. I'm more than happy with my purchase, even without a single further update...and what's 6 months between friends?

Take a break from KSP if you need to. Buy & do up a house and sell it on, go out and play, get a promotion & work hard to learn the new job, something. Then come back and enjoy all the new updates they have released during your absence.

[SciMan]

I've got weekly updates from Space Engineers to hold me over between the huge OMG jaw-dropping updates that KSP seems to do.

So I trade them off, get bored with one, switch to the other, and vice versa.

I have a few other games I alternate between, but that's the general idea. If you want to stick to in-development indie games only, try to choose ones that update on different schedules. That way you can usually find something new to do.

Of course, having things in RL to distract you also works, where applicable.

[Sandworm]

Whether or not someone is happy with a purchase is irrelevant to their criticism of Squad's communication with the community. I like KSP. I enjoy playing it and am happy with the purchase. That is totally separate from my open criticism of Squad's behavior. I would never go away or "take a break from KSP" because of Squad's behavior. I would, and do, only when I bet bored with the game. A game and its developer are different entities.

That said, I am very worried about Squad's actions in recent months. I see many red flags in relation to updates. The last launch was a public relations shambles. The media team was totally disconnected from Squad's plans, initially claiming that the update was live long before it was ready. Let us all hope they have learned from that fiasco. More worrisome is that this latest minor/"soon" update has devolved into yet another 3+ months of nothingness. The community is left grasping at tiny comments about theoretical additions. Where are the screenshots of the new contracts system? Where is the discussion of how modders will be able to write missions? I can only pray that the contracts system won't be as restrictive on mission authors as the tech tree is on parts creators. If they started the project 2+ months ago, they should have the api for missions well in hand.

But it's the emptiness of Squad's "we're working on it" weekly statements that are the most annoying. They say nothing about the update, giving us more information about the state of the associated animation than the actual game. They give the impression that only one or two people are working on software while the rest of the team works one ancillary projects. Given the delays, might that be accurate?

[Guest]

Exactly.. Most of the time the folks I work with refer to it as 'code inertia'. Code over time:

1. Gets bigger.

2. Bigger = more complex.

3. More complex = harder to change.

4. Harder to change = harder to test.

5. Harder to change/test = longer to change/test.

This is true of all softwares I've ever seen, and all software projects. Good design can mitigate some of these effects, but never can it be eliminated. Developers ignore this reality at their peril.

Any code with good design standards, proper refactoring and using an OO approach will barely suffer from that at all. In fact, i feel quite the opposite; when i go to a large, bulky peice of code i feel quite proud i've designed it in such a way it flows perfectly and is easy to change.

[MR4Y]

But it's the emptiness of Squad's "we're working on it" weekly statements that are the most annoying. They say nothing about the update, giving us more information about the state of the associated animation than the actual game. They give the impression that only one or two people are working on software while the rest of the team works one ancillary projects. Given the delays, might that be accurate?

That would also explain the developers that left the team and devs that are 'hired but away from the project'.

[EvilotionCR2]

ugh i cant find it but someone posted a graph showing that update size has been rising and rising. they are bigger everytime

That's definetly not true.

If you consider contracts + money + reputation one new feature, it's a pretty significant one that fleshes out career mode pretty thoroughly.

Well, now I'm confused. The implementation of the system that will bring career mode, "the point of the game", close to completion does not seem like a significant enough update?

Edit for below: My sarcasm meter didn't twitch, did I read it wrong?

No, it is pretty significant, but the problem is that we used to get much more.

Edited June 11, 2014 by EvilotionCR2

[EvilotionCR2]

check the post above this please, it has been put together.

Edited June 11, 2014 by EvilotionCR2
check above

[Red Iron Crown]

That's to be expected. As the software gets more complex, it takes more effort and time to add features and properly test and debug them.

I'd be inclined to wait and see the actual update and the changes it brings before complaining that it's not enough, but if you want a head start by all means fill your boots.

[wasmic]

That's definetly not true.

No, it is pretty significant, but the problem is that we used to get much more.

Depends on how you look at it. Yes, in the beginning, there was a lot of new parts, and the game was so early in development that new parts frequently introduced new mechanics. However, if you think about it, we do get quite a lot with each update. 0.21: Craters on Mun, other stuff I don't remember. 0.22: science (biomes, experiments, other cool stuff). 0.23: science revisited, and tweakables (the tweakables are kinda under-developed, though, I'd hoped for something like Modular Fuel Tanks). 0.23.5: a new asteroid spawning system, the Klaw, a launch escape system and new, bigger parts. 0.24: Contracts and budgets. People have been screaming at SQUAD for a long time, wanting them to add contracts and budgets, and now it's finally coming. And don't forget that Multiplayer is also in the works.

[Drethon]

Any code with good design standards, proper refactoring and using an OO approach will barely suffer from that at all. In fact, i feel quite the opposite; when i go to a large, bulky peice of code i feel quite proud i've designed it in such a way it flows perfectly and is easy to change.

Works well when there is minimal interaction in the code base but the more interfaces there are, the harder it is to keep everything consistent. Worse when there are more people working on the project the integration between individuals and groups gets more complex with the larger project. Its hard for a good process to compensate for humans.

[EvilotionCR2]

Oh yes. Sorry everybody. I just realized how wrong I was. No sarcasm.

[cantab]

Works well when there is minimal interaction in the code base but the more interfaces there are, the harder it is to keep everything consistent. Worse when there are more people working on the project the integration between individuals and groups gets more complex with the larger project. Its hard for a good process to compensate for humans.

Also, I suspect, works better when the developers don't have a load of their previous customers saying "I want a big update and I want it now".

[r4pt0r]

heres one.

note the massive optimization they did for .20 people complained and called that the "chair update" cuz all they got was the command seat. but if you read this http://wiki.kerbalspaceprogram.com/wiki/Version_history#v0.20 you see its so much more, arguably the most important update yet with the changes to loading and the backend

Edited June 11, 2014 by r4pt0r

[RidingTheFlow]

Size in mb is hardly quantitative measurement of work effort. Its pretty easy to make big size update - just throw bunch of high-res (not even necessary good quality) textures in.

[r4pt0r]

no, that isnt update file size, its total game file size. .20 trimmed alot of usless code out, thats a good bit of work. .23 ran smoother than ever due to some other optimizations they did.

[RidingTheFlow]

Even if its game size, its does not really matter... Size increase could mean good thing (more content) or bad thing (more unnecessary things, bloat). And size decrease could mean both good thing (optimization) or bad thing (less content/cuts). So drawing graphs based on size don't really correlate with how "better" or "worse" game became.

Edited June 11, 2014 by RidingTheFlow

[weezl]

Any code with good design standards, proper refactoring and using an OO approach will barely suffer from that at all. In fact, i feel quite the opposite; when i go to a large, bulky peice of code i feel quite proud i've designed it in such a way it flows perfectly and is easy to change.

Design assumptions aren't generally affected by expression languages. And complexity increases as the size of the program increases. Its a Systems Analysis point of view. OO helps you minimize these effects by providing reasonable mechanisms for isolating modules.. but you can't ever change the affect of design assumptions on your future code and your between module dataflow issues in general. This is why all code bases have inertia. Its totally good to have the goal of minimizing it.. I've preached that for 20 years now. But so far I've not seen a large system that doesn't have that issue. And I've work on large systems pretty much exclusively since 1986 or so.. and by large systems I mean code under management of 3/4 million lines of code and UP.

[rkman]

How do we know they're actually doing work, and not selling a game based on a promise of updates?

Is that a serious question? How do we know: there have been almost 50 updates already, and the difference between the first and the most recent update is huge.

Maybe you have not been playing KSP for that long, but at least you could have not assumed that there have been no or very few updates in the past.