Scorched Earth and Fabricators

[LaughingThesaurus]

Oh
So you make all of these awesome changes without breaking too many things? I'm pretty impressed with that.

Edit: Because my experience with technology is that it's very fickle and breaks at the slightest touch when it doesn't seem like it should.

[Fluffiest]

Oh, I at least knew that you weren't on the game for quite a while after it was made, but I didn't really know how much you looked at all the details of the code and such. I have this view of programming where it just doesn't seem feasibly possible without knowing like everything that the code is inside and out. I don't know much about it, and that gives me this viewpoint I guess. I just figured, a game as in depth as AI War, the developer has to be a total expert to not break things.

There's an entire philosophy of programming dedicated to making sure that this isn't the case, and that a programmer can use code written by other people without understanding it inside and out.

[_K_]

There's an entire philosophy of programming dedicated to making sure that this isn't the case, and that a programmer can use code written by other people without understanding it inside and out.

Nah, that's just an urban legend.

[keith.lamothe]

There's an entire philosophy of programming dedicated to making sure that this isn't the case, and that a programmer can use code written by other people without understanding it inside and out.

Yea, I think I recall hearing about that in college.

[orzelek]

There's an entire philosophy of programming dedicated to making sure that this isn't the case, and that a programmer can use code written by other people without understanding it inside and out.

Yea, I think I recall hearing about that in college.

I seem to overheard that part as well.. somewhere during my studies.
Reality... is a very different beast tho.. chaos theory runs rampant and Murphy's laws are suddenly not so funny.....

[keith.lamothe]

I like writing "library" code with a foolproof (at least until the universe produces better fools) public interface.  But we don't do that for our games except where something is complex and/or fundamental enough to need it.  Like a custom data structure that gets used lots of places.  But we don't have time to build the game logic with those kinds of clean barriers of "don't know, don't care" so we just have to both know all the code that we'll ever touch   Given the stability of our games, I think it's working out.

[LordSloth]

What, no variables named after your favorite pets? No abuse of global variables? Heresy.

[keith.lamothe]

What, no variables named after your favorite pets? No abuse of global variables? Heresy.

Haha, even the symbol variable names are descriptive.

And I haven't even checked to see if C# has truly global variables.  We use static stuff fairly often, though even there we go more for singletons.

[contingencyplan]

What, no variables named after your favorite pets? No abuse of global variables? Heresy.

Haha, even the symbol variable names are descriptive.

And I haven't even checked to see if C# has truly global variables.  We use static stuff fairly often, though even there we go more for singletons.

By "truly global" do you mean global variables declared outside of a class? My understanding (semi-confirmed by a quick Googling) is that no, every variable has to be declared inside of a class. But in the case of public static variables, they are essentially just namespaced globals (permits the same uses and abuses, and you can access them just by importing the class), and I'd expect that they'd get compiled down similarly to how globals in C are --- at the least I'd expect all static variables to be stored in a separate section of memory from class instances (though additional stuff to prevent buffer overflows and the like may be done by the VM as well).

Singletons are fun.

[TechSY730]

public, static, non-immutable (aka, point to an instance of a mutable object OR they lack the readonly or const flag in C# or the final flag in Java) are indeed almost as dangerous as global, non constant variables. The only thing they save you from is namespace collision.

Static mutable state does have its uses, but you should be very, VERY wary of making that public. (private mutable statics can be quite useful in some limited circumstances if you know how to deal with the memory and thread safety implications)

[contingencyplan]

public, static, non-immutable (aka, point to an instance of a mutable object OR they lack the readonly or const flag in C# or the final flag in Java) are indeed almost as dangerous as global, non constant variables. The only thing they save you from is namespace collision.

Static mutable state does have its uses, but you should be very, VERY wary of making that public. (private mutable statics can be quite useful in some limited circumstances if you know how to deal with the memory and thread safety implications)

Agreed, though I'm one of those ivory-tower crazies that thinks the best way of handling thread safety / write programs in general is to use a declarative language.


Edit: since the thread's already semi-derailed, have y'all looked at F# any? How well do you think it's suited to game programming, especially interaction with Unity?

[keith.lamothe]

Yea, we don't use goto or whatever, but I'm sure some of the code in our games is war-crimes material when looked at from a "good programming practices" standpoint

[contingencyplan]

Yea, we don't use goto or whatever, but I'm sure some of the code in our games is war-crimes material when looked at from a "good programming practices" standpoint

Ah, but the big question is whether you use break and continue.

[TechSY730]

Yea, we don't use goto or whatever, but I'm sure some of the code in our games is war-crimes material when looked at from a "good programming practices" standpoint

Sometimes you have to sacrifice "good design" for the sake of performance. Given the kind of absurd loads that some of your games have to deal with (AI War especially), I can see that sometimes you have to that in your codebase.

[keith.lamothe]

Yea, we don't use goto or whatever, but I'm sure some of the code in our games is war-crimes material when looked at from a "good programming practices" standpoint

Ah, but the big question is whether you use break and continue.

It's worse than that.  I've been known to do this:

Code: [Select]

for(blah;blah;blah)
{
    //...
    switch(blah)
    {
        case blah:
            continue;
    }
    //...
}

Bwahahaha!