HEY!!!!

Could someone on IRC please ask the devs to reboot. :P

upper case, I will not debate the fact that this weekly update schedule puts too much strain on the developers. I even concur that there should be less updates. Perhaps once a month would be less of a hassle, but I'm no expert.

However, I do not think that players should be given the choice to play with a beta version, so to speak, on the production server. We had mixtures of versions before, and this should not happen again, regardless of what has happened in the past.

Another example would be the infinite money bug. You think credits today have no value? Hah! Back then, we would print our own! ;)

i'm inclined to agree with that tosh. but the decision to allow mixed version or not on the production server, i suppose, ultimately fall in the hands of the developers.

I'm not sure that the semi-weekly updates are that hard on the devs. It's often beneficial to use the scientific method of making small changes, observing the results, adjusting, and making another small change.

I think that what upper case is getting at is that if the focus becomes more on something like this:

SCENARIO 1:
Incarnate: OK team, we've got 3 hours to think of something to release this week or the playerbase will be all over us again.
a1k0n: I could crash the server, that'll buy us more time.
Raybndo: No, no, that's no good. How about we make chat in garish colors!
Momerath: I'll get to work on that right away!
All: Brilliant!

instead of:

SCENARIO 2:
Incarnate: dear Playerbase, we're working on some kickass Kourier code that will allow player-controllable capships within the month and have sidelined all other development until that is complete.
Playerbase: What? We want colored chat! Whaaaaaaah!

then the development of the REAL content takes longer.

I far prefer Scenario 2, and communication of such. If focusing on putting something/anything out every week detracts from long-term goals, then that's no good. It's nice to see a little surprise every week and an incremental upgrade, but I'm waiting for "The Big One™" when we have something REALLY awesome to sink our teeth into.

Being a dev for a small company myself, i do understand the choice of having small regular release, most of the time these are bug correction, exploit correction and small improvement. This is the kind of development that goes in the mainline. Other thing like capital ship are big stuff and these don't goes in mainline for the reason that these change will break everything in no time. This kind of management is much more easier to track and avoid branchs of the software get too far apart. It's not the best development model but it's a pretty successful one.

You can complain about little bug. But hey, not everyone can be perfect. Also i consider that the dev do correct the bug pretty fast. On some other software, you have to wait for almost a month before you can wish for a correction of the bugs. And sometime, they simply ignore the bugs and classify it as trivial.

Again, I do think the dev does a great job pushing little fix and little improvement to keep an active improvement and avoiding stall bug to stay too long.

Just be responsible as a player and when you see a bug, just don't complain and make a bug report, It'll get fixed in time.

Jeez that's kinda harsh.

I think Incarnate has made it abundantly clear that they're chuggging away on the big stuff behind the scenes. They drop in bits of foundation as they become ready, and then Incarnate adds some of his famous "low hanging fruit".

I think there would be more show-stopping bugs if they tried to drop in the big stuff all at once. As it is now they have smaller chunks of code to inspect if something goes awry right after a release. That makes for much faster bug ID and repair.

Go look at War Rock for an example of a half-paid / half free, MMO that recently went pay-to-play. They have a much bigger development team, lots more money, have done this before in other markets, and are rife with hacks, glitches, server issues, a-holes, bugs, and have nowhere near the relationship with players. I like Guild's way of doing things.

what's harsh? i'm trying to give them more time and reduce the stress with less "when's the next update? update tonight? it's pink!!".

i'm not questioning their abilities, but their self-imposed schedule, while shielding those who dont want (and presumably noobs) from the obvious show-stoppers and multiple update.

bonus: less bandwidth for the update server.

uc, I was actually saying that Leebs was a bit harsh - sorry for being unclear.

Allowing two release versions on the same server would very likely create more issues. Creating workarounds to allow both versions to co-exist would be a waste of development time (IMO). It's well known that some bugs don't arise until they hit production use. Good companies respond and patch right away.

