next »

[ThemsAllTook]

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

...alright, I'm completely baffled. I found the specific threads and posts I thought I remembered strongly disagreeing on, but when I reread them they all made perfect sense. Either my memory is faulty, or I misread you the first time, or I've drastically changed my way of thinking about code in the last year (which I'm fairly certain isn't the case, so it must be one of the other two). So, disregard that whole thing!

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

I do both of those things, and still have plenty of bugs. Tools are great, but can't account for human error and unknowns. Everyone makes mistakes, even the best of us.

[moi]

hold the press! I've just realized that JSnake must be basing his coding on the principles of the 4-simultaneous-day timecube theory, which could totally explain the perfect programming and the absence of bugs.

[Rebel Binary]

I don't call them bugs, I call them features

[Eigen]

I don't call them bugs, I call them features

[J-Snake]

I really prefer C++. It feels the most flexible and straight-forward high-level-language to me, though I haven't really tried out many alternatives.

But currently when dealing with xna I am bound to C#. I am treating it like C++ and not as own language, which isn't really optimal. Also I have to structure some data in a certain forced way because I want to avoid any garbage-collector-calls during gameplay. TrapThem is a dynamic game so allocations during gameplay has to happen (if you don't want to deal with structs for everything), but it is possible to limit them to a size less than 1mb, so a gc-call should not be fired during the level-play. Not a fan of managed languages for video-games at all personally.

[enthrallstudios]

"If you make it, they will break it". Some bugs are just obscure, and you usually don't see. there is a bug in Crash Bandicoot 2 that is realized when you bounce on a series of objects a certain number of times that gives you all the collectible items in the game. That isn't something one would usually notice, but someone will. It is possible to get rid of all the game-breaking bugs, but not without a very wide range of tests. I am sure you are catching a lot of bugs, but believe me. Even companies with millions put into testing miss a lot. You are bound to miss a couple. Nevertheless, good luck.

[st33d]

One story springs to mind regarding this sort of attitude:

I get into a car with a friend and I put on my seatbelt.

"Don't you trust my driving?"

"Oh I trust your driving just fine. I don't trust any of these other people's though."

Saying - I've got no bugs - is like saying - I know everyone else's bugs. Which is a superhuman feat. It's just not possible. Somewhere down the line you will have to deal with someone else's code - and their shit will be broke.

But arguing this unfortunately still gets you nowhere. Because my mate still believes that some crazy fucker isn't going to ram him off the road some day.

[Graham-]

The only way to eliminate bugs is to have a complete test suite. The only way to build a complete test suite is to extend it for every bug you find. And even then you'll probably never know... or at least it will be a really long time if your code is complex.

[Fallsburg]

To give you an example from my job.  I write a lot of code, and maintain a lot of legacy code.  One of these codes is a program that takes a proprietary text format and converts it to relevant graphics formats (ai, pdf, ps, etc.).  This code has existed for ~20 years and has been used millions of times.  Just this last week, a bug popped up that has existed the entire time the code has existed, but for whatever reason noone ever thought to test or has ever tried to put a tab in text with helvetica font before.  The program tried to find the length of a tab in helvetica, failed, and screwed up. 

I know you are writing your code from scratch and not inheriting other people's (although, that's not fair since I sincerely believe you aren't rolling everything from scratch), but even still, there are going to be things you don't anticipate.

I know that J-Snake is going to respond with his standard "Trap Them has perfect mechanics, I am perfect, etc." delusions of grandeur, borderline schizophrenic response, but whatevs.

[Belimoth]

That alone can help you identify bugs with the engine.

That is gross. A serious engine shouldn't have any bugs.

If your game is bug-free it is because everything in your game is grid-aligned. Undesirable behaviors are easily tested for in that kind of environment.

Also bugs happen when people try new things, your game is literally just Pac-Man with Tetris physics.

[zalzane]

hey now, grid-aligning things isn't bad as long as the resolution is small enough

[Graham-]

Extending the conversation...

I kind of like bugs. JSnake is talking about being so precise that you eliminate bugs with careful observation. I used to be more like this. Now I just write the code. Then I punish it, with tests, or writing other code on top. Then I rewrite the code.

The truth is that the best abstraction isn't obvious until until you've written new code to work with the original code, and ideally a lot of it. So "perfecting" the old code first can be a time sync. Sometimes when you design algorithms all the perfections are ironed out in the on-paper stage, because the solution is too complex to iterate to. But the code produced this way is a fraction of everything you will ever write, even in highly "algorithmic" systems.

So I put stuff in when I feel it's good enough. The cost for catching a bug when you write something the first time is much lower than the one from finding it later, but the cost for over-architecture is just as bad, and the cost of mastering a piece of code before you know its best use isn't always efficient; it usually isn't.

No matter what you should build good test harnesses. You should test out your ears. That way you can guarantee bugs don't exist, you don't have to re-learn a system every time you change it, and every time you do you can be confident that your changes don't have un-forseen consequences, because your test suite would catch them. The reasoning here just explodes when you work on a team, and more so again when your project is long-term.

I plan all of my work under the assumption that I will write one engine, and upgrade it forever. So in many ways my current game is the basis for every future game. So I want any piece of code that will likely be used a lot to be as robust as possible. It's just as important to me that the test suite is robust as is the code it tests.

When you write code and verify its quality with mental talent you gain a victory, but when you change it to suit new needs, modify it over time, let other people inside it, you have to repeat that work every time you touch it to get the same results. And as systems become more complex that amount of work only increases.

