What to expect from a “3D” or game engine?

I was in a strange intersection in my game-creation tour. Having picked up a little bit of the basics of 3D programming from Allen Sherrod’s book, I realized that programming a whole “game engine” would be probably quite a bit of undertaking – at least for now.

I was a bit torn between different possibilities: whether to do “mindless” but sometimes so necessary experiments with routines here and there; testing OpenGL’s graphics primitives, perhaps just by rendering randomly created objects, rotated, panned, so on. Or, should I really get my hands on a game engine and learn at least one of them? Learning an engine could serve a double purpose: give me concrete skills, plus “teach” me what a game engine can, should and might contain.

I thus started searching for a ready-made engine, and of course: an open source one. Not that I couldn’t enjoy learning and exploring proprietary ones, but I really wanted to see the very core of a game engine, because after all, I am first and foremost a programmer.

It would have to be a specific kind, though; from practical limitations set by my oldish hardware, to a more personal bias of preferring Linux over Windows, not all engines would do.

The list of engines is quite large, indeed! With just googling around, or looking at a Wikipedia list of game engines, there certainly is plenty to choose from. That’s good. And it means a lot of work, also, if you want to empirically test out even every tenth engine.

I in fact tried Unreal engine 3 on a Windows 7 laptop and it choked completely – ugh! The mere download size of 1.9 gigabytes made me raise eyebrows, and I was quite right in my suspicions: the PC should be a real top notch, high-end one in order for it to smoothly run the engine. This is not to say that Unreal series of engines wouldn’t
be technically very good, they are – but they are not for the faint of hardware what comes to the developer side. You can check out the recommended specs on their site for further guidance.

I’d like to see a clean, small engine, with an API that is understandable and manageable. My first project focuses around Finnish single-man missions deep behind enemy lines; so I’d like a framework around that theme. Here’s a little appetite whetter:

Although recon missions were done sometimes in groups between two to a dozen or so during WW-II, in this game the player acts always alone.

The player carries a set of equipment in a backpack. Since the missions take anywhere from 2 to 14 (designated) days, and can realistically sometimes span a time frame of up to 21 days, one of the most critical part of the game is to choose equipment wisely. Ammunitions, dynamite, food, and medical supplies have to be balanced in order to enable a successful deployment.

The player looks at the gaming area from Top camera. Lights are depicted by time-of-day and the season (winter, spring, summer, autumn). These parameters are calculated realistically by known sunrise and sunset times. Light plays a great role in the game, both in aesthetic and tactical way: shadows and reflections of metal can reveal you or your enemy’s position and activities.