Having a parallel client release is something we've considered in the past, but while it might have caught a few recent problems (like the colored asteroids), it would have been a very time consuming hassle for us to work with. As people have pointed out, client-server compatibility is a big issue. The protocol "version number" is not just an arbitrary thing, we often increment it because we've actually changed the protocol in some way. Item stacking, which resulted in a bunch of short-term problems, is a good example. There's no way we could have released a "beta" client that worked concurrently with the old version. Server changes were needed to make stacking possible. It's theoretically possible for us to engineer the entire game to always be backwards compatible with all changes.. but that's a nightmare to maintain. Things start to look like Windows, with win16 and DOS code from the 80s still floating around in a 2007 OS. And our game arguably changes a lot more, and faster, and more fundamentally than Windows.

Our options are either A) have a totally different server on which we test things (called.. the test server, which doesn't have enough testers to really help us much), or B) test stuff as much as we can on our own, and release it into the wild, babysitting it for several hours to make sure we don't need to fix anything.

But, at the end of the day, what upper case is describing here would really, at BEST, only help with a small subset of problems. Client bugs have really not been our biggest issue lately. Much bigger is say, the server effectively going down (like it did this morning, as people noted). The trouble with development is when you know a bug is occurring, but can't reproduce it on your own or with any sort of testing suite you develop, your only option is to put more debugging information into the system and *let* it crash, and hope you can figure it out then. Having a beta client wouldn't have let you log in this morning. It would have helped with the colored asteroids, but that's about the only recent problem it might have mitigated.. everything else hinged on both server and client side changes, so either the old client would not have worked, or both would have had to be updated (with.. different amounts of new stuff? at that point, how do you even decide what's "beta" anymore?).

We're doing our best to keep the game as solid as possible, and get these stupid server-side problems sorted out. We do test the client updates before we release them, but unfortunately.. sometimes stuff happens. I don't want to expose users (newbies or anyone else) to our problems anymore than anyone else, but I have observed the following:

1) The longer we go without releasing, the more of a bug-explosion we have when we finally DO release. So much code has been so torn apart, and untested under production conditions, that a gazillion unforseen problems crop up.. often with some of the fundamental work that underpins what we've been trying to do (example: DELIVERATOR, 2-3 months of development offline, and when it was released, everything exploded so badly the whole thing had to be replaced. Another example: the new client UI, nearly 6 months offline, was similarly problematic when released, although faster to fix).

2) The longer we go without releasing, even if I post regular news updates and other informative things about what's going on, our userbase still starts to get antsy. Some people get more embittered about existing bugs, because they think they'll never be fixed (even if we fixed them a month ago, but haven't released that code yet), others just think the game isn't going anywhere because they don't see any changes. Long periods of offline development have *always* been marked by unhappiness in our community. More angst-filled threads that need to be chilled out, and so on. I know a certain amount of this would be mitigated by the exposure of the Trac system, so people could at least see that various bugs have tickets attached to them (and I am *still* trying to make this a reality).. but I maintain that some non-trivial percentage of our population will be unhappy without some regularly *visible* form of change, no matter how small.

3) It's better for us, as developers, to release regularly. Mostly goes back to #1, as it makes sure our code is tested in the real world. But aside from that, it keeps us from going to far off into developmental la-la land. One of the things that makes us different from most game developers (I think) is the connection we maintain with our community, and I think frequent releases are an important part of that. Without that, the period of feedback becomes much longer, and we start working in a vacuum. That isn't good for us, as game developers, it's much better for us to be continually in touch with you guys as possible, and responding to issues. It keeps us grounded in reality, keeps us focused on fixing and improving the areas that are actually important, instead of going off on our own tangents of what Would Totally Be Neat.

Now, given the above observations, I'm not saying that there isn't anything we can do to improve our release cycle. We're actually trying to improve that, and have been for the last couple of months. Making sure we have fixed server testbeds, which duplicate production, on which to try new code.. and so on. Even upper case's suggestion is a good one, and one we've considered and talked about for many years. But it isn't really that useful right now. It *would* be useful if the game were stabilized to a point where the client didn't fluctuate all that often, and most of the new "content" was server-side.. this is the reality we're trying to create. But, at the moment, there is too much in flux, and too much that's *both* client-and-server.

