I just finished a sprint on explosive projectile weapons; I've got rockets that explode on impact, timed grenades that bounce and roll around, and proximity mines that stick to surfaces (oriented to the surface normal) and explode when an enemy is nearby. Coupled with my prior sprint (the ubiquitous exploding barrel), I've got a massive amount of THINGS WOT GO BOOM!

I love writing my own engine. I think it is rewarding in and of itself (for most of the same reasons Glaiel already mentioned). But I'm really only writing it for me, with a very specific set of features to support two or three games I want to make. I've been able to make judicious cuts because I know the needs of my entire user base. When you write an engine with the intent to release it, it's harder to make those assumptions.

I tend to agree with the suggestion that no one is going to use someone else's "dorm room" engine; I'm slow to trust any library that hasn't been put through its paces by both the author and a community of users. There's also a learning curve to become familiar with someone else's code. It took me maybe an hour or two to be certain I knew what I was doing with small, simple libraries like TinyXML and zlib; realistically, it could take days or weeks to become comfortable working with a robust engine. Finally, there's an implicit set of rules and constraints that come with any engine, and maybe those are well-documented and maybe they're not. The author has a ton of knowledge in his head while writing the engine, and he knows how all the pieces fit together and how to make it do whatever it needs to do. It is extremely important (and difficult) to communicate all of that knowledge to end users in a meaningful way.

I'm not sure I understand your last question correctly. Are you asking whether having your code clearly delineated between game code and (reusable) engine code is a bottleneck? That line is pretty fuzzy in my engine (and probably in most). Although I have separate libraries for major systems, I tend to treat the code base as a whole and will gleefully hack into those libraries as needed to support new features. I doubt there will ever be a time when I could just compile those libraries and never touch their code again. And yes, a well-organized engine is a lot slower to get up and running than a code-like-hell project, but the payoff is that it is more robust and reusable and easier to maintain.

You could also make certain velocity ranges map to certain animation frames, so the animation will automatically match the jump arc whenever you tweak the jump velocity. And it will advance to the downward part if you collide with an overhead obstruction and start falling before the jump apex.

Sadly, I've heard a *lot* of disreputable stories from places like digipen and guildhall.  You could probably learn a lot more about game design just from hanging around here and perusing related tutorials.  Also, play games.

Guildhall grad here to refute that. The experience is somewhat different for the art and design students, but the programming curriculum was excellent. If you only want to make indie games and debate whether games are art, sure, it's a waste of money; but if you want to go pro, it's a good choice. Of course, making games is always the most important thing--no amount of education will matter if you never apply it. Sadly, there are people who enroll in game development programs and expect to coast through it and come out the other side with a fun job; those people don't make it.

So I guess the catch-22 is that self-motivated, hard-working people get the most benefit out of it, and those are the same people who are constantly programming, reading these forums, learning new techniques, etc. on their own anyway. I've got no answer to that, only that I think it actually made me more self-motivated and a better programmer.

And to keep this relatively on topic: definitely go for Comp Sci, OP. I wouldn't trade a solid undergrad education for any game development program, much less one targeted at design (which is a vague name but evokes theory and discussion and not practice and development). And if design interests you, take some humanities classes. Designers should have a broad knowledge of culture and traditional arts, not just of games. The best designers I've known also tend to be voracious readers and film buffs.

After a few slow months of hobby development (aka extremely busy months at work), I've jumped back into my project with a vengeance, fixing a few long-standing bugs, writing a couple of Blender scripts to make level design easier, and figuring out how to do door collision in a non-hacky way.

Incidentally, who knew doors were so difficult to do right? I mean, they're just doors!  I still need to decide how I'm going make them work with AI navigation; AIs could just automatically open doors in their way, but if I ever want to make lockable doors, then I'll need to mark up the navmesh or something and make it find a different path.

Noel also wrote C++ for Game Programmers, so... No. Not C++ bashing. Just like you can use C-style functions in C++, you can write in an object-oriented fashion in C. It's not about the language, it's about the architecture.

And he cites Mike Acton, which reminded me of this. Making the same point, no less.

For instance, all PhysicsJoint objects have a Solve() function, but each has unique internal data: pin joints are described by a local position on each body, distance joints have an added distance parameter on top of that, directed distance joints have an axis direction on top of that, and the data for angle joints is completely dissimilar to the others.

