Thoughts on Game Engine Anatomy Parts I and II

Finished reading Game Engine Anatomy Parts I and II. Had these thoughts:

Do I want a 2D game in a 3D engine?

I think so. Or, rather, a 2D game that utilizes hardware acceleration. The vision I have for Vyde includes some sophisticated effects that I think would be best accomplished in a bona-fide 3D space, but a 2D view would make camera handling easier, and could have an impact on how I store the scene graph.

Some of the effects I'd eventually like to see:

• Real lighting w/ shadows that complement the dark mood of an underground tunnel system
• Physics-based particle effects for crumbing rock, cave-ins, or even ragdoll character animations.
• An environment similar to Diggles' (neat game I found in the bargain bin one day; suffers from terrible engine bugs)
• The ability to zoom in/out
• The ability to go into first-person view, ala Dungeon Keeper

You know, Diggles is worth talking about. This game is very close to what I envision Vyde to be. But I think Vyde would focus a little less on resource management and more on exploration. But the variety of gadgets and "rooms" available in Diggles is very inspiring. I've never tested to see how far out you can go in Diggles... for all I know it's boundless.

What do I know about picking an implementation?

I can program in any language, but I like some more than others. Similarly, I can eventually write any kind of engine, but as I mentioned in a previous post, I want to focus on experimenting with gameplay instead of hacking through technology. So things like Managed DirectX intrigue me. I wonder if a game like mine could be written in C#.NET? How would the .NET CLR affect the game's performance?

What about game assets?

I'm a 3D Studio + Photoshop guy by nature. But I don't have a functioning copy of either anymore. I'm moving into a new, better-paying job soon, so maybe by the time the serious art needs come around, I'll have those kinds of tools.

Source control?

Now might be the perfect time to try my hand at Subversion, recommended to me by my old college buddy Eric. I've been using CVS for a little less than 2 years now, and I think I'm getting tired of it. Don't really feel the need to invest in something like SourceSafe, though its asset management features may deserve further investigation.

Using an existing engine? Hm. I'm torn on this one. On one hand, I want to concentrate on gameplay, not technology. On the other, I always need an excuse to keep my programming skills up, and I'll admit I'm curious to see what the process of building an engine is like. But I don't feel like I'm quite ready for it yet. Still gonna take a look at PopCap's engine.

Modularity

If I go with building my own engine, how modular to I want to design it? Theoretically, I could really go nuts and build an engine whose 2D/3D renderers were interchangeable, but I think that's probably more trouble than it's worth. But in general, building an engine would definitely stretch my OOD muscles.

Another article to read: 3D Pipeline Tutorial

Sandboxing

How can I design, from scratch, an engine that is especially suited towards sandboxing gameplay features? Scripting comes to mind. Level editing in-game comes to mind, too. I remember the old DOS game Abuse. It had a really sophisticated scripting system and level editor built into the game, invokable with a menu command. That is, you could pause the game and begin editing the level right around the bullets and characters suspended in pause. Very cool. I'd like to be able to have some kind of in-game console or GUI instrumentation that would let me inspect things in the playfield and alter their properties. Be playing the game, pause and enter edit mode, right-click on a shooter to discover its fire rate, alter it, then resume playing and see the effect. An architecture that facilitates this would, to me, be worth its weight in gold. But it would demand a sophisticated GUI... hm.