hedgecore posted:

I'm using a model I found online which does have individual wheels but honestly I just set up a Box collider and am treating it like a large box (no wheelcolliders or anything). I'm animating tricks by rotating or flipping the whole thing. I figured this would only make things easier in the "faking it" kind of physics.

Serenade posted:

All this talk of inheritance & co makes me wonder if a mostly functional approach could be a useful way to code a game.

OneEightHundred posted:

Naughty Dog used to write all of their games in a custom LISP derivative until they got bought by Sony and Sony forced them to start writing stuff in C++ instead.

Ralith posted:

Sorry, by "model individual wheels" I meant "perform physics simulation on individual rotating wheels." For a box like that you need to set up anisotropic friction as I described. This will produce behavior that is usually sort of like having wheels.

Manslaughter posted:

In a perfect world, the compiler or IDE warns me of such folly and prevents me from building.

What do I do if I want a default behavior for my interface methods?

Fano posted:

Pity that there don't seem to be many courses that focus on how to architect a game that is bigger in scope than your typical 'make your first game' tutorial, sometimes I feel that I am making a lot of stuff up as I build up my game and that there are probably some concepts/design standards that go into building the infrastructure for a game that I'm simply not aware of since I don't work in the industry.

Then again a course on something like that is probably not too plausible since every game is different.

ToxicSlurpee posted:

Really, much of it is just actually planning things and not being a dumbass in how you plan things.

OneEightHundred posted:

Naughty Dog used to write all of their games in a custom LISP derivative until they got bought by Sony and Sony forced them to start writing stuff in C++ instead.

hedgecore posted:

Gotcha, thank you. Unfortunately... http://answers.unity3d.com/questions/927201/friction-direction-2-work-in-unity-5.html Am I screwed then?

Is there a way I can just turn by setting rotation where it will still respect level geometry? Or will setting it manually cause my model to go through other models?

hedgecore posted:

Gotcha, thank you. Unfortunately... http://answers.unity3d.com/questions/927201/friction-direction-2-work-in-unity-5.html Am I screwed then?

Is there a way I can just turn by setting rotation where it will still respect level geometry? Or will setting it manually cause my model to go through other models?

ToxicSlurpee posted:

In a perfect world we wouldn't need to write code at all.

Obsurveyor posted:

xezton posted:

I can't answer your question, but I can definitely advise that you post that gif in this here thread: http://forums.somethingawful.com/showthread.php?threadid=3611075

DStecks posted:

So, today I was reading Game Programming Patterns, and in its chapter on Singletons, he brings up that an issue with static variables is that it's impossible to know where they're being modified from; but couldn't this be pretty trivially solved by having the variables be static, but private, and accessed via (also static) getters and setters in the singleton? Because then you could drop a debug stop on the setter line. It seems so obvious it can't possibly work, right?

Edit: or in Visual Studio, just right click on the setter and select "show all references".

FateFree posted:

If I'm dealing with nearest neighbor pixel scaling, and I want to zoom in and out of say an overhead view, is there a certain factor i should 'snap' the scaling to every time, like when someone uses a mouse wheel? In other words, does nearest neighbor mean that I'll see a pixel perfect representation of a scaled sprite ALL the time, or only for certain scale factors? Obviously integer scaling like 2x and 3x work fine, but I'm talking about fractions of that (the smallest fraction that makes the sprite look perfect, if that makes sense).

Nude posted:

Also I wouldn't ever put actual code in getters/setters (even debug). I just use them to declare private/public, but that might be just me. Putting code makes getters and setters more like methods instead of variables, but I think that is debatable for some people so take my advice with a grain of salt.

Nude posted:

Lets say you have a variable NumberOfEnemies being used with 10 different classes. And you have a glitch where NumberOfEnemies is 9 instead of 10, you have analyze one by one those 10 classes. I don't see how putting in a debug.log makes that any easier but maybe I'm missing something. IE: You could have an if statement in Class5 preventing it to ++, or Class3 only adds when the number is 4, etc etc.

Nude posted:

Also I wouldn't ever put actual code in getters/setters (even debug). I just use them to declare private/public, but that might be just me. Putting code makes getters and setters more like methods instead of variables, but I think that is debatable for some people so take my advice with a grain of salt.

DStecks posted:

If you aren't putting code in getters and setters, why are you even using them?

OneEightHundred posted:

A pretty good reason is to do this:

code:

public int MyProperty { get; private set; }

ToxicSlurpee posted:

Interfaces are more of a software engineering thing when you have to deal with a lot of people working as a team.

Manslaughter posted:

What do I do if I want a default behavior for my interface methods?

Fano posted:

Pity that there don't seem to be many courses that focus on how to architect a game that is bigger in scope than your typical 'make your first game' tutorial, sometimes I feel that I am making a lot of stuff up as I build up my game and that there are probably some concepts/design standards that go into building the infrastructure for a game that I'm simply not aware of since I don't work in the industry.

DStecks posted:

In Unity, why would resizing the scene view window corrupt my UI panels? I adjusted the size and suddenly two panels vanished, replaced with red wireframe x's.

DStecks posted:

So, today I was reading Game Programming Patterns, and in its chapter on Singletons, he brings up that an issue with static variables is that it's impossible to know where they're being modified from; but couldn't this be pretty trivially solved by having the variables be static, but private, and accessed via (also static) getters and setters in the singleton? Because then you could drop a debug stop on the setter line. It seems so obvious it can't possibly work, right?

Edit: or in Visual Studio, just right click on the setter and select "show all references".

DStecks posted:

Today I learned that in C#, if you try to assign a value to a previously uninstantiated field, this will not instantiate it with the values you're trying to assign it, but will instantiate it as a reference to the value.

As in, this code:

code:

public Interaction(Interactable p_Parent, int p_Tag, List<int> p_AccessPoints)
    {
        m_Parent = p_Parent;
        m_Tag = p_Tag;

        m_AccessPoints = p_AccessPoints;

Was not instantiating m_AccessPoints as a new List<int> with the same contents as p_AccessPoints, but as a cached reference to p_AccessPoints, which the calling method immediately clears after calling this constructor.

dupersaurus posted:

Copy constructors are your friends

DStecks posted:

Today I learned that in C#, if you try to assign a value to a previously uninstantiated field, this will not instantiate it with the values you're trying to assign it, but will instantiate it as a reference to the value.

As in, this code:

code:

public Interaction(Interactable p_Parent, int p_Tag, List<int> p_AccessPoints)
    {
        m_Parent = p_Parent;
        m_Tag = p_Tag;

        m_AccessPoints = p_AccessPoints;

Was not instantiating m_AccessPoints as a new List<int> with the same contents as p_AccessPoints, but as a cached reference to p_AccessPoints, which the calling method immediately clears after calling this constructor.

DStecks posted:

Today I learned that in C#, if you try to assign a value to a previously uninstantiated field, this will not instantiate it with the values you're trying to assign it, but will instantiate it as a reference to the value.

As in, this code:

code:

public Interaction(Interactable p_Parent, int p_Tag, List<int> p_AccessPoints)
    {
        m_Parent = p_Parent;
        m_Tag = p_Tag;

        m_AccessPoints = p_AccessPoints;

Was not instantiating m_AccessPoints as a new List<int> with the same contents as p_AccessPoints, but as a cached reference to p_AccessPoints, which the calling method immediately clears after calling this constructor.