I agree with everyone. It has pros and cons, my main reason is I dislike writing getters and setters for everything when 90% of them will look like:

Code:

Something const& getSomething() const
{
  return m_thing;
}

void setSomething( const Something& thing )
{
  m_thing = thing;
}

Making everything public is good for small and midsize projects, but can potentially cause problems in larger projects. I've worked with million+ line code bases that do it and in practice it wasn't too much much of an issue, outside of programmers that don't agree with it architecturally bitching .

If C++ had AS3 style get/set or C# style properties (and read only variables) this would be a non-issue.  In C++ you can emulate this functionality but it's not really worth the effort. I usually use private or protected variables and getters and setters if a variable is internal, read only or requires non trivial assignment, but not always.

using /2 instead of >> 1

This is really an architecture dependent optimization.  On most architectures shifting will be faster than dividing, on some architectures integer divide will kill you but on most modern CPUs the different will be minor.  On some architectures the shift might actually be slower (Pentium 4 for example had notoriously slow shift).  Like people have said before, it's best to write code that more clearly shows your intentions, a good compiler will be architecture aware and make this optimization for you. If you have a inner loop that shows up as a bottleneck in a profile on your target architecture you can easily change /2 to >>1 when you need it.

My bad habits include copy and pasting code telling myself I'll refactor\clean it up later, even though I often don't, constantly refactoring code with no unit tests, and making all read\write members in classes public, which avoids having to write millions of getters and setters but makes it a pain in the ass to do refactors and doesn't always lead to clear interfaces. I also am somewhat inconsistent with coding style sometimes, but I try to keep it relatively consistent.

I only usually practice these things when writing code that I think I'll work on only and try not to do it professionally, but now I'm working on a game that started as a hobby project\framework and now is a large commercial game with multiple programmers working under me .

Typical Ivan .

[Blue Knights]

Blue Knights is finish.

It didn't turn out fantastically, but it's got an odd control scheme -- so I didn't expect it to turn out awfully well!

Have you tried a more traditional control scheme?  Blue Knights is cool but having to charge everything, including move left and right, is awkward.  Might be more fun if left and right movement where separate keys and attacks\abilities were charge.  Either that or just make it a full on fighting game with special inputs, back to guard, etc.  Are you limiting all the games to two keys (effectively one for Blue Knights) to avoid keyboard input limitations?

Looking good Ivan! If you actually pull this off it will be awesome.  I've been wanting to see a decent Bushido Blade style fighter for a long time.

Yeah, that's the next and somewhat more complicated part. I'm getting some stuff working already though.

I hate dealing with geometry so I'd probably do something cheesy with clip planes and the stencil buffer.

Also, I recommend msvc6!

Why would you recommend msvc6?

Are you looking for collision response techniques, or how to implement certain types of gameplay physics?

Applications of collision detection in games are varied, used in everything from character controllers and bullet hit detection, to lighting and rendering optimizations. At a high level all usage of collision detection code comes down to:

Code:

if( Intersection( object1, object2 ) )
{
  //collision response
  DoSomething();
}

You're right in that RTCD doesn't go into what "DoSomething()" is and simply covers how to implement "Intersect", but its hard to point you to a specific reference if you don't have a specific gameplay goal in mind.  

Do you want to know how to implement a character controller?  Do you want to know how rigid body dynamics work, how to test if a bullet hits something, how to test if an enemy sees the player?  All of these things use collision detection in a broad sense.  As far as I know there is no convenient, high level reference that covers common uses of collision detection and response in games in one place.

Its a good idea for a book or article, but right now the best way to learn this sort of stuff is to look at existing game code.  If you list some common gameplay situations you want clarification on I can tell you what sort of intersection tests they usually use, if that's what you're asking...

Fuck the haters, Dan. Take your money and run.

I know the TIGSource forums have a bias toward Code::Blocks, but it seems strange not to even mention Visual Studio Express and XCode...

Looks like a combination of meshes and particle systems.  The key to the "magic" look of the effects is additive blending, which makes everything glow. This kind of stuff isn't that hard to do in a modern 3D engine with a decent particle\effects system.

Android supports scripting (http://code.google.com/p/android-scripting/).  You can open up a console and write scripts on your phone.

C++0x's nullptr solves this problem, and I can't wait for it.

He can use nullptr considering he's working with VC 2010. Might cause problems if he has to compile somewhere that doesn't support it but now I think most new C++ compilers have support for it.

Tyler beat me to it, but the best way to do this is a simple shader. Palletized textures and color index modes are deprecated on modern hardware and probably won't work. Pregenerating the palette swaps on the CPU will probably work fine but is less flexible and more memory intensive. If you're still using fixed function for everything you should join us in 2010 and start writing shaders .

Although boolean flags and enums work for simple state machines, they can quickly become hard to manage. Your approach is definitely the simplest and it works when you don't have many states to deal with, but you might want to look into more robust state machine implementations if things get out of hand.

As far as open source fighting games go there are a variety of open source MUGEN clones that might be worth investigating. Even if they don't necessarily produce very good fighters there are probably some good ideas to be had on how to build a fighting game engine.  If you want to look at open source beat 'em ups Beats of Rage is an open source game that is actually pretty good.

I guess the disadvantage is they have no equivalent (?) in DirectX's paradigm, but who the hell cares about that?

DX11 has command buffers which can be used in a similar manner to display lists and are generally more flexible and more closely related to the way hardware\drivers work. But you're right that no one on TIGSource cares about DirectX.