So solve all the pin joints together in one batch, then all the distance joints, and so forth. And they'd better all be in contiguous memory. (I mean, why wouldn't they be?) Personally, I find that method of coding maddening, but it is provably more efficient, and when you're trying to ship a AAA game at 60 Hz, that matters. (But maybe shipping at 60 doesn't matter all that much.)

Here's some rambling thoughts on the subject. Some of this might not be appropriate to your situation because I wasn't really sure about what you're trying to accomplish. Are you making a game with this? Are you releasing this for other developers to use? Is this a 2D or 3D engine? So I'm assuming 3D action game engine, because that's what I'm most familiar with.

If you're going to actually make games with this, some sort of entity system is in order. How will you manage destruction of entities? Will entities directly hold pointers to each other, and how will you ensure that they don't end up with dangling pointers? Will you use an inheritance hierarchy or a component model? (And if you're not going to do any of this and are simply making a rendering framework, I'd highly recommend stopping and reconsidering, because an engine without an application is an engine that by definition hasn't been battle-tested, and who wants to use that?)

Physics. Not necessarily full Havok-style rigid body dynamics, but at least collision detection (entity-entity and entity-world). Again, this is absolutely essential for just about every kind of game, so whether you're making a game with this engine or you're expecting someone else to, the work will need to be done; it might as well be done once, by you, in a manner consistent with the rest of the engine.

AI is very game-specific, but certain aspects like pathfinding and path network generation are ideal for inclusion in an engine if you can at least make the assumption that you're making an action-y game engine. If the engine is meant to support everything from shmups to platformers to football, there's obviously very little common ground. Likewise, the core elements of an AI decision system could be included, but without any specific behaviors implemented with them.

Graphics involves a lot more than just loading images and meshes. An engine is more than just plugging content into an API. How will you manage objects in your scene to maintain a playable framerate? (That goes for collision detection, too.) You'll probably want some kind of spatial partitioning to minimize what gets rendered. One topic which I've seen very little discussion on but which was a thorn in my side on an older engine is managing draw passes. Say you need to render your objects once from a light's camera for your shadow map buffer and then again from the player's camera; how do you define those render passes, and how do you define which objects belong to which passes? Beyond just rendering, you need a good system for animations: how to define them, how to play them, how to blend them if you're doing skeletal animation, etc. And shaders and materials are a whole post in themselves.

Likewise, audio is a lot more than just playing sounds. Talk with an audio designer and find out what they want. You'll probably want things like the ability to duck categories of sounds (e.g., turn down the background music and sound effects while a character is talking). Effects aren't always necessary, but reverb is pretty standard.

A good content pipeline is a huge thing that I think a lot of people initially overlook. How will content be authored? Will you need custom tools like a level editor, or can you make do with existing tools? I build levels for my engine in Blender; I know of pro studios that use Max. Heck, Excel and even Notepad can be acceptable tools for some purposes, but easier and better tools will enable easier and better content creation. Are you targeting only yourself or do you expect others to use this engine? (If the answer is the latter, and you're primarily a programmer and not an artist or designer, do not make any assumptions about what is or is not an acceptable tool. Ask someone who will actually use the tool every hour of every day.)

Further down the content pipeline: What sort of preprocessing is needed? Will you load raw images at runtime or bake them into DDS files? Will you distribute games on this engine with loose content files (lame!) or pack it all up neatly in compressed packages? How will these decisions affect development of the game (i.e., can you easily support loading both raw and baked/packaged content)? How easily and quickly can you bake content? How easily can you deploy a complete build? Ideally, building the entire game from raw assets (including code) should be a one-click process that builds the engine, the tools, and the game, bakes and packages the content, builds an archive (or installer), and runs a suite of tests to validate the build.

Debugging/profiling tools: When your engine starts to run sluggishly, how will you debug that? More importantly (if this engine is for public use), how will your clients debug that? Unit tests are nice for making sure you don't break basic things like containers. Autotests (or "monkey input," random button presses) require a bit of work to do well, but are a great way to soak test a game for hours without needing to be present, and they'll uncover a lot of bugs that normal user input might not find. Cycle counters are a good basic way to profile CPU time; clock the number of cycles at the start and end of a function to test how long the function takes.

Is there such a thing as a 'Programmer's Handbook of Style' anywhere, for me to read?

That would imply that any programmers ever agreed on style issues. Ha! Ha!

Though seriously, perhaps you're looking for something like Design Patterns. Knowing common algorithms is good, too. The relevance of these things may not be immediately apparent to any given part of game coding, but eventually you'll start to identify common problems and be able to apply known solutions to them.

Getting stuff like this set up for the first time looks daunting, but it's usually easier than it seems. There's not really a one-size-fits-all solution, because it depends on how the library is distributed (DLL, static lib, source code), but usually, it's just a matter of pointing the IDE at the library's location. And sometimes telling the linker if there are library files you're dependent on (if the library uses static .libs instead of DLLs).

For example, Indielib's wiki covers the library location stuff here. And static .lib files can be listed in the project properties, under Configuration Properties -> Linker -> Input -> Additional Dependencies (in VS2005, anyway; things may be moved a bit in 2008).

I like the idea of using a spreadsheet--it makes it easy to compare values between classes and even write little formulas to help balance things in the later stages of tuning the game.

I just use INI files. There's probably lots of free INI parsing code out there, but I wrote my own that (for better or worse) is tightly coupled with my configuration variables system, so instead of emitting string pairs, it just goes straight into config vars in the engine. It's easy to edit INI files and I can even hot-load changes at runtime, but things aren't grouped as neatly as they would be in a spreadsheet (e.g., a column of health values per class). And like the spreadsheet approach, there's no explicit representation of inheritance in the INI file. (Internally, data is inherited, and I comment the INI file to indicate where classes derive, but there would be the potential for confusion if this weren't a purely personal project.)

Manually creating the .rc file seems sort of hacky. Just right-click on your project in the Solution Explorer, Add -> Resource... and let VS generate the .rc file and assign IDs for whatever resources you embed.

Edit: My bad, Express edition removes this functionality.

You may just need a more recent glext.h than what MinGW ships with. Khronos defines a standard one, and I think some hardware vendors provide their own (I know NVIDIA does for sure, anyway).

http://www.opengl.org/registry/api/glext.h
http://www.opengl.org/registry/api/glxext.h
http://www.opengl.org/registry/api/wglext.h

I checked and PFNGLGENFRAMEBUFFERSEXTPROC is defined in there, so hopefully you'd just have to do the usual address-getting boilerplate code and it would work. I don't know, I haven't touched GL in a while.

I also use Blender. Nothing to see here.

Actually, it sounds like my exporter is rather different from Ivan's. Instead of exporting values from the IPO curves, I just dump the pose matrices for each bone for each frame into a massive XML file, then run a separate tool that (among other things) converts those matrices into quaternion/vector pairs and writes out my custom mesh format.

It would probably have been faster to use an existing exporter and file format, but I like doing these things myself and learning from it.

The nice thing about doing it this way is that I don't have to manage the hierarchical transformations; Blender has already done that for me, and I just use the final values. I don't even need to know anything about the hierarchy of the skeleton, only which bones are transforming which vertices. There's limitations to that, too; I can't easily procedurally modify animations at runtime (e.g., for foot IK). I can do head-tracking because the head is a "leaf" bone, but if I wanted to adjust a bone with children, say rotate the shoulder and have the forearm and hand bones follow, I'd need information about the hierarchy of the skeleton, and I'd have to unwind the premultiplied transforms, make the adjustment, and then remultiply everything. So that's just not something I do.

I'm a programmer, not an artist damnit.

I hate having to stop writing code and start pixeling graphics.  I'll actually go and hunt for bugs just to procrastinate making art! 

On the plus side, the code runs better now. 

I've recently realized what a massive task I've created for myself by trying to make a 3D game without an artist. I'm reasonably capable in Blender and GIMP, but the time it takes to model, unwrap, texture, and animate even a single character is making me miss pixels and 2D games. And then there's sound design and music composition to be done... I think my game may never be done.

All my future projects will be 2D games with procedurally generated art.

Let me try this again, now that I actually understand what that code's meant to do:

The l-value problem is caused by using = instead of ==. It thinks you're trying to assign to the non-l-value expression (temp.numerator / commonFactor).
You also want braces around everything that belongs in the while loop. As it is written, only the instruction dividing the numerator is executing inside the loop.
Finally, the while condition doesn't look like it's doing what it's meant to do. You're looking for whether the division has any remainder, so you should be using modulo (%).

[How do you debug your games?]

How do you debug your games? Printf debugging is pants.

Using a debugger. I luuurve the MSVC debugger. I haven't had much experience with GDB or other debuggers, but I'd assume they've generally got similar features. Being able to insert breakpoints, step through code line by line, and observe (or even manually change) the values of variables are all common and incredibly useful features. MSVC even lets you drag the instruction pointer around so you can rewind or jump over sections of code. Conditional breakpoints (i.e., break only when some condition evaluates to true) can be very handy, too, if you're debugging a function that gets called all the time but you only care to examine a particular case. The MSVC variable watch window is pretty robust, too; by default, it lets you expand and investigate the contents of STL containers, and you can write your own parsing rules to change how it displays your own custom containers.

But sometimes, you still have to fall back to printf debugging. In my day job, I work with a lot of code in a particular scripting language that doesn't have a functional debugger. Or maybe you've got a bug that only manifests in release builds without symbols, so you can't debug it the usual way. (Suspect uninitialized data, but that's not the point.)

Measure the number of triangles (or sprites, if you're doing a 2D engine) you can draw while maintaining your target frame rate (60fps, ideally, but many commercial games settle for 30).

Measure the number of pixels you can fill at that rate. These things are more hardware issues than engine issues for modern 3D games, but your vertex and fragment shader efficiency still matters.

Maintain a *steady* frame rate--amortize the cost of expensive algorithms like pathfinding across multiple frames if necessary, and avoid page faults if you're working in an environment that uses virtual memory.

Measure the number of animated characters, the number of lights in the scene, the number of physics objects, etc.

Measure how your performance is affected by increasing the complexity of the scene. Spatial partitioning and frustum culling should be used to avoid rendering things outside the player's view, and broad-phase collision detection should be used to avoid testing O(n^2) physical collisions.

Measure your memory usage. This is easy to overlook on the PC (and difficult to test realistically without a mass of content), but it's critical when developing a competitive engine for consoles.

Where possible, compare your results to modern engines. Build extremely dense maps for UT3 or HL2 that push those engines below acceptable frame rates, and then see how your engines compares. Can you get more or fewer animated characters and dynamic lights in the world before performance degrades past playability?

9 outputs (1 for each square) makes more sense to me than a single output whose quantized value indicates a square, simply because the choice of squares isn't a continuous range (e.g., the top-left square shouldn't have any more correlation to the top square than to the left square).

A problem with 9 separate inputs is that the network won't implicitly recognize transformations of a given board. There's only 3 actual ways to play the first move in tic-tac-toe (corner, side, or center), but the network couldn't be trained on those 3 moves and adapt them to the transformed cases.

I haven't studied NNs in a while, so there may be a really obvious answer to this that I've forgotten, but how do you train the network for non-game-ending moves? Obviously, it's easy to qualify the success of a move if it causes the AI to win or lose the game, and then you can propagate that back through the network. But for all the moves that lead to that point, what do you do? Averaging the success of all possible subsequent moves seems too brute force...

[export]

I'm angry that we've had a C++ standard since 1998, and only two (to the best of my knowledge) compilers support the export keyword.  I keep coming up with grand template designs that end up getting burned because I can't have translation-unit specific stuff for my templates.  All those idiots who keep saying that export adds nothing to the language need to spend some time working in Ada so they can understand the things that can be done with template separation.

GCC's LTO project seems to provide much of the backend needed for an implementation of export, hopefully we'll see it soon.

Huh, I'm intrigued. I'd never even heard of the export keyword before, and after reading a little about it, I'm still not quite sure I understand what it does. It sounds like its only purpose is to allow us to move templated function definitions out of headers?

Maybe something like this? http://msdn.microsoft.com/en-us/library/system.drawing.text.privatefontcollection.addfontfile.aspx

Be careful distributing loose font files with your game, unless you're 100% sure it's legal (e.g., you made the font yourself). Fonts are usually not licensed for distribution, and you should find a different way to use it. At the very least, embed it in your .exe so it's harder to get at, but that's still legally murky.