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.

Resources: FlipCode & Game Engine Anatomy 101

Flipcode is a site that the CTO of Cyan, Inc. pointed me to years ago. I follow it regularly if for no other reason than to see the image of the day. http://www.flipcode.org

Flipcode pointed me to a series of articles from 2002 entitled "Game Engine Anatomy 101", starting at http://www.extremetech.com/article2/0,1558,594,00.asp.

I'll be looking into PopCap Games' freely-available game engine later.

...

In looking at PopCap's site, I discovered a new game that I liked well enough to buy: Heavy Weapon! This game is great. Pure mayhem!

Vyde is Born

Well this will be interesting. A blog about a video game -- designed, written, produced, and catered by me.

I'm keeping this blog as a log of my progress for two reasons:

1. So others who might be interested in learning about my progress can keep up on it, and maybe learn from it, and
2. To motivate myself.

So here's the setting:

Vyde is the name I've chosen for the game I'm making. The name has no special significance; it's pretty much a made-up word that I thought sounded like a place.

Vyde, as an idea, started back in college. I was a member of Georgia Tech's video game club, Entertainment Software Producers (ESP). Back then, I fancied myself a game designer rather than a game programmer, and came up with an idea for a 2D side-scrolling game involving a randomly generated, boundless map. The game was to serve as a research project, with the goal of answering a few different questions, but mainly this one:

What are the gameplay implications of a game whose playfield has no boundaries?

I've always, always been frustrated with artificial boundaries in games. Like that fence that encircles the first level of Diablo II: why can't you just hop the fence and keep going? Or the ocean in GTA: San Andreas: you've got a bloody plane, why can't you see what's on the other side?

Of course we know the answers to these questions -- the games have boundaries, artificial or otherwise, to accommodate things such as resource limitations and directed storylines. But I've always been a fan of sandbox games, and have felt a compulsion to blend sandbox games and directed action/adventure games. Imagine SimCity with "GTA mode".

So Vyde is a philosophical quest. Can such a game be made compelling and fun to play? What would keep a player coming back for more? Is such a game suited for a 2D world or a 3D world? What must the interface be like?

Now then. With the philosophical foundation in place, I've spent another part of my CPU time coming up with a theme. I want something that I can stick to for artistic guidance that keeps the game from being just a tech demo once it's actually buildable. So here's what I've come up with...

Vyde is a mining game. The player(s?) assumes the role of a miner(s?) in an underground environment. The player will have the ability to interact with the environment, which shall be dynamic in many ways, and the creatures that inhabit it, whose motivations are so far undefined. Elements of the world (geology, flora, and fauna) will have autonomous properties that exact change in the environment without player interaction, thereby keeping the game fluid -- ever changing, rarely static.

This description satisfies me in that it provides an interesting canvas with the following characteristics:

1. It lends plausibility to the concept of infinite space (a vast network of underground tunnels and cavers) without resorting to the tres chic outer-space.
2. As a starting point, constraints on the variety of elements of the world are easily chosen. That is, you've got a lot of room to brainstorm on elements like story, the environment, creatures, artistic styles, etc., without fear of becoming uninteresting. At the same time, you're not saying, for instance, "The game shall be set in space," which has absolutely no boundaries and way too much possibility, which to my mind stymies design by introducing too much "What if I included _____? That can happen in space," and thereby overloading my brain and making me want to go do something mindless, like play City of Heroes. :)
3. I've always been fascinated with mining, and environments that mimic it. Metroid is my favorite game of all time because of how I feel about the claustrophobic, alien nature of it. It's safe to say that Metroid shall be a major source of inspiration for this project.
4. The description (and any description like it) does not enforce a particular point-of-view (2D/3D) or interface approach. I want to keep implementation an unmade-decision at this point. Not enough design has happened yet. However, so far, all my thoughts on Vydehave led to a 2D side-scrolling mindset. A game that lends itself to a 2D, side-scrolling gameplay style serves as a good starting point for a hobby-level project. Ultimately, I want to concentrate more on gameplay theory as my exploratory domain rather than technology, as the latter is often dependent on the state-of-the-art. That, and I want to be able to play this thing quickly, and use the immersiveness of the work-in-progress to both reinforce the immersion and fuel brainstorming for additional features. I do not want to focus my initial efforts on building the next great 3D engine, or developing the next great geometry streaming technology. (I've even considered developing the prototype in Flash. More on that later.)
5. It mandates variety and an aspiration towards continuous evolution. (After all, this is gonna be a hobby.)

Now then, what I plan to include in this blog is whatever pops into my head during this adventure. Articles I've read, games I've played, ideas I've had (and ideas I've shelved), technologies I try, screenshots, links, code samples, and more. A veritable "whatever" of design history documentation.

I hope I enjoy doing this as much as you enjoy reading about it.