On a not-bug-related note, having an "optional" client has always been something I wanted, to allow people to get say.. "high resolution texture packs" or some such (an extra 100MB download, that wouldn't be forced on everyone), or even a client compiled with optimizations for modern processors. Say, an "Optional Clients" button on the updater, with buttons for a "SSE3 client (P4/A64)" or some such. But, at present, this would be an updating nightmare for us, since we would have to maintain all of these along with our existing four ports.. so it really isn't worthwhile. But, it's something else that I think would be pretty cool, and could happen using the same mechanism, if our basic client/server protocol code was not changing very frequently.

you mentioned ticket tracking would be a problem?
what about showing the development process on the website?
so a ticket "done" could be expected with the next patch...
this way it wouldn't be so drastic if you guys decide allright for the next patch we take a few more days and bring it on thursday and then another fixing patch on sunday so 4 more days to develop...

i mean, it would be a bit more up to the devs and the community would still see the progress.

"I know a certain amount of this would be mitigated by the exposure of the Trac system, so people could at least see that various bugs have tickets attached to them (and I am *still* trying to make this a reality).."

I think you misunderstood, Shaded. The Trac system is an existing project management program that will allow players to see the status of development and on tickets - much as you described. Guild has already begun using it, but it needs to be better tweaked and populated before its ready to be seen.

http://trac.edgewall.org/

well. there's not much to add after inc's reply. i think this was constructive to some degree.

we've learned that devs have and are still considering longer interims between releases in order to provide them more time for some development but at the same time that they, themselves, consider the current cycles as not too bothersome. thus, the devs are not feeling (overwhelmingly) pressured to release on fridays. though, they feel there might come a time when this might be needed.

on the other hand, we've also confirmed that some of the user base wouldn't mind longer interims if it meant more groundbreaking releases.

what we knew already is that some people will whine either way and require their weekly dose of insulin to survive.

edit:
thanks for your reply incarnate.

on the third hand, we've re-established that upper case's value as an individual. we agree, this was very constructive.

I don't think I was harsh at all! I just don't want the devs to feel like they've GOT to release something every week or else we'll all whine and moan some more. I'd much rather see steady progress towards big goals than see the devs try to make something happen every week.

OK, perhaps my example of garish chat colors was harsh. And my portrayal of a1k0n as some kind of server-crashing techie was harsh. OK and my portrayal of the subscriber base as being impossible to please was a little harsh. Fine. ;) - (But, seriously, chat looks crazy to me now. Maybe I'm just old and crotchety and looking for things to complain about.)

actually leebs chat looks great now, your problem is you arent quite old and crochety enough to remember the days when chat originally came in 3 colors =D. the single color chat looked dull and uninspired to me.

wandering back ontopic, ty for the post incarnate and IMO having a beta client and/or longer release cycles is counterproductive. that just seems like more stuff for the devs to do that takes away from actual development.

as always, genka, you dont make sense. try to finish your phrases (and for crying out loud, rotate that picture of your red-eyed self on the sofa with the pirate toy gun...) >p

Thanks, Incarnate, for your time afforded to writing your post

uc, I personally didn't learn anything new and Incarnate mostly confirmed my post :)

I'd say we've learned that you are whiny ninny with lame RP who steals dev's time by forcing them to write long responses to your complaints, but that is also not new anyway :)

What we really learned is that pink roids are cool and should stay in game

Feature request:
"pink color" (charges 8)
for
"color cannon"
Damage 3
Velocity 60
Energy 5/blast
Delay 2s
Mass 50kg
Port S
Level -/-/-/-/3
Targeting 10° frontal arc
Special: fires colorbubbles*

which may blind an enemy for about 2 seconds and give ships a temporary new color also used to spray i <3 'name' on roids.

let's paint roids

let's paint roids

YES! It deserves another thread in suggestions!