When you write an evolving test suite you don't have that problem. Then the team's - or your - understanding of a system's robustness is written down, made explicit, and can be collaborated on.

just fyi.

Also, I don't use a debugger. I miss one occasionally, but I'm getting better at not having one. It is always better to write better self-analysis tools yourself. Having other code tell you what your code is doing is kind of backwards.... If there's something you need to know you can always get better info by writing code that reports on it. Then you can reuse that stuff, build on it, and include it in a test-suite. Debuggers are a crutch, though a useful one.

[Fallsburg]

Also, I don't use a debugger. I miss one occasionally, but I'm getting better at not having one. It is always better to write better self-analysis tools yourself. Having other code tell you what your code is doing is kind of backwards.... If there's something you need to know you can always get better info by writing code that reports on it. Then you can reuse that stuff, build on it, and include it in a test-suite. Debuggers are a crutch, though a useful one.

This is one of the stupidest things I've ever read.

A debugger is a tool.  A valuable tool for code development.  It isn't necessary, but few things are.  If your code segfaults or some such thing, why not use a debugger?  Why write your own half-assed debugger that is probably going to be buggy itself and nowhere near as fully featured as a standard debugger. 
This goes for other tools like profilers (call or cache).

[Graham-]

You don't write your own debugger, you write test cases. If you can't narrow down your problem then you should write test cases that isolate it, then put it in the suite. Debuggers are a short-cut. Welcome to programming.

If the range of your problem is enormous then write code that reports on what's going on as your system runs. I'm talking about code that outputs what's going on as your code goes. When you use a debugger you are just stepping through lines looking at what's in memory. Only 5% of that is relevant. You have to find that 5% manually, each time you debug, meaning you have to do the work and the thinking each time.

If you write self-reporting code that 5% will be reported on automatically. You have to write it the very first time, then after that everything is free. And beyond that, it is free for other devs, and you can extend those cases and re-use them. Your debugging labor does not have to be repeated, and you can put it in the test suite.

Your code is your tool. We're programmers. If something can be programmed, program it. Manual tools are for border-line cases and surprises.

[OneMoreGo]

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

this.

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.

It's easy to criticise them, but they have done the hardest thing in the process, complete something, release it and they made money off it too presumably.

Now, if you really have no bugs, where is the download to your game? There's no bugs so it should be fine to release it

[J-Snake]

I get into a car with a friend and I put on my seatbelt.

"Don't you trust my driving?"

"Oh I trust your driving just fine. I don't trust any of these other people's though."

I see what you are trying to say but I don't agree with that because it is not a correct comparison. You are setting rules for EVERYONE, not just for you. If you design the rules of chess then you know the horse will only jump 3 cells, always, no matter who will play it. That is a design-property that assures that. The same can be applied to video-games.

I am not saying I can guarantee zero bugs for every software I make, but it will be rather likely than unlikely. So Bug-free software does exist, which was my main point I wanted to bring across.

[OneMoreGo]

Also, I don't use a debugger. I miss one occasionally, but I'm getting better at not having one. It is always better to write better self-analysis tools yourself. Having other code tell you what your code is doing is kind of backwards.... If there's something you need to know you can always get better info by writing code that reports on it. Then you can reuse that stuff, build on it, and include it in a test-suite. Debuggers are a crutch, though a useful one.

This is one of the stupidest things I've ever read.

A debugger is a tool.  A valuable tool for code development.  It isn't necessary, but few things are.  If your code segfaults or some such thing, why not use a debugger?  Why write your own half-assed debugger that is probably going to be buggy itself and nowhere near as fully featured as a standard debugger. 
This goes for other tools like profilers (call or cache).

Using the debugger is a last resort for me. The downside to using the debugger is it masks code that is hard to understand. If you can't figure out what the code is doing by looking at the code (or hopefully unit tests) then you should probably fix the code!   Of course if it's a third party library you want demystified then that's a different matter.

[J-Snake]

Now, if you really have no bugs, where is the download to your game? There's no bugs so it should be fine to release it

As I said I won't release it until the graphics/music is done.

On a related note, it is not pac-man + tetris-physics. It is based on a fundamentally new physics-system which will blow your mind with the challenges build on top of that.

[Graham-]

@OneMoreGo

Yeah. Debuggers are good for not-your-code, or rushed code (which is sometimes justified).

[ThemsAllTook]

When you use a debugger you are just stepping through lines looking at what's in memory. Only 5% of that is relevant. You have to find that 5% manually, each time you debug, meaning you have to do the work and the thinking each time.

If you write self-reporting code that 5% will be reported on automatically. You have to write it the very first time, then after that everything is free. And beyond that, it is free for other devs, and you can extend those cases and re-use them. Your debugging labor does not have to be repeated, and you can put it in the test suite.

That's not really what a debugger is for. You're not going to be stepping over the same code again and again ad infinitum; if there's a problem that can be diagnosed more quickly with an interactive debugger, you run it once, find the problem, solve it, and never step through that section of code manually again. In a lot of cases, if I'm debugging with printf, it takes several recompiles to isolate the problem, and a fair bit more typing. They're two different tools that both have their purposes, and used appropriately, a debugger will reduce the amount of manual work you do.

Your code is your tool. We're programmers. If something can be programmed, program it. Manual tools are for border-line cases and surprises.

Exactly. Manual tools are for surprises, and when a surprise happens, they're quite valuable. I don't understand why you seem to have an aversion to them, when you also acknowledge their usefulness. A tool is a tool; one size doesn't fit all.