next »

[J-Snake]

The first commercial one should be finished this year, it mainly depends on the artists when it is complete. I won't release it until I am satisfied with the overall look.

[st33d]

Well. Not to be insulting, but your argument about bugs is a bit academic regarding released games isn't it?

I've tested stuff inside out and it's usually just one playtester out of 100,000 that will spot the gamebreaker that made it through. The counter argument people are making to you is that no one's perfect, you don't want to go into a release believing that nothing will go wrong.

[ferreiradaselva]

You guysJ-Snake, you are treating bug as only something that the player can detect. Memory leaks are almost undetectable for the user...

You store something in the memory and forget to release it. That object will be acumulated in memory little by little. The problem will only appear when the memory is full, and the player will not understand what is the problem.

Anyway, this discussion is no longer part of the topic.

[st33d]

Forum surgery performed. Carry on bickering please.

[bateleur]

During a healthy development process bugs come and go but they don't accumulate.

Known bugs don't accumulate, but undiscovered bugs almost certainly do.

* Is it possible to write code correctly every time? No.
* Is there some reason to suppose that the errors which result will be obvious? No.
* Is there some reason to suppose your test procedures will catch all bugs? No.

Even if your process is extremely meitculous and near infallible to the point of inadvisability (that is, you're wasting time and resources being too careful) you will still miss a lot of bugs because many are literally asymptomatic until some later modification makes them relevant.

Example: One of your classes fails to remove an item from a hashtable during deinit. This has no effect at the time at which the error is made, because instances of this class are only ever deinitialised when the class containing the hashtable itself is thrown away. Later an extension to the program means that the hashtable may live for hours with objects being continously created and destroyed. Even if there are zero bugs in the new code, the faulty deinit now becomes a bug that threatens game stability but will still only be found if you run a 40+ hour test or get extremely lucky.

[J-Snake]

If every component is correctly designed on its own. That means if you know exactly its purpose and its limits then you are on the right way. Sure, no one is perfect, but it doesn't imply all software has bugs when it is in completion-stage. Imagine you work with the attitude "sorry, code-bugs just happen" at NASA.

[J-Snake]

bugs don't accumulate, but undiscovered bugs almost certainly do.

For example I heard that they had over 20000 bugs in Crysis2. Do you think they were initially undiscovered? I cannot imagine that. My only explanation is that the coders have an incompetent relationship to their own code and the underlying tech it is build on, which means they don't exactly grasp what they are doing and don't exactly understand the limits of the underlying engine-routines, or/and they are in a heavy rush-mode to complete the game as fast as possible. But there is something rotten in their process for sure.

Undiscovered bugs won't accumulate to such quantities and therefore fixed quickly when noticed.

[J-Snake]

You store something in the memory and forget to release it. That object will be acumulated in memory little by little. The problem will only appear when the memory is full, and the player will not understand what is the problem.

It is seen in a lot of games but I think you can build a working model which ensures that every allocation has a deallocation. That stuff would never happen to me since I am going all the code through twice to explicitely check that property for every single possible instance.

[ThemsAllTook]

Bugs do happen at NASA, and they end up destroying very expensive hardware. In practical terms, no amount of engineering can account for every bug in a nontrivial piece of software, and even ones you think are trivial can hide a surprising number of bugs for many years. I'm not sure if I can find it again, but I read an article a while ago about a code analysis tool someone wrote that was run against a ~100-line UNIX program that's been around and widely used for decades, and found something like 5 serious bugs in it that were previously unknown.

With every post I've read, J-Snake's opinion on pretty much everything seems to be the exact opposite of mine. It's kinda weird. I've found a negative version of myself.

[J-Snake]

I don't say Nasa is bug-free. But it doesn't imply complex software has to be buggy. May be I have a special relationship to my code, cannot speak for others.

With every post I've read, J-Snake's opinion on pretty much everything seems to be the exact opposite of mine.

That is interesting, can you name an example for instance?

[d]

I'm not sure if I can find it again, but I read an article a while ago about a code analysis tool someone wrote that was run against a ~100-line UNIX program that's been around and widely used for decades, and found something like 5 serious bugs in it that were previously unknown.

This reminded me of a similar case concerning a ubiquitous data structure, but I can't remember what it is (maybe b-trees?). It was first conceptualized long before digital computing existed, there have been thousands (if not millions) of implementations since, but the first bug-free (rigorously proven) implementation was only created sometime in the 1990s.

More amusingly, someone ran AddressSanitizer against Safari for the first time and this was the result.

[TobiasW]

I don't say Nasa is bug-free. But it doesn't imply complex software has to be buggy. May be I have a special relationship to my code, cannot speak for others.

Maybe your code lacks a certain complexity, which is present in the AAA titles whose buggyness you have so much scorn for?

After reading your posts, I can't help to think that you're either a genius or a bit inexperienced regarding bigger projects and releases that are widely used/played. I consider myself a pretty good programmer, but I would never dare to say that I can guarantee bugfreeness...

[ferreiradaselva]

I don't say Nasa is bug-free. But it doesn't imply complex software has to be buggy. May be I have a special relationship to my code, cannot speak for others.

Maybe your code lacks a certain complexity, which is present in the AAA titles whose buggyness you have so much scorn for?

After reading your posts, I can't help to think that you're either a genius or a bit inexperienced regarding bigger projects and releases that are widely used/played. I consider myself a pretty good programmer, but I would never dare to say that I can guarantee bugfreeness...

Well, I consider myself a good programmer too(10 years of experience), but even the most experient programmer will make a mistake:

http://www.itworld.com/software/291341/john-carmack-still-learning-about-programming


EDIT: talking about complexity, which was the longest code you've written? How many lines?

[motorherp]

Indeed.  I've been a professional programmer for near 10 years now and if anything I write appears to work perfectly first time I'm usualy very suspicious of it 

[ThemsAllTook]

With every post I've read, J-Snake's opinion on pretty much everything seems to be the exact opposite of mine.

That is interesting, can you name an example for instance?

Hmm, not as easy to find examples as I thought... I just remember butting heads with you over timestep intervals, full screen modes, vsync, and a few other things I think. Hasn't been so much recently, but it looks like most of your posts were in forums I wasn't reading actively. This thread would be another example, of course. I'm not attacking you as a person or anything, it just often seems to me like you live in opposite world.

Let's try this out: What do you think of unit tests?

[BorisTheBrave]

J-Snake, you may be misunderstanding what a bug is. Bug testers don't just pick up stuff like "game crashes if you type a 'q'", but also:

"game failed to uninstall correctly on a users 3 year old laptop, running Arch Linux"
"player was able to access boss room without speaking to plot important NPC through a series of well executed jumps"
"game has no colour blind options" which spawns at least 10 new bugs about places the color blind settings are not appropriate, or have been missed out
"asset production pipeline is running slowly today"
"resource usage during the fancy-fx scene is unacceptable for lower end machines"
"sound menu is missing localization for Portuguese"

In other words, for any moderately large project, the bug tracker covers a multitude of problems, originating from many departments other than development, and often not even discoverable until late stages of development or after release.

[J-Snake]

I know and perfectly understand people roll eyes when I say I don't even need a debugger.
But of course I see the point in it and it is vital for the development-process.

I used to work at university at a time and a part of my job was to help the computer-science students out on a semester project, a bigger object-oriented project. They had to deal with ugly bugs they could not find and often even several software-engineers were around the machine to help find them since one was not sufficient. I have found every bug they showed me in the same sitting without even throwing on the debugger. I don't think I am a genious. I have just conditioned myself into having a hardcore moral when it comes to technical stuff. I take time to understand the code in every detail, I know the exact amount of frames a screen-transition takes, I know the order of all interactions going on, I know exactly the properties of floating-point representation and how inconsistencies can affect the outcome and so on. That is why I am used to shape a complex picture how tricky bugs can arise. I feel more home working alone but also when working in team I keep my moral by principle, everything has to be perfect. For example I was assigned to a team and our task was to write a program that efficiently computes the scattering of radio-waves in complex scenaros like a city. First we made a complete and clean specification list so that it was clear how the program has to communicate with its parts. My job was to design and implement the main algorithm. I remember I haven't used the debugger a single time for that aswell. The main thing to assure was just that each part works solid on its own and that is certainly possible. The program worked flawlessly. Sure, as the saying goes even the smartest programmer makes mistakes but he also removes them after looking carefully through and checking all the parts. If there are still bugs then very likely there was already something wrong in the design-stage.


But regarding the timestep and how it affects the game, what is there to disagree with?

[J-Snake]

@Boris:
Yeah, actually I am out of control for any happening I am not writing myself since I am using a frame-work and expect it to do what I think it is supposed to do.

[Eigen]

You come off a little arrogant but if you can write perfect bugfree code, of which I'm highly dubious, hats off to you

Do you use any static analysis tools and/or do you treat all compiler warnings as errors? What language are you working in anyway?

[BorisTheBrave]

@Boris:
Yeah, actually I am out of control for any happening I am not writing myself since I am using a frame-work and expect it to do what I think it is supposed to do.

Did any of the things I describe rely on a framework misbehaving? Maybe the first one.

Also, do I really need to point out the Lewis-Caroll-like contradiction that you expect frameworks to do what you think, rather than expecting your suppositions about a framework to be what the framework actually does. You don't see any hubris in blaming the world for not matching your expectations, rather than chalking that as an unforeseen bug to be worked around?